Agile done, done done, or pivot?
If Agile calls for constant iteration and improvement, how can Agile developers ever be “done” with anything? In our new ebook, Contested Development, Cameron Deatsch from Atlassian tells a story about that:
“My favorite Agile quote of all time comes from a banking executive. During a visit with Atlassian, he said, ‘So, this came up recently where I was told something was done, I told the rest of the leadership team, but it wasn’t done done. It was Agile done. How do I know what’s done done, or done?’”
Software, unlike homemade cookies, college degrees, and life, is never finished. For the banking executive, “done done” meant software ready for the public and an applause from fellow executives.
Cameron’s story raises a question: If you’re never Agile done, but you’ve been iterating in the wrong (i.e. unprofitable) direction, when do you stop?
If you iterate enough, hopefully you’ll do something right (i.e. profitable). But that’s not guaranteed. Some companies iterate right into bankruptcy, fraud, or embarrassing TechCrunch articles. Others “pivot,” which is Silicon Valley for “change your mind.”
The difference between iterating and pivoting is akin to the difference between sleeping and passing out. One is a choice, and one doesn’t feel like a choice. Iteration is progress. Pivoting feels like defeat. That difference convinces software developers to keep iterating when pivoting would be wiser.
After enough Agile dones, either you reach done done or the moment you should pivot. You likely believe that done done is around the corner, even if it isn’t. How, then, will you recognize when it’s time to pivot?
David Hussman, founder of the Agile coaching group DevJam, gives us a clue in Contested Development. He says, “Sometimes I ask people, ‘How do you measure how wrong you are?’ Too many still stare at me with this glazed look in their eyes. If no one has asked you that, you might be the proverbial frog in a pot. If you assume your ideas and product features are right, you are stuck in the past.”
The lesson is that done done is a dangerous goal without checkpoints. People hike Mt. Everest in stages, from camp to camp. At each one they decide, “Should we keep going? We each paid $65,000 for this…” They consider the weather, the health of the group, and reports from other expeditions. They decide whether to continue (Agile done), summit (done done), or turn around (pivot).
DevOps is a way to measure how wrong we are and establish checkpoints. It demands self-critique, which is a stoic commitment to weigh facts above aspirations and egos. Releasing software more often isn’t merely about getting a product to market first. It’s about questioning why we should create this product in the first place. Summiting Everest isn’t worth much if it kills you. Likewise, there are no bonus points for a done done that dies.
