Читать книгу Agile 2 - Adrian Lander - Страница 23

The traditional approach that organizations use for any large change is to create a big plan. Such a plan has tasks and milestone dates. The theory is that if you perform the tasks and they are done on time, then you will have completed the initiative. You will have “rolled out” the change.

When senior executives meet with their staff about the change initiative, they review a chart showing the status of each task, indicating whether they are on time, and the spend rate. If something slips, it is shown in red. A red task invites questions from the executive. Lots of red tasks indicate that the initiative is not going well—something that is not good for the career of the person leading the initiative. One wants to have all tasks shown in green.

There are several problems with this approach. One is that it discourages honesty. No one wants to report tasks that are in the red, so the tendency is to cover up problems. Scott Ambler has referred to this as green shifting. Such a cover-up is rationalized by the idea that “it will all work out,” and so the progress of each individual task will not matter in the end, as long as the overall initiative succeeds. However, this means that problems are disguised, and so honest discussion—discussion that might help to ensure success—does not occur.

The ability to obtain people's honest beliefs and ideas is essential. You might think that things are fine, but they are not fine at all; and if people are not willing to be frank, they will not tell you what they think that you should be doing instead. As Jack Welch said in his book Winning,

“Lack of candor basically blocks smart ideas, fast action, and good people contributing all the stuff they've got.”7

Another problem is the assumption that the initiative is composed of tasks. If one is performing a largely repeatable process, such as building a new power plant using a design that has been used 50 times before, then one can indeed create a master task plan, and it will be helpful for managing the work. On the other hand, if the initiative is highly unique, then one cannot define all the tasks up front.

Another reason why a task model is not appropriate for a unique initiative is that for something unique, a large portion of the work consists of learning and trying things. A learning process is not well-defined as a task: it is ongoing. Learning occurs throughout the entire initiative, so one cannot, for example, define a task as “Learn how to perform deployment.” This is because while one might learn how to perform a simple deployment, as the initiative progresses, deployments might become more complex, and one might learn better ways and continue to refine the approach. Thus, the learning process is continuous and is never finished.

Agile transformations are extremely driven by learning. This is because most of Agile is not about what you do—it is about how you do it. Agile advocates judgment, instead of prescribed steps. To learn judgment, you must do something again and again over time. That kind of learning is not neatly confined to a task, yet the transformation is not complete until learning has completed—which is, well, never. That is why people say that a transformation is not a destination; it is a journey. You never get there, but you get better and better. Your metrics become better and better. Along the way, you learn that some approaches are not working out, and you change direction.

Some tasks definitely can be defined. But a task model is the wrong approach for planning the transformation and for measuring progress. Instead, what works better is to have various ongoing and intersecting initiatives for problem identification, for upskilling, for collaborating about approaches, for creating and refining metrics, and for instituting and refining various practices.

Unfortunately, there is information on this topic that is easily misunderstood. The person who first connected the dots about DevOps, Jez Humble, gave some brilliant talks during the decade of the 2000s and came out with his groundbreaking book Continuous Delivery (co-authored with Dave Farley) in 2011. But in 2018 he co-authored (with others) a book called Accelerate, which is a great book, based on a collaboration with Dr. Nicole Forsgren. The book addressed the problem of transformation: how to help an organization progress from a current state to one that uses DevOps methods. All good so far.

Dr. Forsgren's work is based on a capability model, and if you read the book, the capabilities are intelligently defined. In fact, they are what Agilists would call practices: they are about how you do things. But Dr. Forsgren calls them capabilities and, by doing so, implicitly (perhaps unintentionally) links them to capability models that are common for old-style IT change initiatives.

These old-style change initiatives were invariably task-centric, and the capabilities usually consisted of the “rollout” of new tools.

That is not what Dr. Forsgren's work is about. It is really good work—perhaps great work—and the book Accelerate is a great book. But the use of the term capability model has the potential to make executives think, “Okay, I know capability models. I'll just create one, and we're done.” And what they often create—we know, because we have seen this happen first-hand—is an old-style capability model that defines a set of DevOps tools, as well as nonsensical capabilities such as testing. We say nonsensical because testing is 90% of DevOps, and what matters is not that you have a testing capability but that you are doing it the right way.

Our point is, don't treat transformation as a rollout or as a process that you can define ahead of time, like a manufacturing process. And don't use a capability model unless you carefully read Accelerate and define your capabilities their way.