But what about the BAU work?

When you make all the work explicit, you get fewer surprises.

When people work in product-based teams, the product development work is front and centre. It is easy to see how this work adds value and where it should live. Less obvious is where the day-to-day “Business As Usual” work sits, how it gets prioritised and measured, and how to ensure it is not neglected.

I like to make this kind of work explicit, as one of several types of demand. Making all the work visible means we can measure our real capacity and prioritise for changing business needs, rather than having “ghost” work hiding in the system.

Understand how value is created

One of the first things we do when we start working with a new organisation is model its value streams: “How does the work work?” how do people collaborate to provide value to their customers, and how does work move through the organisation? There are many ways to do this. I like Event Storming as a way to get a group of people to understand a value stream, and Wardley maps to visualise and help guide the conversation.

Often, we discover that work items are bouncing around all over the organisation, joining queue after queue of work, sitting for days or weeks blocked by completely unrelated work items ahead of them in these queues. Something else needs testing first; something else needs a firewall port opened first; something else needs a change to a database schema first, or a security review, or an API change in someone else’s service.

People soon realise how much faster work can move through the system–how much sooner we can realise value–by moving the people to the work; rearranging people into teams aligned with these value streams.

This feels disruptive at first but quickly pays for itself. Teams report feeling more empowered, more focused, more autonomous, more self-reliant; more able to see the impact that their contribution is making. The real win is that they can achieve this at a sustainable pace. It turns out that working harder or longer hours was not the solution after all.

Create genuine cross-functional teams

For all the talk of cross-functional teams, most digital product teams only comprise the development side of the equation: developers, testers, product managers, and so on; none of their users or business stakeholders are in the team. Back in the 1990s, XP proposed that the “customer” for the team should sit with the team. This is literally the person who will use the product the team is developing! Scrum attempted to model this as a Product Owner, but the dynamics of that relationship are totally dysfunctional: the PO is only a proxy customer but they wield a disproportionate amount of influence within the process.

The real On-site Customer is there to act as both a subject matter expert and a “model user”, helping the team to understand their priorities and needs. But they also have a day job. The original XP project was a payroll system at Chrysler, and the customer in that team was the payroll supervisor, who was still responsible for people being paid!

One of my clients has reorganised into genuine “value stream teams”. We are adopting this terminology to distinguish them from the development-only teams we tend to find in organisations that have a Technology or IT function separate from “The Business”.

One of the teams is helping the finance department to streamline their invoicing processes and automate the repetitive parts. This team has a couple of invoicing staff in it who, while helping to shape the solution, still need to send invoices out. Another team is mining customer data from various fragmented sources to provide sales and marketing insights. Again, they have sales and marketing folks in the team, who also need to carry out customer research and manage campaigns.

So where does all this “day job” work happen? How do we ensure it does not fall through the cracks, or derail the teams’ efforts to provide new business capabilities?

Make all the work visible

For programme-scale product development—typically in the 50-200 person range—we run quarterly planning sessions where we review progress, align on direction and strategy, and set ourselves challenging goals using OKRs. We also use these sessions as an excuse to celebrate what we have achieved. Based on these new goals, there may be some movement of people between teams. Sometimes teams may disperse and new teams form as the profile of the work changes.

You can only do this if you understand all the different demands on the teams. Whether you model your product development work as features, epics, stories, experiments or goals, this still represents only one type of work, namely customer-facing delivery. Unless you can see all the competing sources of demand on the teams and on the organisation—and treat all of this as first-class work—you will continue to be disappointed that your expectations go unmet as all that unmanaged “ghost” work gets in the way.

Four (plus one) sources of demand

We have identified four primary places that demand comes from:

• External demand is work we do to meet or understand customer needs. This work is visible to customers, either directly in the form of delivery–new features and product improvements–or indirectly in the form of discovery–experiments to better understand customer needs. External demand is the easiest work to identify, since it is usually the only work that appears on a backlog.

  Any external demand should have a sponsor, someone who cares about the success of the feature or the learning from the experiment. This person should be able to make priority calls between different initiatives, and to choose between alternative solutions or between different formulations of an experiment.

