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.

Posted by Aaron Korver - Nov 29, 05:23 PM.
Posted in .

4 Comments for Agile's Dark Side

  1. Although I enjoyed the article, several of the issues you mention are not really addressed. Nine seems to be just fluff. While 4, 5, 8 and possibly 10 you dismiss as simple immaturity.

    I would have liked to see a more hard hitting review of the issues, like the difficulties involved with Business User integration and feedback, selling upper management on the idea of software that is often viewed as incomplete, budgeting for sustained cost instead of on a project by project basis.

    Also, you should at least include a real discussion of 4, 5, 8 and 10. Some places to look:

    With 4 there can be difficulties addressing failure with management. How do you point out the flaws with the business request, since many (most) issues are derived from inadequate requirements? For 5 if your developers see their jobs as creative in nature that missed “down time” may be a more serious issue. Also people may have difficulty scheduling their vacations, Dr. appointments, dry cleaning pickup, etc. How do you maintain a sense of accomplishment when all that happens after a release is the planning for the next iteration? Then what price might you have to pay to get a “good” agile implementation under number 8? What ill effects can befall a company who goes after agile half-heartedly. Finally 10, what about the lone coder? The curmudgeonly guru who does actually know the business rules more thoroughly than the users? There is more to 10 than not being able to flirt with you girlfriend at your desk.

    In closing 10 could (should) be addressed by having private offices, or at least cubes to return to. Most people need some space to really think over problems and issues. Even Kent Beck in the first addition of Extreme Programming mentioned that need to take a break and have a space of one’s own.

    Joshua Drake · Nov 30, 09:32 AM

  2. Can you explain how agile can cause increased hardware costs? I’m not following that one.

    Dan · Nov 30, 07:06 PM

  3. I am but a simple gardener, so forgive me if my ideas offend the sensibilities of those greater than I.

    In my garden, I think about what I want to plant before I plant it. I know my seeds, my soil, my weather, my plants. I know that plants grow roots and to pull them up after they grow a bit is fraught with pain and the chance that a plant will die. I know that plants take time to grow.

    My little wisdom, gathering along the way, tells me that the beauty of a rose is not rational and that man, whatever his aspirations, is not agile. Nature, in its sublime way, is agile in ways that take time to perceive. Man seems to work best with well understood structure, roles, and clarity of individual responsibilities.

    I hope these observations of a simple gardener may add something to this discussion.

    Mishkin · Dec 1, 01:16 AM

  4. @Dan
    Sure, I’d be happy to expand my thoughts on that.

    One tenant of a team doing agile is the idea of empowerment. If the current hardware they are using becomes an impediments then they need to address this. Normally the way for this to be addressed is to buy new hardware.

    Another example of hardware costs that may be associated with agile development are Continuous Integration servers. A best technical practice with agile is to have one of these, and I suggest setting one up. However, it usually isn’t planned from the start to have this server and it comes up later as a cost.

    Aaron Korver · Dec 1, 11:31 PM

Commenting is closed for this article.