· 

Why Agile Fails

We’ve been ‘doing agile’ for our current project. And it failed.

 

No, the world hasn’t come to an end. The project will be a success; we’ll deliver what we promised and make our contribution to academic knowledge. But ‘agile’, as a way of delivering what we wanted, has failed us.

What happened was this. For a year, we organised our work as ‘sprints’, holding fortnightly planning meetings, deciding our tasks for the next two weeks, agreeing coordination and requirements, and ticking off completed tasks on our Trello board. But at the end of that year, we found something unpleasant: we had gone off course. By taking our decisions step by step, we had lost the oversight of our major goals. We had taken too long on a relatively minor deliverable, and not addressed the biggest unknown of the project until it was almost too late.

 

This was not a fault with Agile. All the agile methodologies have a clear way of keeping focus on the most important deliverables: prioritisation by the customer. And they have a well-defined means of addressing unknowns: the timeboxed task. The fault was one that is rarely acknowledged by proponents of agile: the customer role is vital and difficult. Lack of a single customer is a common cause of project failure.

 

Certainly, in this research project we had no customer. Instead, in the planning meetings we decided as a group which activities to undertake; there was no strategic overview. And the result was as you might expect: no strategic overview, no strategic deliveries.

 

So, what might our missing agile customer have looked like? The funding proposals for research projects are still forced to set them up as waterfall, with deliverables at fixed times over a long timeframe. Those responsible for receiving those deliverables exist at arm’s length from the project; they would be unlikely to have an hour a fortnight to devote to a prioritisation exercise. So, what kind of person might help us focus on deliverables, timescales, and risk? Asked like that, the answer is obvious: this is a project manager role. In putting together a research project to be agile, we need either a Co-Investigator (a role like non-exec director) with a project management skill set, or a paid external project manager for half a day per fortnight.

 

The agile approach has much to offer academic research. It worked well, with a project manager, in the CyBoK project; it offers a powerful mechanism to coordinate the working of different elements of any multi-person research project. But, in future, we must learn from our early failure in this project, and ensure that every agile research project has a tiny project manager role.

 

That will create research as it should be!

 

-       Charles

Image by Pete Linforth from Pixabay