Agile

Turning to my second potential silver bullet: reducing WIP, work in progress. This is easy to comprehend but hard for people to action. Again optimism plays a role: because we are optimistic, and because we don’t like giving bad news people naturally tend to take on more work than they can reasonably do. Making this worse are members of the agile community who go about talking about “commitment” and “doing twice the work” which makes people feel they should be doing more.

Introducing OKRs with agile and Writing OKRs mini-workshops, 20 & 27 February, online

Use Blog20 for 20% discount – plus get discounted tickets for Introducing when booking Writing

Culture also plays a role. When people like to present a “can do” image, when hierarchy is important and when people are accustomed to doing a little of everything and saying “No, I’m fully loaded” then reducing WIP is harder.

People are reluctant to say they are “full” until they are very close, or even beyond, 100% capacity. But the problems with queuing work occur long before 100% is hit. Even leaving aside human cognitive capacity to juggle many things basic queuing theory tells us that as work increases, the variability in work (i.e. some things take 5 minutes while some take 5 hours) means delays will occur. As capacity nears 100% the system looses capacity to absorb the unexpected (someone is ill, a delivery is late, etc.) so predictability is lost and delays spiral – the “bull whip” effect.

Notice I say system: we all work within systems, not computer systems, workflow systems. One person’s heroic efforts count for little when they work in a saturated system. We end up like Boxer in George Orwell’s Animal Farm, saying “I will work harder”, we work harder, wear ourselves out and burn-out. Too often we forget the old agile principle of sustainable pace. (Watch Stockless Production to see this in action.)

Sponges destroy trust

Once it becomes clear that little is being delivered, and even less to budget and deadline, trust is loss. People are less willing to see work requests queue. They want to see action, any action.

In a rational system some work will wait until there is capacity, but when there is no trust people want to see their requests being worked on. So instead of a team working on a project for a month and then moving onto the next thing in sequence the lack of trust means everything has to happen in parallel, slowly. So, a lot of work happens at the same time, there are much higher switching costs, variability creates delays and management overheads rocket. The team becomes alike a sponge: work goes in but very little comes out.

This can all be particularly tough in start-up environments. In the beginning start-up often depend on a few founders doing ridiculous amounts of work. This culture of long hours and heroic efforts. It is thus hard for people to accept that fewer hours and lower WIP might create a better outcome.

This is particularly true when the founders are still in the start-up: inevitably they worked very hard at the start and they want to see that ethos in their employees. Their start-up survived because they chased clients and worked very very hard. Therefore the founders see hard-work and lots of WIP as the recipe for success. The last thing they want is someone saying “no, do less.”

The same ethos carries over to investors who want to see lots of action, lots of people running around being busy. And because in a start-up it is hard to know what will work it makes sense (portfolio theory) to work on lots of different things to find one that wins. Again this creates a culture of high WIP.

Aligned & misaligned feedback loops

For those seeking promotion it makes sense to be involved with lots of different work and cultivating a “can do” image. Being see as “Dr No” or shying away from work is unlikely to lead to promotion. So there are incentives to take on more work. And when such a person gets promoted than their theory of success is proven so they expect the same from others. Meanwhile, those who surreptitiously balance their work load, keep within their own capacity, beaver away and quietly delivery are less likely to be promoted.

The feedback loop promotes the wrong behaviours: each piece of work is viewed in isolation. Each one suffers its own delays and it is hard to see how one obstructs the another. The project model makes this worse because it disconnects funding (based on benefit analysis) from capability to do work.

If you are lucky you can say “Reduce WIP” and people will do it.

If you are unlucky then you need to build a feedback loop to show these problems, you need to start pushing back where you can, you need to start building trust.

See also: Two Unspeakable Silver Bullets and Why don’t people Test First?

Enjoyed this post? Subscribe for updates and download Continuous Digital for free – please share!

One of the points I made in “Its always time for tea” was why it makes sense to leave things late – until the last responsible moment. I also pointed out there research shows that when you have more time work expands. But, while humans are very good at working to deadlines we are atrocious at estimating time. Later I argued for thinking small – Kelly’s (second) Law of Projects: “Inside every large project is a small project struggling to get out.”

So, it was perhaps unsurprising when someone came to me later and asked:

Q: “What do you do when you have a far out deadline but one you must meet? e.g. you need to change vehicle software to stay compliant when the law changes in 12 months.”

It would seem that waiting until a month before the deadline to do the work is not the most responsible thing to do. But starting now would risk the work expanding in size.

I see several options for this.

First: just try and do the work. I’m assuming this is non-trivial so allow yourself, or your team, a few weeks to try and do the work. This is what we used to call a “spike”, the idea is not to do the work but to learn what you need to do to learn to do the work.

At the end of the time period you can throw anyway your work but you will have learned a lot. You should have an idea of the order of magnitude of the work: month or weeks, a small team (say 4) or many teams.

Having done that, even if you fall back on classic project management to design and plan the work but having done the spike you would be working with superior knowledge.

While you could set yourself an early deadline and try and do the work immediately there is a danger that, knowing it was safe to be late, the team would let the work expand. So, while this approach might not be the most cost-effective it would probably deliver on schedule.

If, from the spike, you are confident the work could be completed in a few weeks you might decide to delay starting on the work. After all, the payback for this work is a year away so work on something which has more immediate value.

One of the problems any early start approach will face is knowing when to stop. It is quite possible that the team will complete the original work but knowing there is time (and funding) to do more they do more. One way to combat this would be to specify the tests right at the start.

Specify the tests and conduct them before you do any more work. See how close you are, and, when you are doing the work execute those tests regularly. When you pass the tests you know you are done.

Having these tests should help you be ruthless with the work the team is going. The problem with many big projects is they accumulate tangental “nice to have” work. Having tests should allow you to sideline any work which is not going to support passing the tests.

Now, it is possible that your spike leads you to believe that getting the work done is a challenge, you might not make it.

One option here is to use this information to ask for more people and other resources in the hope that a bigger team will get the work done faster. Yes, I know that goes against my original advice, and I know that Brook’s Law and pregnancies suggests it won’t help but put it down as an option.

Now we are into spending big money more options open up.

Do the best you can but in parallel launch a lobbying campaign to change the rules or have them delayed. This might sound repulsive, and it is not an engineering solution, but actually big companies do far more often than most people realise.

Another option is set based engineering as practices by Toyota. Form up two teams, give say 90% of the budget to one and 10% to the other. While the big team takes the rational approach the other team work on a lightweight solution. If the 10% team succeed you are on safe ground and potentially save money by cancelling the other work.

Finally, I’m speaking from an abstract perspective. I expect a company which faces this sort of situation has probably done so before, more than once. So in addition to doing a spike and writing some tests I’d want to look at past performance. That might offer some more options or tell you what not to do.

Online Writing OKRs mini-workshop masterclass, December 12, 2022 – limited very early bird tickets available until 28 November – discount code BlogReader to save another 20%.