The agile principle that is obsolete in modern product development

I consider myself a fan of Agile and the values and principles that the states. In fact, I’ve been using agile for many years and I saw how many teams changed and improved over the years through this practices. Manifesto I’m currently working on an agile transformation at the organization level, trying to bring agile practices to the entire company (including marketing, customer services, sales, etc). This transformation also includes taking the IT teams to a new level of “agility” trying to take more advantage of the values and principles it proposes. To me, this meant getting back in contact with the roots of Agile and its foundations. So I’ve been re-reading the manifesto and reflecting on its principles again. And to my surprise, I found one that I feel is completely wrong for modern product development: Working software is the primary measure of progress. Focus on outcome instead of output The underlying idea of this principle is that prototypes, documentation or any other artifact that is not something working cannot be counted as real progress. I agree with that. But it is not enough. Delivering working software that nobody wants or reaches no purpose is useless. . Just puts the focus on output rather than outcome delivering The primary measure of progress when building innovative product ! should be {core metric} improvement Usage, retention, lifetime value or any other KPI that you define as your core metric and you can measure to see if people are valuing your product should be the way to track progress. Just to give the right credit to the Agile Manifesto, the 7th principle was completely logical some time ago when they were . And also considering that the role of software developers was more oriented to deliver what the “business stakeholders” considered important. trying to get away from the waterfall model and move to early delivery But when we moved to a , and the entire team should take responsibility for the outcome, it’s not enough to just deliver working software. product innovation world, where no one really knows what will work And also track learning… When we move away from the Software Factory model, we need to focus on understanding what is the right product to build. This is where plays an important role. Product Discovery Product Discovery contains all the activities we do to what is that “right product” that we must build. Based on lean principles and customer development, a set of tools is used to quickly interact with the users to learn what they need before we move to building the solution. learn and validate So as a measure of progress we need to focus on . both metric improvements (for the delivery cycles) and learning (for the discovery cycles) NOTE: this relates to dual-track agile which I hope I can write about soon. Since the entire team should be somewhat involved in these activities, keeping track of learning helps you measure the progress the team is making towards an innovative product. Final words Actually, if we take a look at the first principle (“1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.”), it focuses on serving the customer through software. I believe that already covers what the 7th principle is trying to do and with a better focus on the outcome. valuable Anyway, this just was a great excuse to talk about discovery and outcome-focused product teams, so I jumped at the opportunity :) Originally published at leanexperimentation.com . If you enjoyed it and want to receive more tools & tips on Product Discovery, you can subscribe here .