The Need for Speed... and Why That's Bad!

I've written before about how software development teams are obsessed with going as fast as possible, and how that isn't necessarily a good thing.  That obsession isn't something that magically appeared with Agile methods - it has been around as long as I've been in the business.  I would assume that the mantra of "we want it yesterday, perfect and for free" came from somewhere! :)

I would suggest, though, that the 'need for speed' has become more acute with Agile.

Groups with whom I've worked are typically coming from a world of serial, phase gate processes.  A ton of time is spent defining and analyzing what will be built up front, and the construction phase is only a relatively small portion of the overall effort (at least on the Gantt charts!).

The approach that Agile methods take is to shift the beginning of construction forward, working from the start to verify the assumptions and decisions in the form of a real system.  This is absolutely a good thing, but I routinely find groups who think that ALL of time that would have been spent analyzing and designing the system can be replaced by a few days in a requirements workshop.  After a couple of days in a week-long workshop people become frustrated and start saying,

Can't we just go start building this now?!

Generally this sentiment comes from people who had not been involved very much in the requirements and analysis phases while using a traditional process.  By the time these people had received the specs for the thing they were supposed to build, they were already under schedule pressure and thus felt that any time discussing what is to be built is waste.

Using an Agile process is different.  Yes, we absolutely advocate spending much less time up front determining what is to be built.  We don't, however, advocate believing that in a few days the requirements for a complex system that integrates with other complex systems can be fleshed out into user stories that several teams can immediately pull into an iteration!  Jeff Patton suggests that 1 to 2 weeks is sufficient to create plans for 3 to 6 months of work.  Others suggest anything from a few hours to "as long as it takes".

Context, of course, is everything in this case.  One system may be able to make use of a Feature Fake that takes a couple of hours to hack together in order to run an experiment which will drive the real requirements.  For another system, the Feature Fake concept isn't just impossible, it would be illegal!

So, in many cases you can't simply jump from many weeks or months of analysis and design to a couple of hours in a workshop and expect to have an adequate level of understanding of what's to be built.  You need to take the time - slow down - at the beginning to create a shared understanding of the business problem to be solved, and to an extent how you're going to solve it.

"HERESY!! Agile is all about going faster!", you say?

Well, no, it's not.  It's about doing enough to be able to build the right thing at the right time.  The definition of enough will vary from domain to domain, system to system, and even team to team.  By virtue of not doing things that you don't need and deferring things that aren't important right now, you will indeed appear to go faster.

It's altogether possible that given the same set of high level requirements, an agile process may take longer to deliver all of them than a serial process.  An agile process, though, would seek to identify the most important subset of those requirements and deliver those as early as possible in order to obtain real-world feedback and incorporate that into the product.

Agile doesn't simply mean "fast".  It also means, "able to change direction quickly".