Shorter Is Better But It’s Not Agile

I’m hearing and seeing the word ‘agile’ more and more around the office. It comes up in hallway conversations and management presentations. Managers have gotten the message and want us to be more agile. That’s great, right? So I ask them what it means to be more agile and the answer I get is rather vague.

It appears to come down to doing more frequent software releases where each release includes incremental enhancements. I don’t hear anything about changing the underlying development process, currently waterfall for most parts of the IT department. Is that all it takes to be ‘agile’? Just release more often?

And so it begins…

This is frequently how the agile conversation starts in big companies. Senior managers decide to be more agile in their approach to software development. They define the word agile however they choose. Their choices are usually founded on protecting much of the status quo and keeping changes to a minimum. Their goal is to improve, not reengineer.

The end result is often smaller and shorter waterfall projects. Granted, this approach reduces risk, which increases with time. So if risk reduction is the primary goal, the technique makes sense — but it’s not agile software development. It’s not even a first step toward using real agile development.

This is how agile approaches using the techniques of Scrum, Kanban, XP and/or Lean get a bad rap. Any software development approach can be called agile. It’s simply a label. Take any development process, make a few tweaks to address perceived shortcomings, and your team is agile — well, at least it’s more agile than it was.

Waterfall in disguise…

However, nothing changes fundamentally. The teams still produce lengthy business requirements documentation. They continue to generate functional and technical specifications. They leave their change prevention — sorry, change control — process in place. They leave the testers out of the loop until the final development stage.

They may achieve some incremental gains as a result of reducing risk. The success rate of projects may increase (depending upon how one defines success). But important questions remain…

• Have the relationships between technical and business people improved?
• Are the stakeholders and user representatives actively engaged with the development team?
• Are lead times shorter for new feature requests?
• Is the quality of the software better?
• Are the software users/buyers delighted?

Take my advice. Stop focusing on the process. Start focusing on the users.

photo credit: Mykl Roventine via photopin cc