Interesting take on "definition of done"

This HBR article takes on software development from the perspective of the business's desired outcomes and "Definition of Done". The business does not want a software system. The business wants an outcome that the system is intended to provide: improved branding, more efficient or consistent internal workflows, better customer service. Therefore, the business need is not necessarily met when the system is in production.

The article suggests current* military managerial thinking as an antidote. The military no longer mandates a command-and-control management style. Instead, they've developed a system of leadership called mission command. The article shows its three primary principles: command as little as is necessary and only plan for foreseeable circumstances; communicate as much higher purpose as possible; delegate authority within reasonable bounds to address unexpected events. This leadership style has been shown to be more effective during the chaos of military operations.

This is clearly applicable to scrum and the definition of done. While the scrum team does not control the business outcomes, the team and the product owner should keep the actual business need in mind. The business should consider adopting the principles of mission command.

But we technologists have to help them trust us.

Stakeholders have been conditioned by technologists to think of software in terms of requirements. I can't stress enough that this is our fault, as technologists. "Customers don’t want a quarter-inch drill. They want a quarter-inch hole." But, in the past, we insulated ourselves from the business's needs by setting up a requirements wall. In effect, we said, "Our job is so difficult that you must tell us exactly what you need our systems to do. Then, and only then, can we scurry off behind our door and concoct our magic. While we're doing that, you can wait here. Oh, and you can't change anything while we're gone." Now they think that this is the right way to work with us. They think that, in order to get their quarter-inch hole, they have to come up with the idea of a drill and explain to us how to build it.

So, we need to let them understand that we have figured out how to do what we do. "It is not as hard as it used to be (or, "We have actually learned how to do it", depending on your level of humility) so we can be more flexible. Help us understand your desired outcome and we'll work toward it incrementally. We don't entirely understand how a new system will address the business need, but we're willing to work with you to learn."

In this way, we can become a valuable business partner. We can bring our problem-solving skills into play, rather than responding with the technical version of "Do you want fries with that?". As the article suggests, we can begin asking good questions: "Why do you want a system?" "How will you measure whether the system we build addresses the business need?" "What business outcome are you trying to achieve?" Then we can use our tools to begin delivering those results more quickly. Also, we can help the business understand that we want to help with the business's outcomes, not just put some system "in production" that we claim meets the requirements they gave us.

Over time, we can convince the business that we are responsible enough to deal with mission command leadership. We understand that they just want a quarter-inch hole and don't really care how they get it. They can give us overall objectives and trust us to do our best to deliver a solid response to those needs. We can be flexible in the face of change, so they can stop worrying about the precision of their requirements statements and talk to us about the business goals. We can get some beta solution up and running quickly and then fine tune it to meet the business's goals.

* I can't resist noting that most people have an outdated view of management that is derived from an outdated model of military command-and-control. Modern military leadership thinking is very strong. Most practicing managers should study it and update their mental models of leadership. Think about the task the military has: take a random group of people, turn them into a team, and train some from within the group to be leaders. The Marines don't have a different hiring process for privates than for corporals and sergeants. They identify and train their leaders from within a fairly random group of recruits. As a manager, do you think your hiring and training process is up to that task?

If the plan doesn’t work, change the plan but never the goal. 4 ways to attract and retain skilled software engineers