A Pursuit of Metrics

Kaizen – that is, Continuous Process Improvement—is central to Lean-Agile. It is obvious that improvement requires change to our current practice. If we are going to make changes, we have a responsibility to objectively ensure that our changes are useful and cost-effective. Therefore, as Scrum Masters we must embrace the right measures in the right areas, and we must understand the balance among Waste, Change, and Cost of Change.

In this post I offer some brief guidance that I have shared with my Scrum Masters on different projects so they could learn this balance through small, controlled steps.

Some Ground Rules

Law #1: We never measure individuals. We only measure our teams and the system within which they operate.

Law #2: Measure only that which will give you information to act on for improvement, or to restore equilibrium to the system.

Always keep the following quote in mind when you start measuring a system or team:

"The goal is not to improve one measurement in isolation. The goal is to reduce operational expenses AND reduce inventories AND increase throughput simultaneously." ( Eliyahu Goldratt, author of The Goal)

Bad metrics are rampant in software organizations. Measures to maximize capacity utilization (such as, Is everyone 100% allocated?) are the absolute worst, and counter-productive as well.

Embracing Lean

Lean principles emphasize several key goals that should be measured. Two of the primary Lean principles are:

A. Optimize the system, and

B. Eliminate waste.

Principle (A) means we should not focus on optimizing just one or two activities in our total workflow of development and delivery. Instead, we must look at the whole process, identify the critical path activities, and focus on total flow through this critical path. This is a difficult goal to achieve. It requires a lot of analysis.

Principle (B) requires that we are actually able to identify waste. This, too, is difficult. Knowing the symptoms of waste helps reduce this challenge. Lean identifies seven types of waste that you should look for in the operation of your teams.

These Seven Lean Wastes are:

1) Transport: Unnecessary movement of work items in which that movement adds no additional value. Software and documentation hand-offs, or context switching by team members apply here.

2) Inventory: All unfinished work, including work in progress. Our code that has not been deployed to production is inventory. It is still 'on the shelf' and not yet yielding business value or revenue.

3) Motion: Movement of people or equipment that does not directly add value to the product. Motion waste is often a result of the physical arrangement of the work floor. Whenever cubicle-bound team members have to go to a formal conference room for a discussion rather than just turning to each other in a common development space, this is motion waste.

4) Waiting: Idling, waiting for the next production step. No value is added at all while waiting. Waiting for requirements, waiting for approvals, waiting for resources are all manifestations of waiting waste.

5) Overproduction: Producing more than is required or requested. Bloated feature sets are overproduction. Gold-plating of features ("They didn't ask for this but we might need this someday.") is the classic software example.

6) Overprocessing: Expending energy and time to meet standards or goals that do not exist or have a diminished Return on Investment. A common example is pursuing excessive precision in development metrics when 'good enough' accuracy is sufficient. Or producing extremely precise diagrams or documentation that will probably be inaccurate when the next sprint is finished. Or a Gantt chart that goes two years into the future.

7) Defects: Bugs, errors, any deviation from what is specified as a goal—all of these force additional rework to reproduce, identify, fix, verify, and re-deploy product.

In applying both of these Lean principles against the Seven Lean Wastes a wise Scrum Master will always embrace an economic mindset. Money matters! If we make a change to eliminate waste, we must be certain that the cost of the change is not greater than the cost of the existing waste. So this means we must be able to have some measure of our as-is so we can compare that to our expected to-be.

Being an Effective Scrum Master means much more than facilitating five Scrum events!

Choosing Initial Metrics

When I join a project, I ask my Scrum Masters to identify the measures they will begin gathering on their teams. Each of them often chooses metrics that are different from the choices of their peers. This is fine because I have learned that where they begin does not matter a lot. What matters is where they end. [Spoiler alert to reader: Whatever measures you first select to apply to your development and delivery process, those will not be the measures you eventually use.]

I tell them that, as Agents of Change, I expect each of them to construct a 'living map' that can change at any time, but always describes where their teams are on their improvement journey:

1. What is your team's maturity today? How effective and efficient are they?
2. How do you know? Can you demonstrate their improvement through actual measurements?
3. Where do you want them to be in six months? Where do they want to be in six months?
4. What measures will you embrace to monitor their progress to that goal?

I periodically ask them for their current answers to these questions in the regular 1:1 sessions I hold weekly with each of them. This allows me to hear if their measures are yielding actionable value, based on the feedback they obtain from these measures of their flow of delivery, and if their measures are fit for purpose to attain measurable improvement - that is, Kaizen.

If you have not yet signed up to receive more content into your Inbox, please do so!