One of the reasons I think that pace is a problem in multidisciplinary teams is that we’ve become used to not planning or reporting on work beyond a horizon of 2-3 sprints [1].
This is for the good reason that we want to avoid predicting – or, worse, dictating – the outcome of sprints further into the future. It also means that we tend to be hyper-sensitive to changes in pace and delivery within or between sprints, but less aware of changes in the longer term. For example, does an alarm go off in your team if you haven’t delivered a tech debt story in the last five sprints? Should it?
I’ve said in other posts that I believe Jeff Patton’s dual-track delivery approach is essential for a team to continuously evolve a product or service. (Or to put it another way, to prioritise product over project.) The question I want to ask in this post is:
If we step back and say that the type of work that a team is undertaking is worth monitoring, is it possible that a multidisciplinary team, working at constant pace, could have more than two tracks?
I think the answer is that it could. Discovery and development are always essential for every team; other tracks may exist, depending on the product the team is responsible for.
Visualising work in our teams
I’m going to suggest that we think about areas rather than tracks so that we can easily visualise the split in work. Look at the visual below. This shows a backlog divided into four areas. There are the two essential areas of discovery and development. There are also two areas that I’ve added for this team: “user research” and “tech debt”.
[2]
As product person for this imaginary team, I’m suggesting that a failure to consider these four types of story will lead to problems in maintaining constant pace for this team. This means that our imaginary team needs to discuss these types of stories in planning. They also need to monitor stories that are prepared and delivered in these four areas so that they can act if there are either too many or too few of them at preparation or delivery stages.
It’s important to note that this does not mean that exactly the same number of stories from each of these four areas needs to be taken into each sprint. The product person is still responsible for prioritisation, and the team is still responsible for deciding how many stories to accept into a sprint. This will allow flex between the areas, which will be needed as the amount of work in different areas will change depending on the stage in evolution of the product (tech debt, for example, is probably more of a factor in mature products).
Adding the quantity of work to our visualisation
We can show the split in quantity of work between the areas by using some shading on top of the image. The shading in the next diagram is extreme in that it only includes “user research” and “discovery stories”. This might happen in the early planning stages before any code is written – which might be OK – or this might show a team that is full of creative experimenters, who need to consider building something at some point.
The next image shows a more standard allocation for our imaginary team, with development stories taking up most of the allocation, but with some discovery, tech debt and user research.
How do I do this for my team?
Discovery and development are critical areas (or “tracks” in Jeff Patton’s original definition) of work for all teams. For some teams, I think that there are other areas of work that are critical to consider in order to maintain pace. What makes an area worth splitting out and treating separately? I’d suggest it’s any area that the team believes has the potential to cause a problem with maintaining pace, or any area that the team has already experienced as causing a problem in maintaining pace.
If your team is worried about tech debt mounting up and causing you to slow down in future, then you should track this as a separate area. If your team isn’t managing requests for user research well, then you should track this as a separate area. If there’s been an incident and the investigation shows that improving test coverage is a priority, then split test coverage out as a separate area and track it.
If you’re using agile or iterative approaches, then you should be able to discuss the areas of work with your team and iterate until you’ve got an approach that fits you. (I hope it goes without saying that iteration also means that you can choose to remove areas once you’re satisfied that they no longer present a risk to pace.)
If you decide that there are additional areas of work that your team wants to consider, then the next step is to follow the recommendations in my other post about pace. In summary, this means discussing what a good balance looks like with your team: what would your version of my visual and shading look like? After agreeing a balance, you need to decide how to monitor and report on the balance that you’ve identified, and communicate your approach to your stakeholders.
[1] I’m trying to be agnostic about approaches but it’s not always possible. Please replace “sprints” with “fortnights” if you’re working in Kanban etc.
[2] Congratulations to anyone who remembers back far enough to notice that this is effectively a balanced scorecard. For those who missed this first time around, the idea was that a successful business needed to devote time and resource to several different areas of activities. If too much activity took place in one section and not enough in another section, that showed a potential weakness. In 1996, Kaplan and Norton suggested using Financial, Customer, Internal Processes and Learning and Growth as the four sections. It can be a useful way to look at the balance of work between different categories. (I once used it to illustrate the desirable balance for social media posts with a split of Original Content, Links, Repostings, and Conversations.)
Recent Comments