Agile and the sound of one hand clapping
There is an interesting report out on Surrey Police’s SIREN project (Surrey Integrated Reporting Enterprise Network; a crime record storage and a data analytics software system).
The system was to be produced using an Agile methodology. The Notes in Appendix 1 highlight that one party in the development was not using Agile: “Modules are delivered in accordance with schedule and agreed Agile development methodology. However, no modules undergo formal acceptance (nether now or at any future point in the project).”
If you are the supplier on a £3.3 million software development project (the total project was £14.86 million) and the customer is not doing the work that Agile assumes will happen (e.g., use the software, provide feedback, etc) what do you do? One thing you are unlikely to do is to stop work. But what do you do?
What happened on the customer side? I imagine that those involved in software procurement at the Police did the usual thing of nodding as the buzz words were thrown at them, not really paying attention and not noticing that Agile requires them to do a lot of work throughout the development process. If I was working for Surrey Police and somebody sent me a load of software to install and beta test, without giving me the funding to do it, I would just ignore what I had been sent.
Paragraph 31 lists the grisly details of what happens when a customer has no interest in signing up to the Agile way of doing things. Or to be exact, (paragraph 91) “The Force’s corporate change and project management structures were based on the PRINCE 2 methodology.”
Paragraph 81 says something surprising “The Agile development process did not have all the necessary checks and balances to control a growth in scope as the products progressed.” Presumably this is referring to a consequence of using Agile on a fixed price contract.
Would the Police have gone down an Agile route if they had understood the work needed from them? I don’t have any figures for the customer costs of using Agile, but I suspect that initial costs will be a lot higher than a deliver everything in one installment at the end approach (the benefits being a system tuned to requirements). Also finding customer champions with the time and expertise to make new systems a success is always hard.
This brought to my mind a case study of software development by another country’s police organization: Sweden. It is described in the book “Lean from the Trenches: Managing Large-Scale Projects with Kanban” by Henrik Kniberg. Comparing both projects could reveal valuable lessons.
I could not get your link to work, maybe they moved the report. I searched it though and had a read. These are the points that jumped out at me:
* The project was oversold from day one, it would have taken a miracle to deliver what they promised.
* The project supervision was always slipshod, reports were on a “just trust me” basis.
* They hired a Test Manager late in the project, and this person decided to start using the “waterfall” methodology instead of what the rest of the project was using, and also decided to use “Factory Acceptance Test”, “Site Acceptance Test” and “User Acceptance Test” stages which are only considered best practice for delivering machinery, and barely apply to software at the best of times.
* They only hired a Training Manager late in the project, so quite likely end users couldn’t have done much early testing, even if they wanted to, unless they trained themselves up from scratch.
* At no stage was there evidence that they consulted with end users at all, neither at the requirements stage, nor at the testing stage.
* The scope was continually extended, apparently without any direct justification based on end user feedback (because there was no end user feedback).
So I agree that given the situation, an Agile methodology is not going to work properly. The end users absolutely must be actively involved in the process in order for Agile to be worth considering. However, let’s suppose they used a traditional “Waterfall” model instead. What would have happened?
* A formal requirements document would have been written up, still without any end-user consultation, but with input from all the high ranking government people who care a lot more about getting their two cents in and their name on the list of project bigwigs than they do about what this thing actually does.
* The company would have written to the requirements, and sent off regular progress reports saying that everything was on track.
* A Test Manager would have been hired late in the day, and handed a big lump of product and told to go test it, but only would have been allowed to test specifically against the formal requirements.
* Rumours would circulate amongst the end users that something big is about to hit them, but no one knows what, and anyhow they are accustomed with being treated like mushrooms so they just shrug and do their best.
* At some stage it would have been declared finished, and handshakes all round.
@Tel
Thanks for letting me know about the (not fixed) broken link.