So you want to deliver software across multiple dev teams? You’re probably confused by all the guides comparing different Agile scaling frameworks. And confused that each of them has so much to learn - a book or two and a bunch of certifications. Let’s focus on the current , SAFe. We’ll see why we'd use it, the key ideas and how it differs from the other frameworks. most popular framework Let’s get the flavour of what SAFe is all about. Why use a Framework for Scaling Agile Delivery? Running big projects is different from small projects. Especially it requires: Coordinating delivery across multiple teams. Working with multiple types of stakeholders. Keeping everyone aligned with business goals. With just one team, everyone can talk to everyone. Coordination happens more naturally. Big projects need more alignment practices. This is where the scaling frameworks can help. Why SAFe®? SAFe emphasises that achieving an is one of the hardest challenges of scaling. Culture problems are . To address this it takes a holistic approach. optimal culture for Agile high on the list of blockers to scaling agile SAFe is not only a project management methodology. It incorporates principles from Agile, DevOps, Lean product development and systems thinking. We can think of SAFe as a core of practices with a supporting knowledge base around them. What is SAFe®? Different SAFe guides describe SAFe as a methodology or as a knowledge base or as a set of templates. This can be confusing but they’re all correct. The knowledge base is used to explain the framework’s core practices and the various ways to apply them. It contains templates for different scenarios. SAFe® Overview There is a lot in SAFe 5.0 and this is just a brief introduction. I’ll just explain some of the most illustrative topics to give a good sense of SAFe. Leadership SAFe that only leadership can change the system. Leaders have to be clear about the intended direction and guide change. Otherwise there can be unresolved disputes about direction or some stakeholders may not fully buy in. The upshot is that leadership is crucial to culture. recognises SAFe looks for leaders to coach and mentor as well as set a great example. This means: Effectively communicating a vision. Motivating by explaining drivers. Building coalitions. Encouraging healthy risk-taking. Ensuring a suitable . funding structure There are expectations on all levels of management. SAFe sees Agile software development as part of business Agility. SAFe is not just about project management. It is aimed at full business Agile transformation situations as well as individual large programs. ARTs (Agile Release Trains) The Agile Release Train is a team of teams. It is a set of teams delivering services that are all part of the same product. SAFe describes the ART as a . This is because the ART is meant to be self-sufficient. It should have available all of the resources needed to deliver value and resources should be long-term dedicated to the ART. virtual organization SAFe values alignment between teams very highly. Teams work to a common cadence and come together regularly. There are two levels of cadence for different levels of the program: at team level. These are every two weeks (basically Sprints). Each team has its own backlog and stories for the iteration. Iterations at ART level. These are every ten weeks (five Sprints). The ART has a and high-level allocations to teams are made for a Program Increment. Program Increments program-level backlog Teams work to their using either kanban or (teams can be free to choose). At the end of each iteration there is a for the whole ART. This helps each team see progress other teams are making. iterations of two weeks ScrumXP demo session The team-level iterations are likely familiar as these map to Scrum Sprints. What takes some understanding is how the Program Increment cycles are layered on top. Program Increment (PI) Planning “PI planning is essential to SAFe: If you are not doing it, you are not doing SAFe.” SAFe PI Planning PI Planning in SAFe occurs every five Sprints (5 Sprints = Program Increment = PI). It brings the whole program together to plan the next Increment. SAFe stresses involving everyone in PI Planning. This is partly to build social relationships and encourage communication. It’s also about ensuring everyone can buy in on the vision. PI Planning is where the vision is agreed. Leadership has a key role to play in PI Planning. Planning starts with a presentation of a draft vision for the next Increment. Leadership should communicate this vision, conveying the motivations and also inviting everyone to think it through. The program will collectively shape that vision over the two days of PI Planning. Here is a sample PI Planning agenda: This sample PI Planning agenda based on one from the documentation. SAFe PI Planning Notice that the agenda starts with presentations of the aims for the Increment and the motivations behind those aims. Architecture is included in this as it’s important to have a plan of how the vision can be realised. At this point plans are being presented to the teams for their input. The rest of the PI Planning is dedicated to teams breaking out to work through their parts of the plan. There’s an expectation that teams will need to coordinate here on any inter-related pieces. This process adds detail to the plan as feedback from the teams is used to revise the plan. A confidence vote is included to ensure that concerns are raised and there is then time for reworking to address concerns. It gives every team the opportunity for input and enables teams to buy in on the plan. This can seem like a lot of process for those more familiar with working with just individual teams. The point is that larger programs need more direction. The illustrates this with a quotation: SAFe guide “The more alignment you have, the more autonomy you can grant. The one enables the other.” Stephen Bungay Program Kanban Features being delivered in a Program Increment are monitored in a . This could be pictured like: Program Kanban The Program Kanban is maintained by Product Management and Architecture. It is used to gain visibility of progress and to ensure that no particular team . becomes overloaded The Program Kanban is not the only way of monitoring progress. Individual teams may also have their own methods, . There may also be higher-level Kanbans for monitoring above the level of features. For example, monitoring (which can span multiple Increments). In very large-scale implementations there may also be multiple related ARTs/Programs, monitored and run as a . either Scrum or Kanban Epics Portfolio Innovation and Planning (IP) Iteration The first iteration (Sprint) within a Program Increment is reserved for . This ensures time is set aside for innovation and other work that does not fit neatly into delivering features. These include: Innovation and Planning Innovation and exploration e.g. PoCs, forming new ideas Infrastructure and tooling or release activities Education and documentation Follow-ups to PI planning, backlog refinement, prioritization etc. The IP Iteration also acts as an estimation buffer, though it . should not be regularly relied upon for that purpose Architectural Runway SAFe does not advocate Big Design Up-front. It also does not advocate leaving the architecture to only evolve out of what teams do. It tries to strike a balance. The problem with not doing any central architecture is that individual teams are not best positioned for medium-term planning that spans the system. Teams have remits on particular areas. It’s difficult for teams to get a wider view on the whole system. The architecture function is intended to set a direction that anticipates future business needs. It also plays an important facilitation role. Architecture can help teams to collaborate by guiding teams on which one does which part and how to go about it. SAFe’s vision of architecture is not of an ‘Ivory Tower’ Architect removed from the practice on the ground. The aim is to provide “ ” architectural planning to set a coordinated direction but not too much as it should avoid becoming restrictive. just enough Critical Success Factors for SAFe® SAFe provides a knowledge base to guide practitioners. There is a lot of information and the knowledge base refreshing asks the question “how closely does an organization need to follow various SAFe practices to get the desired result?” It suggests ten . critical success factors for essential SAFe We’ve covered already that should be self-sufficient and aligned to value (2), synchronized across the (3) through (4). We’ve not touched much on (5), which is about practices to understand the customer and how the solution addresses their needs. We’ve also not touched on DevOps but SAFe recommends releasing often to respond to feedback and has . teams ART PI Planning customer centricity suggestions for achieving this We’ve talked about the whole-ART (6) in each iteration. The demo is actually part of an event (7) which also includes looking at progress metrics and a retrospective. demo sessions Inspect and Adapt We’ve looked at the (8) and how it is used for exploratory and supporting work. We’ve also looked at (9) and how it provides “ ” architectural planning to set a coordinated direction. Direction-setting is a core responsibility of (10), who have the influence necessary to align teams and ensure buy-in. Innovation and Planning Iteration Architectural Runway just enough Leadership Underpinning all of this is the SAFe® (1). In fact the Principles are realised through the practices. These are (with my explanations): Lean-Agile Principles Take an economic view = understanding that delivery involves trade-offs Apply systems thinking = looking holistically both at the solution and the delivery setup Assume variability; preserve options = being flexible and avoiding too much Big Up-front Design Build incrementally with fast, integrated learning cycles = releasing often Base milestones on objective evaluation of working systems = assessing results Visualise and limit WIP, reduce batch sizes, and manage queue lengths = avoiding any teams becoming overwhelmed Apply cadence, synchronise with cross-domain planning = PI Planning on common cadence Unlock the intrinsic motivation of knowledge workers = providing autonomy within a clear direction and encouraging learning and experimentation Decentralize decision-making = only strategic decision-making should be centralized to ensure empowerment Organise around value = prefer feature teams aligned to distinct areas of business value where possible SAFe® in the Wild There has been criticism of SAFe. The biggest is that it centralises too much and this invites command-and-control management. Agile Manifesto signatory Ron Jeffries that “SAFe will be installed in a fashion that won't just fail to support Agile, but that will suppress it.” warns Part of the criticism is that SAFe risks being overused. Certainly one should not centralise where one does not have to. The overheads of SAFe do not make sense unless the program is large enough to need them. The minimum ART size should be in SAFe. 50 people Undoubtedly there is a risk that SAFe can be applied in a way that becomes top-down. The concern is not so much with SAFe itself as with how it is likely to be employed. I will not take a stance on this other than to note that there is a general problem for the industry here. Scrum has also been subject to . corruption in practice There are other scaling frameworks available (LeSS, Scrum@Scale, Nexus, DAD etc.). Some are notably more lightweight. For example, many other scaling frameworks do not require the whole program together and instead prefer teams to send representatives to program-wide meetings. There are also criticisms out there of the whole space of Agile frameworks. My intention here is not to give any recommendations, just to empower readers to be able to find out more (and ). I've written more on this elsewhere Next Steps with Scaling Agile There are a lot of Agile scaling frameworks and comparing all of them is a big job. There are ,if that’s what you’re looking for. guides that do this The SAFe documentation at scaledagileframework.com can take some getting used to.  The presents four configurations of SAFe. , , and . These are tailored to different sizes of implementations. Most of what we’ve discussed is . You have to learn how to click around to the bits that you want, or know enough to be able to search for what you want online. SAFe Big Picture Configurations Essential SAFe Portfolio SAFe Large Solution SAFe Full SAFe Essential SAFe If you’re looking to find out more about SAFe, then is the natural book to go to. It will certainly give you the background to use the documentation and see where to go next. SAFe Distilled Image Credits SAFe and Scaled Agile Framework are registered trademarks of Scaled Agile, Inc Title image of Bear by Alexas_Fotos on . pixabay Kanban image uses Postit Notes by Alexandra_Koch from . pixabay Critical Success Factors image uses various images from . by kareemov, by Alex Berkowitz, by BomSymbols, by Unstashable, by Prosymbols, by Lars Meiertoberens, by LUTFI GANI AL ACHMAD, by Phạm Thanh Lộc, by HLD, by Adrien Coquet, by Luis Prado, by Brad Avison. thenounproject Building Person Agile Team Synchronization Customer Training Adapt Research data Brainstorming Binoculars Weightlifter Clock in Critical Success Factors by OpenClipart-vectors on . pixabay

