No, this post has nothing to do with application optimisation. This post has to do with two of the simplest things you can do to increase the speed (and happiness) of your team’s development efforts. Although not a silver bullet (they don’t exist) this tip is easy to do and with a little discipline it’s sustainable whilst at the same time being applicable to any project.

1. Minimising Work In Progress = Better Speed

If you think you can optimally manage a project without managing your work in progress (WIP) then I wish you luck. You’ll need it. In the distressed projects I’ve seen all of them have had an uncontrolled backlog. With this in mind, I’m going to say now that context switching brought about by high levels of WIP will smash your productivity to pieces. It doesn’t matter what the context is, humans are limited by how many things they can simultaneously do at one time. In fact, for the vast majority of people, this limited to “one thing at a time”. No matter what you think, you are not an excellent multi tasker. There, I’ve said it and I’m glad.

“Standard advice, keep your WIP to an absolute minimum”

There are three reasons why high levesl of WIP are bad.

• It requires higher level of mental bandwitdth to continually switch contexts which ultimately makes us tired.
• High levels of WIP has the tendency to hide problems amongst the mountains of work.
• We easily mistake the feeling of busyness for accomplishment.

When switching between tasks, output does no correlate with the number of tasks in a linear fashion. For example, just because you are working on two tasks, it does not mean that your output will sum to 100% (50% on each task). As the following diagram shows, context switching has a huge cost of around 20% of a person’s bandwidth being devoted to the act of switching contexts. For each subsequent switch, a further 20% is lost each time. ¹.

But it’s not just output that suffers. Consider that quality will also suffer as working memory must reconfigure for each switch. With software development being inherently working memory intensive, even modertate levels of context switching will lead to a reduction in software quality and an increase in software bugs. As software developers know, when working with full effort on a task there is a lot of things being kept in the mind at once.

Although high levels of WIP makes us feel busy another drawback is that in this situation we tend to always gravitate towards the easiest assigned task. As one task becomes harder, we often move to the the next easiest task. This inadvertently leads to problems being hidden. The lack of focus means the true complexity of problems are only found later on in the development. As we know, it’s far easier to work on problems when they are found early on.

It’s up to the developers to manage the beginning and end of work. When developers are complete with their current tasks (according to the definitiation of done (DoD))do they then pull the next piece of work. It’s simple but effective.

The funny thing about this is that it’s not just the human CPU (mind) that works best when focused on one task at a time. Computer CPUs also prefer sequential tasks within the same context. In fact, switching contexts is a CPU intensive task which requires a level of overhead to restore state.

A Simple Context Switching Experiment

Running around doing many things makes us feel productive. However it’s an illusion and this feeling couldn’t be further from the truth. Don’t believe me?

First, draw the following table on a sheet of paper:

Names	WIP - 6 Simultaneous Tasks	WIP - 1 Simultaneous Task
James
Susanne
Daniel
Peter
Rachael
Fred
Time

Round 1: Six Simultaneous Tasks in Progress

In this round write down each of the names simulat one letter at a time. On the first cycle write down the first letter of each name. On the second cycle write down the second letter of each name. Do this until you have completely written all of the names in the list. Write down the time taken to do this at the bottom.

Round 2: One Task in Progress

This time, write down each name completely. One name at a time. Write down the time taken to do this at the bottom.

This is a simple experiment which quickly highlights that the mind has trouble with context switching. Moreover, although the time completion should have been similar we can now see the huge overhead associated with managing multiple tasks at once. For a a task as complext as software development you can imagine why minimising context switching through maintaining minimal amounts if WIP is critical.

2. Faster Cycle Times

Now that your levels of WIP have reduced to a minimum, the next step on the way to faster delivery is to reduce the length of your cycles. In manufacturing speak, this means to reducing the batch size. In software speak this means smaller releases more often. This is incredibly important because it means the team can start delivering software faster so that the customer feedback can begin and problems can be fixed sooner.

In the traditional waterfall model, cycles were typically long with releases being done after many months of work which was preceded by months of system design. Thus, high WIP levels were difficult to manage, problems were often found after the fact, rework was high, - lead times were long and levels customer satisfaction was typically low. It doesn’t take too much imagination to understand why having a 6-12 months schedule for software releases (an entire year of code and features!) will lead to this situation. The larger the piece of software being released into production, the more difficult problems are to fix. It’s a tradgedy that this mode of working STILL happens today.

