From the beginning of our existence, we have been surrounded by various forms of leadership. Whether the leadership was good or bad, that is a different question. We can agree though, that good or bad leadership sets things in motion. As I work with various organizations, I encounter the same. There is good leadership decisions that sets great things in motion and then there is questionable leadership that actually holds teams back
In particular to Scrum or software development for that matter, some leadership decisions are actually contrary to the behavior they are trying to foster. I want to center around the topic of metrics for a moment. Metrics can be good and yes metrics can be bad. Just like anything, if you want to use metrics, you have to learn how to use them and be educated on what the metric is telling you. Usually, the metric alone is just a part of the story, but it can help foster conversations earlier to provide patterns of upcoming issues that might be plaguing the organization. Scrum is all about empiricism and making decisions based on real data, so the framework supports data gathering.
Most organizations operate on a P&L statement and make decisions accordingly. The problem with the P&L is that it is a trailing indicator. By the time you see the affect on your P&L, it is too late. You can establish metrics that help you recognize patterns as long as you are consistent. Above all, don't tamper with (or game) the metric. Once you tamper with the metric it is no longer valuable as a planning tool. P&L is usually reserved for the overall organization, but team oriented metrics are usually created by department for their specific function.
For instance, if you measure and reward your software development team on "lines of code written", you will foster a situation where the team might write more lines of code than necessary to solve the problem. Remember in software that every line of code costs money; therefore, writing the least amount of code to solve the problem is the goal. Support and maintain-ability come into question if your team is rewarded for writing as many lines of code as they can.
I get it though, how can we establish metrics that tell us that a team is as productive as it can be (haven't answered that one in 50 years LOL)? How can we measure that the team is improving? There are ways to do that, but more on metrics in an upcoming post. For now, I want to focus on discouraging leadership teams from establishing metrics in a team that might foster the opposite behavior they are measuring.
In one of my CSM classes, one of the attendees made mention of how their management team tracks the commitment percentage of their team. Recall in Scrum, that a team selects their work from a prioritized Product Backlog for the upcoming Sprint. The Product Owner orders the backlog, the team selects what they can commit to completing in a sprint (also known as forecasting). The management team tracks how much the team "committed" to completing in the Sprint and then at the end of the Sprint measures that number against what is actually "Done". One of our goals in Scrum is predictability, so I don't mind a team tracking this and trying to become better (or using the metric to guide improvement efforts).
I do mind however, when a management team uses this number to incentivize the team to constantly improve the commitment percentage. They get rewarded / penalized in the way of monetary repercussions. There is rarely an instant where a team can constantly improve commitment percentage, there will be ebb and flows because of the nature of software development and knowledge work. The measure of our productivity should be valuable, quality software increments delivered to the customer. There are many different ways to arrive at a metric that helps us understand that.
Let's take the above account and dissect it for a moment. In Scrum, we practice self-organizing teams to foster the creativity, productivity, and flexibility that we strive for in the process. We also encourage innovation which is why we focus on bringing a customer problem (not a solution) to the team in the way of a Product Backlog Items. Team innovation is the goal. They may eventually encounter a breakthrough that takes them to hyper-productivity. Continuous improvement is the name of the game with Scrum. That often means that teams have to try new ways of doing things (experiment) in order to have the next breakthrough to productivity.
In the case where management is punishing/rewarding commitment percentage of a team, can you imagine how often that team is willing to take risks, experiment with a new process, or even a new technology? You guessed it; zero. They will be risk averse; only focusing on making sure their commitment percentage reaches (or is perceived to reach) the target management has set. That becomes the focus, thus the innovation and creativity of the team will suffer. Moreover, the metric might become gamed to appear the team is doing well, but in reality the team is not. I am sure management did not intend that metric to be used as such, which is why we have to be very careful on what to measure.
Find metrics that foster the behavior you wish to see in the organization. Don't lock on to one metric, use many to tell a story. The metric is the supporting cast. Sometimes the metric can spot trouble ahead and help our team be more adaptive to our customer's needs.