BUNCH

Funding

Writes about data, how to manage it, how to do AI with it, how to make data-driven products. Principal Data Consultant at Thoughtworks and 2020 HackerNoon Contributor of the Year - Engineering.

2021 - HackerNoon Contributor of the Year - DATA

2022 - HackerNoon Contributor of the Year - Agile

2022 - HackerNoon Contributor of the Year - Agile Software Development

2022 - HackerNoon Contributor of the Year - Digital Transformation

2022 - HackerNoon Contributor of the Year - Innovation

2022 - HackerNoon Contributor of the Year - Kubernetes

2022 - HackerNoon Contributor of the Year - Machine Learning

2022 - HackerNoon Contributor of the Year - Monitoring

2022 - HackerNoon Contributor of the Year - Product Management

2021 - HackerNoon Contributor of the Year - SCRUM

Nominated for 2022 - HackerNoon Contributor of the Year - Innovation

Nominated for 2022 - HackerNoon Contributor of the Year - Scrum

Nominated for 2022 - HackerNoon Contributor of the Year - Agile

Nominated for 2022 - HackerNoon Contributor of the Year - Digital Transformation

Nominated for 2022 - HackerNoon Contributor of the Year - Kubernetes

Nominated for 2022 - HackerNoon Contributor of the Year - Machine Learning

Nominated for 2022 - HackerNoon Contributor of the Year - Agile Software Development

Nominated for 2022 - HackerNoon Contributor of the Year - Product Management

Too Long; Didn't Read

Developers: Build Less. Deliver More. [Learn how]	

Intro to SAFe®: Scaled Agile Framework®

Intro to SAFe®: Scaled Agile Framework®

Too Long; Didn't Read

Companies Mentioned

Ryan Dawson

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

Intro to SAFe®: Scaled Agile Framework®

Too Long; Didn't Read

Companies Mentioned

Ryan Dawson

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

RELATED STORIES