Have you been asked to put metrics around your team’s efficiency? You’re not the only one. If you’re like me, you accept the challenge and begin the journey to figure out how in the world you actually do it. You may already have metrics around your team’s work, but which one will reflect that efficiency metric you’re looking for? All throughout the Lean Software and Systems Conference ’12 in Boston, MA and at David Anderson’s Kanban Advanced Masterclass in Port Angeles, WA, I kept this question in mind as I listened to and discussed things with other seasoned members of the Lean & Agile community.

What does efficiency really mean to you?

Many managers likely focus on what’s right in front of them and what they are responsible for: their team. The biggest realization that I had coming out of these events and classes was that I need to ask more questions to my executives before I could continue. The first, and not least of which, was “Can you be more specific about what you want to measure the efficiency of? (aka,’ efficiency of what?’)” Think that’s a stupid question… that it is self explanatory? Well, let me throw some questions at you. If you are a development team being measured on your lead or cycle times as a measure of efficiency, what does that really measure? What factors are at play in your lead & cycle times? Do you set your own priorities? Do you get to control policies about how and when you deliver work and what can interrupt work in progress? If the answer is no, then the lead & cycle time measure doesn’t measure your team’s efficiency, it measures the efficiency of the entire system – of which you have likely have control of or influence over only a small part. You could have a very efficient team based on what you can control, but these numbers could reflect large amounts of system inefficiency.

The team or the system?

I heard many times at LSSC ’12 that the average consultant’s client has 5% touch time and 95% delay time factoring into their overall lead times (the measure of the time it takes from request to delivery). Say I’m a development manager at one of these “average” clients. If I only focus on the efficiencies of the things my developers do when executing code I can make an improvement that touches only 5% of the overall lead time. As one of the speakers at LSSC ’12 noted, “pushing people to go faster is not as effective as working on improving interfaces and handoffs.” Thus, by far, the best place to make the largest impact is at the system level. With that in mind, I have to now consider what my executives are really thinking of when they reflect on efficiency. Its an easy term to bat around, but one that is not always measured the same by everyone. I would hazard a guess that most executives are concerned with efficiency around things which please the customers or clients, a.k.a. lead or cycle time.

Kanban to improve system efficiency

Kanban is a change management approach that encourages you to apply evolutionary change across your system while meeting as little resistance as possible. The goal is to balance capacity against demand – to reach and maintain a sustainable pace of delivery. Implementing Kanban, and focusing on continual improvement via feedback loops, can greatly improve your system efficiency. A great book to read on the subject is David Anderson’s book “Kanban: Successful Evolutionary Change for Your Technology Business“. Much of this blog post is informed by things I’ve learned from David or his books. Follow him on twitter via @agilemanager

How to get started:

1) Understand the existing sources of dissatisfaction.

Why are you looking to make a change? There are obviously problems you want to address or you wouldn’t be bothering to begin a change initiative. You need to get viewpoints from internal and external stakeholders to identify current sources of dissatisfaction.

Example source of dissatisfaction: “Your development team is so slow!”
This complaint sounds very specific to your team, right? However, you begin to realize that outside forces can directly impact your team’s policies have a direct effect on their cycle time. Examples would be any prioritization that is not FIFO such as classes of service themselves or non-FIFO prioritization within classes of service (will make lead times longer) as well as expectations of being able to interrupt work in progress (which makes cycle times longer).  So, changing those policies imposed by the larger system makes your development team look “faster.”

2) Analyze your demand and your capability.

In the feedback from stakeholders you may begin to see or hear that there are expectations of various classes of service dependent upon the request type. You’ll also begin to identify types of risk that they are concerned about. This is all crucial information you will want to gather and eventually use to guide your visualization of the demand in the system. Remember though, different types of demand and different classes of service, though they help you serve your customer to their needs, will have a negative impact on your overall lead times, if not cycle times. This needs to be recognized when analyzing efficiency metrics.

Look at your historical data to get a read on your team’s current capability. You need a baseline to set initial expectations. Over time you’ll, hopefully, improve your team’s capability by optimizing both your team and the system it interacts with.

3) Visualize the system

A basic premise is that to introduce positive change to your system, you have to understand how it works. You must be able to visualize your system and how the work flows through it. This visualization, or Kanban, is meant to raise up bottlenecks and problems so that they can be addressed and improve the flow of work through the system. Your Kanban can be as narrow or as wide as you make it. For instance, are you a development group visualizing only the “to do, doing, done” flow or does your Kanban show a wider system of “backlog, requirements gathering, creative delivery, ready for development, developing, verification, deploying, done”? You need to make your Kanban wide enough to visualize the handoffs in your system that are affecting your measurements of efficiency. This is so that you can determine if there are bottlenecks at any of those handoff points and also so you can see the impact of any change made or constraint applied. Ask yourself “Who has to touch this before it can go live?” Ideally, all of those touchpoints are visualized in your Kanban.

4) Limit your work in progress (WIP)

In Kanban, WIP is limited at each step of the system workflow. It is a recognition that, to maintain optimal efficiency of the system, you want to maintain a smooth even flow throughout the system as a whole. Bottlenecks, or traffic jams of work, in the system negatively affect your feature’s commute to ‘delivery’ just as traffic jams of cars on the interstates negatively affect your commute to work. You base your initial WIP limits based on historical data or a formula such as 1 or 1.5X number of contributors in that area of the flow.

5) Implement regular feedback loops

You can’t just visualize, limit WIP and then leave. Systems are living breathing things that change. You’ll add people, lose people, have increased demand or specialization. All of those things (and more) will affect what the optimal capacity of different points in the system are. Therefore you have to frequently get feedback from the system metrics (and people in the system) and then apply models & the scientific method to make informed improvements to the system. Once you do that you watch some more, get feedback and make additional changes. This is the evolutionary approach to change known as Kaizen. Its small, frequent improvements over time.

Back to the efficiency question

So, changing the system is hard. But, in the end you reap the greater rewards. You have the capability of making the big bang changes that touch that average 95% delay time for any given work item.  So, maybe there are things that you can improve specifically in your execution team and, by all means, do so. But don’t ignore the elephant in the room that is the system.