The Importance of Measuring Outcomes, Not Just Features
Many teams need to measure the impact of their work, and when measurement does occur, it is often done in isolation by the product management team rather than shared with the rest of the team. Teams need to determine whether their work is practical. Celebrations within an organization can reveal a lot about its priorities, and the primary measure of success is based on delivered features rather than provided outcomes.
Product managers often do not hold regular retrospectives on the quality of their product decisions and instead, compare expected benefits to actual benefits. Teams must connect their work to critical business and customer satisfaction metrics. While developers have “passing tests,” product managers do not have a comparable measure of success. Product managers often prioritize velocity and output as their key performance indicators, which can create a mismatch between prioritization rigor and validation rigor. Prioritization rigor is usually designed to temper internal agendas, leaving little room for adjustments and improvisation based on data.
To get ahead of their work, many teams have a front-loaded process to ensure that items are “ready for engineering.” However, once a project is done, this can result in a lack of time to iterate based on qualitative and quantitative data. Roadmaps often show features rather than areas of focus and outcomes. Teams often need to be more involved in research, problem exploration, experimentation, and validation. After work is shipped, the team needs more contact with support, customer success, and sales. Features are often delivered in single large batches without the mandate to experiment. While teams may still work in sprints, nothing new reaches customers after each sprint. There usually needs to be higher visibility for refactoring work and debt work-down, as well as low visibility for value delivery capabilities.
To ensure productivity and motivate programmers, it’s best to choose a release cadence that works for your team, whether it’s once a month or when a set of features is finished. Market what you already have instead of what’s in the pipeline, and avoid relying too heavily on long-term roadmaps, which often change. Don’t force programmers to commit to completing certain features by a specific date, as it can negatively affect morale. Less process is usually better, as programmers are often self-managing and self-motivated. Allow each programmer to track tasks with their preferred tool and maintain a flat organizational structure to help them thrive.
Handing off work tasks can cause unnecessary movement and require extra communication to clear up uncertainties. Mistakes like incorrect, missing, or unclear information or materials can lead to waste and require effort to fix. And if these defects go unnoticed for too long, they become more challenging to spot. Automating dependencies on Operations and making them available on demand is essential to avoid these issues. Otherwise, individuals or teams may have to work extra hard to meet goals, which can create new errors. It’s crucial to remove blame and fear from the workplace to encourage honesty and prevent these issues from arising.
Software Engineers who focus on improving processes understand that technology is not the best indicator of progress. Process is. The engineers who promote the constant improvement of how they deliver solutions are the ones who advance their careers regularly and move businesses forward.
Agile Methodologies are not set in stone, and certain ceremonies help with reflection and improvements. There are others that, in some situations, reduce the fast pace of delivery. We also need to understand how to identify what is working and what is not working. At this point, there is no reason to measure twice and cut once. Sometimes, what to measure or cut is not visible because the team or the company needs more direction toward what’s important. We need a purpose to move forward at the organizational level. Individual contributors usually only have little to say in this manner. However, we can start by measuring our work and establishing practices promoting personal reflection and improvement. By modifying individuals, there will be team improvement and company improvement. We need to start with ourselves to promote similar behavior in others.
