Does Agile equal fast?

This is more a question than an opinion or a statement of fact.  In physical or sporting terms, the word agile has pretty obvious connotations of fast.  In fact, the first definition of the word on dictionary.com is “quick and well-coordinated in movement”.  But it occurred to me recently that the Agile Manifesto doesn’t contain any reference to speed at all.  This is an interesting discrepancy.

For me, Agile has always been about manoeuvrability: being able to react to changing requirements, and having the freedom to make wholesale changes to ones approach if things don’t turn out right on the first attempt.  But now I’m starting to wonder whether there’s a tendency among managers to view Agile as a way of increasing the speed of software development.  I’d love to know what you think about it, so feel free to let rip in the comments section below.

Now, Agile makes it easy to track a team’s pace accurately: the process of sizing stories relative to each other makes for a pretty reliable measure of the team’s velocity.

It’s also true to say that Agile, done properly, should always help to meet deadlines.  The iterative approach makes it far easier to produce software on any given date which, though it might be missing nice-to-have features, is still safe to release to customers (and note that I say “done properly” there — it isn’t always the case in my experience).  Compare this with traditional waterfall-style development, which often won’t yield something that can be released until the project is completely finished.

But this doesn’t imply that the pace of development is actually any quicker with Agile: it’s simple a trade-off of time against scope.  Developers have their own speed of coding; testers have their own speed of testing.  This, as far as I can see, doesn’t change according to which project methodology is being used.  If Agile works out well for the team, speed might improve as a function of rising morale (and I certainly don’t have any figures to back that up) but that’s an indirect result of the methodology being used, not a direct one.

If there is, as I suspect, an implicit association in managers’ minds of the words Agile and fast, it could actually jeopardise successful adoption of Agile methodologies.  There could be a very strong temptation to cut corners on the grounds that Agile has to mean quick.  This could result in rushing the all-important sprint planning and backlog grooming sessions, and skimping on the process of creating story cards and conditions of satisfaction.  And, if that’s happening, you can forget about any chance of getting executable specifications done.

If you’re familiar with Agile working, you probably don’t need me to tell you that failing to spend enough time on these things is really bad news.  Developers and testers must take the time to discuss each story thoroughly with the BA or Product Owner before work starts (the whole team doesn’t have to be in on these discussions, but at least the ones who “own” the story must be present).  Otherwise, how can you ensure a common understanding of the requirements when there’s no formal spec document to fall back on?  Equally, skimping on the process of breaking down stories into subtasks in the sprint planning session is likely to lead to important pieces of work being forgotten.  I wince when I see post-it notes on the task board that are either blank or just say “do it”, and it happens surprisingly often.

All of this leads to falling quality and rising risk, as tasks get missed and mistakes go unspotted.  Perhaps I’m wrong, and this isn’t anything to do with people’s interpretaion of the word Agile.  Perhaps it’s all down to business deadlines and business analysts’ time being spread too thinly between multiple projects.  Let me know what you think.