Monday Sep 18, 2006

Agile's Dark Side

Being a self-proclaimed Agile Advocate I seem to find myself in discussions regard the bad points about agile. Books, articles, and talks on the subject of agile always paint the rosy happy story about using agile. I'm no fool, and I realize that things aren't quite as happy as some people make it out to be. No one said that agile was a silver bullet. The reason that I'm an advocate for it is because I believe it is simply a better way to write software. Let's get down to the meat of things. What is the "Dark" side of agile?

1)Increased Visibility can cause organization crisis. Agile, if nothing else, exposes all of the problems an organization has. If no one wants to take responsibility for these problems, then a crisis can (does)arise.

2)Lose of titles. What does it mean to be a "Senior QA Tester" on an agile team? Since everyone is responsible for getting the product done, titles/roles get blurred. Some people have definite problems with this. Especially when it comes time to do the yearly performance review.

3)People have to work together. Which, going back to item one, creates those pesky people issues. Normally you can avoid this on a traditional project by segregating opposed personalities. It isn't easy to do in an agile project.

4)Projects fail fast. This is a negative because in a traditional project, money from the budget usually keeps coming in because everything is "moving smoothly". But in an agile project more visibility may produce angry bean counters if the project goes directly into a dive. Again, there is no where to hide your dirty laundry on an agile type project.

5)Sustainable pace. We are used to slacking off at the beginning of a project and death marching the end. So most traditional projects see spikes in productivity. Agile projects push to establish a sustainable pace among the team. This means the developers are always busy and don't get a "break" from work. People are turned off by that (odd I know).

6)Feeling of micro-management. Agile promotes increased visibility. How do you get increased visibility? Your workers update their statuses in a daily manner. This can cause a definite feeling of micro management amongst the team.

7)Less up front design. Architects are perhaps the most difficult types of people to convince to use agile. This makes sense because these people are the ones who try and minimize risk from a technical aspect. Having a methodology that says, just do the minimum that is needed, to them is risky and goes against everything they have been trained on. I think it is important to remember that agile doesn't mean no design, just no unneeded design.

8)Flawed implementation of agile. If you rush, don't plan, are unsupported, and don't get team commitment you are likely to leave the organization with a mess on it's hands. The organization is likely to stay away from anything agile after getting such a bad taste in it's mouth.

9)Physical reorganization costs. A team is likely to want to remove the cubes and create a team room. Or at the very least reorganize their cubes in order to be closer to each other. There is a cost associated with doing this. Same is true for when the team demands newer hardware to do development. I'm all for new hardware, just realize that again, this is a cost that isn't obvious to an adoption of agile.

10)Loss of privacy. Well, no one said you had privacy at work anyway. But when you implement agile, this loss becomes a bit more apparent. Team rooms, pair programming, these things all attribute to some loss of privacy. Have to make a personal call? Before you may have sat in your cube. Now with agile you might have to go outside the office to have it be personal. Want to check your personal email? That is harder when your workstation is in the middle of the team room.

Change is hard, take time and do things the right way and make sure everyone understands what is happening. Remember that these problems listed above are not show-stoppers. With good leadership and good people they can all be moved out of the way. But I don't want you to go into this with your eyes closed. Know that there is a large possibility that you will see some of these dark sides. Be prepared and don't give up.

Comments:

[Trackback] This is a good list and I have seen all of these things be challenges to teams and organizations adopting agile methods. I've linked each one of the above to one of my previous Agile Advice articles.

Posted by Agile Advice - How and Why to Work Agile on September 19, 2006 at 02:00 PM CDT #

