A thumbleful of notes from a couple of the sessions of the Agile Business Conference 2011. First Jerrett Myers’ and James Yoxall’s talk on lessons implementing an agile project for the Home Office and Metropolitan Police. Then Andrew Craddock’s and Chris Davies’s talk on introducing agile governance at Axa.

These notes are terse, but in true agile fashion I’d suggest there is little additional value in turning them into beautiful sentences…

Delivering Agile in Government: Learning lessons from the commercial sector

Jerrett Myers of the Institute for Government:

• The IfG considers itself less of a think tank, and more of a do tank.
• Classic government problem: benefits are accrued by one organisation within government, but the costs are felt by another.
• The process of IT in government is fundamentally broken: Complex problems with numerous dependencies; Technology and priorities are rapidly evolving; Government processes are slow and unresponsive; …which all added up means requirements are obsolete, high cost of change, over-customisation, low user focus.
• Challenges include…
  • Cultural ones: Taking responsibility, and not being afraid to make decisions quickly; Dealing with high level outcomes rather than clearly defined requirements.
  • And skills shortages: No government CIO approached could suggest a single developer within their sphere to work on the pilot project.
  • And governance: The typical approach is to require 100% agreement before any work can begin.

James Yoxall, of IndigoBlue:

• It’s common for agile adoption to happen only at the fringes of the organisatoin, and if it’s not tackling problems at the heart of the organisation it will always stay that way.
• Projects are commonly implemented in agile to avoid normal governance.
• Good to think about agile as incremental delivery: an incremental flow of deliverables (as opposed to the traditional approach of a single deliverable). You don’t need a wholly effective “team in a room” to be successful at this, because you’re simplifying the problem. Simplifying the process means descoping until your first deliverable is a minimal system, and then you add the additional scope incrementally.
• This requires agile governance, which is a new skill. It requires talking about and explaining the individual steps of the journey, not just the end goal. It also includes showing the senior stakeholders that the many incremental steps add up to something adequate and that meets the overall goal.
• Agile is also: uncertainty management. Preparation is important, but you don’t necessarily need to do all your preparation before all your doing.
• At the start of project be clear about what your uncertainties are, and what their impact is, and decide if you should hold back on the doing before you have cleared up those uncertainties. Sometimes analysis resolves these, sometimes early actions and feedback resolves them. NB: Uncertainty is not the same as risk.

Agile Governance

Chris and Andrew are from Axa and nlighten respectively, and they reported on their experience of introducing appropriate governance structures for agile projects into Axa. I originally recorded these tweets:

• Governance for: Strategic (vision) alignment, risk mgt, resource mgt, performance mgt, value delivery
• Performance governance = delivery-centric measures, retrospectives, continuous improvement
• IT governance is the demonstration of control [is that the same as the actuality of control?!]
• Understanding != documentation, discipline != formality, quality != bureaucracy

My major take-away point, though, is that it’s important to understand what governance is for, and build your control structures accordingly. And one helpful way to determine what it’s for is to think through the consequences of there being no governance structures.

You want more than that? Well, you had to be there.