One of the seven principles behind the Disciplined Agile (DA) framework is Choice is Good. Let’s assume for a minute that your organization has multiple teams working in a range of situations, which in fact is the norm for all but the smallest of companies. How do you define a process that applies to each and every situation that covers the range of issues faced by each team? How do you keep it up to date as each team learns and evolves their approach? The answer is that you can’t, documenting such a process is exponentially expensive. But does that mean you need to inflict the same, prescriptive process on everyone? When you do that you’ll inflict process dissonance on your teams, decreasing their ability to be effective and increasing the chance that they invest resources in making it look as if they’re following the process when in reality they’re not. Or, does this mean that you just have a “process free-for-all” and tell all your teams to figure it out on their own? Although this can work it tends to be very expensive and time consuming in practice – even with coaching each team is forced to invent or discover the practices and strategies that have been around for years, sometimes decades. Luckily, the Disciplined Agile framework provides a better way.
Different contexts require different strategies – teams need to be able to own their own process and to experiment to discover what works in practice for them given the situation that they face. This is why the DA framework presents people with choices through the application of process goal diagrams, see the figure below for an example of options for addressing changing stakeholder needs throughout solution delivery. The idea is to make important decision points explicit, such as when to accept changes, and then present teams with their options and the tradeoffs surrounding those options. This enables teams to make better process choices given the situation that they face. To make these choices, teams need to know: what each option is, the tradeoffs associated with each one, and in what situations the option is and isn’t applicable. The DA framework takes a similar, goal/choice-driven approach to IT process areas such as Data Management and Reuse Engineering as well as enterprise process areas such as Enterprise Architecture and People Management.
Figure. The goal diagram for Address Changing Stakeholder needs.
This choice-driven strategy is a middle way. At one extreme you have prescriptive methods, which have their place, such as Scrum and SAFe which tell you the one way to do things. Regardless of what the detractors of these methods will tell you these prescriptive strategies do in fact work quite well in some situations, and as long as you find yourself in that situation they’ll work well for you. However, if you’re not in the situation where a prescriptive method fits then it will likely do more harm than good. At the other extreme are experimental methods such as Spotify that tell you to experiment and learn as you go. This works well in practice but can be very expensive and time consuming and can lead to significant inconsistencies between teams which hampers your overall organizational process. Spotify had the luxury of evolving their process within the context of a product company, common architecture, no technical debt, and a culture that they could grow rather than change. The DA framework sits between these two extremes – by taking this process goal driven approach it provides process commonality between teams that is required at the organizational level yet provides teams with the flexibility required to tailor and evolve their internal processes to address the context of the situation that they face. Teams can choose from known strategies the likely options to then experiment with, increasing the chance that they find something that works for them in practice. At a minimum, it at least makes it clear that they have choices, that there is more than the one way described by the prescriptive methods.
There is a catchy phrase in the agile world called “fail fast” or better yet “learn fast.” As described earlier leadership should encourage experimentation early in the interest of learning and improving as quickly as possible. However, we would suggest that by referencing the proven strategies in Disciplined Agile you will make better choices for your context, speeding up the learning process and failing less. Better choices lead to better outcomes, earlier.
This article is excerpted from Chapter 2 of the book An Executive’s Guide to Disciplined Agile: Winning the Race to Business Agility.