Appearance
Applying agile to a DH project means working in short iterations, finishing a small usable result each cycle, and replanning based on what you learn — instead of committing to a fixed multi-year plan you cannot possibly get right at the start. Because DH work is exploratory and the sources keep surprising you, this iterative, feedback-driven approach fits far better than a rigid waterfall. You do not need Scrum or any heavy framework to benefit.
What does "agile" actually mean here?
Strip away the jargon and agile is three habits: build in small slices, get feedback early, and adapt the plan. Instead of designing the whole edition, database and website before producing anything, you ship a thin vertical slice — a handful of records, transcribed, encoded, and visible — then learn from it and decide what to do next.
The contrast with the traditional approach:
| Waterfall (big plan) | Agile (small slices) | |
|---|---|---|
| Planning | Everything up front | Just enough, then replan |
| First usable output | Near the end | End of cycle one |
| Response to surprises | Costly rework | Expected, absorbed |
| Risk | Concentrated at the end | Spread and reduced early |
Do I need Scrum, sprints and all the ceremony?
No. Full Scrum — sprints, story points, daily stand-ups, defined roles — is built for larger, dedicated software teams. Most DH projects are two or three people, often part-time. A lightweight Kanban approach captures the value with almost no overhead:
text
Backlog | In progress | Review | Done
---------------|---------------|---------------|---------------
Encode reg. C | Geocode reg. B| Transcribe A | Sample 5 pp
Add map layer | | | Project README
QA gazetteer | | |A board like this — on a wall, a whiteboard, or a tool like Trello or a GitHub Projects board — gives you visibility and prioritisation without rituals.
How do I run a small worked example?
Suppose you have 400 burial-register pages to transcribe, encode and map. Rather than building everything, take one slice:
- Iteration 1 (2 weeks): transcribe and encode 25 pages, publish them as a simple table, and put them in front of a domain colleague.
- Review: they notice place names are inconsistent. You add a normalisation step.
- Iteration 2: apply the new step, do the next 50 pages, add a basic map.
- Review: the map reveals a gap in the data. You reprioritise to fill it.
By cycle two you have a working, end-to-end pipeline and have already corrected two problems that a big-bang plan would have surfaced only at the end.
What is a minimum viable output?
The smallest result a real user can actually use. In DH that is usually a thin vertical slice through the whole workflow — 50 published records, not a half-finished database of thousands. The point is not the quantity; it is proving the entire pipeline works end to end, from source to published, documented output. Everything after that is repetition and refinement.
Does agile clash with fixed grant milestones?
It does not have to. Treat the funder's milestones as the outer frame and run iterations inside it. The grant says "a published dataset by month nine"; agile decides how you get there — which records first, which features to drop if you run short. Map a cluster of iterations to each milestone and report progress as completed slices.
Which agile practices are worth keeping in DH?
Keep the high-value, low-ceremony ones:
- Small vertical slices — finish something usable each cycle.
- A visible backlog — so priorities are explicit and changeable.
- Short review cycles with real stakeholders or users.
- Willingness to reprioritise when the sources surprise you.
Drop what does not fit a tiny part-time team: story points, velocity charts, and daily stand-ups are usually overkill.
Key Takeaways
- Agile means small slices, early feedback, and adapting the plan — ideal for exploratory DH work.
- You do not need Scrum; lightweight Kanban with short cycles is enough.
- Aim for a minimum viable output: a thin end-to-end slice that proves the pipeline works.
- Run one-to-three-week iterations with a review at the end of each.
- Keep grant milestones as the outer frame and iterate inside it.
- Keep the practices that add value; drop ceremony that a small part-time team cannot sustain.
Frequently Asked Questions
What does agile mean for a humanities project?
Agile means working in short iterations, shipping a small usable result each cycle, and adjusting based on what you learn — rather than planning every detail up front. For DH it suits exploratory, uncertain work well.
Do I need Scrum or a full framework to be agile?
No. Most DH teams are too small for full Scrum. A lightweight Kanban board with short cycles and a regular review captures the value without the ceremony of sprints, roles and rituals.
How long should a DH iteration be?
Usually one to three weeks. Short enough to keep feedback tight and replan often, long enough to finish something meaningful given that DH staff are frequently part-time on the project.
What is a minimum viable output in DH?
The smallest end-to-end result that someone can actually use — for example, 50 transcribed and published records rather than a half-built database of thousands. It proves the pipeline works.
Does agile clash with grant milestones?
Not if you map iterations to milestones. Keep the fixed deliverables a funder requires as the outer frame, and run iterations inside it to decide how you reach each milestone.
What agile practices help DH most?
Working in small vertical slices, a visible backlog, short review cycles with real users or stakeholders, and a willingness to reprioritise. Daily stand-ups and story points are usually overkill.