Fake Agile: All of the Symptoms, but not the Disease

Dietrich Kappe, Monday, December 7, 2009 @ 12:56 pm

photo credit: Ramón Peco

For any software development professional who has contracted out from time to time, this story must seem familiar. You interview and are told that they practice agile development. Once you show up at the job site, they tell you they practice their own "brand" of agile, which turns into "sort of agile" or "we've take the best parts of a couple of different methods" or "it isn't exactly" -- wild and crazy hand gestures -- "XP."

It's a classic case of people following the form or ritual of a process without understanding the why of it. Take the morning scrum, for instance. The ritual around these usually calls for them to be done standing up. We've of course all heard of the standups that run an hour or two. Someone on that team doesn't understand the function and is following the ritual.

So, what is a scrum supposed to accomplish? It is a quick way for a self-organized team to stay on the same page and surface issues or obstacles. You cover three things: what you did yesterday, what you are doing today, and any blockers or obstacles you might have. If an obstacle comes up, the scrum master facilitates the removing of that obstacle after the meeting. You do them standing up so that participants don't feel the need to bloviate on and on about something. If you get comfortable standing for longer periods, have them standing on one leg, or on tippy toes, or with a book balanced on your head.

If you're having 2 hour standups, it can point to one of several things. First, your team isn't self organizing but rather a traditional top down, "cut the food for your kids" kind of team. Then you need longer status meetings so you can remote control your subordinates. That's fine, but stop kidding yourself that you're doing agile development. Second, you may have too large of a team. Even at 30 seconds a crack, a team of 30 will make for a long scrum. Consider breaking your team into smaller units. Third, you may not be doing real iterative development. If you're talking about scope and slipping things into the next iteration or expanding your iteration by a day or two in almost every scrum, then you're not doing agile.

There are a number of other problems that may be causing those marathon scrums, but those are usually at a deeper level. I'll tackle another one in my next installment of "Fake Agile: Embracing Failure."

Related posts:

1. Getting a team over the fear of daily scrums
2. Post-Agile in the Game Development World?
3. Building a High Performance Agile Team: Assume You Will Be a One Hit Wonder
4. Agile 2009: A reminder of why each team needs leadership
5. Agile Fundamentals: The Feedback Loop

Comments (1)

Software Development

Comments: 1 so far

• Leave a comment
• Comment feed for this post
• TrackBack URL

1. [...] The old management adage of “You can’t manage what you don’t measure” holds true in software development as well. If you have no feedback loops, and you’re not measuring and improving, you’re not really doing agile development. [...]

   Pingback by You Shall Know Our Velocity | Pathfinder Development | Software Developers | Blogs, Friday, December 18, 2009 @ 7:11 am

Leave a comment