We live in a metrics-fixated world where having more metrics is always thought to be better than having less, and Software Development Life Cycle (SDLC) metrics are no exception. But the truth is that any badly chosen or managed metric will do more harm than good to your organization. To avoid these pitfalls, take ownership for SDLC metrics away from managers and put it into the hands of those who can best manage it: your development teams.
There is no shortage of people who expound the virtues of establishing and tracking SDLC metrics with the mistaken belief that they provide effective “levers of control” for development activities, especially when they are used in combination with reward and punishment. But consider the cautionary tale of Wells Fargo whose use of metrics, punishment, and rewards (which were intended to drive business growth) resulted in massive fines, class action law suits, unhappy customers, and regulation to cap the company’s size (ironically, the opposite of what the metrics were intended to achieve!).
As Atlassian (the maker of Jira) has said “Metrics are a touchy subject. On the one hand, we've all been on a project where no data of any kind was tracked, and it was hard to tell whether we're on track for release or getting more efficient as we go along. On the other hand, many of us have had the misfortune of being on projects where stats were used as a weapon, pitting one team against another or justifying mandatory weekend work. So, it's no surprise that most teams have a love/hate relationship with metrics.”
In his book The Tyranny of Metrics, Jerry Muller shines a light on the dark side of metrics through a series of case studies in a variety of industries. He shows how blind belief in the cult of metrics has led to a culture of gaming and manipulation that results in predictable negative consequences. Understanding this dynamic is critical if you want to avoid the failings of bad metrics use in your organization.
When selecting your organization’s SDLC metrics, consider the U.S. Army’s findings on Counterinsurgency Metrics, which showed that standardized metrics are often deceptive, but metrics developed to fit specific circumstances, especially when selected by practitioners with local experience, could be genuinely informative. The lesson was to abandon fixed metrics and instead determine what is worth counting and what the numbers actually mean in their local context (Muller).
SDLC metrics (like all metrics) are largely misused in industry and can be detrimental to your organization. Having no SDLC metrics at all is better than implementing a bad metric (at best, a bad metric will be a productivity drain, but at its worst, it results in gaming behavior and/or unintended consequences that can actually steer your organization in the wrong direction).
You can avoid falling victim to the pitfalls of bad metrics through careful selection and cultivation of your metrics. Here are some simple rules to follow when defining and implementing SDLC metrics:
(SIDE NOTE: This approach to selecting and managing SDLC metrics will be most effective if your organization has successfully implemented Agile. For those members who have adopted Agile development processes, you will notice that the above approach builds on the Agile tenant of creating self-managing teams and providing them with the skills, tools, and support they need to deliver successfully. As servant leaders, Agile managers entrust their development teams with responsibility to self-organize and self-manage, then let them determine the best practical solutions to the myriad of problems they will encounter. This approach requires instilling both trust and accountability into your development team and generally leads to better results than can be achieved in a command-and-control organization. Why then, would you not also entrust them with figuring out for themselves what the right SDLC metrics are to best perform their responsibilities for the organization? This approach is far more likely to yield effective metrics for your organization than something selected “from on high” and imposed on your development team.
Additionally, Agile development practices (which involve continuous, incremental delivery of working and tested software) is well positioned for gathering metrices that are good measures of the value delivered to your customers.)
Custom application development is a strategic differentiator in the digital economy. Organizations need to make good decisions on how to insource or outsource that development or they risk bad software … and worse results.
The concept of building a software factory has increased in popularity with the drive to build digital platforms, products, and services. It is also a major transformation from traditional, hands-on-keyboards software development practices in and of itself. Before you build your software factory make sure you have a firm foundation for success!
Traditional accounting practices are tailor made for waterfall project management. Organizations that have transitioned to the use of standing product teams using Agile and DevOps need to transform their accounting practices as well or they will leave valuable capital expenditure dollars on the table.
COVID-19 has forced software companies and their suppliers to refocus efforts around prioritizing systems and workflows that are nearly 100% digital in nature. As a result, Info-Tech has observed the quick emergence of six market themes that are highly relevant post COVID-19. This note series will profile key vendors and how they fit into the post-COVID-19 world.
COVID-19 has forced software companies and their suppliers to refocus efforts around prioritizing systems and workflows that are nearly 100% digital in nature. As a result, Info-Tech has observed the quick emergence of six market themes that are highly relevant after COVID-19. This note series will profile key vendors and how they fit into the post-COVID-19 world.
IBM is changing the terms of its ubiquitous Passport Advantage agreement to remove entitled discounts on over 5,000 on-premises software products, resulting in an immediate price increase for IBM Software & Support (S&S) across its vast customer landscape.
Is it true that everything that can go wrong will go wrong? Don’t bet on it to not.
So you’ve gone Agile. You do daily scrums, retrospectives, and all the “right” Agile ceremonies. But still your organization isn’t quite convinced. It is now critical to balance the drivers and goals of both Agile and traditional thinking in order to achieve organizational success.
Do you feel like your Agile teams are treading water – going through the motions but never going anywhere? It’s a risk, and practices such as daily standups, retrospectives, and demonstrations need to be used wisely or you risk losing discipline to meeting fatigue.