I’ve been working as an agile coach at the Home Office for nearly a year and have had the luxury of seeing lots of teams in London, Sheffield and Croydon ‘do’ agile.
I get such a buzz when I see something being done right, but have also had awkward moments when I see folk making heavy weather of something that could be so simple.
So I thought I’d write about how to do agile right, starting with the basics.
What is agile?
Agile is a delivery process – an iterative approach that’s used to build things in stages, instead of trying to deliver something in one go.
As well as building in stages, agile strips away unnecessary process. Projects on the build are broken down into user stories, which are prioritised and delivered in short sprints.
This approach allows teams to react to change – to change the thing they’re creating. Build something small. Test it. Show it to the users. Does it do what it needs? If not, try again.
Build. Test. Repeat.
Why we use agile
We use agile so we can deliver the right thing in the right way. It’s a process that likes to uncover problems, then fix them. To fail fast, then fix fast.
Agile allows teams to ask questions. ‘What’s the problem and how will we know when we’ve solved it?’ ‘What’s the thing we need to do next to deliver the most value?’
Building, then testing what we’ve built uncovers the problems right at the start. ‘Our delivery pipeline is a bit wonky.’ ‘The design we’ve chosen is not effective.’ ‘We’re testing the wrong things.’ ‘The end users need something different from what we initially thought.’
It’s much better to find these things out at the start so you can fix it, rather than just before your deadlines, when it’s too late.
Having a retrospective – a review of work – every few weeks also allows problems to be aired and lessons learnt. Teams ask themselves what went well, what went less well, what they could do to improve.
Agile also encourages stakeholder involvement. Regular show and tells let them see the thing that’s being built: some code, user research, content, a change to a process – anything. The team tells how they came up with the solution, what it does and how it does it. People can ask questions. Try doing that with a document.
What happens when we’re not agile?
If we didn’t build things in an agile way, we might stop inspecting what we do and our things – the services, projects, things we’re trying to build – could gain dangerous momentum.
Isn’t it safer to take small steps and build on the knowledge we gain along the way, than plan for a big-bang release?
Teams might stop asking 'Why are we doing this?’ and start delivering things that may not help anyone. Toeing the party line. Doing what they’re told. Not thinking. End dates might become more important than solving problems. Teams might become slow.
There’s nowhere to hide in agile – every part of a process is discussed in the open in the daily stand up meeting. If there’s a problem – a blocker – it’s discovered and either solved or removed, not left ignored, becoming a bigger problem later down the track.
How agile should work
Agile will not work if there’s no trust. Form a team, give them the problem and let them get on with solving it. Leave them to it unless they come to you for help.
Pretend agile (‘Look: some Post-it notes!’) sitting under the umbrella of top-down micromanagement causes the greatest delay. It’s not honest and teams become confused.
There’s nothing wrong with a waterfall process, as long as that’s what’s been agreed up front and you choose the right team and project. But don’t kid yourself that waterfall and agile can co-exist – they’re mutually exclusive.
Who’s who in an agile team
The product manager. This is the person who decides what's done next.
They define the ‘thing’ being created. They assess the needs of the users (including administrative staff, management, the ‘customer’, any technical constraints) and prioritise them to deliver the maximum value. These could be savings, efficiencies, changes based on real world events.
The team delivers a solution for each need, then the product manager reviews and releases to the end users.
Done right, this can be a very fast process.
The team may need someone help to improve the process. This falls to the delivery manager, also known as the scrum master.
That’s it, get building.