Martin: Let's talk about SAFe. Tell us a little about your experiences. What are some of the positives and negatives? What stands out to you?

Burkhard: I've been working as a project manager for a very long time. I've been involved in Agile product development, mainly for corporations, since 2011. You become involved in projects that are still structured in the classic silos. At this point you're just trying to seek out solutions on how to structure and implement projects well in that format. 

There were many different methods that we tried including Scrum of Scrum & LeSS but the SAFe framework was actually the most suitable approach and solution for me. This was because its scaled structures somewhat reflect the corporate structures. It causes you to ask why you're taking the project on. So it's not simply a matter of completing the project in the supply chain, but also forces you to consider what the corporate strategic goal behind it is. That's often a bit disconnected in corporations. On the other hand, it is also a method to get real feedback from a business perspective. Have I actually set my strategic planning or my guard rails well? How and what can my agile team realize for me as One Team or ART Solution? How do I communicate milestones? How do I communicate budgets and financial plans? I actually found all of that very interesting.

From an IT and supply chain perspective, I think it's an approach that's good for both agile projects and classic projects. That division in PIs is like a common thread that helps agile teams find their way after each increment. On the one hand, I want to deliver a product, create value, gain customers, make money, and I don't want to play around. 

On the other hand, the framework also gives classic projects the opportunity to verify their approach again and again through the small iterations through  feedback loops. For example, are my requirements really formulated correctly? And from there, I believe that both approaches also achieve a synergy effect.

The main advantage from a corporate perspective is how it works. You have value creation in the silos or even in the individual teams within a silo some sub-products. Here, work is often done autonomously, collaboratively, or perhaps agilely, and that's where it works for itself. But you don't have synergies, you don't think lean. How can you achieve uniformity and leverage synergies? That is one point.

The second point is that there is some poor release manager who collects in weekly meetings what has just been completed, where the risks are, and where the dependencies are. The SAFe model with PI planning as the brand core of SAFe turns it around: At the beginning of an interation, we consider with the teams what we will achieve, where our dependencies are. You also achieve alignment through that. And that then makes it easier for the release train engineer to keep the teams in line and to manage risks, dependencies, and impediments, instead of always just getting something thrown at them by the individual teams. So from that perspective, I think this framework is really good.

Can you also elaborate on your experience with LeSS and Scrum of Scrum and why you guys moved from there then somewhere else?

We only used LeSS in a rudimentary way because it just didn't get that kind of acceptance. I think the difference is mainly that you don't have this PI structure where you say, okay, these are now the things we want to achieve in the next PI. I thought that was a little bit more structureless. The difference between LeSS and SAFe is simply that the LeSS approach is more bottom-up, so along the lines of: I now have an agile team here with which I start to develop a product. Then I grow, then all of a sudden I have several teams that are autonomous in themselves. And now I actually want to find a solution from these teams. And then they realize that it might be cool to have collaborative product management or to coordinate things together. So it's more like pulled from the bottom-up.

And SAFe is more of a top-down approach. We have a business strategy here, that's where we want to go, that's our vision. Here we have our Value Streams, that's our Large Solutions, our Trains, and you guys are responsible as a piece of the puzzle to deliver this and that. Because we want to make money on that. And you guys are also responsible for thinking what else can be gained additively: Where are perhaps also consulting services, product services? Because you know the product and the customer best.

That's a different perspective. And I believe that it is easier in the corporate environment to proceed from this SAFe environment - also in terms of people's acceptance. The main thing with the introduction of these frameworks is this fear of losing status, of change, of losing freedom, which can be observed particularly at the middle management level. Do I have to move my workplace when teams are merged? Do I suddenly have to coordinate my train with ten other teams? Am I no longer allowed to do things the way I want to? That was good!

Stories like that are already a problem, and of course you have that with a LeSS approach. We've tried it in two projects, and in many cases you're simply discussing things to death, because people have a bit of difficulty developing a collaborative vision and implementing it.

You are a founder, I am also a founder of companies - we know that: You have a vision, you want to achieve something. And so does your closest network, the people you've been working with forever. But you're going to have some of your 150 people who just want a job from nine to five. And that's fair. But you can't reach them so well with a bottom-up approach, because they say: What do you actually want? I just want to work. I think you're more likely to reach them if you develop and distribute a vision like this.

Because then there is a structure that they can fit into. They say: Ah, okay, here's a new fit, so to speak, and when I look at it, it's not so bad.

Exactly. But if you had a classic management structure, these people look at the framework and say: Ah, look, team leaders and department heads don't exist there at all. Where am I all of a sudden? For them, it's a bit difficult at first. But I think that this is a question of coaching. You have to think together: Okay, you'll find your perspective there, too, so to speak. You, too, will find a job there. That's a bit of a problem, why there are often problems. But otherwise it works out quite well.

