Interview with Dean Leffingwell about SAFe (reprisal)

We know that information technology, and new hardware and software technologies are changing the way the world works, and at the heart of many of those systems—from banking applications to satellites to automobiles—is software. Software has become more and more complex; it requires more and more people to build a good system, and those folks need cooperation, and guidance.

Since 2001, we’ve had the Agile Manifesto to guide us, which unlocked the power of the self-organizing Agile team. Today we simply want to apply that at scale so we can bring the latest practices of Lean and Agile to meet the challenges of the large solution builder, and also help all those teams experience the personal and team benefits of Agile development.

That’s a fair question. If you look back to what we just learned in the SPC class, you’ll recall that there were a couple of threads related to that topic of “big,” one of which is that when you have a relatively small number of teams— maybe five, seven, or even fifteen—that need coordination, the Agile Release Train (ART), by itself, was seen by many in the class as a great way to organize those teams. And managing multiple trains is what the framework is optimized for. But there were others who are very concerned about the Portfolio level, and still others, needing to manage thousands of IT workers and development workers towards an end objective. So you see pressure on all sides. You see people who probably don’t need SAFe, others who find the Agile Release Trains and Portfolio level to be highly effective and efficient and still others saying that SAFe doesn’t even handle the complexity they already have.

As SAFe is right now, I wouldn’t consider it to be overly big and complex. It is tuned for the needs of people building fairly complex systems. But as you saw, there are systems bigger than SAFe was designed to handle, and we are continually pushed to try to help address those challenges as well. We’ll see much of that, along with more modularity, in the next release.

That’s not a trivial question, and there’s no pat answer. There are certain things you know; we need team and program content authority for fast de-centralized decision-making. We need to have people in roles (it doesn’t matter what their titles are) that can take a large initiative, break it into smaller initiatives, manage the small initiatives, and deliver them. You have to have that.

You also have to have continuous integration. We sprint, and we have short iterations—typically two weeks in length, but you saw this week that current teams use one, two, three, and even four weeks of length. We like shorter. But teams must iterate. They must also focus on full system integration, continuous where possible. We also we have those critical PI [Program Increment] boundaries, and those include large-scale face-to-face planning.

Our job as managers is simply to create an environment where the people that do the work can plan the work. That’s not optional. Lots of other roles and responsibilities where you use Kanban, how you apply XP, what prescription do you use for moving things from initiative to action, that’s your decision. You know, we don’t opine on much of that, or we have pretty light-weight guidance, but that’s the crux of the issue. If the teams are working together, they are integrating, every two weeks there’s new value, and they cooperate in building ever-larger amounts of value suitable for release, then they’re going to be SAFe.

But you can’t just pick some words off the website and say, “Well, we call that an epic now, or a feature, and we’re SAFe,” because it’s really the systematic behavioral change that delivers the value.

That’s a hard one for me to answer because there are certainly a variety of them and I don’t track them that closely. I saw a presentation headed for XP2015 that compared another framework to SAFe and noted, “In SAFe, you can only ship every ninety days.” In fact, nothing could be further from the truth. So one can only imagine how or why that’s promoted.

Because in SAFe you can do it every two weeks?
No, you can Release Any Time, every day if needed. The phrase on the Big Picture say “Release on Demand”. The development cadence is decoupled from the release cadence. Decoupling those provides the degree of freedom teams need to be able to manage their own activity without being held hostage to a particular release cycle. We have SAFe shops that shift back office software three, four times a week. And others that maybe ship a big fat desktop client only annually. That’s not the primary concern of SAFe. That’s a business concern. The concern of SAFe is, do we have assets that are releasable?

I don’t think they are at opposite ends of a continuum. Scrum is a practice that’s designed for small teams with three roles. And that can scale across the organization, horizontally, but not vertically. There are no roles above that.

RUP had a set of practices, designed for iterative and incremental development. It could be applied small or large. SAFe is neither of the above. SAFe is Agile iterative and incremental. It scales from small teams of teams, to literally thousands of practitioners. You saw in class, that there are people from enterprises that had thousands of people using SAFe.

Scrum does scale, but horizontally, not vertically. There’s no roles or procedures or guidance for anybody above the team. RUP had a lot of practices, and many roles were well articulated. But it really did start to codify iterative and incremental development.

SAFe is quintessentially Agile, it’s based upon Scrum at the team level, but brings the roles and responsibilities of the other players that we need. In a big shop, only 60% of the personnel are doing develop and testing. The rest of people are engaged in defining that work, integrating that work, deploying that work, governing that work, and making sure the quality is there, for the user and any governing bodies.

