Warning signs that people don’t really understand agile

With “agile” becoming increasingly popular as a buzzword, and with more companies adopting agile methodologies as official policy, it’s common to find people claiming to be more agile than they perhaps really are. This may be either through misunderstanding, or deliberately in order to claim compliance with a corporate target. Here a few things I’ve come across that set warning bells off for me.

Talk of “phases”

However painful and inefficient waterfall development might be, it’s a difficult habit to break, and often people try to hold onto the security of a methodology they know, while trying to introduce agile at the same time. It’s a fair bet that someone who says something like “that user story’s still in the high-level design phase” probably isn’t making the best use of agile practices.

Some teams claim to be using agile techniques “during the development phase”, sandwiched between traditional waterfall requirements capture, design and test stages. This is a reasonable starting point when moving to an agile process, but as a strategy in itself it misses the main benefits of agile, which are short lead times (leading to quick feedback) and flexibility.

As an illustration, I recently spotted a diagram claiming to represent an agile process, and looking a bit like the one below (hopefully I’ve disguised it enough to protect the source!)

The problem with this approach is that, although iterative development in itself is an improvement (particularly when it comes to integration), the real benefits aren’t realised until your users can get their hands on each iteration, so they can provide the feedback which is vital to refining requirements and keeping the project on course. Also, there’s only so much flexibility you can have during development when you’re working to a design produced by someone else, from requirements captured by a third person.

Another manifestation of this problem is the classic “compressed waterfall” anti-pattern, where a team tries to move to frequent small releases by simply compressing a specify-design-develop-integrate-test-release lifecycle (often with document-driven quality gates between the phases) into a few weeks.

Fixing this one is just down to education, and getting the point across that agile methodologies are radically different from waterfall, not just some new processes to complement a traditional development lifecycle.

Agility treated as something imposed from above

Although it’s great that agile methods have become mainstream, and are increasingly being mandated by organisations, they are still principally about people and their relationships, which makes them very hard (if not impossible) to force on unwilling teams. If people are grudgingly “doing agile” because they’ve been told to, they probably aren’t actually embracing the values, but are just implementing some mechanistic practices. The same can apply to subcontractors who have been asked to work in an agile way, which conflicts with an embedded “command and control” corporate culture.

I think the best way to try and convince people of the value of agile is to expose them to teams that are doing it well (or are at least trying to), and to show them how much more productive, rewarding and – as far as possible – fun it is compared to old ways of working.

Requirement sign-off and change control

Agile projects should Welcome changing requirements, even late in
development. That means not asking your customer to sign off and freeze requirements before starting to implement them, and not using change control as a barrier to make it hard for those requirements to change.

Bolting on agile processes and tools

There are a number of tools that are popular on agile projects (unit test frameworks, continuous integation servers, and so on), and it can be tempting to think that as long as you have some JUnit tests, build your code using CruiseControl, or even (don’t laugh) store all your project artifacts in StarTeam, that makes you agile. Of course if those tests are written after the code and never run, if you only build once a week, and if your user stories run to several pages each, have no acceptance criteria or business value, and are estimated by a project manager, then you’ve got long way to go.

Similarly, calling every meeting a scrum or stand-up, renaming releases as iterations and requirement specs as user stories doesn’t make you agile!

A quick glance at the manifesto should serve as a reminder that there are more important things than processes and tools.

A belief that your development process is perfect

One of the agile principles is:

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Paradoxically, the further you go down the agile road, the more you realise the distance you still have to go. It can be tempting when you’re used to high-ceremony processes and quality plans to try to specify an agile process for your project, then expect it to be set in stone from that point forward. Agile teams should be constantly evaluating their working methods to see which are working well, which have stopped adding value, and which can be improved.

[Update] I just came across Pretending to be agile
on InformIT by Pete McBreen, who puts a similar point better than I could. It also reminded me that I’d forgotten to mention resistance to requirement change, which I’ve now added.