Principal Data Consultant at ThoughtWorks. Hackernoon Contributor of the Year - Engineering.
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 most popular framework, SAFe. Let’s get the flavour of what SAFe is all about. We’ll see why we'd use it, the key ideas and how it differs from the other frameworks.
Running big projects is different from small projects. Especially it requires:
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.
SAFe emphasises that achieving an optimal culture for Agile is one of the hardest challenges of scaling. Culture problems are high on the list of blockers to scaling agile. To address this it takes a holistic approach.
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.
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.
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.
SAFe recognises 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.
SAFe looks for leaders to coach and mentor as well as set a great example. This means:
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.
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 virtual organization. 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.
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:
Teams work to their iterations of two weeks using either kanban or ScrumXP (teams can be free to choose). At the end of each iteration there is a demo session for the whole ART. This helps each team see progress other teams are making.
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.
“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 SAFe PI Planning documentation.
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 SAFe guide illustrates this with a quotation:
“The more alignment you have, the more autonomy you can grant. The one enables the other.” Stephen Bungay
Features being delivered in a Program Increment are monitored in a Program Kanban. This could be pictured like:
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, either Scrum or Kanban. There may also be higher-level Kanbans for monitoring above the level of features. For example, monitoring Epics (which can span multiple Increments). In very large-scale implementations there may also be multiple related ARTs/Programs, monitored and run as a Portfolio.
The first iteration (Sprint) within a Program Increment is reserved for Innovation and Planning. This ensures time is set aside for innovation and other work that does not fit neatly into delivering features. These include:
The IP Iteration also acts as an estimation buffer, though it should not be regularly relied upon for that purpose.
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 “just enough” architectural planning to set a coordinated direction but not too much as it should avoid becoming restrictive.
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 teams should be self-sufficient and aligned to value (2), synchronized across the ART (3) through PI Planning (4). We’ve not touched much on customer centricity (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 suggestions for achieving this.
We’ve looked at the Innovation and Planning Iteration (8) and how it is used for exploratory and supporting work. We’ve also looked at Architectural Runway (9) and how it provides “just enough” architectural planning to set a coordinated direction. Direction-setting is a core responsibility of Leadership (10), who have the influence necessary to align teams and ensure buy-in.
Underpinning all of this is the SAFe® Lean-Agile Principles (1). In fact the Principles are realised through the practices. These are (with my explanations):
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 warns that “SAFe will be installed in a fashion that won't just fail to support Agile, but that will suppress it.”
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 50 people in SAFe.
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, [email protected], 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).
There are a lot of Agile scaling frameworks and comparing all of them is a big job. There are guides that do this ,if that’s what you’re looking for.
The SAFe documentation at scaledagileframework.com can take some getting used to. The SAFe Big Picture Configurations presents four configurations of SAFe. Essential SAFe, Portfolio SAFe, Large Solution SAFe and Full SAFe. These are tailored to different sizes of implementations. Most of what we’ve discussed is Essential SAFe. 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.
If you’re looking to find out more about SAFe, then SAFe Distilled 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 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 thenounproject. Building by kareemov, Person by Alex Berkowitz, Agile by BomSymbols, Team by Unstashable, Synchronization by Prosymbols, Customer by Lars Meiertoberens, Training by LUTFI GANI AL ACHMAD, Adapt by Phạm Thanh Lộc, Research data by HLD, Brainstorming by Adrien Coquet, Binoculars by Luis Prado, Weightlifter by Brad Avison.
Clock in Critical Success Factors by OpenClipart-vectors on pixabay.
Create your free account to unlock your custom reading experience.