Your last paragraph has me bothered. I'm getting really sick and tired of the entire Agile Movement. I've been in both 'old school' environments and the great 'Agile' environments. Both had successes and failures. I find it odd that people believe that it's not people that make or break a project, but the 'process' or 'methodology' is the reason for success. IBM (my FORMER employer) has done NUMEROUS studies on development and productivity. Each and EVERY time, in the 60s, 70s, and 80s, they came to the same conclusion: programmers need a QUIET place, comfortable room, good hardware, and ample space with a whiteboard. Pairing is nothing new. Programmers have been doing that from the beginning. It's the private space that's important. There are a ton of other issues with Agile I have (and no, I don't fear change because I continue to be involved with Agile) and this post is not enough to cover them all. I will end with this: if Agile is great for development, then it's PERFECT for Management and Executives. THEY should be paired. THEY should sit in one big room to 'communicate'. THEY should have daily status reports and updates for their chain. It would be interesting to see how much dead weight is cut from the chain as a result. It would be interesting to see whose neck is exposed during the course of their projects. Agile is just another means to an end, but it not THE means. Working with all this just gets tiresome, and THAT is why a project succeeds or fails.

Posted by Dan H. on September 20, 2006 at 07:55 AM CDT #

Hi Dan, thanks for your comments.
I'm curious to know what other issues you have with agile.

I also find your ideas relating to using agile in management to be interesting. Do you feel that the current practices and processes don't involve management enough? Or are you just thinking that all of managment should be run in an agile way?

Posted by Aaron Korver on September 20, 2006 at 09:26 AM CDT #

i think this is more "the down side" than "the dark side". One refers to draw backs. The other refers to evil uses.

http://en.wikipedia.org/wiki/Dark_side

Posted by tim d. on September 20, 2006 at 10:41 AM CDT #

Nice article. I noticed that some of these "dark sides" are actually good things.

Increased Visibility, for instance. I think it's a good thing to expose problems an organization has because it means they're more likely to deal with them.

I'd say about half of them on your list are actually good.

Posted by mike on September 20, 2006 at 02:12 PM CDT #

Hi Mike,

You are correct, these things are more like "perceived negatives" for an agile project. The point behind this list is that there are going to be bumps in the road. I would rather people know about these bumps than be surprised and hit there heads when the run over one.

For example, if you aren't ready for increased visibilty then when something bad is exposed, what are you going to do? Most people's first reaction would be to cover it back up and to stop doing the thing that made it visible. True, this is a knee jerk reaction, but it is human nature to do such things.

However, if you are ready for such things, then you can reflect and adapt accordingly. Thus the point of the article.

Posted by Aaron Korver on September 20, 2006 at 02:43 PM CDT #

My opinion reaches Mike's comment.

The majority of these bad Agile aspects are currently its objectives. If they seem bad, it is probably because the team is not sufficiently implicated in the process. Like anything, people don't like the changes.

My feeling is that if a team chooses to be Agile, then they want to expose their problems as well as their success. If the team chooses to be Agile knowing that solution must come from them, they will take their responsabilties.

What reinforces item 8. Before launching out in the Agility, it is to better discuss it with the team which wishes to change methology: explain that the benefit will come only from their engagement.

Hard speech, but which claims that the Agility is easy?


Posted by Mathieu Boisvert on September 20, 2006 at 07:00 PM CDT #

I could have a point-by-point rebuttal of each of your arguments, but I think that would be completely counterproductive. IMO, Agile software development is about making visibile all the organizational chaos and the icky, interpersonal issues which get in the way of providing value.

Most organizations (> 60%) are unwilling to (or are incapable of) confront those issues and agile software development in that environment will fail. That is OK. It just means leaving that organizational gunk in place is more valuable than trying to solve it. At least now people were able to make an informed decision rather than sweeping it under the rug.

Posted by Carlton on September 22, 2006 at 11:10 AM CDT #

Hi Aaron Korver,

the points you list are real down sides of "Agile" philosophy. Maybe another point can be added to your list : An agile team could find, at the end of a lot of iterations that they could have used an Off-The-Shelf product from the start, or even better : the use of an ASP (or SaaS as they call it today).

Some criticism of agile and extreme programming : http://www.idinews.com/indexmethod.html

Best regards,
Jérôme.

Posted by Jérôme Radix on October 05, 2006 at 04:33 AM CDT #

Post a Comment:
Comments are closed for this entry.