I’m blogging the conference Agile Approaches for Delivering Business Value
National Packaging Waste Database – a DSDM Case Study
Steve Watkins, Head of IT Portfolio Office, Environment Agency and Jeremy Renwick, Kubernetes Ltd
Summary
- Delivering the National Packaging Waste Database (NPWD) on time and to budget
- Facilitating a very diverse stakeholder community drawn from industry and the 4 regulators
- Managing the culture shock of imposing agile on a waterfall community
- Managing an agile project with a geographically distributed team
- Learning the lessons
Notes
Agile process was deliberately imposed on a traditional waterfall environment.
Packaging Waste regulation revolves around market in Packaging Recovery Notes – buying and selling of “evidence”.
At least 12 major stakeholder groups, including 4 agencies!
Project started in 2003 to replace paper-based system. Tight deadlines, so DSDM chosen as approach.
A single system for both the regulators and the regulated industries – first time in UK Government!
Success – users, industry and regulator like the system, time deadlines hit, budget met.
Challenges – Variation in stakeholder views, resentment, relocation, geographically distributed, very few people dedicated to the project.
Tight regulatory deadline, combined with a “proof point” meant that early stages were accelerated – lots of issues not sorted and which came back to bite later…
The view from the Environment Agency IT organisation – government – used to very structured process with rigid processes. Industry had said “here’s the money, get on with it”. Different technology. Tight deadline. Ouch!
As a regulator, the Environment Agency found it hard to cope with the idea of an outside body doing regulation, managing data protection, security etc.
Lots of confusion over roles – who was running this project? Two project boards – one inside Environment Agency, one across Environment Agency and the industry. Half were running with DSDM, half were in BRUF-land.
Resolved to one steering group, one PM, focus on who has skin in the game.
No end to the polititics – more discord over the future of the system and the implementation of regulation – the system forced clarity on a process with some discretionary ambiguity…
Another row before go-live – Environment Agency testers wanted to defer go-live for a collection of non-critical issues… Sometimes you have to just make a commitment! (note that code quality was good)
Culture/philosophy clash between DSDM and Government Waterfall…
Had uneasy hybrid of two approaches – effectively two sets of testing. Key learning point – sort out approach to testing early – without compromise. Go with Agile or waterfall – don’t try to do both.
Further row over support, hosting etc. In the end needed forced collaboration – lock the three sets of lawyers in a room until they agree!
Fundamental problem was conflicting attitudes to risk. Public-sector risk-averseness conflicted badly with MoSCoW.
If you want to procure agile services or projects you need to think carefully about procurement appraoch – most public-sector procurement approaches assume fixed requirements up front! Need to apply timebox and iterative disciplines to the procurement phase too…
Key learning for Environment Agency:
- One size (of process) doesn’t fit all
- Let go of some risks
- Learn to give up control and trust
- Effective and efficient are different things.
- Keep your eyes on the end goal
Key learning from project manager:
- Keep focused on deadlines and business requirements
- Just in time resolution of politics
- Communication – regular, frequent, face-to-face if possible, everyone to everyone. False economy to talk on the phone.
- Prototypes as early as possible
- Effective team-building
Update: Link to presentation on Jeremy Renwick’s site.


October 16th, 2008 at 1:43 pm
Hi,
This case study was an informative read, with points which echo my own experiences in applying Agile disciplines to UK public sector IT delivery.
My own experience at the Coal Authority was generally positive though with a few caveats:
- Making sure that 3rd party developers are familiar with using Agile/iterative disciplines can be a headache, particular in PRINCE2-dominated IT ‘cultures’
- User education: ensuring that business reps know IT nomenclature and are engaged for the duration of the project. I found a ‘terms of reference’ session with my own business reps at then outset proved invaluable
- Using MoSCoW wisely: I’ve discovered that prioritising requirements via MoSCoW can prove irrelevant and distracting in non-iterative project approaches. Make sure everybody knows why we use it, and how MoSCoW relates to a disciplined time-boxing approach.
- Communicate, communicate, communicate! Maintaining open channels between business reps and developers proved to be a god-send when code and database dependency-related bugs surfaced, as they worked side-by-side (or phone-by-phone) to arrive at fixes.