Everybody today talks about efficiency. It’s become the topic of the day fuelled by rumours of old companies not keeping up with young start-ups or even more apocalyptic the rise of artificial intelligence. Regardless of why you want to do it, it is crucial topic that might just make the difference between being a success or a flop. Looking from the Agile perspective, improved efficiency is just the result of applying the right thinking, having the right values and most importantly, always questions you own added value. We are going to look at team efficiency by looking at two very simple but often overlooked concepts:
- Inventory: what on our to do list
- Flow: how quick can we get rid of them
First, let’s look at inventory
. A concept introduced by Japanese companies back in the 50s. Virtually unknown for years, it become one of the underlying principles of every Agile framework. We all have a lot of things to do. The drama of our days is that we have too much on our plate. Not just that but people expect us to actually deliver something at the end of the day, not just be busy working. Inventory refers to the number of items we have to work on simultaneously. Sort of, on how many things can you work in parallel? Problems related to big inventories usually are:
- Inefficiency, wasted time, and multitasking
- A lot of work but no results
- Lack of focus and low engagement or commitment
- Poor quality and rework
One of the often-ignored aspects of doing agile is limiting the inventory or the work-in-progress as we call it. To illustrate that, let’s look at one of the oldest agile approaches, Kanban. In its simplest form, Kanban means visualising the work and improving the flow to get results by using three columns:
- to do, where we list all the items we have to work on but are not started yet
- Work in progress, where as its name says, we list all the items which are started but not yet finished. This is actually our inventory so we’re going to get back this in a moment.
- Done, which is quite straightforward, items are finalised. Done basically means you don’t have to touch them again.
And now, let’s talk about inventory, or work-in-progress. Let’s imagine a team of 7 people who has on its to do list 10 items. I call them items but that could be functionalities, features or just components. So, if we are 7 people and how to finish 10 items, how many do we open? If you ask, most teams would probably tell you that each team member will pick something to work on which means that we’ll end up with 7 items in our WIP column. Now that normally leads to poor collaboration, people working as specialists and focusing on their piece with almost no regard for the end result. The problem however is that the items they are working on usually require some level of collaboration beyond what one individual can do. Let take a simple example of a software application. A functionality needs to be designed, developed, tested, maybe even deployed. So much more than what one individual can do. Fixing these problems is often easier than people think.
Here are a few things to consider when you look at your to do lists:
- Limit your work in progress – you can still achieve a lot of things but go for a more sequential approach rather than everything in the same time
- Visualise your capacity to close items – and here a Kanban board can help. Just put it on the wall and see what’s on your to do list, what you are currently working on and what you have already achieved
- Establish clear policies for accepting work. I am pretty sure people who give you work want results not just to keep you busy. So, work with them and make your progress rate visible. Bottom line is, if you deliver results everything should be fine.
- Set correct expectations because nobody can do any magic tricks to get the work done. Showing transparency and delivering results will create trust and an intimate relationship.
As bad as it might sound, a big inventory is not necessarily a bad thing. It is all about how quick you turn that inventory into something valuable. And we’re going to do this by looking at a concept called flow
. For many years we’ve been educated, taught and managed to be good specialists. To pick one skill or competency and be very good at that. If you are a great designer you will create great design. If you are a great software developer you will create great code. And that is okay but often the problem is will excel at our work but that work by itself is pretty useless. To become valuable, the result of your work will have to be subjected to other operations you might not be familiar with. And since I mentioned a software develop earlier, let’s pick this person as an example of a flow. In a typical scenario, if I am software developer, I sit between somebody who’s doing some architecture, maybe some design and then somebody who’s doing some testing. So, I will have to integrate the outputs of designers and architects and have to produce some outputs – the code – which will serve as an input for testers. So, my flow looks like this: architecture, design, development and testing. Just an example, in real life you might experience something slightly different but you get the idea. Why is flow important? Because it has a direct impact on the end result, in other words, on your efficiency as a team. Just imagine you are a very talented software developer and a very efficient one but nobody is available to test your code after you. You just created a huge amount of useless code which sits there, used by the end customer. Meanwhile you might think you have done your job, you might even think that you deserve a raise because by yourself, you are very efficient. Looking at flow, will tell you how much value you are actually creating.
Consequences of bad flow usually are:
- Waiting time – those who work before you in the flow are not done but you are available so you just wait
- Blockages – those who work before you in the flow are done but you are not yet available so the work will be blocked until you become available
- Overtime because eventually the work will have to be done
Luckily there are some pretty simple solutions:
- Visualise the flow. Just draw the flow and display it somewhere very visible. Like, on the walls. If it’s visual you can easily spot the blockages. It will be obvious that some items are blocked and also that some resources are idle. So, the first step is to see where the problem is.
- The second step is remove bottlenecks. Or optimise the flow. There are a few techniques should help with that. One is limiting the work in progress. Do not commit to more than you can handle. Another one is what we call establish pull instead of push. Normally what we do is, when we finish our work, we push the result to the next operation in the flow with no regard for the availability of the resource in charge. This is call push. Pulling, is the opposite. As a resource, when you are available, you pull some more work from those work before you in the cycle. To illustrate, let’s imagine I am a tester. If we are using push, I will probably get a lot of functionalities to test the moment they are ready to test and probably nobody will ask me if I am available. So, the items will just wait. They will be blocked and we just created a bottleneck. Implementing pull means nobody will give me anything to test until the moment I am available. In that moment, I will pull something to test. This is how you establish flow and avoid bottlenecks.
- Third step, one you have removed the bottlenecks is how do you increase the speed of your flow. It does flow but how fast do items move from one operation to the other. And here there are a lot of techniques that involve great communications between team members and setting up a team of cross-functional specialists.
In conclusion, if you are looking at the right problem there should be something you can do about it. Visualise, see the problems and address them.