Where are you usually active? So, more in this technical area, where you help the teams to move forward in software development and coordinate that? Or more in the personal alignment with people: What's your perspective, how do you get along with others, where are your strengths?

My big experiential strengths are in the actual delivery chain implementation, so the release train engineer job, and also the experience I've gained in building and leading transformation teams at the management level. I also immediately work agile with these managers because there are many benefits. The motto is: Oh, they don't deliver anything, they have a new idea every two weeks, and everything is so intransparent and uncoordinated. And then we do the same with them. We set up a Jira board, think about what the transformation features are, what the stories are, and so on. We think about scenarios, and then we push those into two-week or three-week sprints, do retros, reviews.

In one project, we pulled together all the managers in the supply chain - from requirements to testing and release - formed a transformation team and started by doing Scrum basics with them. Stories, features defined. We defined acceptance criteria. And then we basically pushed them through.

And then coaching questions also come up. But that is not the most important factor. I think it always depends on the context. Someone who was previously the department head on the business side is now suddenly a product owner. What does that mean for him? And that's where training, even SAFe training, can help. And then he knows: He is now, so to speak, the key accountant of his train, of his team. He's responsible for collecting the money in the supply chain, bringing in new features in the group, or even talking to the customers. What are the strengths and weaknesses of his? What can they deliver in the first place, so that they don't get into the embarrassment of having to deliver anything they can't deliver. And vice versa: What are the strengths of the product?

The disadvantage, of course, is that from the corporate point of view, there is suddenly a much stronger commitment to such a product. Previously, this was more the task of the business side, for example IT. Now, however, it is suddenly focused on a product or a chain of products. I think that's the biggest change for them.

One example is the testers. It is really a challenge to get a structure into test and release. The developers are developing something, and in large corporations you also have external development teams. There, it's often still the case that if the tester doesn't find the error, it's his own fault. Instead, the development teams should first be held responsible: It is only finished when it runs. And at the same time, the testers, who are now more like quality consultants, must also be involved at the beginning.

The fact is that if the test department does not include its requirements in automation, for example, either as an enabler or as an acceptance criterion for the feature, it will not be developed. Then there is no story. Then there is no unique ID on the page to query afterwards. Conversely, the testers usually know best where the weak points are in the context of all applications. And how what runs best or worst along the entire chain. So they have to come in at the beginning and say: This is the right test data, or you have to pay attention to it, or if you change something in the system, then something will change three systems down the line. This is where the testers can contribute an incredible amount of knowledge that would otherwise be lost.

In other words, this also shortens the supply chain. And I think that's also much better in the SAFe model than in others. In LeSS, for example, you actually need a feature team in your teams to be able to work together in a really well-structured way. In SAFe, on the other hand, the train is actually your virtual feature team. And whether there are still individual component teams inside, which you slowly transform, or external teams or milestones, i.e. waterfall teams - it doesn't really matter. It's simply a matter of the stream team with product manager, architect, release train engineer, how they control their train and then really create and implement features from it.

You said earlier that what you like about SAFe is the transparency all the way up to the business strategy, which is otherwise not so clear in the group. Do the employees also question the strategy from the bottom up and point out if, for example, the cornerstones are perhaps positioned incorrectly? Or is that something that the Group still doesn't like so much and perhaps tends to keep under the carpet?

I think that depends primarily on the agile maturity level. Or perhaps rather the level of entrepreneurial maturity. By opening up such a channel and a dialog in the first place, opinions can form or opinions can become more transparent. And if people are encouraged on the horizontal level with their dailies and retros to take a stand or express an opinion, then they will also do so vertically along the trains. And in my experience, they actually do express it: Watch out, that doesn't work at all with what you're thinking about! Because you can operationalize that well with key figures.

On the other hand, managers also become more open in the long run and say that they will change things. Initially, however, this is not the case. Initially, it is actually the case that, for example, in a portfolio management team, many product owners or product managers think: Okay, the Epic that is now being submitted at management level is set. I get that. I have to implement that in my PI. It's a challenge to understand that they influence that themselves. With my teams, with my train, I can influence the roadmap and define what I can really achieve! And that's kind of a scaled-agile maturity that needs to emerge.

How did you learn about SAFe? How did you acquire knowledge about it and what would you recommend to someone who wants to know more about SAFe?

In 2015, I first came into contact with SAFe when I saw an article about it. I decided to go to a training in London, which was around the time of the version jump from 3.5 to 4. For a while, I didn't pursue it. However in 2016, I came back to it when I had another cross-silo project that lent itself to it. In Cologne, I went to another SPC training. Afterwards I finally decided to get certified. 

What is striking about all the SAFe training courses is that they don't explain agility to you. So you should know a little bit in advance and have experience in agile working. Scrum, product owner, cutting features - none of that is explained in any great detail. In the new trainings with version 5 it gets a bit better. But, you just have to have some Scrum experience, be interested in scaling, and maybe even have some experience in a Lean environment. In my case, I said to myself: 'Oh my gosh, now that I've implemented a lot of really cool projects in my organization and other companies, it's about time I became a coach.' However, that's not just a career step, it's a completely different profession.

