The Bastardization of Agile

It's always easy to tell when something is resonating within organizations - and Agile is now firmly in that camp based on my experiences over the past two years. There is a tremendous amount of interest in Agile methods and many organizations are taking their first or second steps with it. On the surface, this looks great, but some of my experiences have led me to believe that Agile is thought of not as a different, solid approach to software design and development, but more (as I originally feared) as a silver bullet, completely misunderstood, or license-to-hack with little or no accountability for outcomes.

Herewith are a number of 'incidents' that I've recently observed or participated in:

• Regular loss-of-control-and-context in standup meetings, which at times make them drag on for hours. Scrum masters and PMs/facilitators must be vigilant in staying to the script, and taking issues off-line when necessary - and it very often is necessary. The result of not doing so is completely wasting uninvolved team members' time. Think of it this way: if standups are routinely going for an hour instead of 15 minutes, usually for one team member's issues, you are wasting 45 minutes of other people's time X the number of uninvolved team members. If this occurs on a daily or near-daily basis, the amount of wasted time is huge. And, since you're operating under iteration and timeboxing constraints, wasting team members' time like this will cause iteration goals to be missed repeatedly, and perhaps kill your project. Take very-specific issues brought up in standup that don't involve the entire team OFFLINE!
• "We're going to 'organizationalize' Agile." Which translated means "we're going to superimpose our culture and previous practices into whatever Agile methods (or parts) that we've selected. Translated further, this means that what will be superimposed is a lot of politics and waterfall/SDLC when Agile doesn't jibe with the existing organizational scheme - bad, bad move. Every time I've seen this happen, the projects involved are in trouble, and some have failed outright
• Picking what parts of Scrum or XP are appealing to the PM, Scrum Master, or product owner, and ignoring the rest or superimposing waterfall as related above. Disaster often lurks right around the corner.
• PMs, Scrum Masters, or Product/Business owners reverting to the term "Agile" when making decisions or taking action that are not, by any stretch, Agile. Examples: ignoring the self-directed team concept in Scrum by timeboxing work without consulting the team - which in reality is "make my date" project management - pick the date, work backwards to today, and tell the team when the work they are responsible for is due, regardless of team inputs, risks, or other schedules. Another example: assuming 100% dedicated team members and scheduling work when, in reality, the team members involved are not 100% dedicated because of other responsibilities they cannot get out of or pass to others. Finally, there are multiple product owners (ouch) that must come to consensus on stories and other direction - often quickly - and cannot or will not. The team is then left spinning their wheels waiting or worse, attempting to get some work completed by guessing what the stories/intent are - and the risk of being wrong is often high enough to cause a great deal of problems.

Based on these experiences and what I've been told by my students and colleagues, I get the strong impression that Agile is often used as an 'excuse' to advance a particular agenda. It's usually mentioned as a 'selling point' for projects - particularly to management and project sponsors/stakeholders to get projects approved and funded. It is also used for behaviors that are not Agile at all - when the PM who played the 'make my date' card on the project schedule was challenged in a meeting for not consulting with the people actually doing the work about the proposed dates, she replied, "Look, these are week-long iterations. It's Agile!" No, it isn't when the team isn't involved; it's 'make my date' and the consequent rectally-generated analysis that always follows.

My advice here remains the same as always: if you're going to do Agile development - do it. Completely and without compromise. When I am challenged in my Agile classes about modifying Scrum or XP or FDD to 'fit' some organizational political or budget scenario, my answer is always the same: "If you do that, then you are not doing Scrum/XP/FDD/etc. You are doing something, but not Agile methods."

And its always that "something" that leads organizations and groups who rationalize projects in this manner to fail.

 

Comments

[David]

I think you are being overly idealistic here. Projects have varying requirements (for example dealing smoothly with the internal politics of an organisation could be considered a non-functional requirement, in a broad sense), and a flexible approach to the problem is a benefit, not a hindrance.

"I don't believe you can be purist about this stuff. It's not often I'll do a 100% FDD implementation. I'll look at what are the current resources, what are the current practices, what are the constraints, what's working and what's not and then it's a mix-and-match of practices and approaches." - Jeff DeLuca, SE Radio podcast

[Benedictus]

I think the point the blogger makes is adept and honest. I would like to ask the previous commenter David, who reduces these important observations into being idealistic, does he then support the mentioned behavior patterns, like promoting your own ideas by misusing the name of some hit technology or methodology?

As far as being a purist is concerned, do we call scientists purists when they inform us about the global dangers we will have in front of us if we don't change our consumption habits? When the medical professionals tell us that smoking is highly harmful to our health, do we accuse them of fundamentalism and point them to the importance of habits we have around smoking culture? I don't see much difference between these questions and the resistance of change there is against agile transformations.

Suppose there is something true in the agile ideology. Then by not applying it correctly and diminishing the meaning of its statements (were they put in there accidentally?) we just blur the ideas and set the whole purpose of agile at stake. A bit similarly to the blogger's bottom line we can ask: why do it at all if we don't believe in it? You can always make a long list of factual hindrances there are for agile transformations, but similarly you can always find a million reasons for any change not to happen.

[Pawel Brodzinski]

While I agree with most of your points I strongly disagree with that one:
"Picking what parts of Scrum or XP are appealing to the PM, Scrum Master, or product owner, and ignoring the rest or superimposing waterfall as related above. Disaster often lurks right around the corner."

Actually picking what parts of Scrum/XP/any other nice methodology suits your process fine and applying only those parts is wise. If one of my projects would benefit from stand-ups why not to start them even if we don't keep 2-week iterations? If I find alue in short iterations while I don't have designated scrum master what keeps me from implementing it?

My goal isn't to be agile or have pure-agile processes in software development. My goal is to improve my processes. You can always do it as they do it in the books - 100% implementation of some methodology - and it should work. Unfortunately it's quite an effort to go this way. On the other hand you can choose wisely different techniques from different methodologies and craft your own software development and project management process. Sure, I won't call it agile but as far as I can call it good I don't care.

You can find more about my approach here: http://blog.brodzinski.com/2007/07/agile-methods-applied.html