Improving The Odds of Success For Any Goal With A Definition of Done
In 1626 the King of Sweden, Gustavus Adolphus, began work on what he envisioned would be the most powerful battleship ever to set sail - the Vasa. By all accounts, Gustavus was a brilliant military commander. Over the next two years the King repeatedly alter specifications such that massive amounts of rework were required. The mid-project inclusion of non-essential work - such as adding close to 500 elaborately decorated sculptures - added to the delay. The array of canon on the ship grew both in size and number. The result was an untested design that proved unstable when the ship was launched with great fanfare from the shipyard in Stockholm. Before King and country, the Vasa hadn't made it out of the harbor before a strong breeze tipped the ship so far that water began entering the canon portals and sank the ship.
The lessons from this historical event about meddling managers embedded in a hierarchical system of status and nobility are obvious. This practice is still very much endemic in legacy corporations and MBA programs continue to crank out a plethora of future executives equipped to carry on the tradition. Thousands of executive and Agile coaches make a well deserved living working to remediate the problem.
A lesser but more actionable lesson has to do with Gustavus' approach to project management. As brilliant as he was on the battlefield, this skill did not translate to the material production field where events move toward completion over months and years rather than hours and days.
There is a reason Agile project management leverages frameworks rather than highly structured protocols for getting work done. It recognizes that the world can be a messy place. Particularly when it requires human beings to complete work. With so many variables in play - emotions, physical health, competing priorities around family, pandemics, etc. - it's amazing we get as much done as we do. Frameworks give us the flexibility to adjust and adapt to the situation.
There is a paradox embedded within Agile frameworks. Flexibility and adaptability are important, but there are also elements of the frameworks that are important to get right. The most important is to have a healthy product backlog that is vigorously maintained and defended by the product owner. If this isn't in place, everything else become a major battle to implement. Stories bounce across multiple sprints, errors and rework grow exponentially and stakeholders readily jump to uncomfortable conclusions about progress.
Another important element is what's typically called the "definition of done." If the product owner or Agile team member can't clearly and concisely describe what "done" looks like, you end up with some version of this conversation.
Product Owner: "What do you mean you're still working on that story. I closed it last sprint because you said it was 'done!'"
Agile Team Member: "Well, uh, yeah. It was done. But it wasn't done done. There were still a couple of things I wanted to finish."
If your definition of done is some version of "I'll know it when I see it," there is a good chance you're about to attempt the launch your very own Vasa.
If you'd rather not do that, here are a few things to do instead:
If you are involved during the design phase of the project, repeatedly run a thought experiment where you begin with the end in mind. It's that vision statement thingy.
Work to establish a clear understanding of what "good enough for now" means. And when you've done that, keep checking in with your team to evaluate if anything has changed to cloud that understanding.
Use minimum viable product definitions. Add to this the idea of minimum viable actions. As important as it is to know, as best you can, what done looks like, you need a sequence of actions that will get you there. What are those? In what order can they most effectively be sequenced? How jis what you're learning along the way changing the path to "done?"
Finally, keep your product backlog healthy and strong. Without exception, continuously refine the backlog with stakeholders and the development team so that it is an accurate reflection of progress and future work.
Photo by Jamie Morrison on Unsplash