We now know better. Reducing cycle times leads to far more effective operations. ² In the high clock speed, highly competitive internet universe, we simply can’t afford not to release now. Thus, teams should be aiming to reduce their release lead times to a minimum. In Scrum projects this is often planned in 2 week sprints, in Kanban projects this is set to as and when features are ready. Consider what this does to the project feedback loop.

A Simple Batch Size experiment

For this experiment you will need 5 coins. The goal of the experiment is to start getting the coins to the customer column in the shortest possible time.

First, draw the following table on a sheet of paper:

Coin	Start	Step 1	Step 2	Step 3	Step 4	Customer
1
2
3
4
5

Next, place each coin in the Start column. To move a coiin into the next column the player must turn each coin over twice.

Round 1: Large Batch (Mass Production / Big Release)

In this round, each coin in a column must progress to the next column before proceeding to the next column. This is akin to a large batch, big release mode of working. Time the result and record it. This represents the time taken to deliver your software.

Round 2: Small Batch (Single Piece Flow / Small Release)

In this round, each coin must be delivered to the customer before proceeding with the next coin. This is akin to small batch, fast cycle way of working. Time the time taken to deliver the first (and second, third, etc.) coin to the customer. This represents the time taken to deliver the first feature of your software.

What this experiment represents is the difference between short and long release cycle times. Clearly we can see that shorter releases start delivering value to the customer faster. In contrast to the big batch mode, small batch sizes generally see less WIP, customer feedback happens sooner, rework is smaller (but not eliminated) and faster to perform, and bugs are smaller and easier to fix. Ultimately, the ideal setup would see continuous deployment with small deplyments being fed through on a regular basis.

3. Minimise Handoffs

Passing work between teams is common but it needs to be avoided where possible. The knowledge leakage is almost always huge. Whenever work passes from team to team there is friction in communication, coordinating, specifying, scheduling, etc. Each handoff becomes a potential queue where work will wait when we rely on resources that are shared between different value streams. Escalation becomes common. ³ Work can completely lose its context - a vital ingredient in domain understanding.

One approach is to seek dedicated people from other relevant teams who can be involved in the development process from the get go. This promotes better vertical integration and a better shared understanding thus allowing for teams to be organised so they are self supporting. Another strategy is to introduce automation wherever possible. From testing to environment creation, the benefits of this one should be obvious. Both strategies reduce potential queuing time as well as the amount of non-value added work.

Whichever way you look at it, trying to minimise handoffs is important for reducing knowledge leakage in the prject. Ensuring project continuity and conext is critical for effective working, improved workflows and faster response times.

4. Communicate the Current State of Play

As a high performing (and self organising) team, information transparancy is critical not only for effecitve communication but also for effective working and prioritisation. How will the levels of WIP be controlled if the team members do not know what their team mates are up to. How will they swarm to fix problems if they can’t see them? What are the bottle necks in the workflow? How will task priorities be discussed, communicated and monitored as the project progresses and the requirements change. Visualising the project workflow quickly helps solve these issues.

The easiest way to do this is setup a Kanban or Sprint Planning board - either a physical or digital (Trello, Jira, etc). It’s up to you which swimlanes you choose. There are countless websites which explain planning boards further so I won’t go into too much detail here other than to say that I like to have the following vertical columns:

• ToDo
• WIP (which is split into Blocked and In Progress)
• QA
• Done

Simple stages of the workflow are laid out as vertical columns on the board, whereas more complex processes (WIP in my case) typically combine vertical and horizontal lanes. Mapping the workflow that’s unique to your team makes your process transparent and helps the entire team easily see the status of its work in process. Whichever mapping you choose, quickly becomes visible to everyone who is interested. Knowledge is shared. Work is easy to prioritise and the WIP is easy to see. Visually, people can watch the flow of work from the Backlog column to a releaseable state in the Done column. Importantly, bottlenecks can be quickly identified and addressed.

Importantly, visually communicating the current project state has the tendency to quickly expose the issues in a project that are slowly progress. Compared to the old style Gant Chart and spreadsheet managed projects, visual boards are high feedback mechanisms that help teams address problems early. Remember, the earlier probles are addressed, the easier they are to resolve.

Source: https://leankit.com/learn/kanban/kanban-board/

Conclusion

This post presents four approachable ways that can help teams work faster with less friction. Personally, I think these four methods are attractive because they intutitively make sense as it is easy to reflect on why they are useful. Each one is easy to understand and implementing them is doable in most environments with a little bit of reorganisation.

References