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

Responding to change over following a plan

Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.

Agile Manifesto Principle #2

Following from the Agile Manifesto value that is the title of this post, Principle #2 may be the most mis-interpreted and misunderstood principle among the set of twelve. Teams frequently behave as if this principle was prefaced with the word “always.”

Constantly shifting requirements leads to a frustrating and unsatisfying environment in which to work. It feeds burn-out and erodes morale. The satisfaction of a job well done depends on the opportunity to actually finish the job, no matter how small. Consider the effects on a finish carpenter who has just spent several days installing and trimming a full set of kitchen cabinets when the homeowner declares they want to change the kitchen design such that all those new cabinets will need to be ripped out and work begun on a new design. Or a film editor who has just worked 21 days straight to pare down an hour’s worth of video to fit into 7 minutes only to learn the scene has to be re-shot from scratch in order to match a change in the story line.

Of course, the second principle does not state we should “always welcome changing requirements.” Nor does anyone I know claim that it does. But that doesn’t stop people from behaving as if it did. The rationale offered for agreeing to change requests from the stakeholders may be “We’re an agile shop and agile welcomes changing requirements” when, in fact, the change was agreed to because the product owner didn’t challenge the value of the change or make clear the consequences to the stakeholders. Or the original design was, and remains, needlessly ambiguous. Or the stakeholders have changed without renegotiating the contract or working agreements. Or any number of reasons that are conveniently masked with “welcoming changing requirements.” At some point, welcoming changing requirements is about as attractive as welcoming a rabid dog into the house. This won’t end well.

So, what kind of change is the Agile Manifesto referring to? There are several key scenarios that embody the need for flexibility around requirements.

  • The change that results from periods of deliberate design, such as during design sprints.
  • The change that is driven by the lessons learned from exploration and prototyping. If it is understood that the work being “completed” is for the purposes of testing a hypothesis and the expectation is that the work will most likely be thrown away, there can still be a great deal of satisfaction derived from the effort as the actual deliverable wasn’t working software, but the lessons from the experiment (usually in the form of a wireframe or prototype.)

So what is it that locks out the option for additional change? It’s a simple event, really. A decision is made.

Each of these scenarios where adapting to lessons and discovery is essential nonetheless end in a decision, a leverage point from which progress can be made toward a final deliverable. Each of these decisions can themselves form the basis of a series of experiments which, depending on the eventual outcome, may change.  Often, a single decision point may look good but when several decisions are evaluated together they may suggest a new direction and therefore impact the requirements. If the cumulative insight from a series of decisions results in the need to change direction, that shift is usually more substantial and on the scale of a project plan pivot rather than a simple response to a single change in a single requirement. The need to pivot cannot reliably be revealed if the underlying decisions do not coalesce into some sort of stable understanding of the emerging design.

Changing requirements cannot go on indefinitely or a final product will never be delivered. Accepting change for the sake of change is what gets teams into trouble.

Much like the forces on evolution, there will always be some external force that seeks to change the project requirements so that the delivered product can be stronger, faster, better, taller, smarter, etc.  This must be countered by clear definitions of “minimum viable” and “good enough for now” relative to what the customer is expecting.

In addition, product owners would serve their teams well by vigorously challenging any proposed changes to the requirements.

  • What is the source of the change?
  • Is it random change or triggered by some agent that does not announce its arrival ahead of time?
  • Was the change in requirements a surprise? If so, why was it a surprise?
  • Will this (or something like it) happen again? With what frequency? At what probability?

Photo by juan pablo rodriguez on Unsplash

The Novice and the Master

When coaching people in a new skill, there are several things I watch for in their development from novice to master. Insuring they have the requisite foundational knowledge can be considered a given. Tightly coupled with this is a demonstration of working from first principles. If neither of these are in place than it can be said the learner has yet to begin their journey toward mastery.

Beyond the basics, I look for signs of what’s happening behind the curtain. I watch for how they respond to challenges and conflict. And how they work through difficult decisions.

How a difficult decision is handled is an important indicator for whether an individual is a novice, a master, or somewhere in between. Where novices struggle trying to figure out what to do, masters resolve quickly. Certainly a common issue in play would be doubts about the outcome of any particular action and the probability of recovering from any associated consequences. It is also possible that the issue – either instead of or in addition to – is that the novice has become stuck at a decision node that has an uncomfortable degree of uncertainty associated with it on the front end and they are unskilled at thinking through the “disjunction,” as Eldar Shafir1 calls situations like this.

With the former issue, the tack taken by the novice is to plan out as many details as possible so as to account for every contingency and squeeze out as much doubt as possible regarding the outcome. In the later, the novice simply doesn’t have the information needed to make the decision and lacks the skill to play out n number of scenarios leading up to the decision node such that they can then evaluate subsequent paths.

An example given by Shafir has to do with a student that has just taken a rather important exam (say, for graduate school) but doesn’t yet know the results. If they’ve passed, they move forward. If they’ve failed, they have to retake the exam in a couple of months after the end-of-year holidays. On the same day, they are presented with a incredibly sweet deal for a 5-day Hawaiian vacation over the end-of-year holidays. The vacation deal is good for today and grades won’t be released until tomorrow. What does the student do?

Notice that the outcome of the exam will be known long before the vacation begins. Thus, the uncertainty characterizes the present, disjunctive situation, not the eventual vacation. Additional, related versions were presented in which subjects were to assume that they had passed the exam, or that they had failed, before they had to decide about the vacation. We discovered that many subjects who would have bought the vacation to Hawaii if they were to pass the exam and if they were to fail, chose not to buy the vacation when the exam’s outcome was not known. The data show that more than half of the students chose the vacation package when they knew that they passed the exam and an even larger percentage chose the vacation when they knew they they failed. However, when they did not know whether they had passed or failed, less than one-third of the students chose the vacation and the majority (61%) were willing to pay $5 to postpone the decision until the following day, when the results of the exam would be known.

A solution to this simple example of disjunction (Shafir provides many other examples) is for the student to ask themselves two questions:

  1. “Would I take this vacation deal if I passed?”
  2. “Would I take this vacation deal if I failed?”

If the answer is “Yes” to both or “No” to both, then the decision about the vacation deal is easy. If the answer is still mixed, then I suppose the student will have to dig a bit deeper to get at a level of leading criteria that will shake out the decision. (When I was a student, I would have had to consult my financial adviser – a.k.a. my wallet – first. The answer to everything beyond beer was “NO!”) In the experiment described above where students remained uninformed as to the outcome of the exam, they didn’t have a skill or strategy for resolving the uncertainty and were even willing to pay to make it go away!

Shafir’s work was instrumental in helping me tap into new skills for developing mastery in several areas of interest (specifically, martial arts and woodworking). Disjunction has a distinct visceral sensation for me. It gives me pause to ask questions not about potential future events, but about past events leading up to the present. I find I’m usually missing something about the history of events that either help sort out the indecision once known or cause me to think through better scenarios on emerging events that will influence the decision I’m trying to make.

References

1 Eldar Shafir’s chapter in “Cognition on Cognition” titled “Uncertainty and the difficulty of thinking through disjunctions”

Photo by Motoki Tonn on Unsplash