8220

Guest post by Tim Mattix, Mario Gouvea and Vikram Purohit

With the ever-evolving software development landscape, large enterprises are increasingly “going Agile.” Agile is applicable to many scenarios; for example, Extreme Programming (XP) zeroes in on software engineering while wrapping in novel approaches to boost quality, and Scrum is the most widely adopted agile method. While both of these frameworks work well for software development teams, Agile is even suitable for less obvious initiatives, such as transforming traditional marketing. Similar to PwC’s Architecture Driven Agile, which is defined at the team and program level, the Scaled Agile Framework (SAFe) builds upon XP, Scrum and Lean—with added focus on enterprise-level Agile. By building on XP and Scrum, SAFe can effectively scale Agile throughout the enterprise by introducing Lean and portfolio management principles. This method aligns an enterprise at the portfolio, program, and development team levels—providing a smooth flow between layers. The result is a common vision, executed by Agile Release Trains (ART)—connected Agile teams that serve as the main vehicle for value delivery at the program level—using a combination of Scrum and XP called SAFe ScrumXP, which incorporates Lean tools, roles, processes, and software engineering practices to scale Scrum throughout the enterprise. But scaling Agile for the enterprise is easier said than done. While SAFe provides an adaptable framework for enterprise agility, and is a step in the right direction, four key areas require careful attention to help ensure success.

1. Business and IT Alignment

The first step in scaling Agile is aligning business and IT engagement models to ensure organizational readiness. At the development level, the business plays a large role. However, as IT evolves towards SAFe, the business must follow suit and expand accordingly, defining involvement standards across layers. Lack of business involvement leads to misalignment and disconnect across the enterprise. One challenge with SAFe is a lack of a mechanism to ingest business requests from the development team and program levels. In SAFe, business epics—large customer-facing initiatives, and architecture epics—large technology initiatives, originate at the portfolio level. However, it is easy to imagine a development-level business customer requesting an addition to the backlog of upcoming work. Perhaps a product owner receives a request higher in priority than anything at the program or portfolio levels. Such a scenario could throw off the release train, or even affect the portfolio backlog.

2. Agile Maturity

Before implementing SAFe, an Agile foundation needs to be in place to scale from the bottom up. The development team level is a logical starting point, which allows the organization to realize the value of Agile where products are created. Teams operating at a low level of maturity, lacking the proper engineering practice knowledge and skills, will develop products with significant technical debt, making code hard to change. Such teams may struggle in the beginning, as scaling bad quality code is always an issue no matter the framework. It’s also vital that the enterprise operates from the top down, which can only be achieved with executive and middle management buy-in, aligning direction at the portfolio and program levels. In a SAFe environment, program portfolio management feeds the engine, churning investment and themes into epics, filtering them down through the program level release trains. Finally, features are developed and released. Successful SAFe adoption should build upon a well-established Agile environment and a well-formulated change management approach to ensure executives understand and support Agile and Lean concepts.

3. Maintenance and Production Support Framework

Historically, IT support and maintenance accounts for a significant percentage of an organization’s budget. Even in today’s Agile world, where several approaches such as continuous delivery help reduce post-deployment issues, the essence of software delivery remains the same. The software delivery process must resolve issues identified after deployment, and the associated cost and effort need to be taken into consideration during product planning and budgeting. In SAFe, however, this is often overlooked, which can impact future budgets, put delivery timelines at risk, and reduce development velocity as resources are pulled to support production issues. With quality at the forefront of Agile delivery, it is unrealistic to forgo the establishment of a support framework.

4. Architecture Approach

As each enterprise is unique, one size does not fit all in terms of architecture. For example, while Agile and Lean practitioners prefer emergent and evolutionary design, in some situations, requirements are defined up front, and SAFe needs be adapted to fit this scenario. For instance, Agile processes appear to be more challenging for teams with regulatory and mandate compliance constraints. In pharmaceutical clinical trials, for example, governing bodies publish standards for software and processes, giving organizations a jump on requirements while also imposing constraints. As these requirements are well documented, the architecture can be well-defined and shouldn’t change much. To accommodate such scenarios, Architecture Driven Agile, for example, breaks down requirements into easy-to-manage items, while leveraging solutions architects to design and help create the product backlog. It is not clear on how SAFe would accommodate such scenarios. A combination of SAFe with Architecture Driven Agile practices can be quite effective. For example, an organization can benefit from SAFe’s prescribed approach for the adoption of Lean practices at the portfolio and program levels—while supplementing gaps with Architecture Driven Agile’s focus on architecture, development and business-IT alignment at the team, program and portfolio levels. While SAFe is not perfect, it is constantly evolving and provides a solid foundation to scale Agile, building upon the proven methods of Lean, Scrum and XP. As in most Agile transformation efforts, success depends on the ability to identify potential gaps within a framework and adjust them for each enterprise accordingly. No framework provides a seamless fit, but tailoring SAFe through a navigated approach can help your enterprise in its pursuit of agility.

Image shared by Mark Dumont

8220