Our team's experience of giving Scrum another chance.

Here at OVO our tech teams can choose their own ways of working. Do we pair program or not? What team meetings do we have? Do we want to work in sprints? It's up to us. Scrum and Kanban are two of the most widely used Agile frameworks, and our team, Supply Points and Meters aka. SPAM, used a hybrid of these two. We took elements of Scrum such as regular stakeholder reviews, retrospectives and estimating work using story points, but didn’t plan work into sprints. We had been reluctant to fully adopt Scrum as several devs on the team had bad experiences with it previously. Software development is a notoriously hard thing to estimate and we had doubts as to whether predicting what we could achieve each iteration would be valuable, or whether it would just add an extra meeting and arbitrary deadlines.

Our ways of working had served us pretty well but we had a lingering feeling that things could be better. It was difficult for our product owner to forecast when we would deliver work and it wasn’t always clear what we were aiming to achieve in the short term. Sure, we were writing code and solving problems, but were they the most important problems to solve at the time? Could we deliver the really important stuff faster?

What did we do about it?

At a retrospective the team decided it was time to try out picking either Scrum or Kanban and doing it ‘properly’. One of our Agile Coaches, Georgie Hopkinson, ran a great introduction session on Scrum explaining the basic framework and we agreed our next steps:

• We would trial Scrum for 3 months.
• We would try our best to do it ‘by the book’ - the only thing we’d leave out was shipping software once a sprint - we release multiple times a day.
• After the 3 months, we would get together and decide whether or not to keep going with it. Having this escape hatch gave us confidence that we wouldn’t be stuck working in a way we didn’t enjoy.

What were the results?

Overall, really positive.

What we liked:

Stronger sense of purpose

Since we moved to Scrum what we’re trying to achieve in the short term has been clearer, which has helped our motivation and focus.

Issues are uncovered and therefore easier to solve

Scrum seems to have done a better job of highlighting issues with our process. One issue we used to have was not doing enough planning for upcoming work - sometimes our discipline of refining and prioritising stories slipped a bit, which resulted in us not having many tasks ready to be worked on. Since the move to Scrum if we've not got enough work ready it is made clear by the fact that there would not be enough story points to fill the next sprint, which signals that we need to spend some time on planning and refinement.

Work is prioritised by value, not just what’s available to us

Following on from the previous point, having a bigger pool of stories ready to be worked has meant that we’re more likely to prioritise work based on the value it provides to our customers.

It taught us to consider how the tasks in the sprint can be worked in parallel

Having a boxed off set of stories we've committed to has prompted us to think more carefully about how we can all work on them in parallel, e.g. by pair programming more or splitting up stories. Before Scrum that had a tendency to be hidden as we might have just picked up lower priority items instead, resulting in us taking longer to deliver the most important work.

Bonus improvement: daily stand-ups are more focused

At stand up we now go through the tasks in progress one by one, rather than through the members of the team one by one, which has led to more focus on getting work across the line and much less on justifying what we did yesterday. ‘What can we do today to progress this story?’ has been a more productive prompt than ‘What are you planning to do today?’. This improvement is not really part of Scrum - it doesn't prescribe how you run your stand-up meetings - but I think the change was triggered by us now having clearer short term goals.

What we didn't like:

I have mixed feelings about the usefulness of setting a sprint goal

Sometimes it may not be possible or appropriate for most of the work in a sprint to relate to the same theme, either for technical reasons or because there are other high priority tasks to do as well. This can make picking a sprint goal feel a bit arbitrary and it can end up feeling like we’re just spending time thinking of how to phrase what we’ve already decided. On the other hand having a sprint goal can help the sense of purpose and prevent too many streams of work from conflicting. I think setting sprint goals is something we either need to improve at, or drop.

It’s fairly meeting heavy

In a typical two week sprint we have 2 hours of sprint planning, 2 hours of backlog refinement, a 2 hour retrospective and a 30 minute sprint review. Although the meetings do feel necessary, I’m a developer at heart and prefer to spend my time designing and building.

To sum up

After the 3 months, everyone on the team came to the same conclusion - moving to Scrum had been a positive change for us and we’d like to carry on with it. There’s more than one way to organise a software team and what worked for us may not work for other teams, or even for us in a few months time. Maybe in the future we will feel that we can do away with some of our current practices and achieve the same results with a more lightweight process. But for now, I think the improvements in discipline, value and focus have been well worth it.