Metrics

The GQM Approach: A Framework for Defining and Measuring Effective Software Metrics

Software metrics are important, as they tell you the transparent truth of software delivery. The question remains – which metrics should I use, and why?

Sometimes people just look for an available or known set of metrics and then add more as and when they discover anything new. But does it really make sense to try and apply those known metrics to any scenario?

Why do We Need Software Metrics?

by ShriKant Vashishtha 3 Comments

Humans mostly have a tendency to go by their gut feeling. At the same time, machines mostly don’t tell a lie as their only job is to emit the necessary information.

That’s the reason people like me are scared of weighing machine as that could break the myth of my handsomeness 🙂 . Your family may be insisting you to go for full body health check up, but many fear from them as well.

Those tests will transparently tell you if anything et-all is wrong with your health. If yes, you may take corrective actions. Many people don’t go for them as they don’t want to hear bad news about their health.

You see, truth many times is beyond perceptions and feelings. Something mechanically or electronically measured is beyond feelings and is sheer truth.

Like a health checkup, software projects should also be checked for the performance of their vital organs (parameters). So that if something is wrong, that could be fixed.

Now someone may misinterpret the first Agile Manifesto tenet “Individual and Interactions OVER Process and Tools” in form of “Individual and interactions INSTEAD OF process and tools” and say, “Hey! We are doing Agile. So we don’t need Metrics. That’s so old age!”.

However truth can’t be fictionalized as has been proven in many Lean Startup experiments. Without facts, there can’t be any validated learning. Without validated learning, you never know whether your MVP is good or not.

In software development as well, one needs facts to validate the vital parameters of project delivery.

Appraisals in an Agile Company – Part 1

by Avienaash Shiralige 4 Comments

Appraisals! How many of you dread this word? This is the only time in the year that you get to bargain for salary increments, everyone end-up negotiating to their best. Appraisals are closely connected with salary raise/increments, bonus payouts and it’s feedback intent takes the backseat.

There are three major issues with traditional approach to appraisal:

Measuring and rewarding individual behaviors and contributions OVER team based measurements.
Long appraisal cycle(mostly once a year) discussing both salary increments and feedback.
Feedback process – Filling long appraisals forms with least discussions between reviewers about reviewee.

Metrics to Build Great Agile Teams: Measure Influence, Not Control

by Avienaash Shiralige 17 Comments

Couple of weeks back, I noticed an incident that triggered this post. Senior Management in a company applauded people for showing individual heroics on the project.

Some of them were:

Staying late in office to address a client request?
Responding to project emails at late night..
Rewarding testers on number of bugs found and more.

And then, managers shared this privately with rest of the organisation too. Treating this as accepted, rewarding behaviour invited more such incidents and frustrated many of those who don’t do this. Below comic strip summarises it well.

“You Will Get What You Measure(or Reward)!”

I recently heard an another incident of how testing team kept an very important bug under the carpet before bringing it up just a week before release, and then getting rewards for the same. Such behaviours more likely are the candidates for root cause analysis than rewards.