Agile 2. Adrian Lander
Читать онлайн книгу.
an immensely better understanding of the product and how it needs to work. They become as insightful as the Product Owner, and they start to have their own innovative ideas—sometimes really fantastic ideas.
All too often Agile teams are not allowed to talk to actual users. They only talk to the Product Owner. The Agile Manifesto mentions the customer and the user, but not in the context of collaboration, and the reality of Agile development today is that development teams tend to operate apart from actual customers and real users.
This is a great dysfunction. Not only does it squander the creative ability of the technical side of the organization and convert them into an under-appreciated serfdom serving business stakeholders, but it isolates product marketing research and product vision into silos that the people creating the product have no view of—almost ensuring that the product will be suboptimal for its users.
Transformation Is a Journey, Not a Rollout
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.
The Individual Matters As Much As the Team
The team, the team, the team!
Agilists are obsessed with the team. The word team comes up in almost every sentence. What about the team members? People are individuals. Yes, the team matters, but so do individuals, and the importance of the individual seems to have been lost in the Agile community.
We find this ironic because the first value of the four values of the Agile Manifesto begins with “Individuals.” It does not begin with “Teams.”
Yet today, one never hears about the individual in Agile circles; it is always “the team.” This is also confounding because today's products usually cannot be built by a team; they require many teams. So really, people should talk about “the teams,” but they rarely do; it is always the team, singular, as if each team exists unto only itself.
There is a maxim in the Agile community: “autonomous self-organizing teams.” However, as we will see later in this book, there is rarely such a thing; more common is somewhat autonomous, somewhat self-organizing teams. So teams do not usually operate independently—independence is actually a worthy goal, but it is rarely achieved—and so a focus entirely on the team, singular, is not realistic.
The worse problem, though, is the loss of acknowledgment of individuality. The culture of the Agile community is so biased toward the team that being different from the team is seen as being a misfit. We have read blog posts in which experienced