The Scaled Agile Framework (SAFe), hailed by many as the best approach to achieving success with Lean-Agile at scale, has its detractors too.
They say SAFe is slow. SAFe is too prescriptive. SAFe ruins high-performing Scrum teams.
We’ve heard it all. And unfortunately, we’ve seen it too. There are reasons these myths exist. SAFe, like any framework or methodology, can go wrong.
Mythbusting SAFe is a no-spin conversation will be led by two of Applied Frameworks’ most experienced SAFe practitioners — SPCT Phil Gardiner and SPC Michael Robertson. They discuss what they’ve learned across dozens of SAFe implementations — the good, the bad, and the ugly.
Since we didn’t have time to answer all of the questions in the webinar, we’ve provided full text answers below:
1. Question: Any suggestions on how to measure the impacts and justify the existence of a LACE with full time members? It’s been tough to justify budgeting for dedicated roles on a LACE, and doing it with people who have other full time duties has been ineffective.
Phil Gardiner: Lean-Agile at scale and the journey to Business Agility is one that really never ends as it is one of relentless improvement. When it comes to the LACE, it will grow and evolve as the enterprise moves forward on their journey. If you are an SPC, or have one working with you, there is a great toolkit that incliudes an overview of SAFe’s LACE model as well as a workhop to stand it up. It includes a LACE canvas which can be created collaboratively to align on things like LACE memebrs, stakeholders, KPIs, budgets, etc. Personally, I am a fan of canvases as you can collaboratively create them and they serve as gret one-pagers to communicate and align with others. I also like to see the LACE create a SAFe Epic, starting with an Epic Hypothesis Statement, that can allow the LACE to articulate the business outcome hypothesis that can be validated by the LACE’s MVP (often a first Agile Release Train.) As with any Epic, please be sure to have measures that show that the desired outcome is being met as well as leading indicators to serve as signposts along the way. For example, if the desired outcome is faster time to market or higher quality and the MVP is to align around value and deliver via an ART, leading indicators could be training, PI PLanning, system demos, etc. You may also want to check out the LACE article onthe framework site as it has a good overview of different LACE models, responsibilities, a sample mission statement, etc. https://www.scaledagileframework.com/lace/.
2. Question: What are the best qualities for an RTE? What should we hire for?
Michael Robertson: The RTE role may be the most difficult and challenging role on the ART. This servant leader role is responsible for the facilitation of effective flow across the ART. No one reports to the RTE, and therefore they have no specific authority, however they do shoulder a huge responsibility. The only authority they have is what they are able to earn from the ART. This challenge requires that the RTE have significant professional coaching and mentoring experience, a solid understanding of SAFe, as well as effective political chops. They need to be able to develop a wide spectrum of personal relationships with the ART, Business Owners, and stakeholders.
3. Question: If SAFe is agile at its core, why have all of the authors of the agile manifesto come out in opposition of it? None of them support it. All of the people that popularized the concept and value for agile, all saw this ain’t it. That has always been an interesting position for me. Any comments on why none of the authors support SAFe?
Laura Caldie: Please note that this response was written by Applied Frameworks co-founder Luke Hohmann, former Board member of the Agile Alliance, producer of the Scrum Alliance Collaboration at Scale webinar series, former member of the Scaled Agile Framework team, celebrated author, and noted philanthropist.
“The Agile Manifesto was written by a group of wonderful people who laid the foundation for an entire industry. They are my friends and I am thankful that they created a manifesto that has provided inspiration and guidance for more than 20 years. I am also proud that SAFe explicitly integrates the values and principles of the Agile Manifesto throughout the framework. I am also proud that SAFe includes additional practices that enable organizations to succeed with Agility at Scale.No framework is perfect, and every framework has at its core, the desire to unlock the intrinsic capabilities of the people creating the solutions the organization delivers to their customers. I am proud that SAFe provides an entire set of guidance designed to realize this objective, such as embracing a growth mindset and using Participatory Budgeting to promote collaboration in the allocation of resources in portfolio management.We advocate that organizations invest the time to choose frameworks and ways of working that enable them to accomplish their goals. Our experience is that SAFe is the best framework for scaling agile practices. That being said, the most important test of any method is not the opinion of experts, but the opinion of the people using the method and their relationship to the method they’re using. In this respect we find common ground with all agilists: organizations create sustainable success through deliberate execution, reflection, and continuous improvement.”
4. Question: What are some good techniques for approaching the conversation with engineering or PMO leaders concerning their role in the SAFe framework?
Phil Gardiner: One of our SPCs, Eric OBrien, recommends the following: “Leading SAFe would provide the Principles and Practices of the SAFe as well as an overview of the roles in the framework. After Leading SAFe specific role-based training can be used for (Scrum Master, Product Manager/Product Owner, Architect, and RTE).” That is a great starting point and Leading SAFe is the preferred introduction for both engineering and PMO leaders. If your question is related to how to start the conversation, I recommend starting with why you are looking at a new way of working. Oftentimes, people start talking about SAFe immediately and I have found that focusing on the problem to solve or outcome of interest is more effective. What is that vision of the future? What would that engineering leader or PMO leader be seeing, hearing, feeling, doing, etc. in that future. Then, you can talk about the path to get there and how they can help.
5. Question: How does COD (Cost of Delay) work in government when there is no COD in making money from Don Reinertsens work? Do you apply a different prioritization technique?
Michael Robertson: The Value that government agencies are delivering is very different from commercial firms, but there is clearly Value being delivered. Ask yourself – “What is our Mission, who are our Customers, and how do we prioritize the Value we delivering to them?” Weighted Shortest Job First (WSJF) is very meaningful in this discussion. Understanding the Cost of Delay (CoD) is critical to delivering the right Value with alignment around the Vision and Mission of the agency. Prioritizing work that focuses on execution of the Vision and Mission is what Business Agility is all about.
6. Question: Who would be the key people to have in the LACE in your opinion? How (& how much) do you engage Top Leaders in the SAFe transformation ?
Michael Robertson: Mike: A LACE is meant to be that “Guiding Coalition” of leadership that represents the Portfolio as a whole. It should include a mixture of folks who have decision making authority, and those who are closely tied to the ARTs and can get things done. The LACE is also part of the LPM’s Agile Portfolio Operations dimension, if your organization has implemented LPM. Leadership with decision making authority is critical, but they may not have time to focus on the day-to-day like others can – thus the balance between the two.
Phil Gardiner: There is an activity that we often do as part of standing up the LACE regarding who the stakeholders are and what degree of influence and engagement each will bring to the journey. I recommend that there are individuals inthe LACE who have relationships, or the ability to create them, with influential stakeholders as their support, and ideally engagement, will strengthen and often accelerate the implementation.
7. Question: Can you share a little more in the way of examples about characteristics of successful vs unsuccessful PI Planning sessions?
Michael Robertson: Mike: A successful PI Planning produces a committed set of objectives and a Program Board that identifies delivery, dependencies and risks. The critical piece here is that this plan was created in a robust environment of team collaboration with Business Owners, that ensures a deep understanding of the risks and impediments. This creates alignment across the ART, and a meaningful commitment by all that delivers predictable delivery of value.
8. Question: I have personally seen that these myths get validated when SAFe is blindly implemented as a tool for the sake of a tool. Phil, I completely agree with your implementation strategy of using the tools that make sense for your situation. How have you talked about the consequences of not implementing specific tools?
Phil Gardiner: To me, this is where experience comes into play. Knowledge of the Scaled Agile Framework’s principles, practices, etc. is a small part of one’s ability to help someone achieve sustainable success. The understanding of the impact that delaying, skipping, changing or ignoring what is recommended and being able to articulate what it could cost is critical. The more experience one has starting at so many different points and trying so many different things are what makes the difference. Wherever you are from an experience point yourself, I would suggest that you pause when you encounter something that seems impossible to implement. Why does SAFe recommend it? What values and principles support that practice? What will it cost you to not do it? What will it cost you to do it in a way that does not support the principles? For example, if an ART can’t integrate across teams for a demo, I encourage a customer not to call it a System demo. If all they can do right now is demo what individual teams have done, I would suggest calling it a mutli-team demo instead. That way, when the Business Owners who have been through Leading SAFe show up, they understand that they are NOT seeing the integrated solution. This leads to great question such as why not which, in turn, are great entry points to talk about enabler features.
9. Question: What about LESS?
Phil Gardiner: I did not mention LeSS as it is one of the frameworks I have not implemented personally. I view it as very similar to Nexus, with a focus on helping great Scrum teams scale. I see SAFe as a framework for Business Agility as opposed to one for delivering software at scale. There are things like Lean, Lean Startup, Kanban systems, Lean Portfolio Management, guidance for Strategy, etc. that the Scrum-based frameworks are not intended to address.
10. Question: You mentioned that SAFe is not Rigid or Prescriptive, but you also pointed out that you can warn about the consequences of compromising on aspects of a SAFe implementation. How do you balance the “meet them where they are” approach while not compromising to the point that the implementation fails (and SAFe gets blamed)?
Michael Robertson: First, let’s recognize that each ART’s SAFe journey is different. We all have a different starting point, and ability to grow. Start with a focus on the foundation of Lean-Agile Principles and the importance of a Lean-Agile mindset. Establishing this foundation will greatly enable the team to address future challenges on their path to Relentless Improvement. I like to visualize the change that an ART can handle as a big bubble. You want to push hard enough to move it forward, but not so hard as to burst it. That requires you having a finger on the pulse of the ART so you can focus on the areas of delay and impediments.
11. Question: Where does a lean/agile change advocate start in their journey to SAFe (really new to SAFe). I do not have support internally yet, but am seeing it work for friends/competitors. What can you do to prepare to become an internal evangelist?
Michael Robertson: I’d first suggest you gain some foundational training from a SPC you trust to get you started on the right path. You can also reach out to the SAI SAFe community to find groups you can learn from and a mentor who you trust. To aid in internal transformations, you can buy, rent, or hire qualified SPCs who can help you on that journey. As discussed in our presentation, who you pick as an SPC is very important. This journey is very rewarding if you get a start with the right instructor/coach/mentor.
12. Question: As we’ve started implementing SAFe, we are getting more transparency internally between IT and business — and have more visible metrics. This has exposed long term issues that weren’t visible before. Managers frequently blame these issues on the SAFe implementation. Have you encountered this before and how did you respond?
Michael Robertson: SAFe is a framework. What you do with it is up to you. If you find people are blaming the framework, it’s likely they do not really understand the root cause of the problem they are facing. This is where a well run Inspect and Adapt event can help you uncover the perceived issues (this requires transparency and trust), and then through a Problem Solving workshop, identify the root causes and potential improvement items to address the root causes. That will take the hand-waving and finger pointing out of the equation.
13. Question: I would love to see a webinar on getting started on the SAFe path.
Phil Gardiner: Great idea! To get started, I can recommend Scaled Agile’s collection of videos as well as this presentation I made on Tips for SAFe Success. In addition, you might want to read my blog Tips for Getting Started with SAFe.