Every company wants to know how productive their employees are. That’s natural. If there is a problem, the people at the top need to know where it is, what it is, and how to address it. The way companies keep track of everything is to break everything said and done in the company down into numbers and record it in the form of metrics. This may seem like a good idea, until the metrics start creating issues of their own.
Company heads love the idea of metrics. They want to be able to quantify everything. Sometimes in their lust for assigning numbers, they prioritize the wrong things. To give you an example, a former director at one software company would praise the developers for writing x lines of code. The larger x was, the happier the director was. Any developer worth his salt knows that more lines of code =/= more productivity. In fact, a good developer is more productive with fewer lines of code.
Software development is a thought discipline. Often, the most productivity comes from what appears to be nothing. Trust me, that “nothing” can become something awesome. Developers spend a lot of their time researching issues and contemplating problems. When they solve the puzzle, they use the least amount of code possible to ensure that their code is easily read by others who look at it later.
So, if lines of code are not a good metric for companies to use, what is? Some companies use “velocity”. Velocity is an arbitrary metric meant to describe the amount of “work done” in an Agile environment. There are a lot of issues here. To begin with, nobody truly knows what velocity is. To give you an example of what I mean, Agile Alliance defines velocity like this:
At the end of each iteration, the team adds up effort estimates associated with user stories that were completed during that iteration. This total is called velocity. Agile Alliance
That doesn’t really clear things up for people. Velocity is usually calculated using a point system. This is where everything tends to fall apart. A lot of Agile coaches will advise companies to start out with 1 point = 1 day. Unfortunately, company heads are incapable of understanding the words start out. Once a company head hears 1 point = 1 day, that company’s Agile metrics are corrupted forever, or until the entire upper management has rotated out.
Each developer works differently. Each developer uses different tools, and works at a different pace. A broad spectrum metric like 1 point = 1 day cannot cover the complexities of an Agile team. That’s why the velocity is calculated after the iteration. If a company wants an average velocity, it will obviously have to wait several iterations to obtain that data. Velocity is meant for the development team to use within the team. For management to use velocity externally to berate developers defeats the purpose. 1
Of course, the only metric that the Agile framework strives for is the amount of value realized, which is done through KPIs.
Value itself is hard to quantify, but KPIs can be used to measure how effective we in delivering value. Doshi, Hiren
Then we have the central principles of Agile. The scrum master’s job is to protect the team from outside distractions. The concept of metrics in an Agile setting creates a distraction that takes the developers’ focus away from the product. The team becomes more worried about meeting the arbitrary metric than the needs of the product.
Perhaps there is a place for metrics as an afterthought in software development, but the productivity is evident. When the assigned tasks are completed every iteration, it is clear that the developers are producing. When the new releases are deployed, on time, with all the requested features, it is clear that the developers are producing. If the company needs to prove to others that the developers are producing through arbitrary numbers, perhaps those numbers belong in a back room somewhere. Let the developers remain on the floor doing what they do best…produce.
Comments