Want to go Agile? Here’s how
Agile project management is a super helpful way to organise your thoughts and work practices. Here’s a quick explainer that breaks down the basics.
We’ve also written a case study about how our Public Sector Innovation Network team uses the principles of Agile for our own purposes. We’re not saying we’re experts, but we are saying you don’t need to be an expert to get benefit.
The Agile basics (MVP)
(MVP being, in this case, both ‘minimum viable product’ and ‘most valuable pieces’.)
In our humble opinions, there are 4 pieces of agile project management that you can start with:
- tasks - recorded on discrete pieces of paper or post-it notes
- a defined ‘sprint’ - a period of time, over which you will complete a set of tasks
- a board - with 4 columns, but maybe more
- a daily stand-up meeting - literally standing up
Note: To get your head around the Agile ideas, we recommend starting with something physical. You can always move to a digital version, like Microsoft Teams.
1. Write down tasks
To start, you need to know what you need to achieve. Begin by writing down tasks for a project or regular work.
- Write one task per post-it note (or thing you’re writing it on).
- Each task should be a discrete piece of work (preferably achievable in under a day).
- Start with a verb (for example, ‘Invite Nick to the stand-up meeting’).
A note on post-it notes
Post-it notes can get a bad rap as being too-cool-for-school, but their utility outweighs any faddishness. A post-it note can be picked up and placed somewhere else with ease. A post-it note is constrained in size, which means your tasks needs to be clear and concise.
Some other tips for post-it notes:
- Use a Sharpie (or other fine-ish tipped permanent marker). It means you can read it from further away and you can’t write an essay.
- Write all the information needed on the post-it. ‘Invite Nick’ means that someone else can’t pick up that task without also picking your brain.
- Pro-tip: by being consistent with the colour of post-it note you use, you get an easy way of seeing, at a glance, how many tasks there are in a given category (the categories themselves being up to you).
So grab some post-it notes, grab some markers, and get set to get all your tasks down.
2. Define and plan your ‘sprint’
A sprint can technically be any period of time, but we strongly recommend starting with either 1 week or 2 weeks.
1 or 2 weeks. Your choice. Pick. Cool? Cool.
Now do a sprint plan.
- Look at all the tasks you wrote down.
- Make a pile of all the tasks you need/want/can achieve in the next sprint (so, 1 or 2 weeks). Doesn’t matter who is supposed to do them as that can change. Don’t worry yet about when in the sprint they need to happen.
Cool, now it’s time to build your board.
3. Create your board
You need a place to keep all these tasks and to be able to move them around so you know what’s happening when.
There are two main types of agile boards:
- Scrum (for project work)
- Kanban (for ongoing work)
But we’ll let you in on a secret – the name doesn’t really matter.
We recommend starting with 4 columns, in this order:
- This sprint
We’ve chosen these names because they’re mostly plain English, while also retaining a useful piece of jargon - if you’re ‘sprint planning’ you’re doing this one specific, agile-related thing. If you were ‘fortnight planning’ you might be talking about your personal life, or your gaming habits…
Take all the tasks you put into the ‘this sprint’ pile and put them in the ‘this sprint’ column.
Take all the other tasks you wrote down and put them in ‘backlog’.
Cool, now it’s time for a stand up!
4. Get up, stand-up…
The last piece you need for an Agile MVP is to choose what tasks you’re going to do that day. You do this at the daily stand-up meeting.
- The stand-up should have a time limit - start with 10 minutes and see if it’s enough.
- The stand-up should happen at the same time every day. EVERY DAY.
All good meetings need an agenda, here’s yours.
- Everyone stands at the board.
- Someone is elected boss of the meeting (see ‘Scrum-master in the glossary), they start a timer.
- The first person answers the following.
- How are you feeling? You can record this somewhere on the board, smiley faces or emoji are good, or just talk.
- What did you get done yesterday? Move the corresponding post-it note from Today to Done.
- Was there anything that got in your way (see ‘blockers’)? Make a note of anything, especially if it was an extra task that wasn’t expected.
- What are you going to do today? Move those tasks from ‘This sprint’ to ‘Today’.
- Repeat for everyone in the team. The Scrum-master should keep the meeting moving along quickly (in a friendly way).
Your team should all now know what other people are doing, what they need to get done that day, how they can help each other if needed, and how you’re progressing on your week’s-worth of work.
5. Sneaky bonus step: retro
So, we know we said you only needed four pieces, but this fifth one closes the loop that you started when you planned your sprint – the retro.
Retro, as jargon goes, is just a shortening of ‘retrospective’ (but feel free to wear flares).
The retro should happen at the end of the sprint, and you should take a look at your board and see how you went.
Ask the following questions:
- Did we complete all the tasks that we needed to during the week?
- What went well?
- What didn’t go well?
- What does that mean?
- What can you do about it?
A proper explanation of a retro needs its own proper explainer, but for this purpose, you’re trying to work out how you’ve worked, and what you can do to make that better.
Also, be honest here. If there were things getting in the way of these tasks, that’s legit. If those things include motivation, means-of-production or mental health, that’s legit. This process can be a really helpful way for managers to, well, manage their team’s work, and recognise gaps in skills, resourcing, knowledge, whatever it is.
After you’ve done your retro, pack everything away and go home. Then start back at the sprint planning, where you look at your backlog and move things across to the next sprint.
A project management methodology that organises work into short bursts (sprints) so that changes can be made according to what has been learnt in those short bursts. ‘Agile’ and ‘agility’ can also describe how an organisation/team is able to change quickly. For clarity, we use a capitalised, proper noun ‘Agile’ to describe the project management methodology.
The backlog of tasks that has to happen. This one’s pretty straightforward actually.
Should really be called a ‘daily stand-up meeting’. It’s a meeting, that happens daily, and you stand to keep it short and snappy.
A variant of Agile aimed at continuous improvement of ongoing work, as opposed to discrete projects. For discrete projects, see Scrum.
A visual board that organises the tasks you have to do. Sometimes people use ‘Kanban’ as a noun to describe the boards, like ‘Everyone on level 9 must make sure their kanbans are taken down because the windows are going to be cleaned’. This is technically wrong but y’know, language is fluid.
Minimum Viable Product (MVP)
An MVP is the version of a thing (project work, software release, tea-bun) that is just good enough to put out in the world. You put out the just-good-enough version to learn how people use it, what could be better, then you make those changes in the next sprint. That’s basically Agile in a nutshell.
Actually, this name is completely new to us, but we’ve done the practice before: You make a calendar that tracks how people are going. From there, you can look for patterns to hopefully make life better for members of your team. Plus, Niko-niko is an excellent name.
Planning poker (also known as Scrum poker)
Assigning scores to tasks based on how long something will take or how difficult it will be. You sit in a circle with cards that have numbers on them. The person leading the meeting points to a task and everyone plays a card with the number they think the task is worth. It sounds slightly bonkers, but is actually probably the most valuable advanced Agile move you can do.
Short for ‘retrospective’. A meeting that looks back at a chunk of work and works out how it went and what could be done better next time. (There are a variety of variations of retros, try to find the one that best fits what you need.)
A variant of Agile aimed at discrete projects, as opposed to continuous improvement of ongoing work. For ongoing work, see Kanban. Also, this term was put in place in a place in the world that doesn’t play a lot of rugby, but comes from people looking at a stand-up meeting and thinking, hey, that’s kind of like a scrum. As any second rower who is also a Scrum Master can tell you, it’s not (though we’re kinda into the idea of two teams having competing stand-up meetings). For clarity, again, use the capital, proper noun for Scrum to avoid people thinking you’re having a laugh.
Like a Kanban board but for the Scrum style of Agile.
The person who runs the stand-ups. This name seems to come across even if you’re doing Kanban work (it’s very rare to hear of a Kanban Master). Not a name for the half-back/scrum-half.
A short period of time over which a certain amount of work will be done. Almost always 1 week or 2 weeks.
A meeting that happens at the start of a sprint where you decide what will be in the sprint. Sort of the opposite to a retro.
A generic term for a Kanban or Scrum board. Never actually heard someone use this, but it makes sense.
Literally a fancy word for setting a timer. If you ‘timebox’ something you say that thing can’t go beyond when the timer stops.
The Public Sector Innovation Network (PSIN) was an Australian government network helping public servants understand and apply innovation in their daily work. PSIN ceased on 8 January 2021. See more innovation resources, case studies and news from PSIN.