The discipline of agile software development (or ““Agile” as developers call it) is one that appeals to all managers throughout the organization. Advocates would have you believe that, if done right, an Agile approach will improve decision making, product quality, increase customer satisfaction, increase control over projects, and reduce risk, among other things.
While Agile might not provide all those benefits in all situations – however well implemented – the IT functions of many big companies certainly see some benefits: the number of corporate software and IT development projects that are now worked on using Agile principles has reached nearly 40% of the total in 2015, according to CEB data.
The problem is that a lot of the gains in faster project times that were achieved early on have not been replicated more recently as Agile is used more and more broadly.
This is because a lot of the initial speed gains came from using “tiger teams” comprised of the best developers working autonomously on the most suitable projects. As use of organizational agility approach spreads, more projects become held up by other teams and IT groups who have competing priorities, limited understanding of how Agile works differently, and a lot of organizational inertia (processes, performance objectives, etc.) that makes it hard to adapt to an Agile approach.
Chart 1: Agile’s coordination problem Impact of Agile adoption on speed-to-market; n=90 Applications leaders, 296 Agile team leaders Source: CEB 2016 Agile Improvement Diagnostic; CEB 2015 State of Agile Survey
Focus on Three Groups of Colleagues
To maintain the speed gains from Agile development, IT applications teams (those responsible for developing new software for the firm) need to educate the three different groups of colleagues most likely to slow projects down. The applications team should also create a working climate when they collaborate with these colleagues that matches Agile’s flexible and iterative nature.
These groups are other applications “project delivery” teams, business sponsors, and other IT functions.
Help project delivery teams track project interdependencies: Project delivery teams focus on the individual performance of Agile projects and try to finish each of them on budget and to deadline. But failing to take a broader view can ignore all-important interdependencies among projects; for example, one project may be on track but depend on work being completed by another team that are behind schedule. Not seeing the wood for the trees can affect the entire Applications project portfolio.
Instead of managing these interdependencies from the top down, leading firms help project delivery teams assess the health of projects across the Agile portfolio and respond to performance risks. For this kind of problem-solving, Agile development teams should attach the same importance to tracking cross-project interdependencies as they do to “user stories,” which in the Agile methodology is an important part of understanding what internal customers want.
Educate business sponsors on the differences between Agile and waterfall processes: Business sponsors – line managers who have asked the applications team to create something for them –often have preconceived notions about working with IT. According to CEB’s 2015 State of Agile survey, 78% of organizations say that Agile requires more business sponsor time than the more typical “waterfall” IT processes. More than half of Agile teams interact with the business multiple times per week or more, leading to overwhelmed sponsors who delay development as delivery teams must wait to reprioritize requirements and make decisions.
Some firms use simulation and interactive exercises drawn from real-life experience to show project sponsors their responsibilities for Agile development. This said, too much at once can overwhelm business sponsors, so don’t aim to complete all exercises at once. Instead, tailor exercises to the most important development opportunities for individual business sponsors according to their previous engagement experience.
Establish transparent and shared accountability with other IT functions: Other IT functions have optimized their review and approval processes for projects worked on via the waterfall approach, but this can impede the progress of Agile development teams whose timelines are shorter and more likely to change. In response, senior applications managers should renegotiate the handoffs between their project delivery teams and partner IT teams.
To improve this coordination, formalize handoff commitments through user stories (see above) to establish two-way accountability, and then track adherence through a shared dashboard to identify the causes of delays. Unlike most user stories, the inclusion of an explicit timeline allows other IT functions to understand the impact of delays to projects and prioritize their work accordingly to keep projects moving.