• Internal demand is any work we do to “make it easier to do work”, also known as kaizen. The conventional interpretation of kaizen is confined to process improvement. We apply it in a broader sense to mean anything that measurably improves the system of work. In this sense, training and learning are both kaizen work because they change the system by giving people new skills which will improve throughput, as long as we base the training on anticipated demand. There is no point learning skills we will not need, or that we already have in sufficient quantity for the upcoming work.

  Technical improvement work such as cleaning up code, replatforming, build and release automation, or improving testing, is all internal demand.

  Just like external demand, internal demand should have a sponsor. This is someone who cares about the technical health of a product, or who is looking ahead to ensure that we will have sufficient capability to meet anticipated demand, and sees that we need to act now to train up some people in some constrained skill.

• BAU demand is work we need to do to run the business. This is non-discretionary spend; you have to do this work to keep the lights on and pay people’s wages, or to produce the information that helps the organisation to function and govern itself. This is the day-to-day work that makes money, saves money, or otherwise keeps the company in business.

  BAU demand is not just a quirk of teams that have domain folks in them. Any product engineering team will have reports to produce, metrics to track, governance information—risk and investment updates—to share. Arguably, any repetitive activities like merging code branches, configuring environments, manual integration testing, compiling boilerplate change and release documentation for “compliance theatre”, all count as BAU work. The only difference is that they are hidden inside the software delivery process rather than hidden elsewhere in the organisation.

  While we cannot avoid doing this work, we can look at how to eliminate, simplify or automate it to free up more discretionary capacity. Any work that does this also counts as internal kaizen demand, because we are changing the system of work to enable us to do more.

• Failure demand is the other source of non-discretionary work. This represents any work that we should not have had to do. Some people limit this to only customer-visible failure, but I prefer to use it to mean any work that takes up our time that should never have happened. An outage that is not user-visible but that takes time to clean up is failure demand. Re-running a report by hand because the service was not available is failure demand. And it is not just about restoring a service and getting it up and running again. Any follow-up work such as post-incident reviews, management meetings, email threads, external comms, data clean-up, all count as failure demand. Each one eats away at our available capacity.

  While we cannot eliminate failure demand, we can learn from it to reduce the likelihood of future failures, or to get better at recovering faster. We make any preventative work visible that we decide to take on, and prioritise it as internal demand.

As a bonus:

• Planning demand is the work involved in getting a handle on all these sources of demand! One client found that the initial work to make all of this demand visible was a significant investment in itself, so in the interest of “making all the work visible” we introduced this fifth category of “work to understand the work”.

  We ran some organisation-wide workshops to understand where the real demand was, both external and internal; where the obstacles were; where we were losing capacity by running labour-intensive BAU jobs or cleaning up after errors that should not have happened. These gave us an insight into how the organisation was really working, as opposed to how different people thought it was running.

Choose where to invest

You will not have the capacity to Do All The Things, so there will be trade-offs. BAU and failure demand are mandatory spend. You can’t know where the failures are going to occur, but you can use “yesterday’s weather” to estimate how much of your capacity they will likely take up.

The remainder of your capacity is your discretionary spend. As a team, you decide, quarter on quarter, what proportion of your discretionary capacity to invest in external demand vs kaizen (internal) demand. If you are pushing to get that big new release out the door then you might be focused on building and polishing those last few features, so kaizen takes a back seat for a while. After the product launch you might focus on clean-up work while your customers are happily playing with their new features, so the needle pushes towards kaizen work.

My only golden rule is that you should never have nothing in flight. In other words, there should always be some delivery, some discovery, and some kaizen work happening, even if it is not much. Delivery is your credibility; discovery is how you learn; improving things is your hygiene.

How to structure your people to meet this demand is a topic for another day. The short version is that it can happen in real time, during the quarterly planning session. The first few times you try this, you should expect it to take a couple of days for a biggish programme, say 100 people, and there will likely be tears and tantrums. After a few goes, as the team starts to experience how they can restructure around the work and not suffer the “forming, storming, norming” impact, and as they start to understand the dynamics of short- and long-lived work, you can run a quarterly planning session at scale in half a day, with everyone confident that they are in the best place both for the team and for themselves.

tl;dr

• Model and visualise your value chain.
• Structure the people around the value chain.
• Make all the demand visible, so there is no hidden work. This is key.
• Identify work that will reduce drag and give you more discretionary capacity.
• Decide what you want to invest in, and structure the people around that.
• Repeat every quarter, which is long enough to get work done, and short enough to iterate.