Australia Post: 4 Design Sprints 5 Weeks
This is the story of how Australia Post’s Small Business team got innovating fast!
Our value proposition is simple — help Australian small businesses become the business they want to be — but our technical platform is new, Australia Post is a large-scale enterprise, and our customers move fast! So we have to innovate and deliver quickly.
We have a ‘big, hairy, audacious’ campaign ahead of us and the way we currently validate and deliver our ideas wasn’t going to be fast enough to meet our deadline. Something had to change. So with consideration of our current delivery model, team, culture and stakeholders we decided to try Design Sprints. Not just one Sprint but four Sprints … in just five weeks!
4 full Design Sprints in 5 weeks (and a fifth a few weeks later) covering an entire program of work … and you thought one was hard to pull off?!
Before exploring the process in detail, here’s some some consistent themes that shone through over the 5 weeks:
Concentrated collaboration is paramount — As much as we want to work collaboratively and cross-functionally with our delivery, it’s sometimes hard to avoid working in a silo. A flat hierarchy (deciders aside) of subject matter experts (SME’s) didn’t only help velocity, it helped culture!
No meetings! Focus, focus, focus — Working in a large organisation makes it very easy for the day to be filled with back-to-back meetings. Asking for the full-time Sprint members and stakeholders to be available without question for the full 5 days was a hard sell. We used the metaphor of going on leave for a week to demonstrate that the world wouldn’t end! It wasn’t a holiday, but it sure was fun! But one thing was clear, even one meeting created disruption to the flow.
Our customers are the boss — A huge recruitment effort was needed to acquire a number of well-screened participants for 4 sprints over 5 weeks. And it was worth every litre of sweat. We invited everyone to our testing/listening sessions and, in doing so, instilled the culture of customer centricity within each and every one of us across the program. That’s over 200 people!
P.S. If you’ve never heard of a Design Sprint, you can learn more here or read the book. But let’s just summarise a Design Sprint as a great way to innovate and it gets you moving in 5 days!
Now this all may sound like fun and games, but let’s talk about how we brought it all to fruition.
Why did we choose design sprints?
We were really interested to see if this approach would be one that works with a SAFe (Scaled Agile Framework for Enterprise) delivery model.
And if it did work, would it enable us to deliver value faster to our customers?
The primary scope for the program’s next release had already been set. While this could be seen as a constraint in one way, in another way it really helped us focus on how we should spend our precious sprint time. Across the program we worked quickly with the strategy and program teams to understand the riskiest and most ‘unknown’ major features. We couldn’t afford to waste valuable Sprint time on the easy stuff.
4 Design Sprints in 5 weeks … that’s ‘cray cray’
But how did we run 4 full 5 day Design Sprints in just 5 weeks?
Pre Sprint Planning — All of them up front, over two weeks … that plan changed of course
Sprint every week — Except for a week we missed due to a public holiday
Two core teams — We had two full cross-functional sprint teams, raring to go! As one executed a sprint, the other was planning the next.
Belief in the team — Our stakeholders took a big risk and believed in the team to deliver on something we had never done before, and it showed!
We wanted to get going very quickly, so we partnered with ‘Odecee, A Cognizant Digital Business’ to provide two Sprint Masters, additional designers and prototypers. This allowed us to plan and execute the Sprints quickly and hit the ground running in just 2 weeks.
Who was on the sprint team? The challenge of involving everyone
Once we got momentum, EVERYONE (well, almost everyone) wanted to be involved, creating an interesting problem. The program team was traditionally very collaborative and so there was a sense of ‘missing out’ or ‘not being heard’. This was unusual but, in hindsight, a great problem to have.
We addressed this issue in the following ways to maximise wider team involvement:
Full-time team size — An ideal sprint team comprises 6–8 ‘full-time’ participants with others giving lightning talks or being deciders (stakeholders). Being in a large-scale enterprise is a bit more complicated than in a small organisation or startup. With complication comes a huge reliance on knowledge across our complex environment. Thus, to get a good grasp of knowledge, we stretched our teams to 13+ in some of the sprints. This made running the sprint harder but achieved the goal and team coverage we needed to capture the required knowledge.
TIP: The bigger the full-time sprint team, the better your Sprint Master needs to be at controlling the room. Activities also take longer with a larger team, so keep the full-time team small and get more part-time participants to give lightning talks or act as deciders.
Experts everywhere — Each sprint had 5–7 stakeholders and/or subject matter experts talk on Monday (the first day of the sprint). That’s a lot, but it always added huge value to the team and got us moving on understanding the problem space and customer needs.
TIP: To get the stakeholders and experts you need, take the pressure off them. Specifically advise them that they don’t need to prepare anything (even if they ask). Just use existing assets or come along for a simple Q&A session. Also book them for just 30 minutes to make it easier for them to say YES. Talking on a topic they know, you will generally get more than 30 minutes worth of quality information from them anyway.
Many deciders and stakeholders — In a large enterprise, stakeholders are many and varied. Stakeholders from many departments had to be included if we were to avoid discovering issues when building solutions after the sprint.
TIP: Don’t make the mistake of running a sprint within a department silo. Not including your organisation’s wider team will make it hard to progress possible solutions after the sprint. The bigger the organisational team involved = more support = more likelihood that a real solution will be realised beyond the sprint.
Everyone is welcome — On the Friday (last day of the sprint), when all of the customer testing is conducted, we invited large teams of people from the program to observe in shifts. Because we had a separate room to observe the customers on a TV, we jam packed the room to give everyone on the program the chance to observe customers first hand.
TIP: Great ideas can come from anyone. One of the acknowledged best ideas for the first sprint didn’t come from the agile coach or the business owner or strategy ... it came from the quiet and unassuming graduate student!
The higher the fidelity of the prototype, the easier it is for the user to suspend their disbelief — Don’t judge us, we know what you’re thinking — a paper prototype will give you just as much insight, a co-design workshop will bring as much validation. Nah, the intended value should already have been validated; we’re looking for more detailed interface insights. A theme that continued to occur related to our prototype fidelity. Interactions, language and design aesthetics made a great difference in the user testing insights (let’s keep in mind we still did only one day of prototyping).
TIP: We made sure we had someone who knew prototyping well prior to the sprint. You don’t want to be wasting time struggling to learn a prototyping tool on Thursday (day 4 of the sprint) when you have only one day to prototype. This applies even if the tool is something easy.
What worked/didn’t work about the sprint process?
Cutting through the silos — Many of the senior stakeholders liked the process because it got their teams moving straight away with a sense of urgency
Pressure creates unity — Bringing the different teams together in an environment with clearly structured but strictly limited time created a unified focus on the customer, their problems and the solution. But it’s not just about being in a room together for a few days, it’s the act of building something together that makes the difference
Hearing from the customer — In a large enterprise with lots of stakeholders, you’ll find certain people’s opinions get taken for granted as holding more weight. Nothing cuts to the core and counters unfounded opinions better than seeing real customer behaviour live. Real customer insights, even in small numbers, cut to the core of what works and what doesn’t
Getting to the customer early saves SO much time — We can continue to have meetings, design variations and discuss scenarios but, when it comes down to it, the sooner we can be in front of a customer, the faster and easier it is to deliver value to them
Fail fast! — One of our MOST valuable sprints was actually an invalidation of our intended strategy. I know it’s hard to appreciate, but closing down an idea and communicating why in a scaled organisation can be a huge achievement all by itself — and can save a lot of wasted effort. Design sprints enable that communication to not only be much, much faster, but also easier, and more founded in solid live customer insights (They’re live on TV people! Bring your stakeholders!)
Did you make any modifications to the process?
We didn’t deviate much from the standard 5 day Design Sprint process for the first 4 sprints. Although we did ‘mess with it’ for the 5th Sprint. We dubbed this the ‘Diet Sprint’ and, guess what, the results and insights we nowhere near as good.
But we did add a few things to accommodate our corporate environment, especially around the post-Sprint activities. We also learned a lot about the little details of how to ensure a Sprint is successful — but that’s a whole other article!
Post-Sprint additions
In a large enterprise you can’t rely solely on the full-time sprint participants returning to their teams to communicate and educate others on the insights gained from the sprint. Taking the outputs and insights from a Sprint involves several challenges. It’s no good getting a team up to speed, innovating, testing and proving something works with customers if you can’t convince the rest of your organisation.
Enterprise teams are often large and usually just one cog in a bigger machine. Anything you achieve with a Design Sprint needs to be communicated and ‘sold’ to other stakeholders and teams to turn insights into deliverable product. So to ensure we communicated we added two key things:
Showcase — not just showing off, getting buy-in
Showcases were very well attended with a combined attendance of 100+ people.
TIP: Many people attended to hear feedback and insights directly from customers. Highlight reels of customer interviews showing both the interviewee and their real time use of the prototype were a very popular way of keeping a wider team involved — all they needed to do was attend the 1 hour showcase.
Retrospective & results pack — being clear about the insights
People can watch the same customers and listen to the same interviews but interpret things very differently. We found that a retrospective with the full time participants was a great way to discuss and agree the actual insights, which then went into the Results pack.
TIP: A Results pack records the agreed insights from the retrospective, but it needs to be presented in an easily ‘digestible’ pack for other stakeholders. The goal of the Results pack is a record of what we learnt because memories can be very short.
Maximising transparency — Making all the assets accessible to everyone was really important. And I mean everything. We used a team Wiki.
Organising interviews — Make sure you arrange the customers to interview on the Friday well before you start the Sprint. In a corporate environment, there are often a number of approval processes to follow before approaching existing customers or other public representatives, and they may be busy themselves. Startups and small organisations may find they can fast-track this process.
Will Your Team Sprint Again?
Given the success of our Design Sprints to date, they are now being adopted to supported our existing SAFe (Scaled Agile Framework for Enterprise) process, accelerating and championing our customers’ voices.
Before we say goodbye. A big shout out to Mike Hughes for being fantastic and co-writing this article!