Is it Safe to Borrow from SAFe and Other Frameworks?
It is more common to hear about companies that are “kinda SAFe” or “only partially SAFe” than those with full adoption success stories. And I’d venture that those that are partial aren’t even in the midst of implementing the Scaled Agile Implementation Roadmap.
So, “Is it OK to borrow concepts from SAFe without implementing all of it?”
The answer, as with many things, is “it depends”. However, I do have some specific advice about scaling and stealing.
Don’t Scale if You Don’t Need To
First off, if you only have one, two or three teams, life’s pretty good and you don’t need to worry about scaling very much. You probably have enough people to implement your agile processes just fine and only need to work out the details informally of sharing a backlog and the dependencies between your teams. In general, make sure you understand what problems you are trying to solve before applying any solution or framework.
Where we all get into trouble is when we talk about scaling complexities with many teams. There are 1000s of options today. It is commonly criticized and probably rare that a company adopts just one framework. Some companies do however declare “thou shalt be scrum” and force some rigor through adopting one of the scrum-based scaling strategies: Nexus, LeSS, or Scrum@Scale, etc.
But I’m of the opinion that larger companies should not be quite so prescriptive and therefore need to be a bit more accommodating in the way they apply scaling strategies as well.
It has become popular to adopt multiple frameworks and usually only pieces and parts of some frameworks glued together to make a custom amalgamation of concepts and scaling strategies. Sometimes this happens organically as one part of a company starts one way while another pocket of agilists start doing something else.
The Scaling Manifesto
Before I share my opinions, I’d like to start by introducing you to the scaling manifesto if you’ve not seen this yet. Take a look at scalingmanifesto.org. I would also like to applaud the agile consultants like LeanDog (where I work) that are careful to work with their clients to meet them where they are and implement a practical scaling strategy that works without prejudice or preconceived notions. If your consultant is steering you to adopt one framework, get certified, and only consider one path, you should probably pause and reconsider your approach, in my opinion.
The scaling manifesto, much like the original manifesto, is succinct and general, focused on four main points:
In our work to help organizations become more agile, we have come to value:
Shared vision over aligned processes
Organic growth over pre-defined structure
High performing organization over high performing teams
Team-empowered responsibility over organizational policies
While there is value in the items on the right and the left; we value the items on the left more.
What I like about the scaling manifesto is that it adopts a very pragmatic approach to large scale human challenges in organizations.
No matter what you do, make sure your company has a vision that has been shared widely so your teams know what to align to, how to focus, and how to decide on which products to build. If everyone knows why they’re building what they’re working on and who it’s for, your company will do better work.
Instead of adhering to any pre-defined structure of your organization or processes, allow the organization to adapt freely and favor anything that encourages organic growth. This implies a test and learn approach, and ultimately leads to a customer-centric, design thinking mindset.
Then, perhaps most controversially, the scaling manifesto says instead of dwelling on your high performing teams (i.e. “bottoms up” approaches), you should favor an approach that connects your tribes and factions to build a high performing organization instead. This implies tilting the scale to a “top down” strategy and yet says it in a way that is very practical and does not ignore the fact that you must also have high performing teams. This says you should emphasize and drive coherenece at the highest level and focus on organizational collaboration and performance. (Which all screams “business agility” to me!)
And lastly, one should favor giving agency to teams; trusting those high performing teams with the responsibility to build what matters instead of governing them tightly with policies. And yet, it still acknowledges that there should be *some* organizational policies, just that you should favor offering trust first and giving agency to teams should you have to make a choice.
So, this philosophy, to me, is so profound and so important that I find myself thinking it almost doesn’t matter what frameworks you apply, so long as you keep the scaling manifesto and its principles in mind first. The principles are equally logical and practical and get very specific about some strategies:
Supporting Principles:
1. If you can achieve your goals with a single team, do not scale. Employ the minimum number of people required to meet your strategic outcomes.
2. If you have a single team and it cannot deliver effectively using Agile principles and practices, do not scale. Succeed with a single team first.
3.Respect, trust, and be kind to your people; foster a climate of open, honest, rapid, and empathetic communication.
4. Continuously reflect and improve across all levels and maintain focus on the whole; prioritize collective high performance over the performance of any individual team.
5. Keep teams and their work loosely coupled to preserve flexibility; minimize handoffs and dependencies with cross-functional teams and clearly decomposed work.
6. Radiate information between and among teams to develop shared understanding and promote asynchronous communication; create visibility across the entire work system.
7. Aim for a minimally viable bureaucracy and nothing more; effective and repeatable practices, policies, and procedures will emerge as you scale.
8. Decentralize decision-making; push authority to teams so that they can quickly take advantage of emerging opportunities.
9. Prioritize experimentation for each individual team over conformity across the organization. Celebrate the learning that comes from experimentation — successes and failures — across all teams.
10. Ensure each team is working towards the shared vision and delivering real value regularly and consistently. Demonstrate progress with frequent validations by stakeholders.
What is Worth Stealing?
As much as I’d like to, I realize it’s not enough to say “go ahead and steal whatever you want so long as you adhere to the scaling manifesto”. So, what are common stealing practices? What stuff is worth stealing from the various frameworks? And what are the caveats and warnings?
- Scrum of scrums. Clearly communicating blockers through S1/S2/S3/S4 structures is an easy, non-controversial thing to do. However, avoid treating this like the old ways of thinking’s program status meetings. And don’t forget to share vision statements and updates against goals or minor shifts in direction back down the chain from senior management to the teams as well!
- Backlog sharing strategies. Nexus and LeSS tend to do the most good at collaboration in a pocket of 10 teams or less working in a common, related product space. You may have many of these team clusters in a large organization. Where you can isolate teams of teams, these strategies work well. One key success factors is putting the right, highly-capable, domain experts as the senior product managers in charge of those Area Product Owner roles.
- Agile Release Trains. I hesitate to say this, because that term carries some baggage with it, being at the core of so many SAFe concepts. But the concept of a team of teams being connected in a longstanding way just like a single self-sustaining, durable product team makes sense. What challenges come with this though? Read carefully through the next two ideas.
- Product Increment Planning. Where you have Agile Release Trains (or any co-dependent team of teams), you must uncover the dependencies between teams and align on the goals and context. SAFe strives to do this with a quarterly process to get all of the related teams in a room together for two days to solve this challenge. My own personal problem with this, is that it feels very waterfall in its nature. I know teams need to pause and think about their cross-team dependencies, but I suspect there are more frequent and less heavy ways to do this. Even though 8 days out of the year doesn’t sound like a lot, it’s still close to 5% of your overall team time that you spend on PI Planning with ALL team members, according to SAFe. There is no one-size-fits-all solution here, but I’d encourage you to think hard about the following two things: 1) What is the degree of actual hard dependencies and collaboration you have between teams in your ART? If there are no dependencies or only a small amount, you can probably avoid doing PI Planning entirely and 2) Are there any more frequent ways you could synch up on dependencies between teams on a sprint-by-sprint basis (perhaps through product owners comparing roadmaps?) that would solve the interdependency challenges closer to real time? My preference would be to find a more frequent, lighter weight way to perform a less formal “big room planning” between only the teams that have actual dependencies and direct collaboration items to coordinate.
- Release Train Engineer. This role is one I struggle with, because it is officially a very specific and certified role in the Scaled Agile Framework. And companies that are not actually SAFe run the risk of hiring someone who has spent quite a good deal of time and money preparing to operate in a truly SAFe environment, but if you are NOT, then that person by definition may not end up being a great fit. That said, this role is important but should perhaps just be more dynamic to fit the needs of your situation. In any complex team-of-teams environment, you need great senior servant leaders. And this RTE-like role is something I’ve played before in large and small companies where it’s been called many different things like Delivery Manager or as Gil Broza calls it in the book The Human Side of Agile, Agile Team Lead. See more in my article on The Delivery Manager Role.
- Flow. While Fin and Haydn will tell you Flow is not a framework, it is a business agility strategy worth considering stealing concepts from to address the enterprise and portfolio layers of agility. Flow will help encourage some level of executive involvement and provide concepts to help visualize customer micro-segmentation, executive portfolio level prioritization, and the flow of ideas into funded products and initiatives. I can’t recommend Flow enough. Consider reading both Flow and 12 Steps to Flow and if you have the chance, send your executives and senior leaders to a Flow Academy Workshop!
- Stakeholder Engagement. Stakeholder engagement models are a fantastic way to break down silos and encourage truly cross functional teams to build out products. Consider ALL possible stakeholders at the start of a new initiative and build a trust-based communication model to keep them informed and integrated as your team of teams delivers value to customers. This is particularly relevant in regulated industries where there are multiple critical stakeholders who need to be involved early and often as product roadmaps change to keep risk and compliance in check.
- Design Thinking. Find a way to implement design thinking strategies earlier in the product lifecycle to vet ideas before they get funded. What are the smallest experiments you could run to help inform what products your customers want most? Also work hard to build a culture of experimentation into every team so the team members treat requirements more like hypotheses and look for ways to test and validate ideas with customers frequently to build appropriate feedback loops and a tight coupling of teams to customer segments.
- Communities of Practice. Create Communities of Practice and skill-based guilds to encourage people to explore new roles and get involved. Provide lightweight training to people who are not yet on agile teams so they can learn the mindset before they have an opportunity to practice. How can you encourage the teams still working the old way how to make small changes and start doing things like daily standups, retrospectives, continuous improvement, face-to-face conversations, challenging assumptions and breaking work into small pieces? Communities of Practice break down walls and encourage a culture of curiosity. For more, consider my article: How Do You Start an Agile Community of Practice?
These are just some of the ideas I like to focus on. What else do you recommend to companies looking to pull together the best ideas from various frameworks and systems?
Hi, I’m Brian Link, an Enterprise Agile Coach who loves his job helping people. I call myself and my company the “Practical Agilist” because I pride myself on helping others distill down the practices and frameworks of the agile universe into easy to understand and simple common sense. I offer fractional agile coaching services to help teams improve affordably. See more at FractionalAgileCoach.com
How well is your team “being agile”? Our self-assessment tool focuses on 24 topics of modern ways of working including the Agile Manifesto and Modern Agile basics, XP, Design Thinking, Lean, DevOps, and Systems Thinking. It comes with deep links into the Practical Agilist Guidebook to aid continuous improvement in teams of any kind. Learn more at MakeTeamsAwesome.com
The Practical Agilist Guidebook is a reference guide that gives easy to understand advice as if you had an agile coach showing you why the topic is important, what you can start doing about it, scrum master tips, AI prompts to dig deeper, and tons of third party references describing similar perspectives. Learn more at PracticalAgilistGuidebook.com
Follow me here on Medium, subscribe, or find me on LinkedIn, or Twitter.