So, those folks have a real role, and if they don’t understand Lean and Agile, they’ll operate down a traditional path and Agile will be foiled. So we take Scrum and XP at the Team level and say, okay, but we need Lean and Agile practices for others as well. And here’s some different responsibilities that will help you support those Agile teams.

Now, let’s talk a little bit about history. Both RUP and Scrum were invented in the late 90s. Scrum was invented for small teams— teams of 7, plus or minus two—working together to address a certain set of problems. RUP was used at places like Ericsson Corporation and telecoms where there were hundreds and thousands of practitioners.
RUP freed the industry from Waterfall development, recognizing that you can’t just build it right once. RUP has iterations in it. It moves through logical phases——of exception, elaboration, construction, etc.

SAFe is a flow-based system. SAFe is a model that says, “We build on Agile at the core, and we want our iterations to be as small and fast as possible.” But these skills then need to be scaled up. So I think RUP was a point on a continuum from Waterfall to quintessentially Agile. SAFe is quintessentially Agile, at least to the extent that you can bring continuous integration up and down the stack.

But SAFe can be no more Agile than the CI-practices of the teams building larger systems, and as we know, the CI practices of large systems are not trivial. This is not one single application. This is distributed development of distributed applications that might have four or five hundred people committed to a code line. That’s not typically an instant, continuous integration model. Therefore, these patterns that we have for two weeks and ten weeks are designed to help teams have a forcing function around ‘we have to integrate the full system, at least by then’.

But SAFe doesn’t say integrate only every two weeks. It says no matter how big the system is, you have to do it at least that often.

No, but as I mentioned, we run SAFe at Scaled Agile, and we’re just 3 or 4 teams. We still have to coordinate our efforts, and we find that if we don’t plan on cadence, and commit to each other what we’re going to build, then we don’t have a forcing function to decide what the strategy is, and entropy and mis-alignment sets in. We all have a different view of what’s important. So those synchronization points are as important for us as they are for the larger enterprise.

But it’s not just an issue of scale, it’s an issue in that case of how far out of alignment you might get over what period of time. The PIs are boundaries that we use in enterprises to say, “Hey, every 10 weeks, we’re going to have a handshake.” We’re going to stop and say, “This is good stuff we built so far. Let’s talk about what we’re going to build next, and let’s commit to that new course of action together”.

Of course innovation doesn’t happen only in the course of a single iteration. It’s not that you don’t innovate for eight weeks and then you stop and innovate. The reason that’s there, however, is that Agile delivery is pretty tyrannical. Right? Every two weeks teams have to deliver new enterprise value. And that can cause a certain element of risk aversion, because in a large program, everyone is dependent upon every team, every iteration.

So how do you make a time when you can stop and take a few risks, or think about things more deeply, or think about a thing that maybe you are not going to do now, but you want to collaborate with your buddies and then decide, “You know, we probably have to move to JBoss…”, or “Oh, there’s a better class library for this!”. You need that thinking time, so that innovation and planning opportunity is an opportunity for thinking, and an opportunity for free association, it’s an opportunity to work with others you otherwise couldn’t.

You know, Agile innovates fairly well natively via immediate customer feedback, but customers don’t drive innovation. Producers drive innovation, so if you don’t leave an opportunity for that, a purposeful time slot, the tyranny of the urgent sprint, and the tyranny of the current customer demand, will overwhelm your full intent to innovate. It’s just really hard to do that in an always-on development environment.

Well, if SAFe was implemented right, they will be Agile, okay. But it’s possible to try to fake a way through it. Well, you know what our answer to that is: This is a leadership-led initiative. So we address that directly.

We had very few precious hours in our Leading SAFe two-day class. And the thread of decentralized-making, creating the right environment, that took more than two of those hours. We also spent hours talking to the managers and executives in this room about how to help other managers and executives make sure that this is not a way to pretend to be Agile. Otherwise, You won’t get the results.

Lean is led by leadership. SAFe is led by leadership. There’s no substitute. We need our leaders and managers. And while some might perhaps want a jerk manager or two to go away, they are people just like us, doing the best job they can, but with additional responsibilities. And as Deming noted years ago: “people aren’t the problem; the problems are with the system and only management can change the system”. So, we don’t ignore them, we bring them in right away and say: “Hey, take a Lean-Agile leadership position, and this is all going to work a lot better for everybody.”

