Category: Agile

Agile

Why I Hate Agile

Okay, now that I got the link-bait title out of the way, I am going to rant just a little bit. I imagine that I’m like most of you and I think that some flavor of agile (little a) is really the best way to develop software.

I think that collaborating with the business and getting things in front of them as soon as possible so that you can make changes to it as you go is a very valuable model. I am also very much for the short release cycles that most agile shops prefer.

What I despise, however, is what I call “Agile as Snake Oil”. There are a lot of disreputable companies that are putting the word out there that all you have to do is hire them and they can “sprinkle a little agile” on your project or your company and you will magically get everything you want.

Uncle Bob's Agile BookThey crow that Agile means that you can not make up your mind on what you want until the last minute because Agile Developers have to do what you say and are bound by the Laws of Agile to always change the software for the client. They want their cake and to eat it, too. They want all of the spec changes and none of the timeline changes or compromises.

Oh, that they would actually read something like Robert C. Martin’s book, Agile Principles, Patterns, and Practices. I’ll tell you what, I think that if people only read the end of the book, where Uncle Bob tells a tale of two cities, a project where the team does a “traditional waterfall approach” and the same project where the team practices an “agile approach”, it would make a world of difference.

As you can imagine, the waterfall approach ends in disaster, with stress and hard feelings abounding. In contrast, people are satisfied – almost happy – with the agile approach. The HUGE takeaway from the agile story, however, is that it was not a 100% win for either side. They did not hit their original deadline with 100% functionality. Features had to be traded in if the timelines could not move. However, the business stakeholders were the ones who went ahead and made that call.

I covered this in my last “Agile” post over a year ago, but I think that it bears repeating. Every agile project should do these steps

  1. Gather requirements
  2. Estimate requirements to determine length of project
  3. Work requirements in iterations
  4. Gauge velocity in coding requirements against estimate
  5. Determine whether your velocity requires you to either cut requirements or extend timelines
  6. Lather, rinse, repeat

Developers always get a bad rap for number 5 and it is always largely based on our lack of skill at number 2. Estimating is something that developers really should improve on, however, the business needs to understand two major things. Number 1, those timeline estimates are based on developers being able to work on the project at “perfect world” capacity – meaning 75-80% of their time. If developers are interrupted with conflicting priorities, original estimates and timelines are null and void.

Second of all, those who live in glass houses should not throw stones. If the original requirements are so ill-planned that they need to be drastically refined or changed, then developers should be able to refine and change estimates, too, since they are basically working on a different project than the one they started with.

There are obviously no perfect people in this world, so that means that there is no perfect system. Any system will invariably break down because of those imperfect people going around and “being human”. That being said, the best way to get to nirvana is to act like the participants in Uncle Bob’s Agile Story and rely on the two C’s, “communication and compromise”.

Compromising is the original agile. Be retro.

Agile

The Case for Requirements

RequirementsI was recently reading through some of my backlog of Dr. Dobb’s Journals (a PDF I receive monthly) and came across an article entitled The Requirements Payoff by Karl Wiegers. I’ve archived a copy of the PDF here and it can be found on pages 5-6.

A lot of people seem to equate “requirements gathering” with “big design up front”, which is now often vilified as being antiquated and bloated. Nothing could be further from the truth (about requirements, not BDUF). In the book Agile Principles, Patterns, and Practices in C#, Uncle Bob talks about practicing Agile in a .Net world. In every one of his examples, you have to know what your requirements are ahead of time. The process goes as follows:

  1. Gather requirements
  2. Estimate requirements to determine length of project
  3. Work requirements in iterations
  4. Gauge velocity in coding requirements against estimate
  5. Determine whether your velocity requires you to either cut requirements or extend timelines
  6. Lather, rinse, repeat

You see that the agile process doesn’t work without requirements. In the article, Wiegers says that according to a 1997 study, “Thirty percent or more of the total effort spent on most projects goes into rework, and requirement errors can consume 70% to 85% of all project rework costs”. That is a big penalty to pay for laziness or ineptitude in early requirements gathering. This doesn’t mean that the requirements collected at the beginning are rigid and inflexible. They are just a starting point. However, changing the requirements changes the estimate and also the expected cost in time and resources and can fall under the statistic quoted above.

Requirements are essential to TDD and BDD advocates, as well. The requirements are what a vast majority of the tests are written against. For instance, if the requirement is that the user name is an email address then a programmer will likely write a test (both positive and negative) verifying that the program behaves as expected when presented with an email address or a non-email address, etc. Without that requirement, a test might only be written to ensure the user name wasn’t blank and the stake-holders might be upset when the program behaves differently than they imagined in their heads (and you failed to ferret out in requirements gathering).

It is true that gathering proper requirements in advance costs time. Wiegers sums it up best, however, when he says, “These practices aren’t free, but they’re cheaper than waiting until the end of a project or iteration, and then fixing all the problems. The case for solid requirements practices is an economic one. With requirements, it’s not ‘You can pay me now, or you can pay me later.’ Instead, it’s ‘You can pay me now, or you can pay me a whole lot more later.'”