One of the regular questions I ask, when requested to support an Agile transition, is “Why do you want to become Agile?” This may sound like a silly question; after all, we have laid out the benefits and liabilities of an Agile transition for nearly a decade in these Advisors. Well, the question is not, “Why should one become Agile?” but rather, “Why do you want to become Agile?”
Many organizations have started a transition initiative just because it is hip today to do Scrum or another Agile approach. Of course, we want faster and better and cheaper. The goals and objectives of the transition are often quite fuzzy and, even worse, not aligned within management. So, one manager might tell you how important the direct customer contact is for their business, while a colleague explains convincingly that time-to-market is the primary focus.
A full-blown Agile transition can easily address both of these objectives, but during the process, this lack of alignment can kill the whole transition. One of the early warning signs that you're heading down a dangerous path are dogmatic methodology discussions in upper management levels like the following:
“We must have a single product owner!”
“No, we cannot have a single product owner because our customers demand X!”
“But Scrum says …!”
If you hear discussions like this at the executive level, you know you’re in deep trouble.
Compromises are inevitable in larger transitions. After all, you’re doing an incremental journey. To figure out which of the compromises are pragmatic steps and which of them are simply in the wrong direction, you need a clear picture of the business goals behind the Agile transition. If the business goal is to reduce customer dissatisfaction because of poor quality, you’d better be quite rigorous when it comes to Agile engineering practices (AEP) and test automation while you can wait for the increased transparency to do its work on the interface to marketing. If your business goal is time-to-market, you may want to start with setting up an end-to-end service delivery Kanban system to understand where your most effective levers are and suggest AEP when you have reason to believe that poor quality is a major reason for delay in your value chain. And if product consistency and user experience are you major objectives, you’d better be pretty dogmatic about the single product owner. Not (only) because Scrum says so, but because there is a good reason for this rule in Scrum and this reason applies to your context.
If you have an aligned understanding of the business objectives behind the Agile transition, you also have natural success criteria and you can “talk business” to your managers. However, most business goals are rarely quick wins in an Agile transition. AEP need a lot of investment until they take effect and you may have to establish stable collocated teams first, to have at least the entities you can train and coach. Therefore, once you have selected a strategy to fulfill the objectives, you may want to come up with a set of “capabilities” the organization needs to develop during the transition. For example you could start with “being able to coach stable teams,” then “provide transparency” (this is a good point to start a Scrum introduction!), “reliable delivery on cadence” (the teams need to master Scrum to a certain extent to get here), “empirical planning” (management has to understand how Agile planning works and how to use it), and finally, “improved market agility.” This sets expectations for all management levels and provides an alignment on how to measure progress. It also avoids a lot of fruitless methodology discussions.
