Guidance

Building enterprise class software systems is one of the world’s most complex endeavors. To help address this challenge, the Scaled Agile Framework is broad and deep, and the Big Picture graphic cannot possibly capture every concept that is material to understanding or implementing the framework. To that end, we offer these pages as additional guidance on topics that deserve additional, focused discussion.

Agile Development in High Assurance and Regulated Environments.  Below is a whitepaper on the use of Agile development in high assurance (medical, regulated, aerospace) environments. Since Agile is the best method yet we have found to assure quality and efficacy, it shouldn’t be a surprise that I recommend Agile development here, too. In the whitepaper, we did the homework necessary to debunk the myth that these environments mandate waterfall development, as nothing could be further from the truth. The attached whitepaper lays out the case. In addition, as Rally Software commissioned the work, it  shows how tooling can support many of the reports and documents that are typically required in such environments.

 

Budgets. Lean|Agile Budgeting with the Scaled Agile Framework: Beyond Project Cost Accounting. In the traditional software enterprise, the drive for business agility via Lean|Agile development methods and current methods of budgeting and cost accounting are in inherent conflict. This article provides strategies to reduce the friction, overhead, costs and lack of program and economic flexibility of the traditional approach, and replaces it with a leaner financial planning and reporting model, but one that still provides the requisite fiduciary governance.

Capacity Allocation. Click here to learn more about how the important lean construct of “capacity allocation” is used to help insure system integrity by providing mechanisms and policies for prioritizing important work of different types.

Continuous Delivery. SAFe and Lean and Agile thinking and practices is spurring the industry to break down development silos and provide a more continuous flow of value from concept to tested code. The promise, however, is more than that – the promise is to deliver value to customers faster, not just create internal product inventory at an ever-faster pace.  For this we need not just continuous development flow, but continuous delivery.

Continuous Integration. SAFe is dependent on continuous integration, not only at the Team level, but also at the system level, which incorporates code from many teams on the Agile Release Train. In addition, for larger value streams, continuous integration practices must be extended to these largest systems via cross-train integration, where fast feedback is every bit as important, maybe even more so. Effective Continuous Integration (CI) practices help reduce the cost of delay, and substantially reduces overall program risk.

Coordinating Release Trains Within Larger Value Streams. Value Streams are realized in SAFe by Agile Release Trains, which are limited in scope to 50-125 practitioners. If a value stream can be implemented by a single ART, things are reasonably straightforward and then there is no need for additional constructs. However, as described in this article, when the value stream is too big for a single ART, then a new set of issues around content authority, full system integration, and releasing arise.

Core Values. SAFe is broad and deep and is based on both Lean and Agile Principles. That’s what it’s built on, but what does SAFe itself stand for? In this short article, you’ll see the four things we really value that we believe SAFE helps deliver: Alignment, Code Quality, Transparency and Program Execution. If you do those things well, al lot of goodness would surely follow.

Definition of Done. A scaleable Definition of Done provides clarity for defining quality and completion for stories, features and release increments.

Designing for Testability. If a system can’t be routinely and (mostly) automatically tested and regression tested, development progress will be slow and will likely become continuously slower over time. Systems that are “Designed for Testability” (and refactored as necessary to continuously achieve it) are higher quality,  more trustworthy, more easily modified, and more Agile.

Domain Modeling. If you are only going to model one thing in your lightweight and more agile endeavors to build really big systems, surely this is the one you need.

Features and Components. Software systems can be considered from two critical aspects: structure and behavior. Structure describes the components of the software system and the way they are organized into the whole. Behavior describes the features that deliver end user benefit. When scaling Agile development, features and components are the key paradigms around which to organize Agile teams. While Agile and SAFE lean towards feature teams, as those exhibit the highest velocity of value delivery – at least in the short term – this article illustrates how a balanced mix of feature and component teams enables a fast and sustainable flow of value.

Four Principles of Lean|Agile Leadership. (see Lean-Agile Leaders). #1. Take a Systems View. Embrace the Agile Manifesto. #3. Implement Product Development Flow. #4. Unlock the Intrinsic Motivation of Knowledge Workers.

