Agile is known for its lightweight, fast and flexible approach to software development. Having small teams that can collaborate and take rapid action is part of the allure of the methodology. Over the last couple of decades, more and more big businesses have made a shift toward this approach to project management. But challenges arise when trying to effectively scale Agile at its full capacity above a certain limit, especially when the teams are large and stakeholders are distributed across the globe. Is it worthwhile to keep pursuing Agile across the enterprise when the system seems to be geared toward smaller organizations?
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
Approaching the limit of Agile development
"It's interesting. Agile has a feeling in terms of the number of developers you can throw onto an Agile program before it stops being what it was supposed to be. The ceiling seems to be somewhere around 100 people. More than that and something different happens. At that point, you need a different level of integration and a coarser grained view of your application portfolio. Those tools bring back a form of requirements management," said Tasktop CEO Mik Kersten.
Traditionally, Agile software development has been opposed to in-depth documentation in the early stages. The idea is that, since requirements will evolve, perhaps substantially, over time, the early investment would be wasted. However, when teams are working on projects on an enterprise scale, all with interlocking dependencies, it simply isn't feasible to minimize requirements management and let the chips fall where they may.
Critics of Agile point out that prioritizing development over planning can be a significant problem when changes are substantial rather than incidental. Big changes made late in the game can have serious ramifications in terms of project delays, especially as iterations are added to accommodate the revisions. There may also be a proliferation of bugs that can no longer be easily fixed. Accountability and a firm vision are necessary to ensure that everything works together as intended.
According to Kersten, businesses often struggle to realize the full value of Agile because their view is too narrow. Being truly lean requires looking beyond the development team. "Agile is a local optimization of your value stream. All that matters in the end is what great business idea or strategy you have and how you bring that into the market to your users to turn a profit. Agile only focuses on optimizing the middle of that."
Does this mean Agile is a poor fit for the enterprise? Not at all. But it has to serve a purpose in the larger structure. "It's the right place to start. But if you have Agile development and it takes 12 weeks to get something into production and another 12 weeks to get feedback on it to the Agile team's backlog, you aren't very agile as an organization. It's not lean software delivery. You just have a very agile software development team that's not doing much for the business—it's just coding, it's not responding to the market."
Solutions for scaling Agile
Fortunately, there are a number of approaches that have been developed to address the issue of being big and Agile at the same time. Scrum of Scrums, which brings multiple teams together, and Large Scale Scrum are both approaches that may be used to begin scaling Agile. However, when portfolio and program structure are the focus of improvement, other solutions such as SAFe (Scaled Agile Framework), DSDM (Drive Strategy Deliver More), or similar models may be more appropriate.
Tasktop's own approach to scaling Agile takes the larger business picture into account. The solution's key focus is on integration—both among teams and across the enterprise. It takes into account several realities of big business:
Agile's loose planning must work in tandem with more traditional corporate planning that tends to have a long, regular cycle time.
Reporting, compliance, and governance processes must be respected—even if they seem old-fashioned in the Agile world.
Ensuring feedback among teams is delivered in near real time so that changes can be implemented promptly is also a priority. Without this constant communication, the business value of a good idea may be tapped out by the time a feature gets to market.
Kersten encouraged businesses to ask the hard questions, "What's your cycle time? How quickly can you bring that cool new feature into your mobile app? For that you need information to flow and for people to collaborate. Not in email or spreadsheets but through the tools that they use in real time." Once an organization defines their value stream and institutes requirements at a higher level, projects can start to flow through the Agile pipeline faster. It's the only way to make going bigger better.
What techniques have you used to help scale your Agile teams? Let us know.