Over the last several years, the Scaled Agile Framework (SAFe) has become near-ubiquitous in large organizations. This proprietary system for propagating agile practices throughout an organization is popular for its ability to orchestrate collaboration across many individual teams working toward a shared goal.
Some see it as a beacon of transparency and alignment. Others see it as a bureaucratic, overly-prescriptive behemoth that sucks the joy and creativity out of their roles. But it’s not really the framework itself that divides people: it’s the way each organization implements it and adapts it to their own culture. More often than not, empowered, passionate practitioners find frustration when they join a SAFe agile release train, but it doesn’t have to be this way.
Here at VMware Tanzu Labs, we’ve been involved in many SAFe engagements across various industries and have implemented a handful of approaches that guide clients in creating an environment where a truly lean-agile team can thrive. Whether you are a lean extreme programming (XP) practitioner starting your first SAFe project, or already on an Agile Release Train and wondering how to bring more lean and XP principles into play, here are a few good places to start.
Minimize dependencies
A common complaint about SAFe is that it requires teams to plan out work in large chunks (often 10 or 12 weeks) rather than learning and adapting day by day. When we look into why this is, it often comes down to dependencies.
The primary reason companies adopt SAFe is that their teams are working on pieces of software that are interdependent. When managing a large system, the work needs to be divided up somehow. This may look like one team building a mobile app, another building a web app, yet another working on APIs that will be used by both, and perhaps an additional team working on some common components such as log in or notifications.
SAFe provides a standardized way to plot out the interdependencies between these various works in progress. For example, if the mobile app plans on releasing a feature in March that requires a change to the API, then the API will need to finish that work before the mobile team needs it. At a Program Increment (PI) Planning session, this will be discussed and mapped out on a chart, typically with a line or string connecting the two, calling attention to the dependency. By the end of the planning session, you’ll have a board full of red strings. These lines are the reason all of this planning is needed—to make sure everyone has what they need when they need it.
The problem for the lean product team is that this locks you into a fixed time frame and scope months in advance, preventing you from responding to findings along the way. If you are executing fast build-measure-learn cycles, you plan for the plan to change.
In lean software development, if you deliver your PI commitment perfectly on time and within scope, that’s actually not a good sign. It means that either you have not learned anything during the PI, or you have not acted on what you learned.
But what can be done when we are tangled up in our dependencies on other teams, and their dependencies on us? Unfortunately, not much. If a change by your team disrupts the plans of the teams around you, you just can’t be as flexible as an uncertain marketplace demands. So rather than tracking and planning out all possible dependencies, your best bet is to minimize them. Not to eliminate them completely (if it were that easy you probably wouldn’t need SAFe to begin with), but at least to defer them, especially at the beginning of a project when learning is highest and changes are more drastic.
Were you planning on integrating with a third party reporting system? Maybe you can build top priority reports out yourself, and then once feedback has been gathered and your direction has been validated, you can swap your feature out for the more robust system. Are you dependent on your company’s new single sign-on (SSO) system that the architecture team swears they’ll have running by Sprint Three? Maybe you can build out a simple allowlist until they’re fully ready for you.
Rather than getting tangled up in all those dependency strings on the PI Planning board, cut them, and set yourselves free.
Protect your autonomy
Besides managing dependencies, the other big draw for organizations using SAFe is the alignment from the top to the bottom of the corporate hierarchy. From strategic themes to user stories, priorities cascade down and make sure everyone’s work is contributing to the same goal. While this type of alignment is critical for a large organization, in practice, it often results in disempowered product teams. Architects assign down technical solutions to be implemented by product team engineers, product managers pre-define a roadmap to be handed off to a product owner, and design leads often use “runway” time to do research and complete prototypes without involving the product team. This is antithetical to the idea of team autonomy, leading to disenfranchisement of the product team members. It also leads to poor product outcomes, as the people closest to the work aren’t able to make decisions impacting it.
Repairing this anti-pattern is possible with a cultural shift in the way architect-level teams (of all roles) interact with product teams. If we move portfolio leads and managers away from planning the team’s work for them and into advisory, “servant leader” roles, we can protect the product team’s autonomy while guiding them towards solutions that work in the context of the greater organization.
My advice is to treat the product team as experts on their product and code base, while treating the architects and other leaders as experts on the ecosystem that the product team works in. They can advise on such questions as: What security standards do we have to meet in this organization? What solutions have other teams tried that worked or didn’t work? What third-party integrations are already available? Where is there room to deviate from standard patterns, and where must they be adhered to?
This represents a big shift from how most organizations handle the architect/lead role, and requires coaching at both the product team and architecture levels to get everyone used to this adjustment in responsibilities; however, it results in a more collaborative and effective Release Train.
Treat downstream teams as your customers
Despite your efforts at minimizing dependencies, you will sometimes find yourself on one or the other ends of that red yarn. Maybe you’ve seen this drama play out on your own projects: the API team follows instructions from the architect team on what to build, striving to get it ready for the front-end team that needs it by Sprint Three. The API team gets their work done, probably a little bit late, and hands it off to the front-end team. The front-end team immediately notices that the API doesn’t behave as they expected. The API team doesn’t have time to make changes, and anyway, they just built what the architects told them to. The front-end team also does not have time to make changes, so everyone gets into a room and points fingers until the PI plan is adjusted to reflect the additional effort needed to correct for the misunderstandings. Everyone is annoyed and the project is late.
At VMware Tanzu Labs, we practice user-centric design, emphasizing constant user input via interviews, prototype testing, feedback on live software, and anything else that makes our products ones that users love. We apply this user-obsession to back-end “products” as well, such as APIs and platforms. In these cases, the “users” are our developers, and we put as much effort into our developer experience (DevX) as we would for user experience on a traditional product.
There are lots of ways to get fast feedback from a downstream team. In the case of an API, you can sketch out what you think the response will be in a text document before you ever write a line of code, you can give the team a first iteration that only has one data point in it to test out their integration, or you can even user test your documentation to make sure it’s easy to understand. You’ll not only create a great developer experience this way, but you’ll de-risk any technical assumptions and avoid last-minute misunderstandings, the resulting blame games, and the delayed launches that follow.
VMware Tanzu Labs brings lean XP practices and culture into SAFe organizations every day, because we know it can be done successfully, and we know what pitfalls to look out for. Joining our culture and practices to a SAFe implementation can be exactly what is needed to take it from a “bureaucratic behemoth” style framework to the “autonomous and aligned” vision it was always meant to be.
