, , ,

Dispatches from the Agile Government Trenches

Agile CAN work in Government, and here’s a great resource to get you started.

The National Audit Office across the pond just published what I think is an excellent review called “Governance for Agile Delivery.”

The stars must be aligned, because this is something we are discussing at my workplace and I posted a question yesterday: Can Government Do Agile?

If you are interested in implementing a Lean or Agile delivery method for products in your agency or company, you MUST read this report.

Part 1 gives an introduction to Agile and it’s core principles.

Part 2 addresses the need and cites some Agile Government initiatives already underway

Part 3 focuses specifically on principles for governance of Agile projects

Part 4 is probably the best of all; case studies of how 7 private-sector companies have implemented Agile governance.

Part 4 in particular is a great read, because when you’ve finished you can start to see how one implementation would suit your agency or company better than another, or start speculating about how a hybrid between two or more of the case studies described would be a potential fit for your organization.

Please read the report, it’s not that long – then come back here and let’s chat about it.

Leave a Comment

4 Comments

Leave a Reply

Josh Nankivel

Bi-weekly or monthly prioritization meetings appear to be a rather common thread throughout the case studies. A definite must.

Josh Nankivel

4.86 – “To quantify the value of a new service or product and whether it has been worth the investment, Simply Business is using a ‘Lean Startup’ approach. Projects start with a ‘leap of faith’ hypothesis, such as “We believe brokerages would be eager to use our platform”. Based on that hypothesis, they decide on measures that prove it and build something that will most quickly demonstrate it.”

I love this – learning is the key objective as you iterate. With many waterfall-style projects in the US Government these days, we spend a LOT of time doing design with a lot more assumptions than are necessary, and get feedback/learning way too late.

From the Agile Manifesto: “Produce working software in preference to comprehensive documentation.”