Dark Side of Agile

[raimundox]

could be better if named "common culture conflicts in agile project"

http://blog.natural20software.com/article/agiles-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

[Jeff Xiong]

我怎么看也觉得是在夸奖敏捷。除了第7条，我觉得都是在说敏捷带来的好处。

7)Less up front design.

这一条就像上次关于产品设计的讨论一样。up front
design不是"应该不应该做"的问题，而是需要纳入风险/成本/收益评估体系。比如说我们做spikes，显然这就不是"什么都不想就开始实现"。

--
Jeff Xiong
Software Journeyman - http://gigix.thoughtworkers.org
Open Source Contributor - http://rubyworks.rubyforge.org
Technical Evangelist - http://www.infoq.com/cn/