A Recipe for an ‘Agile for Policymakers’ Training Session

If you’re a product manager and you’re working with policy makers, one of the things you’ll get asked all the time is: ‘What is Agile anyway?’. If you hear this, say ‘Why don’t I run a training session for your team on Agile…?’.

There’s a tl;dr how-to recipe (agenda) at the end if you want to get straight to it.

This is an opportunity to grab with both hands — you might not get it again. One of the key principles of #OneTeamGov is to break down siloes between teams and this is your chance to build empathy between the policymakers and agile teams. In this blogpost I’ll tell you about a quick training session you can do for a whole team of policymakers in an hour that will answer that question and build understanding so that you can begin to involve them more in what you’re doing.

I learned how to do this session from the brilliant Mark Dalgarno, but I’ve made a few tweaks as I’ve gone along. This session relies on the principle that people learn best through experience and applying themselves to a problem. The challenge is that there is much more to being Agile (and #OneTeamGov) than you could possibly learn in an hour. Therefore how can you use the time most effectively to deliver as much of that valuable knowledge and change the team’s mentality in the shortest possible time. At its core, what the session does is takes the team through an Agile approach to learning about Agile (#meta). You make a wall, prioritise what to talk about, talk about it, learn, rinse, repeat.

There are a few things you will need for this — simple things though. Pens, post-its and a decent quietish space. You will also need a good working knowledge of agile.

Before the session there are a couple of things you will need to do to prepare. Fear not — it’s not difficult.

Write up ‘To Do’ (or ‘Options’), ‘Doing’ and ‘Done’ post-its and then write up post-its with a bunch of Agile terms or features that you think they’ll want to know about. For example:

• User needs
• Roadmap
• Sprint
• Sprint planning
• Retrospective
• Stand up
• Show and tell
• User journeys
• User stories
• Backlog
• Product manager
• Delivery manager
• You get the idea…

I would also recommend reviewing this blogpost so that you don’t miss anything.

When you are in the session, the aim is to get the team experiencing Agile and how it can squeeze the most value when time is very short. Always explain why you are doing things in terms of how it delivers the most value to users (remind them that they are the users) as quickly as possible. Once they’re in the room and settled, take them through the following steps:

1. Intros — introduce yourself and get everyone else to say who they are and something about themselves.

2. The brief — explain the purpose of the session (for policymakers to learn how to interact with Agile teams) and how the best way is to experience it and do it rather than just hear about it. Introduce visual management as the technique you are going to use to take them through the material (put up the ‘ToDo’, ‘Doing’ and ‘Done’ post-its, tell them that they are going to experience Agile, not just hear about it and tell them that it’s an experiment.

3. The brainstorm — tell them to individually write down two or three things about agile that they don’t understand, one per post-it and then ask them to hold on to them. This teaches them that in Agile it’s important that we get a diverse range of views and that everyone’s viewpoint and needs are unique and useful. Make sure that everyone contributes — some people will be shy but they might need you the most.

3. The first iteration — Put up the post-its with agile terms that you wrote down before the session started under ‘To Do’. Ask them to prioritise the list.

4. The second iteration — collect up the post-its they’ve just written and add them to the same column. Now prioritise the list again. The stuff you guessed at the start won’t be what they wanted to know. When I last did this, I used the list of words above but it turned out that the team was about to start working on an Alpha project so they had some understanding of the lingo and wanted to learn how to effectively engage with an Agile team doing an Alpha and what they could expect. The questions were like ‘What is an alpha for?’ and ‘How will we know if the team are doing the right thing?’. You can answer their questions and point out that you didn’t really know what they wanted — you had to ask them. This is when you explain the first point: USER NEEDS and CUSTOMER COLLABORATION.

5. The third iteration — Now you get to the explainy bit. Go through the tickets, one at a time, explaining what the topic means in very high-level terms. Encourage them to jump in and ask questions. If any questions come up that require a substantial answer, write them up and add it to the ‘ToDo’ column. After you’ve collected a few of those new questions, prioritise the list again. This is when you explain PRIORITISATION. Keep going (you can repeat the above a few times if you have a small group or good pace in the room.

6. The retrospective — About 10 minutes before the end stop explaining and ask for feedback. Is there anything that you aren’t covering that they really want to know about (they will have thought of new things)? Are they learning what they need to learn? Should you go quicker? Slower? Recover some old ground? How can you do better next time? Get a steer from them on how to use the last 10 minutes to best effect. Then tell them that you just did a Retrospective and use this as an opportunity to explain RESPONDING TO CHANGE

7. The final sprint — Do whatever you decided for 7–8 minutes but use the last 2 minutes to look back over what you’ve covered, take a photo of the session and ask them if they’d like it written up. This is a product: A record of what they’ve learned, evidence of progress and a memory jogger if they ever have to remind themselves. It also shows what you didn’t get to — so they can research later if they have the need. Use this to explain DELIVERING VALUE.

Then explain to the team that they’ve just completed their first and smallest Agile project.

Recipe for an Agile for Policymakers session

You will need:

• Pens (enough for all the people being trained)
• Post-its (again, enough)
• A room with one wall that you can put post-its on
• Working-level knowledge of Agile and an understanding of what matters to policymakers

Before you start:

• Write up post-its
• Review this blogpost.

In the session:

• Intros, the brief and setting up the wall (5 minutes)
• Brainstorm what they want to learn (5 minutes)
• Iteration 1 (What you think they want to learn) (10 minutes)
• Iteration 2 (What they think they want to learn) (10 minutes)
• Iteration 3 (What they really want to learn after having listened to you for 20 minutes) (10 minutes)
• Retrospective (5 minutes)
• The final sprint (Deliver the last bits of value in the way that is best for them, review the wall to show progress) (15 minutes)