I often get to work with teams trying to ‘do’ Scrum and after about 100+ teams, I can confidently say one fundamental issue comes up again and again as a key stumbling block to how effective these teams are. In this post I’ll tell you what it is and 5 steps to addressing it. 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.
This post might help your team if you suffer any or all of the following symptoms.
- You don’t have a product backlog
- You have a product backlog full of much more than items adding direct value to the product
- You have a Product Owner who is struggling to navigating the crap that found its way into their backlog
- Your development team is screaming that they often do not have enough work to keep some of their members busy during a sprint
- You are delaying sprint starts and/or extending sprints to absorb the impact of hidden work and compromised capability
- Your team is having Sprint Zeros like they were 2-for-1 at the supermarket
- You are doing analysis sprints, design sprints… and so on
If you have these problems here is what I suggest you do:
#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.
This product elaboration picture illustrates this a little better:
Direct value are the green and reddish-orange items (basically that stack is your product backlog on its side) and the capability value items are the things you know you did, that narrow ‘your development team capability’ aperture or the things you know you can do, that will widen it.
Next, consider time:
- Past – this is usually work to improve capability value by addressing stuff you put on the never-never. This includes known hacks, fudges, crappy code you added that “TODO” on, shoddy design, smelly tests, no tests , all those outdated comments that everyone spends an hour wading through only to find they aren’t relevant, those manual tasks you thought you would only ever have to do that one time and then you actually do them several times a day and they are long and boring. Basically anything that affects your ability to sprint effectively. This is not an exhaustive list.
- Present – the ‘READY’ items that your team comprehensively knows enough about to be confident enough to commit to deliver in a sprint. Deliver as in ‘DONE” – meeting a Definition of Done that your team and your Product Owner agree is a consistently achieved level of goodness. For example it meets the conditions of acceptance, it hasn’t broken any existing value , the code is clean and generally efficient etc.
- Near Future – items from the backlog for upcoming sprints that you need to create knowledge for now – basically the next reddish-orange items. If you don’t know why you should be doing this, allow me to elucidate.
See the product elaboration picture above? Basically if you don’t do work on elaboration now, your team will arrive at a future sprint planning with big reddish-orange items that won’t fit. Except you will need to commit because your management will be screaming at you and you will be too chicken shit to say no. So you’ll pretend they are green and ‘ready’ and ‘commit’ to them knowing fully well there is little hope of them getting ‘DONE’. Of course you’ll try your best, you’ll work hard when you should have worked smart. You’ll cut corners and more than likely build crap and increase your tech debt., further reducing the capability of your team.
FYI: Typically most ‘past’ work affects capability and most ‘present’ and ‘near future’ work is around direct value. Also the Product Owner owns the Product Backlog and the development team owns the Capability list.
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.
None of the lists of items is locked down – that would be denying emergence and is a recipe for undoing your improvements. Resist the temptation to get Gestapo on it. Instead, consider just making it absolutely visible and develop a cadence of reviewing it regularly.
One thing though – when you have your capability value items list up – go round and make everyone swear on the life of something precious to them that they won’t knowingly add anything that constitutes any kind of debt without stopping the line and getting everyone to agree to it. That is not to say you are going never have any more, only that you all knowingly accept to do so.
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. FYI – only the ‘now’ work – ready items off the product backlog count as your sprint commitment.
Without this you are going to get screwed. One or both of the following things will happen:
- You will run out of ready items to work on for later sprints and return to that place where your sprints are crap, nothing gets delivered, you work long hours just to create the knowledge you needed to have to even consider committing to anything.
- You keep delaying the capabilities improvements until everyone would rather drink arsenic than touch the code and you are delivering far less that you ever did. Frustration and mistrust is growing and most likely your team is shrinking because people just got fed up and found a different job.
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.
#5. Retrospect
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 and let me know how you get on.
Gratitude
I am profoundly grateful to all the teams I have worked with who been the experimental jets for this learning. Also all the wonderful agile practitioners who I have known and whose ideas have mingled with mine. The product elaboration funnel is inspired by the work of Jeff Patton– who rocks in so many ways. Please check out his site and say I said ‘Hi’.