Over the past several years, as I’ve been helping teams and organizations improve their ability to deliver software products that are desirable, viable, and feasible, I have been experimenting with a Behavior Framework that has proven to be rather effective. And I’d like to share it with you in hopes that you find it useful and that you provide me feedback on your experiences with it.
My plan is to write a series of blog posts all related to the behaviors framework. Some of them will be about a specific behavior. Some of them will be about tools or techniques that help teams express one or more of the behaviors. Some of them will be my own experiences. And some will be damn near complete fiction.
In this excerpt from Escape Velocity, we take a more in-depth look at Velocity and try to answer (at least in part) the question, “What Is Velocity”?
This article focuses on using Chain of Command as a means of reducing cyclomatic complexity in our code. Along the way, we also create better adherence to SRP.
I recently worked with a team on a fairly significant refactoring. I paired with different team members each day over a three day period as we moved code around, pushing responsibility into other classes, reducing complexity, and make the code more expressive. On the fourth day, I put together some notes on the things we saw and general guidelines for the team to keep in mind. Nothing herein is new to the community, but it might be new to you.
So there we were, at an agile conference. Well, not at the conference exactly. But at a bar very near to an agile conference.
A few patrons were talking agile stuff - like they do. And someone, as evidence in support of their stance that all metrics are evil, used the “But the Scrum Guide”, defense.
“But the Scrum Guide doesn’t prescribe any metrics. As a matter of fact, the word metric is not in the Scrum Guide. Not once.”
I found this claim dubious, so I checked it out.
In a prior post, we talked about why we should manage WIP. We showed that we can use a future value calculation to give us an idea of how long it will take to complete multiple items.
While our future value calculation is both informative and interesting, it is not particularly useful beyond making the point that doing more at once takes more time. What we want to know is how does this materially impact our ability to make software. For that, we can look to a more simple (and useful) calculation based on Little’s Law
Having too much Work in Process, also known as Work in Progress (WIP), is a remarkably common issue. In my experience, management often encourages this behavior. I don’t know if it is the notion that we will get more done if we work on more things simultaneously. Or perhaps there is a fear we won’t get enough things done unless we work on several of them at once.
This blog post is inspired by another Quora question; “What metrics do you use to track Agile Efficiency?”
To begin with, I want to state that if I had to choose between efficient and effective, I’d choose effective. Efficiency is often about output (how many widgets per hour), whereas Effectiveness is often about outcome (was the purpose consistently met).
Agility is about responding to change. Efficiency is achieved by driving out variation. An over-focus on efficiency will lead down a path of standardization and control, making for a less agile system.
That said, given the question was specifically about agile efficiency, I’d look at a few things - Throughput, Cycle Time, Deployment Frequency, and Mean Time to Recovery.
Now, metrics are not bad. But, they are often used in bad ways.
It might help to be aware of some of the side effects of mismanagement of metrics. From inadvertently creating behaviors that actively work against our best interest, to altering the meaning of the metric, mismanagement can do more harm than good.
Charles Goodhart is an economist and former advisor to the Bank of England. In 1975, Goodhart delivered two papers to a conference at the Reserve Bank of Australia. In those papers, Goodhart was discussing research and theory related to monetary policy and control in the United Kingdom. In the years leading up to 1975, existing monetary targets and the controls used to achieve the goals were no longer producing the results desired or expected. There had been what most considered to be evidence of a stable money demand in the United Kingdom. It was believed that the growth of money could be controlled through the setting of short-term interest rates. Higher interest rates correlated with lower money growth.
Goodhart warned, however, that policies and practices based on specific targets were flawed. Goodhart stated,
“Any statistical regularity will tend to collapse once pressure is placed upon it for control purposes.”
“Any statistical regularity will tend to collapse once pressure is placed upon it for control purposes.”
A common paraphrasing is, “When a measure becomes a target, it ceases to be a good measure.” When I talk about this, I tend to add, “And the target therefore no longer means what you think it does.”
Goodhart’s law is a critical piece of information when we think about metrics. No matter how tempting it might be, the moment we set a target for a measure, we’ve changed the system, thereby changing what the measurement means, thereby changing what the target means.
The lesson here is pretty simple. Don’t set targets for metrics. And please don’t give teams incentives towards targets if you do set them. I know. I know. Management 101 says this works. But, science says it doesn’t. Seriously. Setting targets and providing incentives for knowledge work lowers performance. Don’t do it.
Instead, provide guidelines to the teams. My favorite guideline for metrics is, “Monitor trending. Dig in when the trend changes and you aren’t absolutely certain why.”
This article is an excerpt from the book, “Escape Velocity”, available on LeanPub, Amazon, and elsewhere.
Now, metics are not bad. But, they are often used in bad ways.
It might help to be aware of some of the side effects of mismanagement of metrics. From inadvertently creating behaviors that actively work against our best interest, to altering the meaning of the metric, mismanagement can do more harm than good.
Western Electric had commissioned an extensive study that ran from 1924 to 1932 at their Hawthorne Works in Cicero, IL. The intent of the study was to determine the impact of ambient lighting on worker productivity. Would employees be more productive under high levels of light or low levels of light? The workers in the factory were divided into two groups based on physical location within the plant. For one group, the lighting was increased dramatically while for the other group (the control) lighting levels remained the same. Researchers found that productivity improved among the group for whom lighting changed whereas the control group had no statistically significant change.
Employee working conditions were then changed in other ways. Working hours were adjusted, rest breaks were changed, floors were rearranged, workstations were kept cleaner, and several other adjustments were made, including returning the lighting back to normal levels and changing practices and policies back to original standards.
With every change, productivity made small improvements. By early 1932, and the end of the studies, the factory productivity was at an all-time high and employee attendance and retention were at record-setting levels. Some groups seemed to do better than others, but across the factory, all measures were improved.
When the studies ended, productivity, attendance, and retention soon returned to original levels.
The key takeaway from the Hawthorne studies is - that which gets measured will improve, at least temporarily. “The Hawthorne Effect” is described as the phenomenon in which subjects in behavioral studies change their performance in response to being observed.
This, at first, seems like a precious nugget of management gold.
Measure productivity.
Make it known.
Ka-Pow! Increased productivity.
The perfect management formula.
But the reality was (and is), that while that which is being measured shows improvement, it does not mean the overall system has improved. Working longer hours can lead to employee fatigue and burn out, as well as lower quality. Lack of attention in areas not measured, such as quality or workplace safety, can lead to other negative outcomes.
If your team is slacking so significantly that merely measuring their velocity can result in a marked increase in velocity with no ill- effects, then you’ve a more serious issue at play than velocity.
What’s more, there is no guarantee that the thing being measured has actually improved. Velocity might have gone up because the team inflated story points. We should rephrase the key takeaway to that which gets measured will (appear to) improve.
This article is an excerpt from the book, “Escape Velocity”, available on LeanPub, Amazon, and elsewhere.
Recently, on a private forum, a member posted a query about their team’s recent drop in Velocity. Concerned about how their boss would respond, this individual wanted to know how to troubleshoot velocity issues.
After spending over an hour crafting a response, I decided I would also add it to my public blogs in case there are others who have similar questions about velocity.
When leadership asks for an increase in velocity, there are a few common behaviors that occur. Each of them are an attempt to satisfy the potentially unrealistic ask.
It is intriguing to me how often a manager will make a change such as this to a system of work and then later proclaim that the team is gaming the system. This is simply not the case. In fact, the gaming of the system is the improper application of targets or goals for lagging indicators. The rest is just natural consequence.
You can find more on the topic of velocity and metrics for agile teams in my book, "Escape Velocity".
Leaders (and teams) attempt to achieve velocity increases in numerous ways. Most, as you can imagine, have unintended side effects on the teams and none significantly improve the actual flow/delivery of value to their customers. Here we explore a few ways teams might be encouraged to increase their velocity. Unfortunately, no matter how well intentioned, using such techniques still has a negative impact.
This content and more on agile metrics is available in the book, "Escape Velocity"
Demanding more velocity is far and away, the most common Velocity Anti-Pattern, and quite possibly the most harmful. It manifests itself in a number of differing fashions, but the basics are the same: Somebody determines that the team needs to get more done in less time. So they send out the message - “We are going to need more velocities.” This person is usually an authority figure and typically doesn’t do the actual work being asked of the team. And they clearly don’t know what velocity is. More velocities? Aw C’mon, really?
This content and more on agile metrics is available in the book, "Escape Velocity"
