Communication is the key to managing the stakeholders. Many times, not enough efforts are made to communicate clear details, status, risks on the ongoing projects. On the other hand, not everyone can detail every important aspect or gauge what’s important to communicate without being subjective and setting aside all emotions during communication.
Usually, Engineering teams are focused on their work and do not put a lot of emphasis on communication and highlighting the risks with all the data. Even when they do, the usual sentences will be ‘should be able to complete on time’, ‘too many bugs’, ‘not ready’, ‘looks good’ which are all subjective in nature and do not really convey the information that helps in making a decision.
Often there are assumptions that communication happened or that everyone knows all the details. This leads to management being in the dark on important aspects.
One way of ensuring smooth communication is to have proper data to represent the status and risks.
Metrics in SDLC
Metrics are pure data. They show you numbers without emotions which is the most important factor in analyzing the data. The real problem, in SDLC, starts when these metrics are considered as a single source of truth or when they are taken up as absolute measures or when used inappropriately.
A few notable points on metrics:
i. Metrics are indicators of current or past conditions–they are not THE truth. The proper initial response to any metric anomaly is to investigate, not act.
ii. The more a quantitative metric is visible and used to make important decisions, the more it will be gamed.
iii. Be careful what you measure because that is what you are going to get. You should measure things, but understand when to make them as targets.
iv. Vanity metrics makes you feel good, they cannot be used for decision making.
When and when not to use Metrics in SDLC
There are some metrics that are absolutely useful while there are others that are mostly misleading or distracting, more of a Vanity metrics or that can be easily gamed. In other words, not well thought of. Every Manager, every leader at some point goes through the process of picking a wrong metric, getting carried away with the same.
Always ask questions before you pick a metric:
i. Will they be gamed?
ii. Are we choosing Vanity metrics?
iii. Do we need to use this metric as a measure?
iv. Do we need to publish this metric?
Take for example – ‘Zero technical debt’ as a Metric – this means all bugs identified, during the SDLC, should be fixed and cannot be left in the backlog. If we start measuring teams on this metric, the whole focus will be on fixing every bug even if it’s from a feature that no customer has been using, even in cases when it’s impacting the new features and so the customer adoption.
There are a few metrics that we should watch silently, during the SDLC, to understand how the team is doing, to understand what needs to be improved in our process. If you upfront publish these metrics as measures, they will eventually be gamed.
Top comments (0)