But unlike some of the previous anti-Agile rhetoric I’ve encountered, this isn’t by Traditional Consultants accusing Agile Consultants of playing with post-its instead of doing “real software engineering.” Nor is it by Traditionalists looking at Agile from the outside and saying “that dog don’t hunt.” Rather, it’s by practitioners who have been on “Agile” projects and burned in some way. These are working programmers with skin in the game. And they’re hurting.
So I started reading more carefully.
As I read through the vitriol in the comments, I noticed two general patterns.
The first pattern involves people who have been burned by a corrupted flavor of “Agile” foisted on them by clueless managers in dysfunctional organizations. By “clueless,” I mean the kind of manager who thinks the way to find a qualified coach is to find someone with a certification from a 2-day CSM class. Or the kind of manager who thinks that if we do a global search and replace on key phrases in our process docs that we will somehow be transformed into an “Agile” organization. By this I mean:
phase -> iteration
project manager -> scrum master
requirements -> stories
estimated hours -> points
status meeting -> standup
Sadly, there’s nothing we can do to prevent this bastardization of the word “Agile.” It happens with every buzzword. ISO, CMM, CMMi, RUP, take your pick.
I was on a project once where management decided that UML was the right cure for all our ills. Of course, it wasn’t. Didn’t help a bit. Actually made things worse. After everyone got trained up on UML we had to have meetings to review useless artifacts created only so we could check off a task item: “Create Use Case.” But UML was not the problem. The real problem was an executive team in so far over their heads that they were willing to believe in magic, and a staff so burned out and sick from the verbal abuse that they were willing to pretend magic existed.
So, to the people who are victims of Fake Agile, I extend my deepest sympathies. “Agile” ruined your life only in that it provided an all-too-glib buzzword for your organization and management to latch onto. I dearly hope that you’re able to experience real Agile: frequent delivery of value at a sustainable pace while adapting to the changing needs of the business.
Actually, maybe you already had experienced Agile, but your clueless management screwed it up by initiating an “Agile Transition” with so-called Agile Consultants or Coaches who dictated and enforced cumbersome variations on Agile practices in a sad command-and-control parody of Agile with the ironic result of decreased communication, collaboration, visibility, feedback, and alignment. For you, I hope you can escape the nightmare and find a healthier organization.
But there’s a second pattern of responses that I find both disturbing and fascinating. The responses in this category do not appear to be motivated by a misunderstanding of Agile, but rather are attacks on Agile practices: standups, pairing, collaborative teams, open team rooms, and the like.
At the mild end of the range in this second pattern are people who object to being “interrupted” by meetings or derailed by having to collaborate with others.
I suspect that some of these folks are introverts working with a whole passel of extroverts who took to the social nature of Agile like ducks to water. Introverts need time and space to process stuff internally. If they don’t get enough time to themselves during the workday, they burn out. If this sounds like you, I hope that instead of seeing Agile practices as evil you can work with your team to achieve a workable balance of collaboration time and alone time.
At the more extreme end of this second pattern, however, the comments get nasty. Some refer to the business stakeholders as idiots, use dismissive labels like “bean counters,” and decry the work of other “crappy programmers” that they have to clean up after. These aren’t just attacks on Agile, they’re attacks on people.
Perhaps some of these comments come from good people who have been in toxic environments too long. I want to give everyone the benefit of the doubt.
But I think that at least some of these folks have a vested interest in the status quo. They liked the old way of working because it allowed them be the magicians behind the curtain. No one knew what they did or how they did it. They could pick and choose the work they liked.
These are the folks who think they are at their most productive behind a closed door, headphones on, music blaring, being “Programmer Man” (or woman, as the case may be). They dismiss requests for help with an airy wave of their hand and a distracted, “RTFM.” They think Dogbert is right about just about everything and they resent being stuck working with a whole pack of Wallys. They like to work from 3PM to 1AM because those are their best hours: things are quiet and they’re not interrupted. They write what they want, the way they want to, without concern for what the business stakeholders asked for.
Many of these people are undeniably brilliant. They produce more code—working code, even—in an afternoon than an average programmer can write in a month. And it may even be beautiful code, too. Well-factored. Clean. Really good stuff.
And yet these folks are not nearly as effective as they think they are.
Their code might be elegant, but because they dismiss Product Managers and BAs as “idiots,” their code doesn’t do what the business actually needed.
Even if their code does do what the business needed, the fact that it was created in isolation means that doesn’t play well with the rest of the system. So it takes weeks to integrate and test it. These brilliant programmers, self-satisfied with their own competence, drastically discount the work required to turn raw code into something that has business value. They blame everyone else for long integration cycles, unable to see their own hand in the mess.
And even if their code works within the context of the rest of the system, the organization is frequently bottlenecked through them because they’ve decided to take on the mantle of the hero.
For these folks, Agile represents loss. A forcible expulsion from their comfort zone of darkened offices with closed doors and noise canceling headphones. The loss of autonomy afforded by opaque processes. The loss of sovereignty over “their” code.
And so I wonder if perhaps at least some of the current backlash is offered by those who are being forced out of their self-imposed isolation, into an open team culture. It feels like a crisis to them. It may even feel like Agile is ruining their lives. But as Jerry Weinberg says, “it’s not a crisis; it’s the end of an illusion.” In this case I think it’s the end of the illusion that they were the best because they cranked out more code than anyone else. Or the illusion that all that teamwork stuff is a bunch of fluffy nonsense and not nearly as important as the technical heavy lifting they do.
The truth is that creating even a modestly complex software system is of necessity a social activity, a team sport. It is not enough to be brilliant. It never was. Effective team members have social skills. They listen, collaborate, share, and contribute.
So, to the people who think Agile ruined their lives because it requires an uncomfortable level of teamwork, I say: what a marvelous learning opportunity for you. Yes, you are brilliant. But to advance as a professional, you need to be so much more than that. A deeper understanding of algorithms, OO design, or functional programming will not help you move forward further. It’s time to get on with the difficult and painful work of learning to be a good team member. Welcome to the next stage of your career.