Lean-Agile Roast: SAFe — Part 2
SAFe Pros & Cons with Arne Roock, Håkan Forss & Erik Schön
Arne Roock and Håkan Forss are good friends of mine and incredibly experienced Lean/Agile organization coaches who have made substantial contributions to advancing the Lean/Agile/Kanban community. Since Arne moved to Stockholm in 2017, we get to meet and talk more regularly. In several of these conversations, we touched on 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 Håkan and me, and we recorded our conversation, which went on for over an hour. When we had dinner later that evening, Håkan said that he felt like he had been roasted (of course in a very friendly way). Although this was not our intention, we all agreed that it would be a great concept :-) Here’s the second part of our Lean-Agile Roast on SAFe. Part one and three are posted on Arne’s and Håkan’s blogs. If you prefer to listen to the whole conversation, you can download the audio file here. (Part 1, Part 3)
Arne: And, Erik, with your skepticism about SAFe do you see any good parts?
Erik: As we talked about, there’s a lot of good stuff. There’s a full set of goody bags and what I hear from Håkan is that it has lots of good training material. So you can cherry-pick the stuff that you need. When the organization has done a self-assessment to identify its needs and is willing to change and learn, then you can pick a lot of goodies.
Arne: One thing I hear consistently from different people is that big room planning is super helpful, and whether or not you’re using SAFe a lot of people believe that big room planning would benefit the organization a lot. Do you have any experience with that yet?
Erik: At Ericsson we never tried big room planning. We tried to remove the need for big room planning by having cross-functional, co-located, long-term stable feature teams. These were all-encompassing end-to-end teams that were doing all of the work from customer needs via system architecture to delivery. They were allowed to go into all parts of the code in an internal open-source model. That eliminated the need for big room planning completely. Of course, you might have bigger features that need several teams to collaborate. But then there are other ways to set up that collaboration for big features. We used a “feature anatomy” which is a simplified system anatomy: you take the part you’re working on and show all the dependencies between the different capabilities that you’re trying to build. So there are many ways to skin a cat.
Arne: I guess that’s one concern about big room planning that it helps you manage dependencies, but it doesn’t really help you to get rid of the dependencies. It’s just putting a band-aid on the wound.
Håkan: So we recently did our first real SAFe big room planning or PI [Program Increment] planning. And one of the realizations, when the teams were doing this, was that they were not organized as teams in the right way. That became obvious when they started to actually do the planning because there were a lot of dependencies and so on. So they actually started to self-organize and move people around during the big room planning. So I think it depends on how it’s facilitated and how you think about it. And the real magic about big room planning is not the planning part. It’s having people in the same room. And as we know from the Agile Manifesto: face-to-face communication is the most effective way to communicate. And big room planning facilitates that, not just isolated on a team level but you also bring in the business people and other stakeholders. For the stakeholders in our instance, it was a big revelation. They started to understand the complexity of doing the stuff that they want to have done. And therefore you have a dialogue and you start asking yourself: OK, or maybe we can simplify things and we can focus more on the 20 percent that brings 80 percent of the value. You will have a lot of these discussions that have been really really hard to have in other contexts. So, meeting face-to-face and also having what SAFe calls a “takt” or a cadence in the whole organization where planning that spans multiple parts of the organization takes place at the same time. So if you need someone, you know that you can just go and grab them and you can discuss. This is the really good stuff about the SAFe framework. It’s about the cadence and then you also do the planning at the same time. That’s really the thing that it adds to agility. And of course, this is nothing new. It comes from applied systems thinking and the MIT guy [Peter Senge], who wrote The Fifth Discipline: The Art & Practice of The Learning Organization. It was implemented at Harley Davidson for the development of their motorcycles. So it borrowed from that and they’ve combined it with the face-to-face meeting with everyone in the big room. And that’s where the real magic happens in SAFe. The rest is basic Agile stuff but packaged in a way that you can sell it to people who don’t necessarily know the details.
Arne: Is there anything you don’t really like about SAFe and that you would like to change if you had the power?
Håkan: They got the Cost of Delay part totally wrong. But I understand how they thought about it to make it simple to work. And the focus on story point effort estimation is totally wrong.
Erik: It was wrong already in 2010/2011 when we read the book [Agile Software Requirements by Dean Leffingwell] :-)
Håkan: Yeah! Because it doesn’t really work. But I do understand why it’s in there because it’s an easy way to get started with the practices. But if you don’t know the source material, what Don Reinertsen writes and talks about, and if you don’t understand flow efficiency and so on — then you can get stuck there. So you don’t move on to the next level. But hopefully, there will be an experienced guide to help them to realize what they really want.
Erik: Isn’t it scary that that hasn’t been improved since 2010/2011? Because it was incorrect then and still is today.
Håkan: Most people using Scrum and go to Scrum training also get trained on this: using effort estimation. It’s not just SAFe. So I think that’s the biggest flaw that I’ve seen so far. Except for the fact that they don’t know how to build good presentation material. Meaning the slideware is overwhelming and not really well done in terms of text density. But that can be improved.
Erik: More LEGO® figures! [DISCLAIMER: LEGO® is a trademark of the LEGO Group, which does not sponsor, authorize or endorse this blog.] ;-)
Håkan: More LEGO® :-D
Arne: Of course! I’d like to talk a little bit about Lean and Kanban in conjunction with SAFe. I remember that I think David Anderson said you don’t need to scale Kanban. You don’t need to add an extra framework for scaling Kanban, because you just do more of Kanban. If you want to scale it, the way I understand it, you can just expand whatever you’re managing with Kanban upstream and downstream. Or use Kanban at different flight levels. Do you agree with that? Is it really that simple? If people have really understood Kanban that they don’t need anything else to scale?
Håkan: Yes! So if you take out the Scrum part in SAFe and keep the Kanban stuff in there, then you have a really good Kanban implementation with all the flight levels. It is my secret plan that we will eventually take over the Scrum part.
Erik: (laughs).
Arne: But isn’t Kanban just a tiny box on the top left of a huge poster?
Håkan: No, not anymore. It’s now actually on all the levels, so Klaus Leopold would be happy. It’s Kanban on all levels.
Arne: So they have assimilated that like they’re assimilating everything good?
Håkan: Yes.
Erik: The black hole ;-)
Arne: Okay. Well, what do you think? How do you see the connection between Lean and Kanban on the one side and then SAFe on the other side?
Erik: It’s difficult for me to answer since I’m not really a SAFe practitioner. Looking at it from the outside, I can’t say that I see much of Lean in there, but that’s because there is so much stuff in there. So the essence seems to get lost, at least for me when it comes to Lean and Kanban. It looks to me from the outside as if it’s just one nice goody bag of things that you could use. But once again: if you have skilled people like Håkan or Henrik Kniberg working with SAFe then of course you would emphasize good things like Kanban.
Arne: Is there anything you recommend in addition to SAFe? I mean there is a lot of stuff already in there, but is there one book or one model you think people should also learn about?
Håkan: SAFe doesn’t really describe organizational structure. It does not give you a lot of help on how to be a true Lean/Agile leader. It kind of emphasizes one point of it, but this is not really integrated into the model. So that’s something that I think you need to add. And my personal view is you need to implement something like the Hoshin Kanri and add Toyota Kata or Four Disciplines of Execution (4DX) into the model to make this really connected to the business.
Erik: And then you’re talking about how to develop your strategy and how to make your strategy happen. A method or approach for that.
Håkan: And it’s not described in a clear way in the SAFe framework how you run your company and how you set up the organization. That’s not in the framework at the moment. And that piece is missing and you could interpret this as you are doing inspect-and-adapt only at the end of each program increment. That would be between eight and twelve weeks. And that is of course absolutely too slow. So you need a daily or at least a weekly cadence of doing improvement work as well. And that is not part of the framework at the moment.
Arne: There’s this tweet that comes up every now and unfortunately I can’t remember who wrote it. It basically says instead of trying to scale our processes we should try to de-scale our problems or de-scale our organizations. While this sounds very tempting and it gets a lot of likes and retweets, I wonder how realistic this really is. Do you have any thoughts on this?
Håkan: If you’re a bigger organization and you haven’t developed ways of how to communicate with each other and meet each other and actually have a dialogue to be able to scale things down, then it becomes harder and harder. And what I think is: having the cadence, visualization through Kanban boards, connecting them, and then meeting in big room planning can really help to make it happen.
Erik: What I have seen in several parts of Ericsson and other companies is that if you have teams that are as end-to-end as possible from concept to cash meaning delivery and customer usage and then maintenance — that is a way of de-scaling. So that part is in one sense solved or at least solvable. Then the tricky thing in bigger organizations with more complex products is when you need to have several teams to collaborate. Then you need something to make that collaboration happen. And then we’re back to interactions, collaboration, and communication, and, setting up lightweight structures for that. On a regular cadence of course. Visualization of the dependencies you have is also important. And that could be a big room planning or it could be a “system anatomy”. You need to have something to make it tangible.
Arne: I guess we all agree that most organizations are doing way too big projects or they don’t slice it into smaller batches. They plan everything in one huge batch and try to deliver this and then it becomes a huge mess because there are so many dependencies. I wonder if SAFe gives any incentives to incrementally reduce the batch size.
Håkan: I say “yes” and “no”. So the “yes” part is that they describe the different flight levels. If you look at it from a strategic point of view the portfolio level is emphasized: these are things that will take more than one PI, more than 8 to 12 weeks to finish. So it puts emphasis that on that level you should focus on things that take a little bit longer. So that’s kind of what the “no” part of breaking it down is. But then if you step down into when you actually do the PI planning for an individual train it says everything that you plan should be finished within those 8 to 12 weeks. This is what they call features. This should not take longer than a PI.
Arne: PI is a Product improvement, right?
Håkan: Yes. Or Program Increment. You could say to some degree some concepts emphasize that you should have big things. But as we know, larger organizations have a grand scheme of things they want to do. Then break it down into smaller parts is supported close to the team and on the Agile Release Train level. So it’s kind of a “yes” and “no”. And then if you put the emphasis on shortening the lead time for a feature, it would be cut it in half by delivering it sequentially instead of parallel. So it helps you in that direction as well: to shorten the lead times.
Arne: Is it part of the framework to measure lead times?
Håkan: Yes.
Arne: So that’s not something you just sneaked in there?
Håkan: (laughs) No. I don’t think so at least. There are four core things they emphasize that will be improved if you implement SAFe would be: shorter time to market, higher quality, more throughput, and more engaged employees.
Erik: It sounds like they sneaked that in from one transformation journey that we were both on ;-)
Håkan: Yes. Maybe that’s why I find some of the stuff in there to be quite good.
Arne: Interesting. How do you say: good artists steal, bad artists imitate? It was a smart move to steal everything that’s good, package it, and put it into the framework.
Håkan: I was trained on what was the 4.5 version, and now it’s like 4.6., so even the framework itself is always improving and being iterated on. So new stuff is added, and other things are removed or tweaked. So it’s not something that is just standing still. And for me as a trainer if I want to train on the latest version I also need to read up on that latest version, so I can’t just cheat my way into keeping it. I can‘t train people on the old stuff and still tell them this is the new stuff.
Erik: And that’s a bit of my fear I guess: These black hole‘ish tendencies to get all the good stuff in there. Then you expand the framework — step by step it gets bigger and bigger and bigger. So in order to learn the game, play the game in order to redefine and improve the game, it’s very hard, because there’s so much to learn. And it’s growing and growing. So there’s a risk you don’t get to the redefine and improve step …
Håkan: Sure. But if you follow the implementation roadmap, one of the first things that they say is you should form what they call the Lean-Agile Center of Excellence. So that you actually have a group in the organization that could help the rest of the organization to think about this. So if you formed that group with some experienced people that see the big picture and have some experience it’s less likely that you would fall into that trap. And we talked about the implementation roadmap. And it’s actually a very iterative process. So it’s not like a linear project plan or a transformation plan. It’s very iterative, you start with one train and then inspect and adapt. And based on that you implement more trains if needed. And then you inspect and adapt and then you can add and grow. So it’s a very similar pattern to what we talked about before in terms of ramping up. So it’s not like a big-bang implementation.
Erik: And who are the people doing that? How are managers involved here? Or can they sit on the sidelines?
Håkan: Sure they can. But the emphasis in the training is you need to train the managers first. And there’s a lot of talk about the W. Edwards Deming, that you need to change the system and that the managers are the ones who can change the system. So if they want the results they need to change. So you train a lot of the managers up front and then you train the people who are going to be more close to the development teams as you get close to the actual implementation. There are really a lot of good thoughts in there that you can use. And then if you have some experience from other ways of doing things, and you have things like I’m really fond of the “Switch” framework from Dan and Chip Heath. A lot of that stuff is in there and combined with some of the John Kotter stuff it‘s forming a good mix. So if you have some experience with them and you use it in an iterative fashion as they describe it, then it can really help you.
Erik: It sounds like you’re advocating a transformation approach inspired by the goodies that are in there and complementing it with other stuff, or?
Håkan: Yes. So everything that we have talked about, you have all the good stuff in there. They talk about the “Switch” framework to some degree. They talk about Kotter. They talk about Deming and are leaning back to the Lean and Agile principles.
Erik: So it’s all there.
Håkan: Yes. And of course, you can totally fail with it and do a big mess. But what I have seen is that it‘s typically things outside of the implementation itself that’s gonna make it fail. Organizational structures, core beliefs inside the organization, and so on, which is not matching up with the framework.
Arne: I find it interesting that you say there is a big focus on training managers up front …
Curious to hear more about Håkan’s experiences with SAFe? Hypotheses on why it is successful and what alternatives there are? Why it’s like a big bowl of candy and what Marie Kondo has to do with it all? Then check out part one and part three of our conversation!
You can find my work on leadership, strategy and Lean/Agile, e.g. the book The Art of Strategy, at Yokoso Press, Medium, SlideShare and YouTube.
