Get certified - Transform your world of work today


Agile Can Be Dangerous

12 March 2012



Good friends, go in, and taste some wine with me,

And we, like friends, will straightway go together.

BRUTUS [aside]

That every like is not the same, O Caesar,

The heart of Brutus earns [grieves] to think upon!


I wonder if Shakespeare's words reflect some situations with Agile. Many projects that fail use "something like Agile," think they are using "true Agile," and are doomed to die. Caesar did not have the benefit of hindsight when he saw things "like friendship" dooming him. We do.

I was speaking with one of my friends who had just returned from a project retrospective meeting after it had failed. Following are some parts of the conversation that he recalled:

PM/CSM (project manager, a recent convert to ScrumMaster through certification): We used a lot of Agile throughout the development life cycle, yet it failed. Guess Waterfall was better.

LSD (Local Scrum Don, and thus the interrogator): So what elements of Agile did you use?

PM/CSM: Elements? The whole hog, man! Bug tracking on Jira, collaboration on wiki, daily stand-ups, three-week sprint releases, and whatnot. We even played planning poker. I didn't know it would all come to this!

LSD: Planning poker is good fun. Did the whole team play it?

PM/CSM: Do I look like I would let the whole team play a game for hours just because some moron wrote that I should? The leads and I sorted the stuff out. We used the extra person-hours on more productive things.

LSD: Did everyone attend the daily stand-ups?

PM/CSM: Every member, every night, without fail. That is what the book says, right?

LSD: Oh, at nights. And how long were they?

PM/CSM: Around an hour, but sometimes more. We didn't miss covering any of the issues. What kind of meeting is over in ten minutes, tell me?

LSD: Did you have sprint demos at the end of each sprint?

PM/CSM: No, the damned sprint product never came into a state where it could be demo'd. And we were always in a rush to start the next sprint. But we did everything else in Agile.

LSD: And why was that? What did the devs say?

PM/CSM: They gave us some crap about requirements coming in late. I scrambled a lot to get those to their desks before they started the task. Still they whined. What do I do if the client didn't blow up the stories before the sprint started? If I delayed the sprint start, the relationship would have taken a hit.

LSD: And do you think the relationship is in a state of Nirvana today since we didn't stop the sprints then? Did you have the retrospective meeting?

PM/CSM: Let's not get all cynical now that it has failed. It's easy for you to say this now. You can't imagine the pressure there was at that point, to keep the development going. The client's chief technology officer was breathing down my neck to keep it going and to please bear with them. The retrospective just sounded like too much. Anyway, everyone was already aware of what went right and what didn't, and people were busy planning out the next sprint. So we did away with the retrospective.

This conversation lasted for a good two hours, my friend reported. Neither side was able to convince the other.

We come across such teams and managers every day. And that makes me think that Scrum is not for the weak of heart. It's not for people who are steeped in Waterfall and keep counting person-hours till the end of time, and who sweat at the thought of moving a story out mid-sprint. If you can't commit to it, Scrum isn't for you. Waterfall is probably a more suitable development model.

Here's what I came away with after hearing about that conversation:

Agile is light on processes, but not loose on them. Many managers enjoy Agile because they feel it frees them up from the process overhead. They are correct, but only partially. Agile, by definition, is a very light-on-processes framework. However, the few tenets it stipulates must be adhered to. Iteration planning meetings create a sense of belonging and ownership to the sprint deliverable. Many old-school Waterfall managers count the person-hours spent on these meetings and pass on them. That's one of the worst things to do, and it defeats Scrum even before the team gets started.

"Implement and inspect" aren't principles, they're the way of life. Numerous projects get into difficulties using Agile because they don't abide by the rule to give frequent "potentially shippable" releases. The end of the sprint should be a sacred time and the demos/retrospectives as good as written in stone. Otherwise you're neither here nor there. We bargained a bulletproof design phase just so that the product gets customer attention regularly, and eventually the customer gets what was asked for.

It's the people, silly. Clients and managers alike sometimes use Agile to push things too hard for the team. In the name of biweekly releases, a lot of pressure is put on the team members and they eventually burn out. The tenet of Agile is to make the team all-important: Seek the members' opinions on what can be done, let them decide effort estimates, allow them the liberty and will to own the product. Thrusting estimates they have to meet upon them, or having them sit through two-hour calls at the end of the day, in the name of a stand-up, will make them hate the manager, Agile, and the product — which does not augur well for a world-class product.

It merits repeating: Agile is not for the weak of heart. Have the courage to delay a sprint start if stories haven't come in. Have the courage to scrap a sprint midway if there are too many changes. If you aren't doing this, the short-term impact is on the morale of the team and the quality of the sprint release. The long-term impact is that laxity enters the genes of the business guys. Just delay a sprint by a week, or scrap one sprint midway, and pay attention to the results. It may correct your problem once and for all. If you just keep on being too "good," you may become the bad guy in the end.

The conversation at the beginning of this article may seem outrageous, but it's an everyday story for failed projects that were using "something like" Agile. Much like Caesar, those involved think they're in good company and don't need to watch their backs. And, much like Caesar, they meet their fate: dead or busted.


Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.

Article Rating

Current rating: 3.6 (7 ratings)


Alvin Christian Opano, CSM, 3/13/2012 9:26:33 AM
Great post! This is the realization that management should have. The sad part is that most of the times, no matter how hard you explain to them, they think of Agile as just another set of practices and standards. They should begin to realize that Agile is a way of life. It really is more of a lifestyle than a set of processes. And being a way of life means importance should be given to those living entity they like to call "resources".

You must Login or Signup to comment.

The community welcomes feedback that is constructive and supportive, in the spirit of better understanding and implementation of Scrum.


Newsletter Sign-Up