Can software development in the public sector ever be Agile?
Posted by Mark Pillatt | Posted in Development, Government, Public Sector ICT | Posted on 16-04-2010
Tags: Agile, Development, Methodology
3
I am a project manager in the IT services sector, and I have been delivering, and watching my colleagues deliver, software development projects to the UK public sector for the last ten years. Some of these projects were labelled “Agile” by the sales team, the intention being that that the customer’s rather vague ideas on what he wanted would be clarified as the project progresses with some give and take on scope. The end product would be a system that best meets the customer’s business needs given the resources that have been contracted.
Those were the intentions. However, on the whole, it did not work out that way. Initial collaborative harmony between customer and supplier is eventually replaced by embittered discussions on the scope of what has been delivered and its cost. The customer falls back to the ill-defined, all encompassing “scope umbrella” that was discussed at project inception; the supplier pleads that he has gone far beyond the call of duty, and now faces financial ruin, to meet the customer’s unreasonably demanding expectations.
Why does this happen? What causes this loss of trust between customer and supplier, and the relationship to sour?
The four principles of the Agile Manifesto1 are
1. Individuals and interactions over processes and tools
2. Working software over comprehensive documentation
3. Customer collaboration over contract negotiation
4. Responding to change over following a plan
Surprisingly, it’s the first principle that causes the difficulty. Relationships between customer and supplier at the project level are often very good, with both parties eager to make the project a success. However, despite this, the flexible, responsive way of working vital to Agile is not achieved.
Individuals rarely have the freedom to act as such. Supplier project managers have to toe the company line, minimising commercial risk as much as delivering what the customer needs. On the other side, the customer project manager will live in a highly consultative world, with many stakeholders to satisfy underneath deep hierarchies. Consequently, the concept of autonomous decision-making is rarely realised. That’s even before taking into account that the lead customer representative is too over-stretched to commit enough time to development, because they are either still trying to do their day job or have wider responsibilities within the programme of which the software development is a part.
Even if some of the corporate constraints are shed, then the full benefit of working together may not be achieved until some time into the project. Customer and supplier will be coming together for the purposes of the project, and will probably not have worked together before. Indeed, the supplier’s team may also be newly formed. It takes time for teams to gel, and to become fully productive2. If they are trying to follow a methodology like scrum, then everyone needs to know what that means, and have some practice doing it, before the full benefits can be reaped.
As for the other Agile principles:
2. Few people nowadays will argue against the importance of working software over comprehensive documentation (unless, of course, they are independent “customer friends” eager to prove their worth, in which case they will demand both, usually in retrospect).
3. Contract negotiation often wins over customer collaboration. Enough said here; there are reams written on public sector procurement practices elsewhere.
4. Most customers and suppliers want to do the right thing by developing systems that meet current rather than historical business requirements, and will strive to do so unless stifled by surrounding bureaucracy.
So, if Agile development does not work, what should we do? Revert to the devil we know, Waterfall? Safe – Yes. Effective at delivering systems that meet current business requirements in a timely manner – No. Instead we should try to be nimble if not properly Agile:
A. Develop in small chunks. Deliver capability incrementally rather than in a big bang, and let the business start reaping the rewards afforded by the new technology. A further benefit is that requirements for later development will be better articulated against the background of a working system rather than a blank page.
B. Base projects on outline specs which fix the scope but not the detail. Detailed specs can be written when the project is in flight, close to development time. And specs need not be homogenous; use cases, wireframes, prototypes, etc – use the tool that conveys information best in context.
C. Interact. Review progress regularly, not just by examing the time-line, but look at what has been built and gain feedback; the fewer surprises at delivery, the better.
D. Engineer the software. Grasp Agile good practice such as continuous builds and continuous testing. The earlier that there is a “working” system, however narrow in scope, the greater the likelihood of a stable release.
2 Group Genius: The Creative Power of Collaboration by Keith Sawyer (ISBN-13: 978-0465071937) is an interesting and enjoyable read




