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 Agile coaches say that if someone works differently than others on the team, then the team can do without them.
The team ethos is so extreme that it is sometimes compared to a communistic view; the individual is entirely subordinated. Agile coaches discourage any kind of individual recognition; only a team should be recognized for its success. Different levels of career experience are generally not seen as significant, despite that experience does make a world of difference, which we will discuss later. The egalitarian view that anyone can work on anything permeates Agile culture, yet the reality is usually very different.
People are individuals, they have careers, and they have financial pressures and personal needs. They want to advance in their careers, so the idea that everyone is equal translates into no one can advance: if you are on a team, you will always be on a team, and you will never progress in your career. Your income will never increase, because the value of your experience will not be acknowledged. When you become expert in working on certain things, the value of that will not be recognized because, according to Agile theory, anyone can work on anything.
Fortunately, real companies do not usually operate this way. Most real companies have pay grades and career levels. But the Agile community is a parallel universe. Levels and individual differences do not fit the Agile narrative, so there is no framework for discussing it in an Agile context.
Teams matter. Teams are powerful. Teams are a valid construct for developing software. Extremes are what are bad. The extreme idea that only a team matters is not realistic and is unfair. The extreme idea that no one can advance is unfair. The extreme idea that anyone can work on anything has the noble goal of empowerment and opportunity for all, but by itself it is extreme and must be balanced with the reality that there are experts too—more on that later.
Culture: Individual vs. the Collective
There is a cultural struggle in human societies pertaining to focus on the individual versus the group—the collective. It might stem from a difference of values, in terms of whether a culture generally prioritizes equality over individual liberty (freedom) or individual liberty over equality.
During the mid-1900s, Jean-Paul Sartre and Albert Camus were fast friends. Both were socialists, as were most people among the intellectual community at that time in France. However, over time the two philosophers realized that they disagreed at a fundamental level: while both valued equality and liberty, Camus found that he valued liberty more than equality, while Sartre realized that he valued equality more than liberty.
The
