During my recent time at MHCLG I did a series of opinionated sessions on agile/digital ways of working I think of as the [IMHO] series. They were light on speakers note and long on rants – but the slides were solid enough so I am sharing what I can here.

==========================================

THE ART OF EFFECTIVE AGILE
Habits of happy, high performing agile teams in public service – IMHO

==========================================

TABLE OF CONTENTS

1. Agile in context
2. In/Effective agile
3. Agile mindset
4. Agile discipline
5. The GDS approach

===========================================

1. AGILE IN CONTEXT

“Agile: make it up as you go along.
Waterfall: make it up before you start, live with the consequences.”

Paul Downey (@psd), February 19, 2015

Agile means having the serenity to accept the things you cannot change, the courage to change the things you can, and wisdom to know the difference.

Agile in Government is not like the majority of the books or the blogs. The Civil Service is the home of bureaucracy, land of the plan and lover of the milestone.

…but despite this an agile practice has flourished in the belly of the beast it just has to get creative to be effective.

===========================================

2. IN/EFFECTIVE AGILE

FORMULA FOR EFFECTIVE AGILE:
agile mindset + agile discipline = effective agile

WHEN THINGS GO WRONG:
agile mindset minus agile discipline = agile inertia
agile discipline minus agile mindset = cargo cult agile

AGILE INERTIA:
The illusion of action due to an abundance of debate, experimentation and learning but no delivery (or plan).

CARGO CULT AGILE:
The illusion of action due to an abundance of prescribed activity without accomplishment (or understanding).

===========================================

3. AGILE MINDSET

I like the MODERN AGILE FRAMEWORK (modernagile.org) a lot more than any devotion to the original Agile Manifesto or any specific Agile™  methodology.

The framework consists of four principles:

• Make People Awesome
• Experiment & Learn Rapidly
• Deliver Value Continuously
• Make Safety a Prerequisite

AGILE MINDSET – IMHO:

• Agile is a way to cope with ambiguity
• Agile is a team sport…not the DMs job
• Agile means accepting plans change…all the time
• Agile requires [over] communication
• Agile requires openness, transparency and trust
• Agile benefits from a defined destination but the directions evolve in the journey

===========================================

4. AGILE DISCIPLINE

Agile discipline is the antidote to the distrust bureaucracy has for agile.
They see the madness but we demonstrate the method.

The book ACCELERATE :The Science of Lean Software and DevOps: Building and Scaling High Performing
Technology Organizations by Nicole Forsgren, PhD, Jez Humble, and Gene Kim is a pretty dry read and a lot of it is focused on more technical DevOps activity but the elements of it that focus on team ways of working and leadership have influenced me as much as anything in my career – it posits an approach that is disciplined and focused on delivery that I have found inspiring over the years.

Key capabilities include:

• Transformational Leadership (Vision, Intellectual Stimulation, Inspirational Communication, Supportive Leadership, Personal Recognition)
• Lean Product Development (Work in Small Batches, Make Flow of Work Visible, Gather & Implement Customer Feedback, Team Experimentation)
• Lean Management (Limit Work in Progress/WIP, Visual Management, Feedback from Production, Lightweight Change Approvals)

AGILE DISCIPLINE – IMHO:

• Robust retrospectives – open, honest and action orientated not avoiding the hard truths or airing pet peeves
• Stand-ups focused on sharing progress, identifying issues and seeking support not justifying how you spend your time
• Sprint planning is a conversation about optimising the delivery of most value in the available time while being honest about constraints and capabilities
• Follow the ‘3 C’s’ (card, conversation, confirmation) for stories…they are a collaborative activity – conversation is key
• Embrace ‘business driven development’ or similar to provide rigour and consistency to acceptance criteria
• Agile still requires ‘plans’ – product roadmaps and delivery/release plans – they just change and evolve.
  Do try and avoid specific dates though!

===========================================

5. THE GDS APPROACH

I prefer to think of it as THE GOVERNMENT WAY rather than a GDS thing these days – but the reality is much of the broader good practice still emerged and was codified by those early GDS folks (for this environment at least.)

It is more than agile though – it is an entire way of thinking about the work and it starts with the principles.

GOVERNMENT DESIGN PRINCIPLES (www.gov.uk/guidance/government-design-principles):

1. Start with user needs
2. Do less
3. Design with data
4. Do the difficult complicated hard work to make it simple
5. Iterate. Iterate. Iterate. Iterate. Iterate. Iterate. Then iterate again
6. This is for everyone
7. Understand context
8. Build digital services not websites
9. Be consistent
10. Make things open; It makes things better
11. Minimise environment impact [this one was new to me]

THE LIFECYCLE

The service lifecycle progresses through phases based on user needs:

Discovery → Alpha → Beta → Live

User needs are at the centre of this process, with iterative development at each stage:

• Discovery: Research and exploration
• Alpha: Prototyping and testing concepts
• Beta: Building and refining the service
• Live: Operating and continuously improving

It is important to remember though that it was never supposed to be quite so linear or replicate a stage gate model – it was ALWAYS supposed to be more adaptive and messier than that – with continuous feedback loops and iterations – Micheal Brunton-Spall summed it up way back in 2017 – Alpha to Live is not a linear progression

THE SERVICE STANDARD (www.gov.uk/service-manual/service-standard)

It is hard to underestimate how important the Service Standard has been to improving ways of working and embedding good practice in digital across Government (and beyond). Sure I have some thoughts about the state of Assessments in the Year of Our Lord 2025 but there is no doubt that the Standard (and the Service Manual) have been a huge boon to providing good outcomes for users and holding the poor instincts of some influential folks at bay.

Meeting users’ needs:

1. Understand users and their needs
2. Solve a whole problem for users
3. Provide a joined up experience across all channels
4. Make the service simple to use
5. Make sure everyone can use the service

Providing a good service:

6. Have a multidisciplinary team
7. Use agile ways of working
8. Iterate and improve frequently
9. Create a secure service which protects users’ privacy
10. Define what success looks like and publish performance data

Using the right technology:

11. Choose the right tools and technology
12. Make new source code open
13. Use and contribute to common standards, components and patterns
14. Operate a reliable service

TEST AND LEARN

I’ve been particularly impressed with the Test & Learn approach that the team at the Cabinet Office have been embracing (with help from Public Digital and Nesta). Less dogmatic, more dynamic and embracing skills and methods from other areas I think it is providing an updated blueprint for delivery.

A continuous cycle of improvement:

• Do whatever it takes
• Test the thing that matters the most
• Learn from the results
• (Repeat) to speed up this loop

(Reference: www.nesta.org.uk/report/test-and-learn-a-playbook-for-mission-driven-government/)

===========================================

Next up is my [IMHO] take on Roles, Responsibilities and Relationships in digital delivery.