Organizations overcome challenges in quantifying Agile value by embracing a solution that assesses, benchmarks and course-corrects Agile development teams. How is this done? Through agile value management.
Agile development is challenging to manage and measure, especially when compared with traditional development models like Waterfall.
Management is often uncertain when functionality will be delivered and at what cost, whether it delivers required quality, and with what inherent risks. Due to its inherent nature of using Story Points to assess progress, Agile value is challenging to quantify.
If something’s difficult to measure, it’s hard to evaluate, manage and ensure value delivery. Through an example, this blog sets out to show that it’s possible to counter these challenges and restore balance between the relationship of Agile teams and management.
Imagine this common scenario: A major client-facing application that digitally transforms the company is a year into development with delivery postponed every quarter. Sprints are chewing through the backlog, but it keeps re-filling with refactoring, bugs and newly discovered requirements. Turn-over on the team is creating challenges in productivity and quality, and onboarding new team members takes too long, which impacts overall productivity.
Management keeps receiving progress planning updates that show a smooth, Agile development machine with sprints and stories paced to deliver, but then the budget keeps increasing and the delivery date shifts to the right. Management is struggling to reconcile the reports versus actual cost, productivity, quality, and deadline progress. They’ve replaced the project manager once, but are frustrated by conflicting messages and are distrustful of quality, timely progress.
The development team is confused and team members are leaving the project (and the company) due to management pressure to correct a project, where the team feels it is moving through the Agile process effectively. They feel that “management” doesn’t understand how Agile works and its value proposition; coming from Waterfall project management, they believe that management simply doesn’t get Agile.
The development team also feels hampered by staff turnover, resulting in lost productivity, institutional memory and decreased quality. If management got off their backs and let them work, they could deliver a successful product.
Behind management’s interest in seeing the product done and delivered is that they see it as key to their digital transformation, and a competitive and defensive necessity versus their market peers. If Agile is so much better than Waterfall, why are costs, duration and quality spiraling out of original forecasts? At least with Waterfall you knew what the milestones were and could prioritize deliverables. With Agile, it’s all about backlog and Story Points.
Management eventually lost faith in the development process to deliver the application in the competitive timeframe needed with a minimum viable product and a semblance of cost controls. They feel like they’ve lost grip over a project that has become out of hand with no end in sight. Both groups need a concrete measurable process that allows all parties to objectively and consistently assess the team performance, product health and quality. They need a dependable way to visualize progress (productivity, cost, delivery speed, quality, security, maintainability).
The company previously subscribed to research from IDC and heard about the IDC Metri Agile Value Management (AVM) solution that assesses, benchmarks and course-corrects Agile development teams. AVM is a systematic, quantitative, comprehensive, data-driven, and repeatable solution, based on ISO standards, and has demonstrated quantifiable value to clients.
The IDC Metri AVM solutions team began the process of breaking down the product development process and product.
Measures of value creation occurred across multiple sprints. Enhanced function point analysis, based on ISO standards, is to assess progress and efficiency rather than Story Points. Source code analysis assed code quality and security, to reduce refactoring and the number of CVEs. This analysis not only identified the gaps, but provided specific, tactical recommendations on how to address them. Further, the benchmarking team gauged their performance to understand how competitive their team was versus market peers.
After six weeks of work, management and team received dashboards and analysis that clearly identified gaps and remediation.
The engineering dashboards clearly identified poor code and CVEs that allowed the development team to better and more rapidly address quality issues. As they adopted the guidance from the engineering dashboard, the development team found their practices improving. Quality and performance improved due to lower testing efforts attributed to enhanced coding practices. Also, improving practices and identifying better practices reduced team stress, and enabled newly onboarded team members to more rapidly become productive.
The benchmarking team let management identify areas to invest and realize team improvement. The management dashboard provided managers the opportunity to check key project factors, notice and correct negative performance trends.
Based on the provided forecasting assessment, management realized the development team wasn’t ready for the required business delivery milestones. Even if they performed to peers. So, management made the decision to augment the team with third-party staff to ensure success.
Both the development team and management needed the same thing – a common, agreed-upon definition of “reality”. They started off with two different frames of reference. For the development team, their frame was backlog, sprints, velocity and Story Points. For management it was cost, time, quality and milestones. The two groups were speaking different languages and couldn’t reconcile. By bringing in AVM, management and the development team now had one frame of reference everyone could agree with. They had a complete analysis that brought together technical and business needs.
The team had one language from which they could understand development health, address gaps and deliver agile value.