Agile 2. Adrian Lander
Читать онлайн книгу.
Then he said, “A smattering, but actually very much a minority … and that's actually quite tragic.”14
Agile coaches and Scrum Masters focused on the nontechnical practices as if they were the be-all and end-all of software development, ignoring critical things such as test coverage, code branching, integration testing, issue management, and all the critical things that every programmer knows are essential. The retrospective, in which a team is supposed to talk about how to improve their work, was facilitated by the Scrum Master, who was usually nontechnical, and so the discussion tended to steer toward the Scrum practices, because team members did not want to bring up issues that the Scrum Master would not understand. Teams then went back to their desks, anxious to get back to work after all of the Scrum-related ceremonies (what the Scrum practices are called), and so important technical issues went undiscussed.
The Agile conversation was essentially taken away from software developers—the people for whom Agile was created. After all, the Manifesto begins with (italics added), “We are uncovering better ways of developing software … .”
Agile thought leadership was increasingly controlled by those who wanted to advance an increasingly extreme behavioral agenda. Programmers speak up from time to time, but with trepidation. For example, a poster on Reddit wrote this:
“I hate Scrum. There. I said it. Who else is joining me? Scum seems to take away all the joy of being an engineer. working on tasks decided by someone else, under a cadence that never stops. counting story points and ‘velocity’. ‘control’ and priority set by the business - chop/change tasks. lack of career growth—snr/jnr engineers working on similar tasks.”15
The Scrum Master and Agile coach roles became so entrenched that organizations now assume that they need those roles. No one questions it. More important, no one questions the skills and knowledge that are needed for those roles to actually be effective.
The career of a Scrum Master or Agile coach relies on the perceived value that they provide. Since the experience of most was not in the technical realm, the natural evolution was to inflate the value of the nontechnical dimension of things. We saw a rise in Agile dogma, in which Agile or Scrum advocates—usually Agile coaches or Scrum Masters—would deride anyone who challenged Scrum or Agile practices. We have mentioned the term Agile doubter. These dogmatic people were such a problem that in a 10-year retrospective on the state of Agile, the British Computer Society referred to Scrumdamentalism—a play on the words Scrum and fundamentalism—as one of the main problems with the state of Agile.16
The Agile community suffered from groupthink: the community mostly spoke to itself. One of our editors described the community as insular. During the first decade of Agile, Agilists mostly read books that said “Agile” on the cover, but important ideas from other communities, such as those that study organization change or organizational psychology, did not permeate the Agile community. In the words of Norwegian Wood's author Haruki Murakami, “If you only read the books that everyone else is reading, you can only think what everyone else is thinking.”
The result was that thinking in the Agile community became highly constrained: the community would only tolerate ideas that either modified existing Agile practices to be more extreme or added new nontechnical practices that were also extreme. Anything else was either ignored or dismissed as “not really Agile.” So for the entire decade of the 2000s, Agile was confined largely to nontechnical thinking—an irony since Agile was created for software development.
Meanwhile, companies such as Google, Amazon, and Netflix had real problems to solve. They needed to be able to deploy to hundreds of millions of users many times a day, with confidence, and allow teams to make rapid changes and redeploy without delay. They needed agility in their software development and release processes.
So, they invented techniques to help them to achieve these things: techniques such as on-demand test environment creation, test-first integration testing (aka ATDD), containerization, container cluster management, and many other things. Jez Humble was the first who we know to have assembled these ideas into a coherent whole and publish a book about them, which he called Continuous Delivery, and the methods he described became known as continuous delivery, often abbreviated as CD. Gene Kim later wrote about CD ideas in his book The Phoenix Project.
Humble was an advocate of Agile methods and viewed himself as an Agilist, and he spoke about his work at Agile conferences. His talks were well attended, but few in the Agile community at large paid attention: what Humble was advocating was technical, so it was largely ignored by the large and growing cohort of nontechnical Agile coaches, particularly those who had built a career around Scrum. The established spokespeople for Agile—the popular Agile authors of the day—also largely ignored what Humble was talking about, preferring to pile onto the process topics that had been trending, and a few kept tweaking the now dated practices of XP. As a result, CD methods and related ideas became their own movement, which we know today as DevOps—a term that arose shortly before Humble's book was published.
The Agile community saw the rise of DevOps in the early 2010s and became alarmed. Agile was under threat from something new, so they claimed it as their own. Those who still advocated for XP claimed that DevOps was just XP in a more evolved form (not true). Agilists pointed to Humble's Agile origins but did not acknowledge that the majority of Agile coaches paid little attention to CD until DevOps rose to widespread awareness.
To be fair, there are many technical Agile coaches, even though they are a small minority. Those people indeed saw CD as continuation of the march of Agile ideas that began with XP and before. They were a fractional cohort, though.
Today if you ask an Agilist about DevOps, they usually think that DevOps is an evolution or outgrowth of Agile. That is not how it was, but it no longer matters. Agile is a set of ideas. DevOps is a set of ideas. Both sets of ideas, and many others, are extremely valuable in the context of product development.
The Introvert vs. Extrovert Problem
Earlier we posed the question, do these practices favor certain ways of working at the expense of others so that certain people benefit but others are at a disadvantage?
The group that authored the four values of the Agile Manifesto was pretty homogeneous. As we said, they were all English speaking, most were from the United States with a few from England and one from the Netherlands, all were men, and all were very experienced. They did not represent a “typical” team of programmers. It is reasonable to expect, therefore, that they had some collective biases that differ from how a typical team of programmers would feel and think.
Since most were experienced, one might assume that when they wrote that they value “individuals and interactions over processes and tools,” they were thinking of themselves as capable individuals—individuals who are highly experienced and who have refined judgment about IT methods. Such individuals arguably need less oversight—less process.
Within the principles that some of the group came up with, one of them reads, “The best architectures, requirements, and designs emerge from self-organizing teams.”
That one principle has resulted in a strong preference within the Agile community for “self-organization,” that is, a team in which there is no designated leader. The authors of the Agile Manifesto were able to come up with four values in the course of a weekend, so they clearly were able to self-organize enough to accomplish that. Would they have been able to continue to be organized over a period of months to create a complex software product?
No one can say. The principle regarding self-organizing teams has been one of the most contentious statements of the Agile Manifesto. An article by one of us in LinkedIn about self-organizing teams received 45,000 reads in the first two weeks—two orders of magnitude higher than the normal read rate for that author.
What happens