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 is difficult to measure, it is 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 will help digitally transform the company is a year into development with production delivery being pushed out every quarter. Sprints are chewing through the backlog, but the backlog keeps re-filling with refactoring and bugs and newly discovered requirements. Turn-over on the team is creating challenges in productivity and quality, and on-boarding 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 they are being hampered by staff turn-over, resulting in lost productivity and institutional memory, and decreased quality. If management would get off their backs and let them work, the project will be delivered effectively.
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.
Working with the IDC Metri AVM solutions team, they began the methodical process of breaking down the product development process and product.
Across multiple sprints, measures of value creation were implemented. Enhanced function point analysis, based on ISO standards, was used to assess progress and efficiency rather than Story Points. Source code analysis was performed to assess 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, team performance was benchmarked 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 remediations.
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.
Benchmarking team practices against peers let management identify areas to invest, and realize team improvement. The management dashboard provided managers a way to check the pulse of key project factors and quickly notice, and course-correct negative performance trends. Also, based on the forecasting assessment provided, management realized that one problem was the development team was under-resourced to meet required business delivery milestones, even if performing to peers. So, management made the decision to augment the team with third-party staff, to ensure milestones could be met.
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, and a complete analysis that brought together technical and business needs. The team had one language from which they could mutually understand development health, and how to address gaps and deliver agile value.
Interested in more content around delivering agile value? Join us on the Agile Value: How Can You Manage What You Can’t Measure webinar on January 12.
