Agile is the buzzword that everyone is talking about, and dev teams may get too caught up in replacing agile activities for hard results. Agile itself is continually improving its metrics, and companies have more opportunity than ever to apply only the metrics that achieve transformative results. When a dev team dedicates itself to results over simply applying the latest so-called agile metric to say "We're agile," great things happen. Here are vetted KPMs that translate into real results.
Setting a Level of Quality for Stories You Commit To
Committing to a story without delivering at a consistent level of quality is bad for business, At the very least, it will cause needless slowdown in your process and frustrate your team. The first step in setting any metric is setting a quality standard for it, and agile development metrics are no different.
Each department should dedicate itself to delivering results that are aligned to the quality standard of the wider team. Quantifying the level of usability for stories that you commit to will not only translate into more immediate results, but it will also weed out bottlenecks in your process.
Committing to the Most Relevant Forms of Testing
Depending on your industry and product, you may already employ different forms of testing: security, function, automation or performance. Are you committing yourself to the most relevant forms of testing? What are you actually quantifying if you are putting more emphasis on automation rather than performance? Perhaps you need to combine certain aspects of testing department processes to give your overall product a better quality and higher timeline. You will never know unless you take a look at what your tests are actually focused on.
It is likely that you do not have the time to test every build manually. Nor should you overlook or push forward possible defects only to find them later on - you will have to deal with them at some point! The answer for many companies is a developer desktop that you can test through an automated process, manually testing only the builds that make it through your initial automated tests.
Production Incidents
There are two types of production incident KPMs that should be on your radar: 1. minimizing production incidents within each department, and 2. comparing the performance of teams against each other over time. This should help to improve the total quality of your product over time as well as reducing the time to market.
Setting a percentage standard for build purity is a great way to normalize results between departments. This quality metric will also help to identify the slow-moving teams in your company.
User Feedback or Sentiment
User feedback has been highly relevant before agile became the go to corporate buzzword; however, your journey into agile should lead you to quantify user sentiment more specifically. Capturing user feedback is a simple thing these days; the value add from this generation is to create a percentage quality metric, perhaps similar to your production incidents metric, that gives you a standard to meet in every new build.
Many companies go one step farther and find the correlation between levels of user feedback and the profitability of the build. Perhaps a 96% positive feedback rate leads to a 5% higher level of subscriber retention. The earlier you begin collecting this data, the more accurate your statistics will be. In any case, you will be in a much better position to develop plans for future builds that respond to the concerns your customers put before you in social media conversations, emails and other communications.
Continuous Improvement
Prioritizing your continuous improvement stories gives your departments the ability to self organize and hold themselves accountable. Different departments or teams can also be held accountable against each other, which usually comes out better for the product and the end-user. Perhaps you will find certain processes that are better off under a shared department umbrella.
Because continuous improvement is such a hot buzzword, you can also use it to get your investors more interested in your future proposals. Make sure, however, that you are not using the power of that phrasing for the semantics alone. If your product is underperforming, being disingenuous will obviously get you in deep trouble. Make the cultural as well as the technical changes that are necessary to fully implement the philosophy of continuous improvement at a core level.
Committing to a process just because it is deemed agile for semantic purposes means very little for business. Make sure that part of your process is checking for metrics that are most relevant to your brand and end user. Keep your ear to the latest agile processes, but dedicate your resources to delivering on your commitments regardless of how a process is categorized.