Many Scrum teams have one fundamental issue comes up again and again as a key stumbling block to how effective these teams are. Here you can find how to make your team more effective and the rest is up to you.
So the fundamental issue is this: the Scrum team does not understand the nature and type of work they are doing and so are not self-organising around it effectively.
#1. Understand the work you are doing:
Specifically, understand the work in terms of time and value.
First and foremost, let’s look at value:
– Direct value – work to implement features or fixes that people will pay for or have paid for. I group non-critical bugs and enhancements and such like under ‘fixes’.
– Capability value – work to add things that increase your capability to deliver or remove/refactor the things that are reducing your capability to deliver.
That is it. If any work does not fall into either value type, it is waste – do not do it. So now that you know what to look for, you’re ready for the next step.
#2. Make work visible
Now go gather work. People are clearly busy – raid the backlog, declare a ‘hidden work’ amnesty, collate it all and make it big and visible. I prefer using post-its in the first instance. Put it all on a big wall.
Bring stuff from the product backlog, get the programmers to ante up their secret side projects, encourage testers to confess all the work they end up doing that no one gives them any credit for. Ask the rest of the organisation what others are doing that you secretly depend on every sprint but no one acknowledges.
Take the view that any work that isn’t on the list doesn’t get done – simple as that.
Invite ideas for capability work (you might need to first talk about what capabilities you need though – so do that). It might be training or having a consultant in to give an injection of skills, it might be building up specific expert knowledge. Whatever it is, get it , write it down and make it visible.
With all the work visible and normalised – you’ve removed all the duplicates and everyone is clear what each post it represents, you can move on to the next step.
#3. Prioritise the work
The Product Owner should already have the backlog items prioritised by business value anyway – if not – they need to do that. Everyone can help with that, but ultimately it is their call. The immediate goal for this is to have a backlog is at least prioritised for the next 2 sprints. At this point, you need to make a clear distinction about what is ‘ready’ and what is ‘not ready’ for a sprint.
Next, prioritise the capability value items based on how much you all generally believe they might enhance your ability to deliver over time – the stuff that will speed it up now at the top and the less impactful stuff further down the list. Crappy code that rarely gets touched – whilst crappy – might hold little value for tackling now. But don’t worry, they are on the list and will get done.
So now, all the work is in an ordered state, you are ready for step 4 – making time to do it.
#4. Make time to do the work every sprint
Now you need to figure out how you’re going to spend the time to do each type of valuable work. I recommend you do some of each type every sprint. The basic idea is, every sprint, to do a combination of now work (ready items off the backlog), elaboration (non ready , near future items , again from the product backlog) and capability improvement work.
Without getting bogged down in numbers, I suggest you start with 70/20/10 and adapt. This means figure out the time you have for the sprint and then:
– Spend 70% of it working on the items you committed to get DONE in the sprint. Clearly you will need to adjust your sprint commitment too – so DO NOT commit to items based on 100% of your time and then work like the clappers to get them done in 70% of the time. That is just nuts.
– Spend 20% of it working on elaborating near future ‘not ready’ work (this covers every knowledge creating task that enables your team to be able to commit to doing the near future work in sprints like UX analysis, exploring test cases, reviewing with customers, tech spikes and all that kind of stuff).
– Spend 10% of it working on the capability improvements. You might only get to start them – when you are in sprint planning try to find ways to dissect the large capability improvement items into things that you can complete in a sprint to minimise branching issues and gates in the code to separate large refactoring.
The fact of the matter is, with the type of work you have to, you have to invest to do it. You will end up paying one way or another.
The preceding 4 steps are hard to do and sustain, but are essential. At your retrospectives remember to acknowledge that you got this far and celebrate too. Then seek ways to improve. Check your percentages – are they still working for you? Evaluate your capability now, are you getting the benefit you expected to get? How are people feeling about being more open with the work they previously had as covert ops?
Pay attention to what the ways the work is requiring you to self organise. Are you learning and amplifying that learning? Is everyone helping out the best way they can?
The larger the development team capability grows, that more strain on your Product Owner to make enough backlog to sustain the development team. Is it time to slow the elaboration? Or maybe the team needs to help by doing more.
Lots of ideas – but the key is to retrospect effectively. Please do so with care, respect and openness.
Great you got this far – well done! Now go do it for real.