Agile or Fragile

Criticisms of the Agile methodology range from the complaint that all that iteration is just a lack of planning and organization to the complaint that the Agile process is overbearing, controlling micromanagement.  Which is a bit unfair, the actual Agile Manifesto 12 principles is reasonable.  The problem is software engineers like rules, like process, like some external authority that validates what they do, so Agile becomes the next silver bullet.

What's Good

If you have a team that's large, doesn't communicate well and is led by people who are either inexperienced leaders or simply leaders who are spread to thin, Agile may be for you.  Done right, it provides a framework that everyone can understand and live by and a framework that encourages communication.

What's Bad

In a nutshell, people stop thinking and point to the framework as the one true solution to all known problems.  Bad news, the next monsoon will still knock down all the houses in the village, scrum or no scrum.  The rest of this post will be taken up with what's bad, annoying people who have latched onto the Church of Agile and will brook no dissent.

Let's take a look at a few Agile assumptions.

Agile Assumption 1: The Waterfall Methodology is the Enemy

Because it's easier to sell your idea if you have a counter example which sucks, the Waterfall methodology is set up as the enemy.  Agile projects are light and responsive!  Waterfall projects require years of analysis followed by years of implementation followed by unhappy and baffled customers.  Really?  The customers didn't participate in the analysis and implementation?  Sure, if the people running the Waterfall failed miserably to do their jobs.

Let's take a more reasonable contrast: upfront analysis versus a lack of upfront analysis.  Because part of what Agilistas argue is that you don't need to do a lot of upfront analysis.  You ask a few questions, you run off and slam some code, you come back, get your response, go off, slam some code, wash, rinse, repeat.  That's great because you can use that as an excuse to not do the part that nobody likes.  The engineers don't want to talk to the customers because the engineers are nerdy and anti-social (said with love!).  The customers don't much want to talk to the engineers because, well, the engineers really are nerdy and anti-social (said with less love, I'm guessing).  This is convenient for the engineers who can go off and build whatever they want and then be baffled by the unhappy customers.  But they can do it quickly, which the engineers like because they think it's efficient.  The engineers can say, "Hey, it's an iterative process!".  Yes, it is, and it's an iterative process which will never, ever end because the engineers started off doing something they thought would be cool and was in fact way off at the wrong end of the parking lot.

If you do a lengthy (Waterfall!) analysis and the customer ends up with something the don't want, it's not just because the customer is an idiot who can't make up their mind.  It's also because you assumed that the customer knew exactly what they wanted (and the customer assumed that too) and so your "analysis" was to write down whatever the customer said.  Probably not correctly, because it was both boring and more complex than you realized.  Which isn't analysis, it's stenography.  Bad stenography.  Work with the customer, question the assumptions, push back if what they ask for doesn't make sense.  Do analysis.  Go back and look at the Agile principles.  Do they say "don't do analysis"?  No.  You just think they do because you're lazy and don't want to do a good job of analysis because you just want to code so much that you're willing to pass up on the opportunity to do it right the first time.  You will never finish.

Agile Assumption 2: Pair Programming leads to Quality Code

Yes, this is XP, but often the Agilistas will borrow from other methodologies, perhaps without even realizing it.  How is pair programming supposed to work?  Two smart creative people sit down and work collaboratively to solve a problem.  It can work that way, but there are other scenarios.  Strong engineer plus strong engineer - they try to kill each other.  Strong engineer plus weak engineer - the strong engineer carries the weak engineer.  Weak engineer plus weak engineer - crap squared.  I'm all for collaboration, I'm all for code reviews, but if you see a productivity gain from forced, 100%, wall-to-wall pair programming, you have some people who need firing.

Agile Assumption 3: Documentation Is Always Out of Date

Sure, if you don't do your job.  Seriously, what's wrong with you?

Agile Assumption 4: All Teams are Self-Organizing

From the core principles: "The best architectures, requirements, and designs emerge from self-organizing teams."  No empirical evidence, but is sounds damn good, let's go with it.  And where we go is to the underlying assumption: all teams are self-organizing.  They aren't.  There will always be members who just want to show up, sit in their cubes for 8 hours, collect their paychecks and go home.  These people aren't going to step up to the plate and make sure that the architecture is solid, the requirements are thoroughly vetted and the designs well thought out.  There are groups made up of individuals who seriously care and will produce and there are groups made up of individuals who will not fix a bug unless the customer finds it.  The latter is not going to produce the 'best', no matter how much process you hand them.

Conclusion

Agile isn't bad.  Like I said at the beginning, go read the core principles.  Pretty sensible stuff.  Now look at the mountain of nonsense and process and non process that has been piled on top of those principles and don't do any of that.  Agilistas like to claim that if your Agile project failed, it's because you didn't do it right.  Oh, the irony.

As noted above, where Agile can be really useful is projects which involve a number of different groups without good channels of communication coupled with weak management.  By 'weak management' I don't necessarily mean 'bad', it could be that the managers are spread too thinly to be effective coordinators or are too junior to have the necessary diplomatic skills to make a large project work.  Agile can provide a useful framework and add a little spine where it might otherwise be lacking.  The team also has to be good, you can't make a silk purse out of a sow's ear.

Like any silver bullet, Agile only kills the werewolf for which it was designed and often not even that one.  Use it when it makes sense, not when it seems like the cool thing to do.

Oh look, somebody smarter than I am wrote a better article.