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

This post was previously on the Pathfinder Software site. Pathfinder Software changed its name to Orthogonal in 2016. Read more.

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 taken 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 call for them to be done standing up. We’ve of course all heard of the stand-ups 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 long 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 stand-ups, it can point to one of the 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.”