To sprint or not to sprint?
Start with these 4 questions
Sprinting is all about rhythm. Kick off with planning. Standups at the same time every day between 9am and 10am. End the sprint with a Showcase and review everything with a Retro. These practices, done consistently and predictably, provide a steady drumbeat for the team. But our work is developing people, not developing software. It sometimes has a different tempo.
Should we sprint back to back?
Where does BAU (business as usual) fit in?
Do we need to use everyone in the team?
Or the biggie that we’ll tackle in this article — Is all work done by a Sprint?
In the past we’ve jumped from sprint to sprint without looking up and asking whether we should, you know, be sprinting. We’re now starting to work out when we should sprint as a team, and when we should ‘jog’ on our own.
Which forces the big question — Just because we can sprint, should we?
We love sprinting, so there’s got to be a pretty good reason not to sprint right? The answer is: Yes. We’ve come to the realisation that there now needs to be some really compelling reasons to sprint. The shininess of Scrum is now a bit less blinding, so we’re focusing more and more on metrics and maximising value.
When deciding what the next few weeks will focus on, we need to answer a big YES to at least one of these questions before limbering up to sprint:
1) Are the team able to add value by collective thinking?
2) Will it actually be quicker together?
3) Are we exploring or learning about a new concept or product? (in Agile they call this a Spike)
4) Are we avoiding a single point of failure in the team?
So, let’s look at each in turn:
1. Creating value in collective thinking
One major benefit of sprinting as a team, is that you can focus lots of different brains on a single outcome or problem. There’s obviously masses of value in different perspectives. The key for us seems to be setting the team a challenge that requires them to think creatively, and to give them a drop dead finish date. Either we don’t know what the solution will be, or we haven’t decided which way to go. This allows the team to get under the skin of the problem and then design the most appropriate solution. This could be something like; “What would happen if we turned off the LMS (Learning Management System)…?” or “How can we help our first time managers get up to speed quickly?”. Setting a creatively framed challenge is pretty empowering, as the team need to do its own the research and design. Lock stock.
Unfortunately we’ve also done the opposite of this: essentially a bulk effort to clear a predetermined to-do list, covered with the facade of Agile. Unsurprisingly the result wasn’t empowering, engaging, or enlightening for the team!
2. Sprinting is quicker(?)
Scrum usually allows you to do things faster as a team than you could on your own. It was one of the main reasons why we started our Agile journey in Learning & Development. Therefore when deciding to sprint, you need to be pretty certain that what you’re focusing on can actually be ‘Done’ quicker with a dedicated team focusing on it. This isn’t always the case! One of our early-learned principles is that we often need to go slow, to go fast, to minimise waste and get the right outcome. So there’s sometimes this initial lag which needs to be factored into any go-no-go sprint decision. An example would be the need for a research sprint or discovery phase to bring the whole team up to speed on the problem (we now do these for most sprints — see this article). Therefore the default sprint position shouldn’t be a ‘yes of course it will be done quicker’. But more of a considered, fact filled, data driven decision.
3. Sprinting to learn. Well, we are in L&D!
Sometimes it’s worth going ahead and sprinting on a low value output if the process helps unlock a new method, tool, or learning that can be applied to other sprints. It’s like an Agile R&D sprint. The journey, not the destination is important, and all that good stuff. We recently tried the Google Ventures 5 day Sprint process to test a concept on how can we help our new managers get up to speed quickly on the skills they would need. We learnt loads about their sprint process which we’ll apply next time to this particular type of sprint or borrow the elements we like (see our article on this experience). So sprinting to learn something new about the team, or to test an Agile method, tool or concept, feels like a pretty good reason to sprint. It’s learning on the job, something us L&D folk love to experience personally while we help everyone else as well!
4. Avoiding single points of failure
As mentioned in earlier posts, Scrum has really helped us remove a reliance on a single individual to keep things afloat. Spreading the load, spreads the risk. We recently ran a Leadership Development sprint, just for this reason. It didn’t strictly satisfy reasons #1–3, however, we could see the risk and strain created by only one person knowing everything. The aim therefore was to get more people across the context and the BAU requirements of the programme, so that more hands could be available in the future if needed. Going ahead with this type of sprint needs to be really considered, as it generally goes against reason #1 and takes many people away from potentially more value-add work.
We really do love Agile, particularly Scrum. But we do want to make sure it’s super clear when this approach is adding value to the work, and the team, and when it’s simply not. This may be one of the key differences in applying Scrum to the non-software development world; there’s quite a lot of grey to work through!
Making sure we can answer “yes” to at least one of the 4 decision points above, gives us some clarity and boundaries, and means we’re not simply ‘doing’ it just because we can.
