I have been roasted (in a very friendly way) by Arne and Erik, two great friends that I have know for almost ten years now! Arne and I met at the first Kanban Leadership Retreat on Island 2011. Erik and I met at Ericsson 2012. I have learned a lot from both Arne and Erik. They are deeply knowledgeable and are also true practitioners with solid track records. Since Arne moved to Stockholm in 2017, we get to meet and talk more regularly. In several of these conversations we touched the pros and cons of the SAFe framework. We agreed that we would need a longer discussion to properly discuss the topic, so Arne invited Erik and me, and we recorded our conversation, which went on for over an hour.
Here is the third part of the conversation. Part one and Part two will be posted on Arne‘s and Erik‘s blogs. If you prefer to listen to the whole conversation, you can download the audio file here.
Arne: I find it interesting that you say there is a big focus on training managers up front. That actually sounds really tempting to me, because what I’ve seen a lot is that the managers say:
“Okay, we want to become Lean and Agile. So we hire a Lean person or an Agile person and then try to delegate this to this person and then try to weasel out of it.”
But in fact it is a really really big investment, especially for managers. And I assume that if you buy the SAFe package it is totally clear that before you can start with the implementation you need to sit down and learn the stuff. That that sounds really smart to me.
Håkan: The SAFe framework says that all the leaders need to be trained, before we start an Agile Release Train (ART). You want SAFe? This is how we do it. You are training the leaders so that they have an understanding of the SAFe framework, before you get started. And what we are trying to emphasize in our journey is that we want the leaders to be able to actually teach this to the teams further on. Supporting them of cause. Our focus as coaches on the enterprise level is to train and coach the leaders so the leaders can train and coach the teams.
Erik: But that would be an add on in line with Toyota leadership principles?
Håkan: That’s actually described in the implementation roadmap to some degree.
Erik: That it should be train the trainers?
Håkan: More or less, yes. Or it could be my Lean leadership glasses that tells me that that’s in there.
Arne: I would like to talk about the big picture thing, because I remember last time we had drinks you were really thrilled about it. Can you explain what exactly it is and what do you like about it?
Håkan: So I think the big picture is a great selling tool for people that don’t understand how SAFe could be connected. So by actually showing how things could be connected, you are reducing the fear of just walking into something that is unknown. Which, if you don’t have the experience, can be very comforting. Someone has thought about how it could work as a system. It helps to reduce the fear among the managers about this fluffy Agile thing and that we just gonna experiment and the future will tell if we get the business results. The SAFe big picture described how it could work as a system.
Arne: And what are the elements in the big picture?
Håkan: The big picture itself is divided in three or four levels. It depends on what version you want to implement.
On the basic level it’s describing how the teams would work together if you have multiple teams. This is kind of the basis for organizing an Agile Release Train. That is if you are at least 50 people. Otherwise you don’t need SAFe. It describes how the teams would interact and the timeline for the basic events for team level.
And then you step one step up, there it shows how the interactions between teams would look like. It also describes the roles needed to make it work.
On the third level, it shows how multiple Agile Release Trains interact and who could be involved in doing that. How would it look like in terms of an iterative fashion? How would that look like? What do you need and what could be additional things that you need to think about?
And then on the top level, which could be third or the fourth level, depending on the implementation. This level ties business strategies into execution for the different teams and Agile Release Trains. It is based on what SAFe call Lean Budgeting and a flow of Epics, related to your strategic initiatives or themes. If I would compare to Klaus‘ Leopolds different flight levels, you would have a team level, then you would have a multiple team level, then you will have a portfolio level.
Arne: And who creates this big picture and what do you do with it? Do you put it on the wall, or do you use it for trainings?
Håkan: Okay. So maybe you’re referring to the big picture that I created that was a compliment to the SAFe big picture?
Håkan: I can describe what I created in addition to the SAFe big picture. There are a lot of the things on the SAFe big picture and it shows one, or a couple of iterations, but not necessarily how it would play out in calendar time. What I did was to try to illustrate for people how SAFe would play out during the year. So I took all the different events in our organization, including pilot Agile Release Train and other “Agile Release Train”-like organizations that interact. Then we tried to show the flow in between these different parts of the organization
Arne: So you tailored SAFe to the organization you are working?
Håkan: I took the concept and I kind of just played them out for a year. So instead of describing a couple PIs and kind of looks like it ends there. We played out what will be the the different program increments, PIs, over the year for Folksam. We mapped the events and how they connected to how we make decision on a strategic level – Budgeting, quarterly reports, and when we should do inspect and adapt and so on. All this to show how it all connects on the different levels.
Arne: Was that Håkan magic? That’s nothing that’s prescribed by SAFe?
Håkan: No, it was just playing it out in time and illustrating it. And I’m a big fan of visualizing stuff. So making a picture sometimes helps people to to think in new ways.
Erik: I agree. To have something like this big picture, however less or complex it is. It’s good to have it on on one sheet of paper. I’m used to the Larman and Vodde big picture. I don’t remember what it’s called even, but we had it in our journey at Ericsson. It shows a number of business requirement areas from the outside in. That was a very simple scaling mechanism. You take a combination of Scrum and Kanban, Kanban for the flight levels, and you can use Scrum or Kanban on the team level, and then you have an enterprise level Kanban board where you structure your lanes according to business needs to have that as a very simple scaling mechanism. So I think visualizing that and seeing that makes things really really simple.
Håkan: And that’s more or less what I tried to do. The big picture actually shows SAFe play out over a year, not just like a snapshot how it’s connected at one point in time. A lot of the stuff in SAFe is of course then very general so it’s kind of: here’s a snapshot in time how would it look and how would it interact? If you make a decision here on a strategic level, how is that then executed over the year? And maybe where you have synchronization between different trains, how the features would be planned in different parts of the organization? And illustrating that the more times you go through different trains and you have dependencies between different teams and trains the more lead time you typically generate. One of the goals of this implementation is to shorten the lead time. The Big picture kind of shows some of the problems.
Erik: Curious question: Do you currently have component teams, meaning teams that are working with a certain technology area?
Håkan: Yes. Is that our current context. And we are now trying to educate the organization on the downside of having that setup. One of the great tools to do this, which is I think something that they borrowed, is the dependency board. SAFe use it in the PI Planning (big room planning). This is a very powerful thing to most people, if they haven’t really understood it before, the dependency board will really help. They can take a look at all the strings that you will typically have in the organization and they will realize how many dependencies there are. That would affect lead time.
Erik: Do you see that as a gateway to move to a more cross-functional feature teams, which could go into all areas, because they have the competency from the beginning?
Håkan: Yes. It’s described in the SAFe framework that it prefers featured teams. But of course most organizations are not there in the beginning.
Arne: Erik, you mentioned earlier the Shu-Ha-Ri principle.I was curious about your take on how SAFe fits into those three steps. Maybe you can briefly explain what it means?
Erik: Sure. Let‘s go into eastern wisdom here. I tend to prefer that the Anglo-Saxon or American version of it: Learn the game (Shu), play the game (Ha), redefine the game (Ri). So first you need to learn the rules of the game, then you need to practice, and then you play the game a lot. And having done that, you can start redefining the game to take it to the next level. And as I said earlier, I think my fear would be that if there are so many rules to the game (like in SAFe), you might just get stuck in the first phase, which is learning the game. You might ultimately get to play the game and practice the game, but then there is potentially a new version of the framework coming out, and it’s getting more complex. So you never get to redefine the game yourself. You’re always playing by someone else’s rules. And that would be one one fear that I have, bearing in mind that I never practiced the SAFe framework myself. I tend to like Okham‘s razor: don’t make things more complex than they have to be. Or the Einstein dictum that you keep it as simple as possible but not simpler. So that’s my basic philosophy of life and probably that’s also where the dissonance between me and SAFe comes from .
Arne: Maybe you can Marie Kondo your SAFe. For every element you ask: Does this spark joy? And if the answer is not yes, then you thank it and throw it into the bin
Erik: Modern Eastern philosophy of life. Fantastic.
Håkan: Yeah. Why not. And I agree with Erik’s fear. If you just focus on implementing the framework, it’s probably not going to give you that much value. And that’s also why when we train we put a lot of emphasis of understanding the principles.
Erik: Curious question: How have you done a down selection? Have you picked parts already, a subset, where you start from?
Håkan: Some explicitly and some implicitly. So the explicit decision that we made so far is that we will not use what they call the large solution part of the SAFe framework. So we are using the portfolio implementation and that’s a way to not make it bigger than you need it to be. We are definitely not implementing at the moment things like the Lean UX part of it. The organization is not ready for that. We are moving in the direction of the lean business case on the portfolio level and on the financial and funding level.
Erik: So the Lean Business Canvas?
Håkan: It‘s a hypothesis based epic description, so you do it more based on the business value that you want. And you frame the hypothesis about how you think you would be able to achieve it. And then you need to test toward what you deliver. Are we actually achieving the results that we were expecting? We are moving in that direction. So, yes we select the things that we think could work in this organizational context.We also try to add things that we think are missing like the whole Hoshin part of how you actually work in your organization about goals and improvements. We will most likely add things like a Toyota Kata or a Four Disciplines of Execution type of framework to work on continuous improvements.
Erik: So always think for yourself.
Håkan: Of course!
Arne: I have one last topic I want to discuss and that’s tools. I vaguely remember when SAFe started it had a strong connection to one of the big tools. Was it VersionOne?
Håkan: It was Rally Software.
Arne: Is it still a thing? Does SAFe come with a tool?
Håkan: I’m not absolutely sure about the history here. I come from a Kanban background, so I’m leaning more towards tools should be visual boards with sticky notes and things like that. But I think Dean Leffingwell was a part owner of Rally Software so there’s a strong connection. And Rally Software also implemented SAFe in how they developed their tool. The SAFe Framework does not include any tools like that. However there are a lot of software tools that are supporting SAFe.
Arne: I’m learning a lot about right now about remote work and distributed team. Is there anything in SAFe about this? We know that it’s not perfect but I was wondering if Is there a section about how you handled the remote teams or you should not have remote teams or anything like it. Because it feels like it becomes more and more of a topic for four companies.
Håkan: I would say SAFe definitely prefers face to face communication.
Arne: Well that were all of my questions. Do you have anything you would like to add?
Erik: Well I think it’s always good to have the influences and the inspiration from several sources. And SAFe is definitely one of them. I would personally recommend people to go check out Larman and Vodde what they wrote ten years ago. I think the scaling thing is basically a solved problem by the brown book. Very pragmatic very much like try this avoid this try this we’ve seen it working in several contexts. It seems to be a pattern. Avoid this: We’ve never seen this work in any context. And it encourages you to think for yourself and try and experiment. So that would be one thing for me to investigate and be curious about what later turned out to be LeSS, the Large Scale Scrum framework, because they are in a sense trying to address the same kind of need similar needs but not exactly the same but in slightly different ways.
Håkan: That book is a great book. I really like it and the concept of trying things out is really valuable. And I think you need to also dive into things like what is your strategy for becoming better? So I really like the the book This is Lean by Niklas Modig and Pär Åhlström. And then of course the Don Reinertsen books are also really good. And then complement it with Toyota Kata or Four Disciplines of Execution.
Arne: Okay. Awesome. Thank you very much for your time.
Erik: Thank you for having us.
Håkan: Thank you!
Fantastic stuff, in questions, answers and reflections from all 3 of you, across all 3 sections!
A few things I’d like to either build on or clarify:
1) I *love* how you’ve illustrated the Big Picture over a longer time than 1 PI. You know I’m with you in the strength of visualisation 🙂 And that you’re understanding as a system visualisation.
The other thing the Big Picture does is act as a Table of Contents – on the SAFe website, every element is clickable and leads to guidance. Why? Because most of that is in response to customer execs asking “Yeah, but how do I *do* that?” Very much in the ‘Learn to Play the game’ state, which you have to emerge out of. And it’s a real risk that orgs don’t, particularly when guided by consultants without your maturity.
2) Train the leaders – I haven’t taught the v4.6 of Leading SAFe, but the very first slide in 4.x used to be the Deming quote: If you can’t come yourself, don’t send anyone. It’s front and centre that as a system, the responsibility is on management to own and lead the change, and to create & sustain an environment where teams can do the great things we know they are capable of.
3) Regarding ‘focusing on learning new versions of the framework’ – this should only be a concern to consultants and trainers. Implementing orgs should start with this as a stepping stone and then follow their own evolutionary path. If they want to take in new/changed ideas from more recent versions of SAFe (or any other source), that’s great, but it’s evolving their own brand of Ways of Working.
It is worth noting though that most of what’s new since v4.0 have been clarifications based on real world feedback of misunderstandings, strengthening elements that orgs tended to skip over, or filling in gaps where Dean & co got enough “what goes *here*?” questions. I don’t think anything’s been invalidated since December 2015.
3) Tooling – yes, Rally were the first tool to support SAFe, largely because SAFe has much origins in the in-house Agile practice that Rally had. PI Planning is an evolution of Rally’s Big Room Planning, abstracted from that context. SAFe is to Rally as Lean is to TPS. Dean served as Rally’s methodologist for a while. These days, other fine tools are available (ask me for details about fine… and failing). And if your Release Train is co-located, absolutely I’d be looking at stickies on walls first and foremost (unless compliance insisted on audit trails).
Sidenote – when Rally got taken over by CA, CA rebranded it “CA Agile Central” (ouch). Now CA have been bought by Broadcom, I believe the original name is returning. Again, ping me for detail on that story as I’ve been living it the last 9 months.
4) Dependency boards – one of the biggest drives towards feature teams comes when you visualise the dependencies. When that board in PI Planning looks like an explosion in a sweater factory, you realise you’ve got a problem with your organisation design.
5) Other sources – absolutely. It will be no surprise to you & Erik that my own practice has very strong threads of Reinertsen, Toyota Kata, This is Lean, 4DX (I got this from Eric Willeke when we were colleagues) and Stephen Bungay running through it, all informing how I coach SAFe. I have a white paper due out soon that explicitly describes PI Planning in Mission Planning terms.
Once again, fantastic conversation that I’m super happy we could listen in on, with fair yet respectful skepticism.