Don't buy instruction manuals when you really want outcomes

There’s a fundamental disconnect between people selling agile training and the people buying it. For those selling, the training is the end in and of itself - they are delivering the service they promised you. For the people buying, the training is a means to an end, namely a more effective organization. If the training vendor successfully teaches your organization their version of agile, but your effectiveness fails to improve, you probably aren’t happy, even though the vendor did as promised.

What you are interested in is an outcome. What they are selling is an instruction manual.

For simple, repeatable processes, memorizing the instruction manual is sufficient. If you learn the steps required to change a tire, balance a checkbook, or assemble flat pack furniture, then you can likely repeat them over and over to great success. The key here is that for processes like these, the outcome is directly determined by following the instructions, no matter how complex the instructions.

The process of making software, however, is not that simple. We aren’t interested in following a recipe, we want to learn how to cook.

Nevertheless, instruction manuals are a lot easier to sell, especially given how daunting real mastery seems. In fact, the complexity of the real process (and the instructions), makes the manual even easier to sell, because negative outcomes leave you assuming that you followed the instructions incorrectly, rather than feeling like the manual itself must be flawed. You’ll tell your friends that the instructions helped some, but your organization must have been too broken to fully benefit, for example. The vendor sold you a fantastic shovel, so it must be your fault you failed to find gold.

This doesn’t mean that manuals are useless, however. There are reasonable parallels between learning about agile and things like learning to cook, learning to compose music, or even mastering martial arts. A common pedagogical technique for learning to compose music is transcribing and analyzing the work of others. The transcription process itself is relatively mechanical, but over time you begin to see commonalities and themes and can even begin inferring ‘rules’. Many great soloists and improvisational players have started by learning the solos of others, decomposing them and adding snippets into their mental tool chest, and then synthesizing everything they’ve learned in interesting and novel ways. You can think about recipes (for cooking) and kata (in martial arts) as similar ideas.

In all these examples, learning the sequence of steps by rote is just a training technique to reach the real goal. Learning the steps without understanding how mastery advances your overall goal will leave you only able to play someone else’s song or make someone else’s cake.

Once you’re aware of this disconnect between what your ultimate goal is and what you’re buying (or practicing), you’ll see this in other places. In the software world, we see this with specialist agencies. Making software requires writing code, but also knowing what to build in the first place and how it should work from a user perspective. When you undertake a software project, your ultimate goal is putting software into production that delivers business value. That’s the outcome. Getting some comps designed or some user research performed are merely steps along the way. Design artifacts that you can’t easily build or research that isn’t actionable may satisfy the contractual terms you agreed to with an agency, but they don’t help you achieve your desired outcome.

This realization suggests a path forward. Where possible, seek to align incentives. If you’re engaging an external partner, try to buy outcomes instead of instruction manuals. Be clear with yourself about what you’re actually buying. Instruction manual vendors like to imply they are selling outcomes. If you opt to pursue agile training, don’t lose sight of the most important part of agile. Prepackaged processes must be seen as a starting point born of the experiences and contexts of people and organizations other than your own. Treat them as such and expect to change them after you’ve thought deeply and intentionally about how they may or may not be working within your organization.