Learn from the Agile Skeptics
Learn from the Agile Skeptics
When I’m teaching a class on agile basics, I like to play a game where I give points to the people who challenge what I’m saying or give examples of when what I’m saying might not always be true.
Not only does it encourage class engagement, it gives people an opportunity to safely disagree.
I embrace those who are skeptical about agile development and encourage them to tell me more. Once they see that I will not become defensive, and in many cases, even agree with their concerns, they are much more open to working at coming up with solutions or at least, a common understanding.
This technique of using opposition to your advantage is one change management pattern that Linda Rising and Mary Lynn Manns describe in their book, "Fearless Change: Patterns for Introducing New Ideas."
When I encounter people who “don’t like agile,” and I ask them why, I would say there are two categories of answers.
The first category has to do with what I’ll call “hype” (i.e., it’s sold as a silver bullet) and the second category has to do with “process” (i.e., we need more planning up front).
Let’s talk first about complaints that fall into the first category – the hype. In the post: How do you convince an agile skeptic? by agile coach Daniel Markham, he says these are the reasons why people are against agile:
- Fake success stories
- Trainers who can't do the work
- Inflexibility on the part of adherents
- "Feel good" agile
- Magic Bullet syndrome
- Reversal of team dominance
- Cargo Cult agile
- Non-answers to questions
- Conflicting advice
- It's the same, only different
- Little Gold Star syndrome
Markham does an excellent job of describing these negative perceptions of agile, followed by some basic descriptions and definitions of iterative development, incremental development, Scrum and agile.
In the case of “hype”-like complaints, I think the skeptics make a good point!
The best way to address this type of complaint is with good education and training on Scrum (agile’s most common methodology) and agile (a set of principles and mindset, rather than a prescriptive methodology).
As for “process complaints,” I contend that those complaints are more likely aimed against a poor implementation of Scrum vs. a complaint against agile.
Agile (and Scrum, for that matter) promote the practice of “inspecting and adapting.” So if you have a problem with a process, bring it up, and work as a team to try and improve that process.
A link to a more recent blog post from a skeptic was sent to me the other day on how agile is the new Waterfall. Actually, I’d say the author of this post is more negative than a typical agile skeptic.
He appears to be an “agile hater,” claiming that “agile has become everything that Waterfall was to developers and worse. It is a sheep in wolf’s clothing and I’m going to expose it here today.”
I won’t go through the entire post (which would result in a virtual field day for those of us who like to “learn from the skeptics”) but filter out what appear to be some of the “process concerns”:
- “The reality of agile is that you still have immutable decisions made by business people with no real understanding of technology. Those decisions are then forced on to developers.”
- “Unfortunately, with little or no documentation, now the developer is accountable for the outcome while having little or no authority to create a winning one. This responsibility without authority makes agile even more toxic than Waterfall.”
- “The addition of the daily “scrum” ensures that anyone who is perceived to be working too slowly (whether this is true or not) is immediately highlighted. This type of “boiler room” atmosphere may work great for a few, but for most it is a source of significant stress and ultimately lower productivity.”
Again, these issues are more likely due to a new Scrum implementation. This author seems to be using “agile” and “Scrum” interchangeably, as many people do, which certainly adds to the confusion.
In fact, the post ends with a suggestion of starting over with minimum process, which the author admits is agile, but says it’s with “a lowercase a agile, not uppercase a agile.”
(Note there is currently no standard on the use of lowercase agile vs. uppercase agile. As a writer, this is frustrating for me, but I digress.)
The author has come up with what he feels are solutions to the above problems, which is great. However, I would suggest that these problems are not experienced by most Scrum teams and his solutions are not appropriate for everyone.
I’d also suggest that when a team is experiencing process issues, they stop, reflect and adapt. It’s not clear whether or not the problems this author experienced were discussed in a retrospective, but had they been, the team may have been able to resolve these issues and continue to improve.
Neither Scrum nor “agile” (upper or lowercase) are going to be perfect or make software development easy. If someone tells you that, challenge them.
Whatever processes you use, the team is bound to encounter problems. Listen to those problems and work as a team to resolve them.
Healthy skepticism is a good thing. Listen to and enlist help from the skeptics in finding solutions in order for your team to continue to learn and grow.
Yvette Francino has more than 30 years in the software development industry, and is an independent consultant, experienced agile leader, coach, author and trainer in various methodologies including SAFe, Scrum, Kanban and large-scale custom methodologies.Learn More