Working in Sprints

The Resolve Engineering partnership was in the local business news again recently talking about the evolution of their ways of working through sprints.

https://www.becbusinesscluster...

https://www.in-cumbria.com/new...

"The ECOE was created, in part, to address resource and capability challenges in engineering delivery and introduced a new way of working through focused ‘Sprint’ teams - small groups of people tasked with solving specific, real Sellafield/NDA site challenges"

It’s great to see the adoption of this way of working into these contexts, especially in something as specialised and regulated as the wider Sellafield operation. It demonstrates how the underlying principles of 'sprints' can apply to almost anything, and having run hundreds of sprints over the years in different organisations, this caught my eye and prompted me to add a bit of commentary.

For the reader unfamiliar with the approach, here's a simple introduction to how 'sprint' teams came about.

A 'sprint' is just a timeboxed period of work focused on a goal. It comes from the Scrum framework which was created around 1995 and has since become pretty much the norm for software and digital product development teams.

Scrum itself is guidance in a concise set of rules and events which provide a structure for organising work, particularly suited for complex and adaptive environments - where things aren’t always clear and can change rapidly. Scrum (it is named after rugby), is freely available and has massively changed IT and product development. It has been used in contexts diverse as marketing, the police force, education and wedding planning.

It’s a strong and smart framework which guides teams to first optimise for value (choosing the next most important thing to deliver), followed by flexibility (get feedback and then either improve it further or choose again).

That said, it does take discipline, attention and a skilled facilitator to get the most out of this way of working.

Here are a few tips to tune up sprints if you’re using them already, or if not - some important considerations before getting started with them:

1. Always have a goal. A sprint without a goal is just a meander. Quantify the goal as an outcome to be experienced by the customer (i.e. whoever's benefit the work is being done for).

2. Sprints are underpinned by the values of focus and commitment - there are others but I'll stick to these here….

(i) Focus ideally means a fully dedicated team with no other work, but if that's not currently possible then at least minimise their distraction. Any other demand on the team that's not about the sprint goal will reduce the chance of it being achieved. Most teams can absorb a little, but think about how much and its impact.

(ii) Commitment. Often mistaken for a guarantee, commitment means the team will do everything in their power to achieve the goal, and reciprocally, leaders will do everything in their power to assist the team. It's a 2 way bargain.

3. Keep sprints short. The 6 weeks Resolve are using is on the long side, but that might be fine for their context. The trade off is the longer the sprint, the more focus will drift and the more likely something new will come up that can't wait. Longer sprints actually make it harder to deal with that growing new demand, so a good tip is to start long if it feels right at first, and then shorten. 2 week sprints are overwhelmingly the most common, worldwide.

4. Stay flexible even within the sprint. Sometimes the goal can be achieved with a list of pre-identified tasks but to be honest if that's the case it doesn't really need a sprint, it just needs heads down work. Instead, a sprint is a collaborative exploration of how to achieve the outcome. Expect the 'how' to reveal itself as learning happens.

However, the goal must also be achievable and realistic - so starting with too little knowledge of how to achieve it is risky. Finding the point between just enough up front analysis versus discovery takes practice and balance, and even experienced teams will miss the sprint goal sometimes.

5. Empower the team. The Scrum guidance is that the team members have all the skills and resources to achieve the goal. We see this put to the test when they encounter a dependency on someone outside of the team, because that person - being outside of the team - will have their own goals and may or not be able to assist in time. In practice, if there's a dependency that's recurring, then you need that skill permanently in the team. If it's a rare dependency it's not economic to hold that skill in the team full time, so instead understand the SLA and plan ahead. For example, website development teams don't usually keep a lawyer in their midst, but will know the lead time required for a legal review and ensure they factor it in.

6. Cross functional working. People in the team should be able to do more than one type of task; if they can’t then there will be overload on some and a scarcity of work for others. This leads to the damaging strategy of 'resource optimisation' where individuals are given work to 'stay productive' or split across teams. Instead, encourage and grow cross skilling; it smooths the flow of work, increases predictability, improves quality (more pairs of eyes on a job), provides back up and increases diversity of thought. Grow 'Generalising Specialists'.

7. End the sprint with a review. This is one of the essential scrum events, where the customers are shown the efforts of the sprint and their feedback is actively solicited and collected as potential enhancement opportunities. Not a presentation or playback, but give the customer a working product (or prototype), or a new feature they can experience, hands on.

This provides the powerful "ah, now that I see it…" moment, the real world feedback that can’t be predicted or simulated easily. Regular short sprints means feedback loops are tight and frequent, which maximises the chances of the product being the right thing, at the right time, done right.

8. Transparency. Literally, make work visible. This is one of the other Scrum values underpinning sprint based working. Successful scrum teams will visualise their progress and their impediments, either digitally or on a physical wall chart. This draws people to what's happening with the work, serves as a real time dashboard, guides day to day planning and avoids extra status reports. There are various ways to do it so experiment, but whatever method is used always focus on the work remaining to reach the goal, rather than what's been done. "99% of the way to the airport is still a missed flight" (apparently Biggles said that)

9. Duration. Keep sprints the same duration (unless making a deliberate change for the long term). If work isn’t finished at the end, don’t extend them - even by an hour. This regular cadence and strict timeboxing is deliberate, as the team will quickly learn through trial and error how much they can accomplish in a fixed period. Once this takes hold, that team will exhibit predictability in their delivery, and through that the trust of their customers, stakeholder and leaders. It's a powerful force for improving everything from budgetary forecasting to psychological safety.

10. Metrics. With that regularity comes the ability to measure over time. Each sprint is like a mini project, providing recent data which can be used to spot trending within the bigger project or product lifecycle. The most useful metrics are often the simplest, those that can be counted by eye or jotted down on paper. Some teams use velocity, which can help but watch it doesn't turn into a target. Lagging indicators like throughput (features per sprint), cycle time and lead time are valuable for planning and forecasting. Leading indicators like work item age and work in progress are valuable for guiding an efficient, low waste flow of work.

There's plenty more, but the 10 key points there should help anyone working this way already, or for anyone embarking on it - set you off in a good direction.

If you'd like to dig further into how to get the best from agile ways of working like this, give me a shout.

As a post script, the term sprint is actually quite a misnomer because they're not meant to be a short all out effort, over in a flash where you collapse at the end with nothing left to give. Rather, a rhythmic, sustained pace that can carry on indefinitely. Much more like a fell run. But hey, it wasn't me - so it is what it is.

(Image credit Maico Amorim, Unsplash.com)