Iterative Development and Experimentation
Teams do not measure the impact of their work. Or, if measurement happens, it is done in isolation by the product management team and shared. You need to find out if your work is working. The primary measure of success is delivered features, not provided outcomes. Product managers do not conduct regular retrospectives on the quality of their product decisions. They compare expected benefits to actual benefits. The team needs to connect work to crucial business and customer satisfaction metrics.
The pressure to deliver a product on time and within budget often leads to neglecting quality-related work. The current corporate culture that values busyness over productivity is absurd. Ignoring work is not a sign of productivity, but delivering value is.
Developers have “passing tests,” but product managers do not. Product managers view velocity and output as their key performance indicators. A mismatch between prioritization rigor (deciding what gets worked on) and validation rigor (choosing if it was the right thing to work on). Prioritization rigor is designed only to temper internal agendas so people “feel confident.” Much work goes into determining which ideas to work on, leaving little leeway for adjustments and improvisation based on data.
By focusing on execution, we limit the system’s growth potential. By making ourselves indispensable, we make our teams and organizations less resilient. Once a decision has been made, it should be shared along with the rationale and perspectives that shaped it so that others can learn, too. Accept that we operate in a changing world where centralized control is too slow and disconnected from reality. Teams should be lean — small enough to move. But they are also multidisciplinary, containing all (or most) of the skills they need to achieve their mission. This approach helps to improve the development process and work towards goals.
A front-loaded process is in place to “get ahead of the work” so that items are “ready for engineering.” Once work is “done,” the team moves immediately to the next “project,” leaving no time to iterate based on qualitative and quantitative data. Roadmaps show features, not areas of focus and outcomes.
The team is not involved in research, problem exploration, or experimentation and validation. Once work is shipped, the team needs more contact with support, customer success, and sales. Without the mandate to experiment, features are delivered in single large batches instead. You might still work in sprints (yay, we’re “Agile”), but nothing new is reaching customers after each sprint. Low visibility for refactoring work and debt work-down. Low visibility for value delivery capabilities. Every team member must feel included in the process, no matter how far away they may be.
[¹]: Brave New Work: Are You Ready to Reinvent Your Organization?
