Sounds great doesn’t it. You go to an interview and the interviewer says “yes of course we’re using agile”, and it becomes clear on the first day that actually they are not using Agile. Not the conventional interpretation at least.
The trouble is that the term ‘Agile’ has a bit of a project manager feel about it. ‘Blue sky thinking’ and ‘giving 110%’ in a ‘thought shower’. You know the sort of thing. In the mind of a non technical manager, its the sort of term that evokes thoughts of speed, dynamism and efficiency. Ultimately, getting more delivery for less cost, and the ability to change direction at the drop of a hat.
Some of that is true but only to a certain extent, and critically WITHIN REASON. To qualify that, manipulating the backlog because priorities have changed is doable with minimal impact. A full on mid sprint U turn will annoy almost everyone, nacker the burndown, delay delivery and potentially compromise quality. Worse still, not having a proper backlog and dreaming up new requirements on the fly also carries a massive impact. This is not agile. This is the headless chicken approach to software development, I (and others) dub ‘Fragile’.
Unfortunately, I speak from experience of the effects of these non-Agile practices. Agile is not an excuse for not having a plan, it is not a license to change requirements with reckless abandon and nor is it a way of getting something for nothing.
I therefore feel its worth reflecting on Agile first principles to understand why this is the case and where the perceived flexibility and speed (should) actually come from and maybe help my fellow development community avoid similar pitfalls.
Agile is like a series of many short projects (sprints), typically 2 weeks. The project owner will have a long list of requirements (stories) collectively called the backlog. At the start of each sprint and in partnership with the owner, a subset of those requirements are selected for the coming sprint. We estimate the stories with a view to delivering a working piece of software that meets the criteria, ready to deploy by the end of the sprint. Its the accumulation of these working pieces over the course of many sprints that form the finished product.
Once the sprint has started, you leave it alone. You can do whatever you like with the backlog though, and that is where the flexibility comes from. As a project owner, there is medium-long term flexibility if priorities or requirements change. As a developer, there is sufficient short term stability to work effectively and deliver a working product. Everybody wins.
No massive functional specification to re-write when something changes on the business side – just a few extra stories on the backlog, and because the project owner sees progression more frequently problems on the development side are quickly identified and remedied.
Perceived speed is a product of flexibility. I say “perceived” speed because agile or otherwise, the amount of work is the same. The perception of speed doesn’t come from doing the same work quicker but from not doing the same work twice.
There isn’t that heart-stopping moment you might get in a traditional (waterfall) project as the final product of 6 month’s work is unveiled to the project owner and what’s been built isn’t what was expected. Some ambiguity or false interpretation of the specification has led a well-intentioned development team off on a tangent. Subsequent remedial work is generally required both to better articulate the spirit of the requirements in the specification and rework the product itself.
The agile approach relieves this problem with continuous delivery and promoting regular face to face communication. This encourages developers to ask questions where tasks are not clear and allows project owners to quickly identify and resolve any emerging tangents before they have a significant impact. This makes it far more likely that the product will be right the first time and no expensive reworks are required.
In my opinion Agile is a great methodology for software development projects, but like software itself, the key to success is in how its implemented. Understand what agile is and how to get the most out of it. Be wary of projects claiming to be agile that have poorly defined requirements and/or volatile priorities. As far as requirements are concerned, agile affords manipulation of the order of well-defined requirements, refining them as you go, NOT winging it.
I’ll finish by repeating my initial points; A full on mid sprint U turn is NOT Agile. Worse still, not having a backlog and creating requirements on the fly is also not Agile. That’s just fragile and it doesn’t end well.