OPTIMIZING AGILE TEAMS AT THE ENTERPRISE LEVEL – PART 1
Agile has matured into a recognized, respectable methodology for running software development projects – it’s no longer just the latest “buzzword” for which technologists are clamoring to obtain the hottest certification “du jour.” Many companies have gone all-in, with complete “Agile Transformations” and are now using some flavor of Scrum, Lean, Kanban, Scrum-Ban, etc, across the enterprise. Most software practitioners would agree that Agile, done well, could generate great success for an engineering organization, especially for teams that have hit their “velocity sweet-spot” and are notably independent. But realistically, most teams do not run completely independently.
Moreover, velocity can take on different meaning when looking at organizations that are comprised of many agile teams. What about a dozen or so in the setting of a large software factory / IT shop? By most viewpoints, one team’s high velocity generally doesn’t equate to a high output for the whole software factory. Perhaps more importantly, how does an organization know if their software factory is running efficiently? What can they do about it?
Enter Enterprise Agile.
SAFe (Scaled Agile Framework), DAD (Disciplined Agile Delivery), and LeSS (Large Scale Scrum) are some specific methodologies that have been introduced to address the challenges of scaling above the team or project level, and tie agile velocity to an enterprise perspective and business needs. These methods and practices are highly desired by large organizations because they attempt to:
- Provide more inclusive product estimation models for time and effort.
- Infuse a light level of portfolio and architectural governance.
- Broaden normalization of KPIs, such as average story points per sprint across the enterprise vs. the team level.
- Foster pervasive multi-team coordination across business and engineering groups.
- Grant visibility into overall progress across unified product suites.
- Facilitate risk management from an enterprise vantage point.
- Drive Velocity at an Enterprise Level.
Following the advent of Enterprise Agile frameworks, one might still ask: Have we achieved “Agile Nirvana”? The answer is most likely “to a certain extent.” Even the most successful organizations are working to find additional optimization opportunities.
- To punctuate this point, consider the following scenario:
- Assume that an organization has four highly efficient agile development teams working on one product group (Teams A through D).
- Assume the teams work independently, but from a single backlog, yet are aligned to specific areas of expertise.
- Assume each team has attained their own steady and optimal maximum velocity.
Based on each team’s expertise, backlog with their own relative estimates (points), and optimum velocities, the chart below demonstrates the number of sprints estimated to deliver the components of a single enterprise project for a critical new product release. The four multicolored horizontal bars represent the four teams, and the colored milestones represent finish to start relationships (inter-dependencies):
- Team B has a dependency on Team D for work completed at the end of sprint 1
- Team A has a dependency on Team D for work completed at the end of sprint 2
- Teams B and D have dependencies on Team C for work completed at the end of sprint 2
- In total, 7 (calendar) sprints are estimated to complete the product
Most will notice that the workload is unbalanced, possibly due to the expertise of each team driving the backlog required to meet the needs of the project. Perhaps just as important, if any team is late in delivering work product across a dependency, the target release date is put at risk.
In looking at the evolution of scaling agile development, the above scenario is indicative of enterprise challenges where:
- Resources are not calibrated for optimal value stream output.
- True “Enterprise Velocity” is still difficult to determine and therefore cannot be maximized.
- Inventory and enterprise waste builds up because work in the critical path is uneven across teams.
- The business may still have challenges with non-development release activities such as synchronization with marketing and support.
In summary, even with improvements to agile methods and approach, critical data on project performance can be difficult to determine, and interdependent risk can be a challenge to manage.
Now, imagine a situation where the unified backlog is tied to priority and dependency, as expected. Further, consider the notion that team utilization across the project group could be ascertained. Finally, envision that monitoring and reporting mechanisms were in place to expose these inter-dependencies against overall project progress.
Using the scenario above – the same teams and resources with the same inter-dependencies – one can see how the overall timeline can be reduced with a “simple” re-calibration of teams at a key point during the project.
Moreover, by employing Enterprise agile release techniques, an optimal backlog can be implemented with the appropriate priority and dependency. When coupled with sprint and release planning, this management behavior can facilitate completing dependent work product at least one sprint earlier than a dependent team will need it. This is depicted in the graph by the dashed lines.
To create even more velocity it clearly makes sense in this example to shift some available resources and reduce Team B’s workload. Their timeline is the longest (critical path), and one could also assume that because of the protracted time frame that their backlogs of features have the highest complexity, the most risk, and their work packages will likely provide the greatest amount of core business value.
Both the C and D Teams have resources available to help accelerate delivery of remaining project work starting in sprints 3 and 5, respectively. By evaluating both teams against domain knowledge, work complexity, risk, and overall ramp up time one determines that Team C can achieve optimal performance sooner than Team D. Based on the release target, Team C can be reallocated to work items from the Team B backlog at sprint 3, and workloads can be re-calibrated. There are certainly some considerations that need to be addressed, including keeping the most difficult stories allocated to Team B. Assuming two-week sprints, this change reduces calendar delivery target from 14 weeks to 10 weeks, which is nearly a 30% reduction in time to release or market.
Of course, there are some key components required for this to be plausible:
- Team re-calibration must retain resources to support or continue development on other initiatives that are not critical to the goal
- Resources must be cross-functional enough and have enough domain knowledge of other teams to be effective and require minimal ramp-up time
- This must be carefully monitored, with continued analysis and evaluation, to ensure success
- A cost-benefit analysis should occur prior to shifting resources, as in this scenario, we have increased overall resource cost, while shrinking overall schedule
While this is a simplified example with only four teams, optimization across ten or more teams can create significant economies of scale with regard to Enterprise velocity. One can only imagine how the complexity will grow exponentially with the number of teams, modules, and technology in use.
As with most ideas the notion itself is far easier than the implementation. The fluidity of agile development can create real challenges for organizations with respect to WIP (work in progress) status. However, with continual change management and perseverance, many organizations are adapting scaled agile frameworks and seeing benefits.
ATG’s next article will focus on some critical “How-To Steps” to implementing Scaled Agile Frameworks. Please join us as we explore how to build awareness of productivity across teams, deploying a monitoring system at the team level that can be rolled up to the portfolio level, and how to design accurate reporting to capture increased Enterprise velocity.
Angela Boardman and Joel Sisk, authors of Optimizing Agile Teams at the Enterprise Level, are consultants from Advanced Technology Group (ATG), a management and technology consulting firm that aligns People, Process, and Technology to provide Fortune 1000 companies measureable technology-based improvements.