Are you finding that Scrum isn't working for you? Do you constantly find that you're never quite able to complete your Sprint Backlog and even when you get close it never really feels like success? You're more of a feature factory than anything else.
Well it's almost certainly because of this one thing. What is it? Let's talk about it!
I've been using Scrum with teams and a variety of organisations for the past 20 years, God has it been that long! And when Scrum fatigue sets in it's almost always because the team are not using a Sprint and Product Goal or because they're using them in the wrong way.
Now if you've really tried to use a Sprint and Product Goal properly but find that the work that you're doing just doesn't lend itself to one, keep reading as I will cover this point later on.
Now if you don't use a Sprint and Product Goal in the right way you'll end up turning into ScrumBut. Why? Because you'll end up focusing on getting all the stories taken into Sprint done which is the wrong thing to focus on.
Yes look purpose of the Sprint is not and never has been to get all the stories done. Look, things like story points and burndown charts are the wrong things to focus on. They make you chase the completion of each story taken into Sprint because a) you want to get that burndown chart down to zero and b) because you want your velocity to either hit what you said it would or do better.
Now ScrumBut represents a diluted version that undermines the benefits of Scrum. ScrumBut goes like this:
We use Scrum BUT we can't set a sensible sprint goal so we ignore it or create a generic goal like complete all stories or finish testing the stories from the previous Sprint
Now if you're a Scrum Master you really need to get to grips with this. You're the expert in Scrum and you should know the Scrum Guide. The Product and Sprint Goal is fundamental to Scrum.
So let's be clear, to get the benefit of Scrum you need to be working on:
A single product or service
There needs to be a clear vision provided by the Product Owner
From that vision you need to have clear goals identified
You work on one of these product goals at a time
The Product Owner will decide when enough has been achieved against this goal in order to move on to the next goal
The product backlog should only contain work related to the goal you're working on
Each Sprint is dedicated to creating value towards that Product Goal
And to this end the team decide on a single Sprint Goal that will get them closer to realising the Product Goal.
Look if you don't do this you reduce your ability to innovate and inspect the adapt during the Sprint.
Does your Sprint feel like mini waterfall? Well look it's because you create all the stories up front prior to sprint, you focus on getting them all done in sprint and then reflect on it at the end, this is waterfall.
Instead Scrum teams should focus on a specific Sprint Goal such as, set up a deployment pipeline and release an empty site to production.
You can generate a few stories prior to Sprint start but don't try to create them all.
Then work on the goal as a team to discover what is needed to achieve the goal.
It does not matter if you complete all the stories you took into Sprint the only thing that matters is achieving the Sprint Goal, getting it done and adding incremental value to the Product Goal.
It's one of the many reasons I believe there's no value in story points or burndown charts, in fact it's worse than that, these things are a total waste of your time.
Now in my humble opinion if you want to have metrics that actually have any value then you should use flow metrics,
Look if you don't use a sprint goal the first thing that usually happens is that it causes a lack of alignment against the Product Backlog.
Yeah teams take items into Sprint from the backlog but the set that they choose don't make sense together.
The next issue is that the team ends up not working as a team they end up working in silos one of the very things Scrum is designed to stop.
This happens because the individual team members work on single items by themselves.
Because there's no shared goal to bring them together and the items they're working on don't relate to each other so essentially it's mini waterfall.
Next it leads to a lack of focus and causes the Daily Scrum to just be a status update, I'm sure you've been there before.
Because everyone is working on separate items it's not possible to talk about progress towards a single defined valuable increment because there isn't one.
The Daily Scrum should be all about progress towards the Sprint Goal, does anything need to change?
It also makes it more difficult to define the roadmap for the product and it makes it harder to engage with stakeholders as they simply can't see the value in the Sprint as a whole.
And it can make the Sprint Review session difficult or even pointless.
Another side effect of not having a single Sprint Goal is it increases the team's work in progress and context switching, which results in reduced morale, lower quality work overall and of course increases the time to deliver.
And Sprint Planning is made much more painful and takes longer because you end up talking about a lot of different pieces of work not aligned to a shared goal, plus you end up following a plan instead of responding to change, come on!
Look it's very hard to respond to change when you've got a lot of unrelated work but if you've got a single shared goal it is much easier. It reduces innovation, inspect and adapt element, empiricism, it's just reduced to the retro.
Look this is not the way it's supposed to be you're supposed to work together on this problem during the Sprint.
So if you're not using a Sprint Goal and have been thinking that this is fine I'd suggest that you sit down as a team and have a chat about it.
Now I mentioned earlier that if you've already tried to use a Sprint and Product Goal but the work you're doing just doesn't lend itself to one then I'd have some pointers for you. And here it is, you should stop using Scrum, yes stop using Scrum!
You almost certainly don't have a single product or service and very likely have multiple Product Owners so your backlog reflects a load of unrelated things. Trying to crowbar what you're doing into Scrum is likely causing misery so stop it.
Scrum is the wrong framework for you, look instead use Kanban you'll find it works much better. You're just using the language of Scrum but for no benefit.
Look the Sprint and Product Goal is so fundamental to Scrum that there's little to no benefit without them, it’s simply not designed for your scenario.
Now using Kanban doesn't mean you have to abandon planning, retros or even the Scrum Master role, you can still use them, but probably reduce the cadence of the daily meet-ups.
Look I urge you to think about this seriously if you find yourself in this scenario and start to make some changes you'll be a lot better off.
Komentarze