As a Scrum Master, a Release Train Engineer, or a Project Manager, your task is to improve your product, and to sell your product. As an SPC in a scaled environment or as an Agile Coach in a normal agile environment, your job is to optimize delivery processes and improve teamwork. That is your product, but also your supply chain. You also need a team and requirements. You also have to determine your key figures, but that's a different story. 

You've worked a lot in corporate groups. But have you also done SAFe with smaller companies? How big should you be to be able to use SAFe in a meaningful way?

There is a general best practice that you need around four teams. But I don't think it really matters that much. The method itself, working with a PI and holding a meeting beforehand, in which I describe dependencies and functions, can also be done with fewer teams, even with two or three.

There is no added effort with fewer teams, in fact most people involved are all on site anyway, so there's no need to travel. It makes sense to deal with the important question: Who actually does what with this part? Do we split it up, does someone do it alone? Where are dependencies? What are our respective delivery goals for our next four or five intervals? That just makes sense to me. It gives you a common thread. And if you have two or three teams, you don't need to make a big organizational fuss about it, I would say.

That means that even if you were to scale your company up to ten and then to a hundred and then to a thousand employees, you would work with SAFe right from the start - and then just a bit more pragmatically, the smaller you are.

Yes, definitely. On one big project, we were in the open floor plan office, in the hallway there was a PI wall. And every morning, teams and people had to walk past it and think about where we were. There was a defined thread between teams, and the vision was always clear in front of us. And I think small teams and companies need that, too.

After all, there's validation. I think the coolest thing about the agile approach versus the waterfall model is that through these incremental products and through these small delivery iterations, you always have this common thread, you're always confirmed that we're doing something meaningful, useful, good, that we might even be making money already. And I can identify with that as an employee. And it's precisely small companies, young companies with young employees, that need this kind of identification factor that goes beyond the fun factor. They also want to achieve something.

I think the coolest thing about the agile approach versus the waterfall model is that through these incremental products and through these small delivery iterations, you always have this common thread, you're always confirmed that we're doing something meaningful, useful, good, that we might even be making money already.

Let's talk about failures. What are some common problems and stumbling blocks you've seen with the teams and managers you've mentored so far?

At the team level or at the training level, you often have the problem that they can't really work agile in the corporate environment because they simply don't have a sufficient environment for testing. There are often no chances to experiment, except for the classic release date that occurs every three months where they throw all their stuff together and then test it on an environment. But then the work is not agile. Then they do not need to be motivate to develop the most important and urgent things first, because they can't test and verify them anyway. This is an important point.

Teams should be able to develop separately from each other and deploy at any time. The coolest product is not just the one that has the highest customer value, but the one that has an accepted quality and that I can deploy at any time, that is documented, and that can provide value at any time because I can change it at any time. And that's what the infrastructure has to deliver.

At the management level, as I said, it's more the fear of change that's the problem. This is often the case in middle management. These are personalities that have grown out of the company. They have been there for 20 or 30 years. They've studied there and are team managers and department heads, and that's all they know. But they also know about the 25th change process that passes them by. And they just hope that the sow will pass them by this time, too, and that they will survive it. And then the coach comes along and says: "Watch this, surprise, we're doing everything differently now!"

Is there a trick you can pass on to other coaches?

That's really difficult. Above all, it's a lot of one-on-one meetings. As I said, especially in corporations, you have teams that think they're working agile, but they're not. They might work iteratively, so they have phases where they write their concept. Then at some point they hand it over to an external service provider, who then develops something, and then they test it. That's not agile. Agile means that we can work closely together to verify the result. So that's the first move they have to make. And the second is simply persuasion through practice. That one can show through small steps how something quickly changes. I think that's a spot that always works for me.

And apart from that, I'm thinking about taking another part-time training course this year as a systemic coach, because I find that this systematic end-to-end approach suits me well. It also fits into this environment, to really learn a few more psychological methods to convince people a bit more. Yes, that simply persuasion works. SAFe helps quite a bit there, too. I always say: Guys, think about how long this framework has been around and who is using it! If it was crap, it wouldn't exist anymore!

I can simply google and find a thousand things about SAFe, and that also provides security. And there are trainings that are standardized, even in market value. If I now want to grow or suddenly need three coaches or RTEs, then I can also provide them quickly if I stick to the standards.

One last sentence: A framework like this is like a gilded cage when you have children. Yes, in the beginning you tie the cage very small, because it also gives security until they walk or are fledged and can fly a bit. And then you can set this frame further and further, more and more tolerant. Where do I make it narrow, where do I let them run? You can actually find a solution that is actually a good step forward.

This page in German