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.
Business Owners. Business Owners are a small group of management stakeholders who have the primary efficacy, governance, and ROI responsibility for the value delivered by a specific release train. As described in this article, Business Owner play a key role throughout the flow of value through the release train, and have particularly critical roles during Release Planning.
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.
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.
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.
The 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.
Sprint Goals. Sprint goals are a high level summary of the business and technical goals that the team and product owner agree to accomplish in a sprint. In SAFe, Sprint goals are integral to the effective coordination of an Agile Release Train as a self-organizing, self-managing team of teams. As described in this article, sprint goals help the team in three dimensions: 1. Align the individual team members and Product Owner to a common mission for the sprint; 2. Continually align the individual teams to the Program PSI objectives and provide context for understanding cross team dependencies; 3. Provide a simple communication protocol between the teams, management, and business owners, so that management is continuously apprised of the work in process.
Value Streams. In SAFe, release trains are formed around value streams to simplify development, eliminate unnecessary steps and handoffs, and to accelerate the delivery of value via implementation of Lean and Agile principles and practices. This article describes the process of identifying, organizing and mapping the value streams in the SAFe enterprise in preparation for establishing ARTs. (Note: Value Streams will appear as a first class icon in the next release of the Big Picture, at which time this article will be moved into the baseline framework.)
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: 23 April, 2013
© 2010-2013 Leffingwell, LLC. All rights reserved.