A few months ago an article was published in Computer Weekly where corporate IT Lawyer Alistair Maughan, argues the case that Agile will not work in Government projects. I didn’t see this article when it was first published, but it was brought to my attention when a colleague noticed that one of the comments arguing against the article, referenced a presentation I gave.
Many thanks to Francis Fish for referencing my presentation where I discussed introducing Scrum on a UK government project and used Agile methods to rescue a failing waterfall project, again within a UK government programme of work. I’m really glad my message got across despite the ropey presentation, although in my defence it was my very first attempt at public speaking.
I’ve been working on UK government projects for over 10 years. During my initial 5 years on government accounts I was part of Valtech teams using RUP and aspects of XP, the later 5 years I was fortunate enough to implement Scrum and Kanban on my projects. With my Agile UK government experience I feel I am justified in challenging many of the misconceptions mentioned in the article.
Firstly, mismanaged projects will go spectacularly wrong independent of the project management framework. Projects fail for many reasons including ill-conceived requirements, poorly skilled developers, inept management as well as inappropriate SDLC.
So to address some of the points in this article:
“But Agile simply won’t work in the real world of government ICT.“ This is not true, Valtech have implemented a number of successful projects using an Agile SDLC on different government accounts. Often Agile methods have been used to “rescue” otherwise failing projects but increasingly the merits of running a project using an Agile approach from the outset have been accepted.
“We need a Richard Dawkins to bust the myth of the Agile gospel.” We need to bust the myths of Agile, that Alastair has heard and believed. Agile does all of the same value adding activities found in a waterfall project, just at an appropriate time, for example User Acceptance Testing when the real requirement pops out during development rather than right at the very end. This approach increases the effectiveness of risk management enabling us to make better choices over the life of the project ensuring on-time delivery if (and only if) this is the most critical measure of success.
“Under Agile projects, you pay a given amount of money for a set amount of effort. But you can’t guarantee a specified outcome for a specific price.” You can guarantee an outcome by controlling the richness of the implementation. A key differentiator of Agile methods when compared with more traditional approaches is the focus on outcomes in preference to outputs.
“Departmental budgets are managed very tightly” Agile enables much more detailed and accurate planning at the appropriate time, using prioritisation and identification of the richness of the solution that is acceptable to the stakeholders. With the added benefit of being able to more accurately account for the overspend as soon as it happens and justify the reduction in richness when appropriate.
“Agile can’t give you a clear specification of outputs up-front.” Neither can Waterfall, the chances of change is too high while the procurement proceeds, this says more about government procurement than Agile. A well executed Agile project will provide sufficient specification at the right time to satisfy stakeholders. It is not an issue of Agile projects rejecting documentation (or specification), rather that, when done well, they defer detailed specification to reduce exposure to late breaking changes or lessons learnt resulting in rework to the specifications.
“As if that isn’t problem enough, Agile offers insufficient means of remedy if things go wrong.” It’s a contractual responsibility not the SDLC to offer remedy. Further, an Agile project should provide evidence of progress in a far more tangible manner. Valtech (and many others) have been working hard to develop contracts that deliver the flexibility in scope that customers deserve while acknowledging the suppliers responsibility for the management of technical risks and the intrinsic qualities of the product.
“You can have an ICT project with a watertight contract, clear deliverables, openly and legally procured, with a fixed price and appropriate remedies if you don’t get what you want.” Waterfalls might deliver what the customer wanted at the time of specification but rarely what the customer needs; as has been often quoted, 40% of features delivered by waterfall projects are never used (Gartner). The act of insisting on a full specification of everything to deliver will actually make projects bigger. This is a natural consequence of the penalties traditionally applied when new scope is added late. By contrast an Agile project will be accepting changes in scope while encouraging challenge to “gold plated” solutions preferring “good enough” (but no less!).
Please find links to my presentation slides on implementing Agile on Government projects.