They’re not spoon-fed. The Product Owner has the authority within the bounds of whatever the team is responsible for building. That is their domain of concern, and they have the authority to work with the team to decide that. But clearly, the decision of what the full system does is not only a local concern. POs are part of a larger team, one that includes product Managers.

The alternative doesn’t really work. Let’s just say one builds a first Agile Release Train, maybe ten teams. So do ten individual product owners each decide what they’re building? Of course not. So you have to collaborate around that, and you need some decision-making authority. In Scrum, that’s a Chief Product Owner. In other environments, consumer environments, ISV environments, etc. — Product Managers are the people that are able to make these tough, system or product level decisions. And if they collaborate well with their Product Owners, they’re going to do a great job. And if they don’t, they’re going to be an impediment.

So no one is a Product Manager? Or …
They are called Product Managers in SAFe. They own the Program Backlog. That’s a critical role. It might not be called that. It might be something else. It might be a Chief Engineer or Chief Product Owner. That’s just a role title; it’s the responsibilities that matter.

Okay, so a person can be Product Owner in a local team and still take on product management?
Well no, they’re part of the product management team, so what we describe is that the team of teams on the left side of the picture is product management working with product owners. So there is a collaborative effort that acts like a steering wheel. And why would anybody want to take that role on for the team? Because that’s their part of the steering wheel. Because without that role, then it’s product managers saying, “Here’s a feature and how to build it.” Or, “Here’s a feature and it’s not discussed or elaborated, good luck with that!” Who does that interpolation? Who can go back to the Product Manager or go directly to the customer in the ideal case and get that feedback? That’s what Product Owners are for. I love Scrum Product Owners! I’m glad they invented that. I don’t think I could have invented SAFe if we didn’t have product owners in Scrum.

Okay, so let’s take the UX case. Let’s say I’m building a fairly large system and I’ve got 70 or 80 developers. Those UI implementations have to be done by the team, there’s no question about that. We don’t council that there’s a UX team that builds all the UI. Absolutely not! The question is: what overall model is designed for the best user experience? Can 10 teams individually come up with the general case?

So what we described in a typical case is that there’s some UX design guidelines, style-sheets, some design elements, splash-screens, and wire-frames that track ahead of implementation. Typically, an individual or two, sometimes even a small Scrum team can do those wire-frames, but they don’t do the implementation, it’s too slow. If every Agile team did their own UXs, you would go really, really fast, but you would end up with an explosion of UX experiences. Bad for the user. If you’ve centralized UX development, you’ll have a really nice UX experience, but it will be delivered too slow to market. Bad for the company.

So what’s the U-Curve optimization? Some amount of guidance? It’s the same pattern for architecture,? If we’re implementing single sign-on, there’s lots of ways to do it, lots of different protocols and implementation options. Wouldn’t it be nice if we just shared a common one, say, SAML for example? An Architect can say, “Well, let’s just pick one and all teams can use the same protocol and common code”.

So what if one representative from each of those ten teams would just gather every week and decide on UX stuff in a Scrum of Scrums?
That depends a lot on context. And if it works, they should just do it. It’s a framework after all, not a prescription. But what you find is—if there’s a lot of UX in their world, there may or may not be experts on each team that are great at that, so you just simply have to have some guidance.

What I’ve seen in larger programs is typically only a person or two— the most I’ve ever seen is three on one Agile Release Train— just working on the wire-frames, the overall user experience, and helping ensure that when Team A implements Feature B and Team C implements Feature D, they use the same type of controls and the transition from screen to screen is smooth and the data goes along with it. That takes gestalt! You have to be able to step back and say, “What’s the user experience I’m striving for?” That absolutely spans features, teams, and components, so you have to have some governance if you want a good UX experience.

But the teams can, if they want to, self-organize around bringing that…
Absolutely! But UX is quite a specialty skill and many teams get really frustrated by the process of usability testing. That’s because every usability test says you need to change things. So it can be quite frustrating for many teams to do that in the course of each sprint. So the groups I’m working with typically, but not always, have some guidance. And they mostly want to quickly build and deliver something that works.

I wish that bright people will continue to try to address the problem in large-scale application development in such a way that we can improve the outcomes, not just for the end-user, but for the people doing the work. I think it’s been a bit of a crime, that we work so hard in development and IT, we develop amazing systems, and yet we often go home time feeling bad about the result, Stakeholders aren’t satisfied. Deadlines are missed. Quality might not be there. I just think that’s unfair. So my wish is that we can all go home feeling great about that PI. For that, we need to change the system. That’s what SAFe is for.