Researcher Lauren Gawne has just completed a linguistics PhD thesis. She is not necessarily a technical person, yet has embraced the technologies of the NeCTAR cloud and by doing so, says it has created many online benefits, cost savings, efficiencies and collaborations. “I can now search texts much quicker and modify them to suit my purposes." Lauren is encouraging other researchers. "Reach out...there is such great infrastructure...try something new and do not be afraid.”
You are here
Agile Project Management and Procedural Literacy
I recently participated in a small-group discussion at THATCamp Brisbane that dealt with the topic of Tech Project Metaphors. The session was led by Sarah Smith who has written an extended blog post on the topic. Our small group comprised of software engineers, project managers and one scholarly editor, me.
As a scholar in the humanities, I have significant experience in textual scholarship, scholarly editing and book history, and, as a project manager, I have some experience with software development projects. I don’t know how to code, but I have developed a strong appreciation for the poetics of code and I deeply admire the skills and thinking that go into writing code. These are not qualities that humanities scholars commonly possess. Despite the emergence of digital humanities in recent years, a lingering “two culture” attitude inserts a significant barrier between the humanities and computer science.
The discussion about metaphors in tech projects intrigued me because it stressed the importance of effective communication in any enterprise, but it also provided a point of engagement where software engineers, project managers and scholars looked each other in the eye and talked about the problems they face in getting jobs done. The metaphor of the ship attracted most attention on the day, perhaps because the discussion of captains, steering, engineers and shipwrecks provided a fairly accurate depiction of past experiences within the group. Any project (technical or otherwise) can be seen as a journey with a departure point, a destination, and a mode of transport that is prepared, maintained, and steered by a crew. But the success or failure of the journey relies on the cultural dynamics of the crew and an ability to effectively communicate specialist knowledge when strategic decisions have to be made.
If the metaphorical journey is a finite, state-funded, digital humanities project that includes software engineers, project managers, and scholars, then effective communication to facilitate positive decision-making is essential to production. For most projects of this description, no single person possesses all the knowledge required to reach this destination. Some people might be seen as captains from a distance, but avoiding icebergs will require knowledge beyond their reach.
In a divided culture, the activities of those on the other side of the chasm are frequently veiled by prejudices inherited from the past. Communication between groups is subsequently conducted through those veils with little understanding of the complexity, knowledge and skills that lie on the other side. Overcoming the negative outcomes of such a situation can be achieved by pursuing “procedural literacy”, a term that AustESE Project Manager Wilfred Brimblecombe recently pointed out to me. In a digital humanities project, that does not mean that the scholars necessarily need to learn how to code, or that software engineers necessarily need to become experts in literary studies or history. But it does mean that a significant effort must be devoted to understanding the points of intersection that inform the writing of code and the writing of scholarship.
The AustESE Project draws on the expertise of members of the steering committee to determine the processes that inform the writing of scholarship and the expertise of its technical advisers and software engineers to determine the processes that inform the writing of code. Following an agile method of project management, the points where these processes intersect are recorded in a growing list of user stories that will be used to guide software development, identify hazards that need to be avoided, and provide a flexible course that responds to the needs of the scholars, the needs of the software engineers, and the needs of the software that is emerging.
In addition to the creation of user stories, the project team will also draw on methods from fields that go by the name of interaction design, user experience design and human computer interaction. For this particular journey the AustESE Project team aims to leave a project map that outlines the architecture and the meaning of the AustESE Workbench in ways that can be followed by experts and novices from both humanities and technology backgrounds. We’ll post samples of this work in the near future. But, for now, look to The AustESE Project page for an idea of our destination.