First let me summarize the article without editorial content. I will apologize in advance for the number of lengthy quotes but for those of you who haven't read the article I wanted to give you a feel for the points it makes, and to hopefully illustrate that I'm not exaggerating what the author is claiming. Here is the summarization:
- "Agile has not only failed like other fad methodologies ... but ... is making things worse in IT"
- The author "recasts" the agile principle of early and continuous delivery of valuable software as "delivery over quality". His conclusion is that "focusing on continuous delivery has the effect of creating an unmanageable defect backlog while developers work to put something in front of the customer"
- He goes on to elaborate further, using an example where "a huge defect backlog had developed over the previous 18 months" which needed "groups of iterations devoted solely to ... the backlog". His conclusion in this case is to go further on his "delivery over quality" theme and state that "agile promotes the practice of ignoring defects".
- His next point is restating the agile principle of responding to change over following a plan as "development over planning". He elaborates that agile "does not distinguish between big and small changes" and that agile does not account for the fact that "every change has a cost". His justification? People often change really big things late in the game using the rationale that ... it's an agile project..."
- His next criticism is his claim that agile promotes "collaboration over management". The support here is the statement that "In too many agile projects the Scrum Master is little more than a hapless cowboy waving his arms in despair while his charges go in all different directions at once. You cannot replace accountable and responsible project management with some immature utopian myth of self-organization."
- The author describes something he calls "agile thinking" which is "the ability to take the input of all the variable elements of the project—budget, time, design patterns, reusability, customer needs, corporate needs, precedents, standards, technology innovations and limitations—and come up with a pragmatic approach that solves the problem at hand in such a way that the product is delivered properly." His conclusion is that "Agile as a methodology cannot deliver agile thinking, however, and inevitably ends up preventing it."
- The final point I'll call out is the author's claim that "One of the hardest things for many developers is pragmatism." He cites a project based on "a purist design" that was "a marvel of abstration" that failed.
WOW! When I see articles like this I would like to dismiss the whole thing as massively un-informed, but let's explore the details, just for fun. In writing this I am using Agile as I practice, teach and coach it. I also want to state that I'm not an Agile purist, apologist, or anything of the sort. But I have been using Agile successfully for a number of years and one of the things that struck me, as I'm sure it struck many of you, is that I don't recognize much Agile, at least "good Agile", in what the author describes. Unfortunately the industry contains far too many examples of teams claiming to be agile who are nothing of the sort (more on this later). But this doesn't mean that Agile doesn't work. It does reinforce the fact that more teams should seek help in getting professional training and/or coaching when adopting agile.
The author, like many people who comment on the failings of agile, clearly hasn’t worked on an actual agile team. If he had he would have experienced many if not all of the practices I describe in the remainder of this post.
Let's look at the points in detail:
- The author claims that agile stresses “delivery over quality”. This couldn't be farther from the truth. A couple of points from an “actual agile” implementation easily rebut this:
- With every team I work with part of the Done criteria are quality goals. Typically:
- No known defects against the story
- Unit tests written so there is xx% (80% is a typical, minimum target) coverage.
- All test plans successfully executed.
- No regression or new functionality defects identified
If these criteria aren't met then the work is not done and is not accepted. If a team is not doing something like this then it is hard to believe they are delivering production ready code, which is a core tenet of any agile implementation!
- If a team finds itself creating a defect backlog (i.e. technical debt) then they deal with it in the sprint retrospective (why is it happening?) and the next sprint planning meeting (what do we do to address it?). With the root cause(s) identified and addressed and a plan to deal with the backlog of technical debt in place the team moves forward on a better footing and verifies their results in the next sprint retrospective. This is happening every sprint (1-4 weeks) and, if done well, means that the team is continually improving both their own performance as well as the software that they are creating. Compare this to the typical waterfall project where opportunities for review, retrospection and improvement occur months (and months) apart, and provide only limited opportunity to improve the results of the current project.
- To stress this point, and deal with the author's "huge defect backlog" created over 18 months - there is no way this should happen in an actual agile environment. Looking at the author's specific scenario:
- Where was the "inspect and adapt" principle as shown in Figure 1? Were there retrospectives? If so, how did they fail to address this issue for 18 months?
- How were the Done Criteria defined? It would seem that they either weren't defined well enough from a quality standpoint, or they weren't enforced effectively. But, again, how was this allowed to continue for 18 months?
Figure 1. Inspect & Adapt
I've also seen teams that claimed they were doing Agile create a mess just like the author describes through a combination of mis-management, horrid Agile execution, and the presence of far to many "Wallys". But that doesn't mean that Agile has "failed like other fad methodologies". Those teams fail no matter what methodology they (mis-)use! - If you are doing agile correctly it should actually be “quality over delivery” because you're delivering production quality code at the end of each sprint and not relying on an interminable find/fix cycle at the end of the project.
- The author states that agile stresses “development over planning”. This can be true, but not in the way the author states. Personally I strenuously object to the agile idea that architecture evolves. This is one of the ideas that people like the author cite when pointing to a lack of planning. The reason for my objection is the following: if "architecture" is defined as "the design/definition of the things in the system that are hard to change" then expecting it to evolve in a reasonable and efficient way seems unrealistic. In setting up agile projects I will typically use the Sprint 0 concept, which is itself a bit controversial among some agile practitioners, to insure that the things that need to be thoroughly thought through before getting into development are given the attention they deserve.
- In making the "development over planning" point the author states that agile "does not distinguish between big and small changes" and furthermore that "Every change has a cost, but agile does not account for this". This seems to show a spectacular lack of understanding of the principles of Agile.:
- In agile all changes are small, by definition, since stories need to easily fit into a sprint. The key is effectively figuring out how large changes can be broken down into a series of smaller ones.
- The author also uses "big" to mean risky. Contrary to the author's point agile teams should not "change really big things late in the game". They should be doing the opposite. Most teams use an analysis of "Risk" vs. "Value" as shown in Figure 2 to insure that they are attacking the upper, right quadrant (High Risk/High Value) first. Just the opposite from the author's point.
Figure 2 - Risk/Value Matrix - Then the author doubles down on the previous, spurious, quality argument ("in for a penny, in for a pound" so to speak). But one thing I found interesting about his position is the “Ode to Traditional Practices (Waterfall?)” that he engages in. Really? The original article that defined the waterfall method (http://www.cs.umd.edu/class/spring2003/cmsc838p/Process/waterfall.pdf) actually says that the method (as it has come to be practiced - see Figure 3) doesn’t work for any kind of complex project.
Figure 3 - Typical Waterfall Process
One could make the argument that the industry has been heading toward Agile for the last 40 years. Royce's original article at least hints at prototyping and iterative development, and it is those initiatives, along with the adoption of incremental development that helped created a path to Agile practices. - “Collaboration over management” – the key point that the author makes here is Scrum Master as hapless cowboy. He sees the Scrum Master as a Project Manager from whom all authority has been stripped, which utterly misses what the Scrum Master is and does. There is no reason for the Scrum Master to be "waiving his arms in despair" because he/she has no "charges {running} in all different directions at once". The Scrum Master does not have "charges" but works with the team to facilitate, to remove impediments, and to make sure that the team and the individuals within the team are being faithful to their commitments. If these things become a problem the Scrum Master takes the problem to the team and they collaborate on a solution. The Scrum Master role can be challenging because with a team that is new to Agile they may have to use a little more of their "command & control" repertoire then is considered "Agile", as discussed below. The key to a successful Scrum Master is realizing this and working to mature the team so they can play more of the "servant-leader" rather than project manager role.
To do this well requires a team capable of growing into their self-managed / self-organized role. There are plenty of Wally’s in the industry, and a team of them couldn’t order lunch without supervision, but they are just as poisonous to a “traditional” project as to an agile project. The argument could be effectively made that agile, with short delivery cycles, frequent retrospectives, and team accountability, is more effective at rooting out the Wally's than monolithic waterfall projects. There is a nuance here that the author, not surprisingly, misses. That is that adopting agile can be challenging for a new team for a number of reasons: - Many new teams are building software on top of legacy code that already has quality problems and typically doesn’t have a set of automated tests to provide the safety net that agile relies on. There are ways to address this, but the situation is almost always going to be improved incrementally and there will be challenges while and until it gets better.
- New teams are used to command and control environments. Transitioning to working in a self-directed fashion takes time and some getting used to. In working with new teams I describe 3 stages that they will go through:
- "Tell me what to do" - still in the old command and control mindset.
- "I'll tell you what I'm doing" - taking initiative, but still not in the team mindset.
- "We'll tell you what we'll do" - this is the team mindset that is needed for high performance agile.
This is probably one of the biggest areas where teams benefit from agile coaching. But it doesn’t mean that Agile doesn’t work, just that it takes some time and effort to get there. - The point around "agile thinking", the importance of prioritization, and the failure of Agile to address these is particularly surprising. The author never mentions the Product Owner role which is where all of these things come together. It makes me wonder if the projects that the author worked on actually had this role defined. It is fundamental to Agile that the Product Owner factors in all of the aspects described by the author to establish business value and then prioritizes the most important things, from a business value standpoint, to be addressed first. Agile Release Planning takes all of this and creates a projected, and tentative, roadmap that puts the highest priority items in a schedule context beyond the current sprint.
- The basic premise seems to be summed up in the statement “ One of the hardest things for many developers is pragmatism. Rather than think practically, they inevitably fall into abstract approaches to problems”. One of the problems with generalizations is they are always wrong (irony is intentional). This thinking is an example of the “programmers just want to build cool stuff and need adult supervision” camp. The flip side of this is the “managers are useless idiots and if you just keep them away from the developers everything will be perfect.” camp. Both are equally false in general. There are un-pragmatic developers and pointy-haired bosses, to be sure, but in almost 40 years in the software industry I've found that people are a lot more complex than that and can be trusted more than this attitude implies. To use this as an argument against collaboration seems naive and overly simplistic. I would counter by making the point that Agile focuses the team on delivering Business Value, as defined and prioritized by the Product Owner, each sprint. How much more pragmatic can you get than that. The fact that the author worked on a project where an un-pragmatic, "purist design" was a problem isn't an Agile failure. If anything this seems to show why the YAGNI ("You Aren't Going to Need It") principle is so valuable. If that Agile principle had been applied then that design would probably have not been allowed, which means that the project might have been saved if it had actually followed good Agile practice.
- The author hasn’t done any interesting research, but is publishing an opinion piece. He justifies his position with the statement "I've been involved in a number of agile projects”. But based on the total lack of insight into how Agile really works it seems obvious that although the projects the author was on said they were Agile they clearly weren't. The most damning thing the author says here is that he was "overall responsible manager" on at least one of the projects. Given the author's lack of Agile knowledge it is hard to believe that particular project was doing anything that most knowledgeable people would recognize as Agile. One of the biggest problems we have with Agile, at least from a PR standpoint, is that there are so many teams who say they are doing Agile and they just aren’t! An alarmingly large number of companies I’ve seen over the past couple of years say they are doing Agile but I believe that in 1-4 questions you can determine if this is true. The questions are:
- "Describe your daily standup." Typical response: "We don't have one."
- "How do you manage the product backlog?" Typical response: "We don't have a backlog."
- "How long is your sprint?" Typical response "It depends..." That's enough.
- "Describe your Done criteria." Typical response: blank stare.
There are obviously more questions that can be asked, but I’ve found that these four seem to be indicative of how well a team is doing in terms of following an agile process.
I’ve been involved in building very sophisticated applications (highly configurable; multi-tenant; highly scalable; etc.) with agile teams and we’ve always been able to do this. Writing appropriately sized stories is an area where a lot of product owners struggle initially but all of the teams I've worked with have managed to get there with a little work and practice. High risk/value stories may emerge late in a release cycle and have to be tackled, but that should be the exception, not standard operating procedure. The author clearly doesn't understand the type of planning that does occur in an effective Agile environment.
So, my conclusion is that this article is basically a massive pile of misinformation that somehow CIO decided to publish. Those of us who have been practicing Agile for a while know that it can and does work. We also know that it is not easy. It requires us to do things that are uncomfortable at times. To communicate openly and honestly. To be transparent. To collaborate effectively. To be accountable. Teams take time getting there, but once there they can be extremely productive. Despite what the author's experience was on his several, almost certainly not well run, Agile projects.
As always, thoughts and comments are welcome.
