Parallel Works

The most effective team is the one that is working on as many different things as possible, right?

Do more things at once, get more things done. Just like using threads in a piece of code.

It turns out, parallelising work in a team is exactly like threading. You need to carefully pick and choose when you parallelise and be conscious of just how many worker resources you actually have.

And it's not the number of people you have in the team.

Same Projects, Different Dimensions

Any software delivery team probably has a collection of medium to large pieces of work that need to be done. The sort of stuff that can't just be picked up and knocked off over the course of a couple of days.

In other words, projects.

Every project you start counts against you when it comes to Work In Progress (or WIP for short).

Kanban tells us that the more WIP you have, the harder it is to deliver things effectively because it causes increase context switching and longer cycle times. The longer the cycle time, the longer the delay before you see the value from the work.

Project WIP is no different, except it causes a number of wider ranging issues because the scale of the work is larger.

The first issue is siloing.

If your team has establish a pattern of a single person per project, then the knowledge they gain during that project is likely to live only in their head. Sure, you can mitigate this with knowledge sharing sessions or ensuring that their work is being reviewed by someone else, but the effect of that sort of thing is limited if other people have their own projects to worry about.

Siloing is subtle, because it leads to all sorts of other ill effects like a lack of collaboration (why help someone else when I have issues of my own?), a lack of shared ownership (why care about what other people are responsible for delivering?), and most importantly a lack of redundancy. The bus factor is a real thing when everyone is working on something by themselves.

If you try to deal with siloing by sharing knowledge and experiences across the group, but you still have a lot of project WIP, then another problem rears its ugly head: cognitive load.

Lots of things going on at once means lots of things that people need to be aware of, which fight for the limited amount of space in their heads. This in turn leads to less understanding of the problem space and an increased risk of errors and defects, along with a reduced effectiveness of the knowledge sharing that you were aiming for in the first place.

In turn, high cognitive load leads to all sorts of other side effects, like reduced morale and burnout, because people get exhausted with all of the things that are happening.

As a manager you're no different, if there are a lot of things going on at once you can't possibly be across them all, even if you lie to yourself and think that you can.

So, high project WIP is bad, but if it's so bad, how does it happen in the first place?

Surely we're smarter than this?

We Found The Gateway

It's pretty easy to fall into the trap of having a lot of project WIP, and I can say that from experience.

There are always so many things to do! When I start planning, I aim to maximise the amount of stuff that gets done. I want to disappoint as few people as possible and push forward on as many fronts and boundaries as I can, delivering the maximum possible value.

Contributing to this, is the common practice of estimating things in Full Time Engineer Weeks or Quarters (FTEW or FTEQ), which implies that an estimate of a single engineer for a few weeks is valid.

In fairness, sometimes it might be a valid estimate. There really is a subset of work that a single engineer can accomplish in isolation.

But it's a tiny subset and the vastly more common case is that you want a team of engineers working on something from start to finish to avoid all of the bad stuff that I mentioned above.

Of course, that increases the cost of everything, which then makes planning conversations harder because you have to answer more difficult questions. As a manager, depending on who you're answerable to, this can be a very challenging minefield to navigate, especially if your stakeholders think they know how to manage your team better than you do.

I've been pretty lucky at Atlassian because the project WIP problems in my team mostly stem from us not wanting to disappoint anyone and not being as aware of our limits as we should be. There's some pressure, but I have a lot of support for pushing back and setting appropriate expectations.

The other factor that can lead to large amounts of project WIP is rollover, which is to say when something you were doing in the last period isn't quite finished yet, so it rolls over to the next period.

Of course, that thing is almost done right? Just needs a tiny little bit more attention to push it across the line.

In my experience, it's probably not almost done, so failing to account for rollover work in planning for the next period often leads to a self-fulfilling prophecy where you get rollover work for the next period and so on and so forth.

There are other factors that lead to project WIP, but I think that's enough for now.

But what to do?

More Power Mr Mallory!

I don't really know what to do, but I can tell you what I tried to do, and you can make your own judgements.

I tried to put a hard limit on project WIP by changing the atomic unit of execution from "an engineer" to "a team of three engineers". This broke the team down into a smaller number of "streams", each one of which was capable of doing a certain amount of work.

At Atlassian we have a project management framework called The Atlassian Way, which breaks projects down into four distinct phases: Wonder, Explore, Make, and Impact.

My proposal was that each stream could conceivably have a single project in the Make phase (i.e. actually executing and engineering), a single project in the Impact phase (i.e. it's delivered and we're adjusting and checking value) and a few pieces in Wonder/Explore (i.e. we're grooming them to be executed in the future).

In doing this, I greatly decreased the amount of work that we committed to for the next period (which was FY22 Q4).

It didn't really work.

The transition quarter was rough for a number of reasons: we had a bunch of interruptions (like this famous one) and a suite of rollover work that we didn't account for, so we still had a lot of project WIP going on.

This in turn meant we continued to suffer from the effects of said WIP, which mostly comes down to not as much being delivered as we would have liked and an unhappy and exhausted team.

But I'm not discouraged. After all, no plan survives contact with the enemy.

After that initial clash, it's all about how you adapt.

Finding A Way Back Home

So, having too many projects all happening at the same time is bad.

Or, more accurately, it's bad for my team.

As a manager, it's important to understand just how many projects your team is capable of doing at the same time. One project per person might very well be sustainable for some teams, but it certainly doesn't work for us.

I don't really know if one project per three people is sustainable either, but it seems like a worthwhile experiment to try. We might not have nailed it this time, but change is hard and that's no reason to give up, especially when the feedback loop is an entire quarter long.

Next time we'll try harder, commit to less things and ensure that we have a little bit of wiggle room by not committing to only critical things. That way, if something happens, we can more easily decide what to give up on.

And I'll continue to write everything down because it's not science unless you write it down.

It's just screwing around.