Dean: My degrees are in aerospace and biomedical engineering, so I see myself as a systems engineer dedicated to software. In one form or another, I’ve spent my entire 40+ years career being responsible for software and complex systems development.
Cliff: I can see the imprint of that: SAFe seems to have a systems view of things.
With regard to your origins, you created RELA and Colorado Medtech.
Dean: In 1977, I founded RELA, and later absorbed the publicly held company, Cybermedic. The melding of those two organizations resulted in Colorado Medtech, also public. That was my first 20 years as a CEO, we built complex medical devices and other fun stuff that included one of the coolest adventure rides on the planet for a major theme park. I became a software quality methodologist by necessity because we were building systems that could literally save people’s lives, or if defective, could kill them. Since then, the focus on software quality has been a driving passion that informs everything I do. One of the reasons that I so enjoyed the transformation to Agile—especially after starting with eXtreme Programming—was the intense focus on the quality of code.
My exposure to Agile came through XP first and Scrum second, and I saw two things that I had not seen earlier: in XP a set of courageous software practices that were technically sound, and in Scrum, a simple and lightweight project management method. I thought that the two applied together were really cool, but I immediately noticed a clash between the user communities. Technically, I never really understood the basis for the competition, because to be effective you have to have both approaches. But methodologists don’t agree with other methodologists.
I’ve also been involved in Lean throughout my career. I was chairman a company that made a lean version of MRP [Material Requirements Planning]. Colorado Medtech had a manufacturing capability, so I also cut my teeth on Lean manufacturing. I attended a workshop from Goldratt on the Theory of Constrains, learning from Goldratt himself. Lean helped save a division of our company that was critical to our ultimate success.
Fast-forward to the present day where we find ourselves building the world’s most complex systems with this incredibly robust body of knowledge that includes Lean, Product Development Flow – Don Reinertsen – Agile, XP, Scrum, and Kanban. SAFe integrates and builds on that pool of knowledge to help address growing systems complexity. And after all, what software developer today should not understand all of these aspects? That is one reason that you see some of heat around SAFe; we don’t see it as a zero sum game. It’s all good. In fact, the next version of SAFe will incorporate kanban for teams, in addition to Scrum and XP, bringing optionality, balance and integration of the best of the best to the team’s choice of approach.
Cliff: As you pointed out, there seems to be quite a division in the industry. I don’t think that is healthy. Being from the same time period as you, I see all these things as different schools of thought that overlap in terms of ideas. These recent approaches do seem to complement each other. There is a long view that many people need to see.
Dean: Your website reflects the larger perspective, which is why I agreed to invest some time in this interview. I don’t usually engage in defending the framework because it speaks for itself through the website, scaledagileframework.com, and the case studies. You don’t need a methodologist’s or service provider’s opinion about it, everyone can decide for yourself. There is nothing hidden.
For example, about a year ago, a blogger was criticizing SAFe. That’s fine; there are plenty of improvements to be made. I criticize it myself. But he wrote that he could not figure out what he didn’t like about SAFe and then he realized that it was because there were no people in it. To me, that is like looking at the Eiffel Tower and seeing no iron. When you look at the Big Picture and click through to the articles behind it, you will see more people than anything else.
To simplify SAFe, I’ll share a discussion that happened just yesterday with one of the world’s largest software companies. They have some enormous challenges in a really large program—involving 400–500 developers and stakeholders from many aspects of the business—and are looking to SAFe for help. Absolutely mission critical. I said that the first thing we could do is organize, train, and empower Agile teams. Second, communicate the mission, provide some UX and architectural guidance for consistency of purpose and usage, and then let them define it, design, it, plan it, build it, validate it, and gather customer feedback in a continuous series of two-week iterations. And finally, we facilitate largely face-to-face planning, feedback, JAD and problem solving sessions for the entire program, every ten weeks or so, on a fixed cadence. How could that not work?
“There are at least three hundred thousand
Agile practitioners using SAFe today.”
When you look at it in such a simplified form, you wonder whether criticisms of SAFe are based are on its fundamental constructs, or misconceptions, or perhaps the fact we are in a competitive marketplace for thoughts and services? SAFe is clearly a disruptive change to the industry. But SAFe is built on Agile teams. Period. There are at least three hundred thousand Agile practitioners using SAFe today, who were previously locked out. They were living in waterfall SDLCs. Just last week someone told me that there was a time when they could not use the word “Agile” in their company. Of course they use it now with SAFe. For many, their organization’s very survival now depends on it. We hear things like: “You’ve given us a wee bit of hope for this company,” and, “It used to be easier to write software that didn’t work than it was to change a requirement.” We changed that with SAFe.
That kind of personal feedback, along with the business results, are what motivate us every day. When we hear controversy about the method, we look at the measurable results companies are getting, see what can be improved, and move on to the next revision. And because SAFe is a work in process, we don’t get all emotional about it, rather, we learn and adapt. If I remember correctly, there’s an agile principle that speaks to continuous improvement, so I assume that applies to methods as well.
Cliff: One of the objections seems to be that SAFe is very prescriptive.
Dean: SAFe documents a set of proven success patterns. For instance, the SAFe Big Picture depicts teams iterating and delivering value every two weeks, and every so often—8, 10, 12 weeks—they check in with their end customers and larger stakeholders to validate the net accumulation of those iterations. Then they run a larger Inspect and Adapt workshop at the Program level to address the larger issues. Is that prescriptive? Sure, but can you imagine that you shouldn’t do that?
What’s more, XP and Scrum are very prescriptive as to how the teams do their work. Clearly, we need Agile guidance for people above the Team level, because it takes more than development teams to deliver end user value. Sometimes when you have a headache, maybe you need to take an aspirin. Might help with the pain.
Cliff: I think the push back is, why tell them that it has to be a certain number of weeks?
Dean: When someone interprets SAFe so literally it usually means they haven’t taken the time to click beyond the Big Picture to learn about the actual intention. For instance, if you click on “Develop on Cadence,” you’ll find the following: “ … while the Big Picture illustrates five sprints per program increment, that is arbitrary and programs can pick whatever cadence that best suits their abilities and context”. That’s guidance around a principle, not a prescription of how many aspirins to take.
And by analogy, can you fully understand a software system by simply looking at a sketch of the domain model? Obviously that’s not enough to reason about the underlying system. So it is with SAFe. The Big Picture is the domain model, but the principles and implementation lives deeper.
Cliff: It looks prescriptive if you don’t click through and read it. But what you are saying is that there is a lot of judgment in these things.
Dean: Absolutely. It’s just a framework.
Cliff: Is SAFe hierarchical?
Dean: There has to be a top of a picture and a bottom. Where does strategy come from?
Cliff: Strategy is inherently hierarchical because it is the outermost level of intent, in terms of what an organization is trying to do.
Dean: Strategy and investment funding comes from the top. The teams don’t pay their own salaries or decide what business the enterprise should be in. I think there is also a misconception about what is meant by the SAFe core value of alignment. Is “alignment” management telling the teams what to do and how do it? Or is it guiding the mission for the program? What’s the alternative: no mission, misalignment?
Cliff: I have actually heard from some camps a rejection of alignment. The objection seems to be about bottom-up versus top-down, and about self-organization versus coherence.
Dean: Therein lies the crux of the issue. A key principle of product development flow is that overall alignment delivers more value than local optimization. To achieve that alignment, empower teams, and speed value delivery, SAFe fosters decentralized decision-making under an umbrella of common mission and some architectural governance.
For example, the group I spoke with last week has about 400–500 people working on a platform that processes billions of dollars of revenue and needs a major revitalization. They will be launching three or four Agile Release Trains with some 50 teams. Don’t you think there has to be some guidance that says, “Here is what we need to accomplish? These are the features that drive the most important behavior. These are the common UX patterns for the user navigating. Here is our view of an architecture that will hold it all together.” Do we believe that 500 people can independently and emergently arrive at a common conclusion? If you answer those questions truthfully, you’ll acknowledge that the vision for the new platform must be driven by the overarching business strategy. And there have to be people responsible for that. People who shoulder the ultimate responsibility for success of the enterprise. And yes, they tend to live at the top of the organizational chart.
Cliff: Is there a sweet spot for SAFe, or a range of organizations that it is a best fit for?
Dean: SAFe was designed in real world context at places like John Deere ISG, BMC, Navteq, Nokia Siemens Networks, etc.; places where there are 300–1,000 practitioners that need to collaborate on their work. Last week I was at the Scaling Agile for the Enterprise Consortium in Brussels. There were a couple of Agile thought leaders on stage who, when asked about scaling, basically said “Don’t do it. Don’t scale agile. Don’t get that big.” Seriously, can you imagine the response from the enterprise, “Sorry, it’s too late, we are already incredibly successful, and we are already big.”
If teams don’t need to collaborate on a common mission, that’s a different issue. For example. If there are even a large numbers of teams building largely independent products, the level of governance in SAFe may not be necessary – though a common way of working may well be. But if you are building, say, a field crop combine with many hundreds of people involved, and there is a virtual rat’s nest of complexities and dependencies—the electronics, transducers, computer systems, actuators, the control system that gets fed from GPS to move the combine straight down the field, the engine control unit, real time vehicle service information and status reporting—well, you get the idea. That’s what SAFe is designed for.
And in the IT and ISV world, can a few agile teams build a significant enterprise class product these days? Should we compartmentalize the development of a such solutions into isolated teams, or should we build a team of teams that synchronize and work toward a common mission?
“We sometimes work with applications so large that it takes
multiple instances of SAFe to support it.”
multiple instances of SAFe to support it.”
To meet that enterprise demand, all of the sudden, there is a lot of energy going into various methods for scaling Scrum, and some are public about their belief that they are competing against a “big, one-size-fits-all framework.” That’s SAFe, of course, but I have news: we sometimes work with applications so large that it takes multiple instances of SAFe to support it. SAFe fits well for 8–10 release trains working together, but beyond that you’ll have a different level of problem of scale, and you’ll need multiple instances of SAFe. That’s one of the reasons we put Strategic Themes in 3.0, as a connector to other instances of SAFe, and to the enterprise’s overall business strategy.
That makes SAFe a highly scalable framework, but it is not designed to solve the problems faced by just a few teams looking to align their sprints. It is the larger enterprises that need SAFe, many of which are in the process of a SAFe transformation. If you name almost any ten Global 1000 companies, SAFe is already being deployed in a number of them.
Like with any disruptive technology, there is an adjustment phase that will come more easily to some than others – think S-curve ‘early adopters,’ ‘early majority,’ etc. When SAFe is deployed for the first time, it can feel top-down to the Scrum coaches who are coaching the teams, because with SAFe their teams need to be aligned on a release train. Is it worth it? The results say so. And the teams quickly get into it as they realize they are empowered to contribute to the larger value. Working on a team of teams that is delivering enterprise value faster is simply more satisfying for all. SAFe is successful in the market for only one reason, it works. Check out the case studies pages [here] for the objective measures of the value of SAFe. Simply, winning is more fun.
Cliff: What got my attention when I first discovered it was the picture. It was the first picture that filled in the pieces of the puzzle.
Dean: Didn’t it make sense to you when you saw it? Although if we both looked at that very first picture now, I’d be a bit embarrassed. It looks like Fred Flintstone might have drawn it. Oh, I guess that was me. But SAFe evolves. Version 4 will be out this summer.
Cliff: It does make sense to me.
What are the reasons you would have multiple instances of SAFe? Is it because of different portfolios? Different sources of funding?
Dean: It is typically driven by the different value streams, business units, and operating budgets. In a really large business, say a 25B company, each business unit may have a few hundred million in revenue, and each business unit will invest a percent of that in IT and software development. But because of the organizational challenges of managing large numbers of practitioners, and because many are working in largely separate domains, they tend to naturally fall into pockets of 300-500-1,000 people, each with an instance of SAFe.
Cliff: Do you end up with a SAFe steering committee that oversees the multiple SAFe instances?
Dean: Well that’s up to the enterprise architecture and enterprise portfolio strategy, currently a bit outside the scope of SAFe. And in any case, they wouldn’t be steering SAFe instances so much as they would be defining and coordinating portfolio investments that business units use SAFe to realize.
The root cause of much of this debate comes down to a discussion about who decides what gets built. If 3-5 teams are working together in a domain they know, can they largely determine together what gets built? Probably. Would 100 development teams in a global healthcare company be the ones to decide if the company should enter a different market, and provision teams to address that opportunity? Of course not. Strategy and investment funding is a centralized concern.
Cliff: Teams are not always aware of the long discussions and analysis that take place before that point.
Dean: And perhaps we leaders cause some of that lack of visibility when we fail to have a systems, rather than a parochial or functional view – when we mandate waterfall SDLCs, when we fail to communicate a clear strategy and compelling mission, and worst of all, when we overload the teams with unrealistic and unachievable commitments. That’s why the SAFe model depends on Lean-Agile leaders, and the emphasis on taking a systems view, implementing flow, and empowering teams by constantly communicating vision and strategy.
Cliff: One hears a lot in the Agile community about culture, and being Agile versus doing Agile: What role does mindset of leadership style play in a SAFe implementation?
Dean: It plays a huge role. [Dean calls up the SAFe website and clicks on “Implementing”.] Look at steps 2 and 3 of a SAFe rollout. [They are, “Train All Executives, Managers, and Leaders,” and “Train Teams and Launch Agile Release Trains,” respectively.] Let’s start with Executives. In a SAFe rollout, the process is as follows: Over on the left here [he points to “Train Lean-Agile change agents”], everyone needs to understand the principles behind SAFe. This is what the process of building that mindset looks like: We train change agents (SPCs, both internal and external) to teach “Leading SAFe,” a course that introduces managers and executives to Lean and Agile thinking. Those leaders participate in a release planning simulation and do an exercise sprint, right in the classroom. They study the Agile Manifesto. They learn about Lean and Product Development Flow. Then they learn about Agile Teams, Agile Release Trains and how to implement an agile portfolio. The last two hours is a leadership module. We finish there, because if they are not ready to lead, rather than follow, success will be limited. Then the teams are trained in SAFe Scrum and XP, and organized around value streams that can more reliably deliver value on demand.
“Is there a new mindset required to be
successful with SAFe? Yes.”
Is there a new mindset required to be successful with SAFe? Yes. Do we achieve it? Almost always. Are we dependent upon it? Absolutely. How else would companies get the results they are getting? But you can’t see mindsets in the SAFe diagram, you gotta click!
Cliff: The site is pretty rich, there is a lot of stuff. How does servant leadership fit into this?
Dean: We use “Lean-Agile Leadership” as our metaphor, which emphasizes taking a systems view, embracing the Agile Manifesto, product development flow, creating a learning organization, and enabling knowledge workers. Operating as servant leaders is part of that.
Cliff: There seems to be a misunderstanding in the industry about some core Agile concepts, such as what servant leadership is. Books I have read on servant leadership—and indeed ways in which I have experienced effective servant leadership—stipulate that servant leadership is not about totally leaving things up to the team: it is a style of leadership.
Dean: It is indeed a style of leadership. It is not passive; it’s supportive, but it still has responsibility for outcomes. Managers do not abrogate their responsibility, or indeed their authority, just because we better understand the power, and indeed humanity, of self-organization and empowerment. We must have both, leaders who lead, and teams and programs that are largely self-organizing and self-managing.
We are now are dealing with hundreds of thousands of practitioners who have embraced a new method, indeed a better way, more empowering, more fulfilling, and potentially far more effective, a new belief system. But it is a huge danger to exclude or belittle management. Perhaps this is because they haven’t been managed well in the past; and yes, we still see plenty of that. Perhaps they assume managers cannot learn new behavior; and perhaps some cannot. But we also see the opposite, an emergence of a new form of leadership. One that is based on common principles. We see that every day too, and that inspires us to keep moving forward.
That includes new ways of planning work, which SAFe provides via large scale face-to-face planning. It’s absolutely key to what we do, and we take that to a level where some have said, “Well it’s not Agile to have 100 people planning together.” But face-to-face communication is a key tenet of Agile. For example, look at the group in the photo on our website [here]; I know that group. They get as many as 175 people “together” every ten weeks, in multiple locations, and they plan simultaneously. Every ten weeks they pull together folks from the US, India, and Serbia, they bring the business owners in to participate. See that table in the middle? Those are the business executives. Every ten weeks they spend a part of two days with the teams. Frankly, it’s exhilarating. There is nothing like it, and if you read Lyssa Adkins’ article in InfoQ [here], she attended one and noted that she had never seen anything like it. She called it an “agile accelerant.”
Cliff: That was quite an inspiring article. She talks about the arc of her thinking on it, and how it changed as she experienced SAFe.
With regard to the release planning meeting, how flexible is that. Is it always a two-day session?
Dean: Two days is very standard, but it depends a bit on scope. It isn’t just planning and alignment, its a joint requirements and design session. The group in the photo takes two and a half days, because they have a lot of folks in Mumbai with a 12.5 hour time delay.
Cliff: Does it ever take longer? When I have done release planning with teams, it can take a week.
Dean: It doesn’t take that long with SAFe. You are planning only the next Program Increment; you will do it again in about 10 weeks. Take a small bite. Limit the batch size. One big international company plans across five trains at the same time—and they still do it in 2.5 days or so, but they plan together because they are interdependent. This is one aspect of SAFe that is prescriptive: you plan together every PI. Face to face communication is part of the Manifesto. You aren’t SAFe without it.
Cliff: How much preparation is needed?
Dean: It depends on whether it’s your first time or tenth. Your first time can be more challenging. Alignment has to occur in management, development, system design, operations, etc. and it might not be present prior to the meeting. Some upfront preparation is going to be required.
For example, I was recently talking to a company that had been worried about their first big room planning experience. They were afraid that the first session would be chaotic because they were obviously not fully ready—you never really are—and people were wavering in their support. What would happen if they met for two days and nothing useful came of it? Well, the CIO was a Lean-Leader. He said, “this is going to be a really critical learning experience for us. It’s just us, so what can possibly go wrong, really? Let’s get going with that first meeting.”
Because of his leadership and what took place in release planning, they now have a common way of working, they have an aligned view amongst the executives and teams, they eliminated much of the excess work in process. You cannot underestimate the value of finding and addressing program level bottlenecks, identifying otherwise hidden dependencies, finding the way to flow, and navigating competing priorities.
Cliff: How do you deal with the organizational structure issues? These organizations must have existing functions for QA and Testing and release management and so on.
Dean: The release train is usually virtual, at least initially. Just a group of the right people who agree to plan together, commit together, execute together and inspect and adapt. A business is not going to close down the business unit and merge with IT. The DevOps IT/OM group is still going to have a director who runs operations and deployment. But they have to operate as an extended team to accomplish the mission. [Dean points to this page, and “Finding the Value Stream.”].
Cliff: So it is kind of a matrix?
Dean: It is. It typically starts as a virtual organization. In some cases—the easier ones—they are already organized on lines of business.
Cliff: Is that a natural path?
Dean: In some cases. Lets say an automotive components supplier has four BUs building four product lines. Most of the business people, devs, testers, architects, etc. are all in the BU. That’s a pretty straightforward value stream, and the virtual and the physical organization are basically the same.
But if someone is implementing single sign-on across a suite of products, or trying to improve the supply chain, you’ll have to bring people in from a number of areas and different platforms. And you can’t just create a new organization for the purpose of this large-scale initiative, even if it’s long lived. So release trains are often virtual.
Cliff: How does this compare to, say, Spotify?
Dean: I’ve talked to them a bit, and I’ve followed the method. We have even discussed SAFe for scaling further. If you look at their organizational metaphor, they have Squads, which are 5-10 individuals and a product owner, pretty much the same as SAFe agile teams. They have Tribes, organized groups of Squads that deliver largely independent solution value of a type. There are up to 100 or so people in a tribe—a fairly natural social limit, a direct parallel to a SAFe Agile Release Train. As I understand it, Guilds are basically communities of practice: they advance skill development, which we don’t model in SAFe. At Agile Israel 2014, Spotify’s Head of People Operations gave a talk about their self-organizing and self-managing Squads, and he showed some of what happened initially. Lots of fast success stories, for sure. Then he showed the initial UIs for Android, IOS, Windows, etc. They looked like they were built by different teams, because of course, they were. He noted that was suboptimum for the user experience, and then described how they went back and reworked those apps with a common UX governance, so the user experience was largely the same across devices.
We are all learning the same lessons by doing Agile at scale. Is great design emergent or intentional? Both! I have a great respect for those guys. I don’t see it as a competitive method; I see it as a different set of labels for accomplishing the same thing. We absolutely support communities of practice and what they are able to accomplish, but, for the time being, they are outside the scope of SAFe. Besides, if we added them, we’d be too prescriptive :)
Cliff: Have you ever had any organizations struggle in getting SAFe going, and if so, what are some of the suggestions that you have to avoid that?
Dean: We have a very simple mantra: if you train everyone and launch Agile Release Trains, you will succeed. If execs, business owners, architects and product managers think that Agile is just a process for developers, it’s not going to work. Everybody has to understand what they are doing and what everyone’s role is. We believe that the success of the initiative is ultimately dependent, not on the framework, not on the consultants and coaches, or not even solely on the teams—it also depends on leadership. If leadership is trained in Lean-Agile thinking, people accomplish great things with SAFe.
Cliff: Is SAFe “Lean Systems Engineering” (LSE) already out, or is that coming out?
Dean: It’s well under way. A lot of the content has been developed. For example, the principles of Lean Systems Engineering are built in explicitly, whereas they are a little more hidden in SAFe. We have defined most of the core concepts, what’s a system, a system of systems, how to express systems intent without over-specifying, adaptive requirements and design, set-based development, MBSE, kanban for teams and systems work, etc. We met with about 20 systems engineers yesterday in a feedback session, and they showed us some things we need to change. It will be available to the public sometime soon, but we have not fixed the date, because we are not sure when we will reach an MVP. But I think we are over half way there.
“SAFe is designed for large-scale software solutions—
banking, financial, insurance, ISVs, etc.”
Cliff: Why would someone use SAFe versus SAFe LSE?
Dean: SAFe is designed for large-scale software solutions—banking, financial, insurance, ISVs, etc. But if you are building a satellite, where you have the satellite itself, the ground station, the web farm feeding data to the users, then that is really a system of systems, and you have to understand how the subsystems are built and interact. How one system may impose requirements on another, and how capabilities span subsystems. It’s a different problem, the systems and subsystems and their interfaces are physical and tangible, and the notion of value streams is not necessary the right abstraction at the highest level.
The large systems builders—industrial, defense, automotive, home automation, and such—come to class to learn about SAFe and how to best to apply it to their context. But they also note that “We don’t really have a Portfolio level concern here, it’s just one really big system.” We are learning from them how to model things differently. Systems, subsystems, components, capabilities, and features all play a role.
Cliff: And you have hardware-in-the-loop testing.
Dean: You still design with fast iterations and integrations. You build in small batch sizes. But you also probably have IV&V teams who may be the only ones that can put the whole thing together and test it. You have supplier subsystems and internal programs that may or may not be using Agile. You might have a customer that says “here is the system and software requirements specification, do it like it says.” You have delivery milestones for certain. You have a whole different set of constraints. It is not as free form as it is in SAFe, but you still want the benefits of a Lean and Agile approach. That’s the challenge of the modern systems builder and we think we can help with SAFe LSE.
Cliff: Is there anything that you would like to mention about what people can look forward to?
Dean: You can look forward to the continuing evolution of SAFe. The next release, SAFe 4.0, will be out this summer. It will include a number of new constructs and content elements. For instance, it will integrate kanban guidance for Teams, alongside Scrum, so SAFe teams have a clearer choice of methods, and can even combine them as they see fit.
And by the way, we are not so sure how well that news will be received in the Scrum and Kanban communities, but we think the teams deserve that choice. Let’s say you are adopting SAFe at a major systems builder, and you have a small group of 3-5 optics engineers, do they need a Scrum Master and Product Owner? Not clear. Do they need to visualize work and understand flow? Do they need to integrate with the rest of the system every two weeks? Absolutely.
But personally, I look forward to SAFe Version 8.0! That should be awesome. Some of the people in my SPC class asked me why I don’t just call version 4 version 8, but we all know that would be cheating. And of course, we have SAFe LSE 1.0 that will launch sometime this year, along with companion courseware.
Are there going to be multiple ways to scale, be it Scrum and others? Of course. Are we learning new and better ways to deliver bigger and better systems more quickly? I sure hope so. As of now, we are on Version 3.0 of SAFe, and it works. It has a large footprint of customers experiencing success, and a global community of consultants, partners, and practitioners implementing it, supporting it, and telling us how to improve it. We’ll keep listening and evolving. That’s a pretty good launching point for a next set of innovations.
