In a recent post, I talked about the value of playing a game about Agile portfolio management. The game showed how, over time, stable Agile teams are more productive than ad hoc teams of even the highest performers. As a result, Agile turns on its head the way many people look at portfolio management: rather than feeding teams to projects, portfolio management should feed projects to teams.
This example shows one of the many virtues of serious games, their ability to help us make sense of important principles about the operation of systems. Our brains struggle with systems thinking, so anything that can help us move beyond our cognitive limitations is a good thing.
Some aspects of Agile are easier to understand than others. Someone knew to Agile usually doesn’t struggle with ideas like short, regular sprints or user stories. The same person usually takes a lot longer to appreciate the importance of a strict adherence to “done” criteria.
The high cost of being sloppy about done criteria is harder to see because it doesn’t manifest itself immediately. Over the course of multiple sprints, all those wafer-thin details add up, however. The pernicious effects of not being done are not all immediately obvious. While you might anticipate problems convincing the Ops people to put code into production, if you haven’t completed all the testing you originally had promised, you might not anticipate how laziness about being Done with a capital “D” wrecks planning. If we have a hundred details from previous sprints still dangling, how do we know what our capacity for this sprint really is?
The importance of done, therefore, depends on understanding how the team operates as a system. Consequences take time to fully play out. The interaction between moving parts of the system, such as the team’s technical debt and its ability to plan, are complex and often unknown. Positive and negative feedback loops create surprising results: I’ve seen teams fall victim to a technical debt/bad planning death spiral that accelerated faster than anyone ever expected.
I can preach the gospel of “done” to an Agile neophyte, quickly adding, “The importance of this discipline isn’t obvious to you now, but you’ll grow to appreciate it.” I could elaborate on the challenges of systems thinking, which is necessary to understand the importance of done, and even recommend a good book on the subject (for instance, Dietrich Dorner’s The Logic Of Failure). I’ll then cross my fingers and hope that the other person takes the time to read the book, and then makes the connection to the software development team as a system prone to breaking down from technical debt.
Alternately, I can say, “Let’s sit down for 30 minutes, and I’ll show you the importance of done criteria through a simple game designed for that purpose.” There are plenty of other Agile disciplines that depend on systems thinking to understand and appreciate, and they’re worthy candidates to teach through games.