Mike Lyons argues that Agile project success should be measured primarily by value delivered (outcomes) rather than by the traditional iron triangle of cost, scope, and schedule. He warns against the 'feature factory'—delivering features without validating real user or business value—and illustrates this with an anecdote about low adoption by call-center reps despite advanced technical features. Lyons recommends defining value metrics per stakeholder, continuously seeking feedback, and balancing value measurements with existing constraints (cost, schedule, regulatory).
Chapters
I'm guessing you'd be able to repeat this by now. But in Agile delivery, we focus on measuring value delivered as our primary indicator of success, rather than the traditional iron triangle of cost, scope and schedule. Now, it's not that cost, scope and schedule are no longer relevant, it's just that they're not as important as delivering the right thing to the right people at the right time. This change of focus, it aligns our efforts with what truly matters to the business and our stakeholders. That said, there's a common pitfall in Agile project delivery, and we call it the feature factory. The process shown here, brainstorming features, designing features, build features, ship features, and then declare success. Might seem productive, but it's missing a critical element. Well, there's no consideration of whether we're actually delivering value. Simply optimizing for feature delivery doesn't always guarantee we're creating meaningful outcomes that support our objectives. What if nobody uses the feature? Or even worse, what if the new feature makes our products harder to use or unstable? Go away, you paperclip. No one likes you. The missing element is feedback. We need to validate that the new feature is actually delivering business value. We need to get feedback from our customers, our users, our stakeholders, that our new feature is driving measurably better organizational outcomes. So we need to shift from a sort of output focused team to an outcome focused team. Another important aspect of value as we think about outcomes is that value. Well, it's context specific. Different stakeholders have varying perspectives on what constitutes value. For instance, business operations might prioritize efficiency and cost savings, but for systems operations, it might be improving system uptime, while information security focuses on risk mitigation and data protection. So there's no one right definition for business value. And as Agile project managers, it's our job to understand and balance these diverse value perspectives. Remember the story I told you about the customer service team that I'd initially overlooked? As key stakeholders on that project, our development team, we were pretty proud of the advanced features that we'd built. Features like automated chatbots and multi channel integrations and advanced analytics dashboards. We'd spent months perfecting these features, and from a technical standpoint, they were pretty impressive. However, when we rolled out the platform, we were surprised to see that our adoption rates were pretty low. So I went to the call center and I rode shotgun one day to observe a rep using our system. Now these reps, they work in a super fast paced environment and they're often juggling multiple calls simultaneously. They needed functionality that allowed them to access customer information and resolve issues quickly, not necessarily one that required navigating through multiple advanced features. It was a wake up call for our team. We realized that while we delivered technical value, we hadn't adequately considered the value from the perspective of our primary users. This experience taught me the importance of continually validating our understanding of value across all of our stakeholders. So how do we measure success in terms of value while still honoring constraints? It starts with clearly defining value metrics for each stakeholder group. Now, all of this doesn't excuse us from the iron triangle of cost, scope, and schedule. While tracking these value metrics, we must also respect those constraints as well as other constraints like regulatory requirements. It's a balancing act, but it's one that leads to more meaningful outcomes. Now, to put this into practice, I have a couple questions for you to consider. In your current or most recent project, how are you measuring value? Are those metrics aligned with all of your key stakeholder perspectives? And number two, what constraints were you working within? How do they influence your approach to delivering value? Our ultimate goal is to create tangible, measurable value that aligns with our organization's mission. By focusing on value over mere feature completion, we can create impactful results. And that that's worth measuring.
