Building complex products is unpredictable. We are forced to make a lot of assumptions (guesses). This is the why we use an agile framework like Scrum, as it allows us to verify our assumptions as early as possible, before we go too far down the wrong track.
At our service, we have feedback loops. These help us create a better product (are we building the right thing?) and increase our productivity, quality etc (are we building it right?).
A feedback loop has four basic steps:
- Plan something
- Do it
- Check the result and see if it is what we want
- Based on the result, adjust what we do the next cycle
There are two main feedback loops in Scrum:
- The sprint
- each day.
Every sprint is a big feedback loop. We come up with a plan for what to build in the sprint and how. Then, we complete these items during the sprint (hopefully!), before we inspect in the sprint review and retrospective how we did.
In the sprint review, we get together with the customer and/or users (or, less ideal, just the product owner as a proxy for these) to get feedback on the features we implemented in the sprint. Now that we can see the software up and running, what should we do next?
Do we need to make any changes to what we have built so far? Perhaps, our requirements don’t quite make sense now that we can play with the resulting software. Or perhaps seeing the software gives us new ideas that are much better than those we initially had. Let’s add these changes to the backlog!
The sprint retrospective instead focuses on the process and how the work itself went. What worked well and what should we do differently next time?
The second feedback loop is the one starting and ending in the daily stand up. This is a chance for the team to adjust their plans, based on how the progress has been so far, with the goal to maximise the chance of reaching the sprint goal.
How did we progress yesterday? Are there any problems? What should we do today? Are we on track to deliver all the stories we thought in the sprint? If not, what should we do about it? Do we need to regroup somehow? Do we need to go back to the product owner to adjust the scope of the sprint?
Other feedback loops
On top of these loops, we are likely to have several others which are not strictly speaking part of Scrum itself but nevertheless essential to our success. A couple of examples could pair programming (here each feedback cycle could be just seconds or minutes) or the test-driven development cycle.
We can also have some much longer loops, where we inspect a whole project or a big release made up of several sprints’ work. This must be in addition to the loops described above, not instead of! This leads me on to the first main point:
1. If the feedback loops take to long, we learn too late
Feedback loops must be quick or by the time they give us crucial insights we will already have spent a lot of time doing the wrong thing. There are, however, several reasons why our cycles may not be as short as they should be:
- Longer sprints than needed
- Too big stories
- Infrequent releases to production
Longer sprints than needed
The shorter the sprint, the quicker we learn. There is obviously a balance to be struck, though, as starting and finishing sprints involves some overhead. There will also be practical limitations for how quickly we’re able to produce something shippable and valuable.
The rules of Scrum tell us that sprints must be no longer than one month but even a month can be a costly learning experience if we went down the wrong track.
60% of Scrum teams do two-week sprints, which is great as it means they get feedback twice as frequently as those who do one-month sprints. Would a one-week sprint be even better? Maybe – give it a go and see!
Too big stories
Big stories spend a lot of time “under water” between when they are started and when they are finished. Small stories will surface problems quicker. However, for these small stories to deliver the maximal benefit, we can’t wait until the sprint review to get feedback on them. Otherwise, we might already have implemented other stories on top of them, which leads to extra rework. Much better then to call the product owner over and show the story as soon as we finish it or even sooner if there is already enough to see to tell if we’re on the right track.
Infrequent releases to production
If we’ve only got one big release at the end of our project, we run a big risk of delivering the wrong thing. Sure, we gather customer feedback in the sprint review and we might also do user testing to verify that we are on the right track. However, until we ship, there will always be a certain amount of guessing.
The ultimate learning is to see how useful our product is to real users out in the wild. To be able to do that, we need to deploy it into production and measure how real users use it.
Some teams release to production multiple times every day. Others release at the end of their sprint. Further some, particularly on new products, where they need to build up a certain amount of functionality before the product makes sense to the users, need several sprints to produce something releasable. The key is, no matter often you release, try to make it even more frequent to learn quicker (unless you’re Amazon and already release every 11.6 seconds).
2. If we don’t act upon what we learn, the feedback loops are pointless
My second main point may seem obvious but is important. Far too often I see how teams and their product owner either turn a blind eye to the learning or don’t act upon what they learn. I’d go as far as saying that this means they learn nothing!
Learning doesn’t come by itself. Just because we “do Scrum” and all the events that comes with it, there is no guarantee we will actually learn anything.
A few examples:
- In the stand up, one team member is giving the same update day after day. It’s clear they are stuck on their story but no one steps in to offer help or try to find out what’s going on.
- We’re four sprints into the project and the burn-up is clearly indicating we’re unlikely to hit the launch date. However, we do nothing about it, other than hope that things will go quicker from now on.
- At the end of each sprint, we demonstrate the resulting functionality to the users but when they give feedback, we just nod politely, knowing we will never do anything about that feedback. Ain’t nobody got time for that! We’re about to move on to the next feature!
To maximise our learning, we need to be intentional about it. Each Scrum event is an opportunity to inspect and adapt. We can’t be agile if we’re not willing to act upon what we learn. That would be to try to follow a plan, rather than responding to change. That is very much something the Agile Manifesto frowns upon.
Speaking of feedback loops… What do you think? Do you agree with these two things being the most important or do you have any other experiences? Please share your thoughts in the comments below.