Skip to main content

Riding the Paradigm - where agile meets programme

There are challenges to running an agile approach to delivery inside a larger organisation where agile is not yet fully understood. We are frequently asked how we approach these challenges and manage them here at GDS, so here Mike Beaven explains how we are riding the paradigm and the lessons we have learned along the way.

I was slightly bemused to be told the other week that I was 'Riding the Paradigm' by a colleague from a software engineering house.  I had just been explaining the challenges of marrying our agile development heart with a broader government change programme.  The expression was, I believe, coined by Jim Highsmith (a signatory of the agile manifesto) to describe the situation facing organisations where there is a need to work in both an agile and a corporate programme way.

What this mean is terms of Cabinet Office and GDS is that we have a pretty established and successful agile software delivery engine.  Whilst it is relatively new it has become a firmly established way of working beyond the core delivery teams, and lean/agile methods are used across GDS in a variety of teams.  However, we interact with other programmes and projects and need to be accountable when we spend public money. That gives us a challenge in terms of needing heavier processes and being able to articulate what we do in good old milestone, cost and risk ways.

The base premise here has been to make the programme processes lighter and more agile, let the project management office take the load from delivery managers but still be in control of our agile delivery streams in terms of money, risk and delivery expectations.

We have made some good progress in terms of the way new work is initiated, assessed and sized up ready for progress onto delivery.  Business Canvas has been a useful tool in understanding the context of digital product and a means to challenge a departments approach.  We are now looking to apply this to a wider set of initiatives (around 30) across 17 departments.

We are still learning in terms of how we manage the in-flight delivery work and get a view on risks without disrupting the flow of delivery. This will be our focus area over the next few months as GOV.UK moves into its first live delivery phases and co-delivery projects with departments move out of prototyping and into serious beta work.

Our main learning so far:

  • You need different methods for different areas of managing delivery - one size does not fit all.
  • Backing to implement programme techniques into agile teams - trust is key and talking with delivery managers beats a written report.
  • Control areas like risk, people allocation and spend control centrally - let one team do the worrying.

For the time being though we will be on that paradigm.

Sharing and comments

Share this page


  1. Comment by Transforming government services | Government Digital Service posted on

    […] lot of time working with departments on pilot projects in 2012, and I mentioned some of the methods in a blog post last summer. This helped us understand how best to work collaboratively with departments and agencies, whilst […]

  2. Comment by mpw1950 posted on

    A sound programme approach has a strategic vision supported by a capability roadmap. Traditionally the roadmap has been a series of large, sometimes multi-year, delivery projects. There is no reason why the roadmap should not be more granular and consist of incremental agile elements.

    The smaller project means that quality, cost, risk and timetable can be more easily understood and therefore managed. However all too often, as the post hints, corporate oirganisations impose inappropriately heavy governance bureaucracy on even small manageable projects so that managers spend more time worrying about compliance than delivery.

    For agile development (and business change) the PMO has to adopt similarly agile governance methods. It works but it is rarely allowed in practice. It is not so much about tools but senior management attitudes.

  3. Comment by just0musing posted on

    When you say "Business Canvas has been a useful tool in understanding the context", do you mean Business Model Canvas as in this at ?