Implementation Strategies for Business Epics.Business epics are large initiatives in SAFe that drive business value and typically cross the organizational boundaries (release trains), time boundaries (PSIs), or both. It is a key capability of the agile enterprise to properly analyze and sequence business epics for implementation. While it’s easy to think of epics as big, binary, monolithic, committed blobs of work, the reality is they should be implemented incrementally to achieve the benefits of agility. Moreover, once the technology, benefits, and economics are understood, some won’t deserve to be fully implemented, as the initial effort delivers most of the potential business value.

Lean-Agile Leaders. The foundation of Lean and SAFe is leadership. SAFe Lean-Thinking Manager Teachers are life-long learners and teachers who help teams build better software systems through understanding and exhibiting the values, principles and practices of Lean, systems thinking and Agile software development. Lean Thinking Manager-Teachers adhere to four primary Four Principles of Lean|Agile Leadership.

Lean Software Development in SAFe. In addition to the primary feedback from practical experience, the underlying theory and principles of SAFe are based on three contemporary bodies of knowledge: Agile development, Lean Systems Thinking, and the Principles of Product Development Flow. While these principles and values are implicit in SAFe, this guidance article makes the explicit implicit, with the hope that it will further guide those doing this critical work to lightest and leanest effective implementations.

Mixing Agile and Waterfall Development. Agile development delivers better results in quality, productivity, employee engagement and time to market. But it takes time for an enterprise to get there. In the meantime, Agile development programs will need to coexist, and even be dependent on, programs using the traditional waterfall method. It’s not easy, (but what is?) but it’s doable, as this important guidance article illustrates.

Mixing Agile and Waterfall: Technical Strategies for Interoperability at Scale. In this follow up article to the above, Alex Yakyma describes four mechanisms for better linking the teams and the code, in mixed-mode development.

Principles of Agile Architecture. This guidance article describes Seven Principals of Agile Architecture that have proven to be effective in re-legitimizing the role of architecture, and by implication the System and Enterprise Architect in Agile at scale. But of course, like everything else, these roles change significantly in a Lean|Agile transformation, and that’s why we continue to develop SAFe in this dimension.

Shared Resources. Agile Release Trains are built primarily on the skills and abilities of Agile, cross-functional Define|Build|Test (DBT) teams, along with additional, specialized roles such as Product Management and System Architects. However, most trains need specialty resources that are not dedicated to any specific Agile team, or even to a single train. These can include data, security and enterprise architects, documentation specialists, IT administrators, configuration and release managers, and more. This article describes the role of shared resources and provides some suggestions for keeping them involved, integrated, aligned and synchronized with the Agile teams on the train.

Strategic Themes. This article describes Strategic Themes, whichs are specific, itemized business objectives that connect the portfolio vision to the evolving enterprise business strategy. They provide business context for decision-making within the portfolio, affecting investment in value streams and release trains, and serve as inputs to the portfolio and program backlogs.

Test-First

Agile testing differs from the big bang test-at-the-end approach of traditional development. Instead, code is developed and tested in small increments, often with the development of the test itself preceding the development of the code. This article describes how writing test first tests serve to elaborate and better define the intended system behavior before the system is coded.

 

Supplemental Models

SAFe is itself, a system. Underlying the system is a well-defined set of requirements and test types, artifacts, and organizational models that tie it all together. This “semantic backplane” is used by those implementing SAFe for managing investments, defining and tracking requirements, implementing test automation and test coverage, implementing tooling and traceability, and providing for reporting and metrics. The following Supplemental Models provide the technical details on these important elements and their relationships in SAFe.

Agile Software Requirements Model. When you want to scale Agile development, you’ll need requirements abstractions that provide for understanding investments, and requirements terms that can carry just-the-right-amount of specified system behavior for Teams, Programs and the Portfolio, as well as defining the testing terms and practices you’ll need to assure quality at all three levels. The Agile Software Requirements model provides this for SAFe.

Program Relationship Model. One of SAFe’s four core values is Program Execution. The Program level guides the formation and implementation of Agile Release Trains to carry all that value to the end users. Though it may be the center of the SAFe universe, Programs do not stand alone as they have relationships to the Portfolios and investment Themes that drive them, and more. See these relationships in this model.

Last Update: 17 April, 2014

© 2010-2014 Leffingwell, LLC. All rights reserved.