For his latest book, We Run on Agile, Martin Seibert had the opportunity to sit down and chat with SAFe and Agile experts like Dr. Thorsten Janning and Michael Frey to gain insight into what it takes to succeed in this realm.
This time, Martin has found another experienced conversation partner to talk about Scaled Agile; Burkhard Schmidt, coach for the introduction of scaled agile methods (SPC), SAFe-Lean portfolio manager, Lean-Agile trainer and founder of bschmidt.com consulting GmbH.
The complete interview is available in our Knowledge Base. In this blog, we'll summarize a few important parts of the interview.
The Strategic Goals behind the Development
In his career, Burkhard has worked primarily with corporations, trying out different scaling approaches. In his experience, when do organizations start looking for solutions to extend agile development methods? And what effect can the Scaled Agile Framework have in this regard?
Many large companies are classically structured in silos and are relatively compartmentalized organizational units, Burkhard says. And here, at some point, executives or project managers are looking for ways to structure and implement projects well across such silos.
In this regard, he says, the SAFe framework came close to the corporate reality, "because on the one hand, the scaled structures make it a bit like the corporate structures." But on the other hand, SAFe is not just about executing and delivering projects within the framework of a supply chain, he said:
"[...] but also about considering what the corporate strategic goal is behind it. [...] In corporations, you're often a bit disconnected, and SAFe is a method to get real feedback from a business perspective."
PI planning is the core of SAFe. Here, unlike other scaling models, there is no release manager talking to all the teams to collect what is ready and see where dependencies exist. Instead, the objective is be made clear at the outset:
"At the beginning of an iteration, we think about what we want to accomplish and where our dependencies are with the teams. By doing that, we create alignment, and that then makes it much easier for the release train engineer to keep the teams on track and manage risks, dependencies, and impediments better than if the individual teams are always just throwing things at him."
Scaling as a Bottom-up or Top-down Approach
When asked about the fundamental differences between the LeSS and SAFe frameworks, Burkhard emphasizes where scaling comes from. LeSS, he says, is more of a bottom-up approach, where scaling occurs relatively organically from the bottom up: an agile team develops a growing product, and as the product grows, more autonomous teams become involved, and from that, at some point, the desire for collaborative product management or coordination emerges.
In contrast, SAFe follows more of a top-down approach, he said:
"We have a corporate strategy here. That's where we want to go, that's our vision. Here we have our Value Streams, these are our Large Solutions, our Release Trains, and you as a team are responsible to deliver this and that as a piece of the puzzle. Because we want to make money on that. And you are also responsible for thinking what else can be gained on top of that [...]. Because you know the product best. And you possibly also know the customer best."
In a large company or corporation, this perspective often makes sense, Burkhard finds, because the approach makes it easier to increase acceptance across all divisions, but especially at the middle management level, and to reduce fear of change.
There are certainly pros and cons to each framework, he says, but the SAFe model has the advantage of first enabling companies to verify their supply and value chains, and second to quickly develop good software that customers are willing to pay money for.
Challenges with Agile Scaling
However, scaled agile software development also comes with challenges, as Burkhard describes from his experience. One hurdle here, he says, can come from infrastructure alone. Teams simply won't be able to work in a truly agile way if, for example, they don't have a suitable test environment to continuously deploy changes:
"That means they often have no possibility at all, except to pile their stuff together on their classic release date every three months and then test it in a test environment. But then I'm not working in an agile way, so I don't need to motivate them at all."
At the management level, on the other hand, the main problem is the aforementioned fear of change. Especially in middle management, you can encounter many personalities that have grown with the company culture:
"They've been there for 20 years, 30 years. And they simply hope that the whole thing will blow over and that they will survive. And then the coach comes along and says: Watch this, surprise, we're doing everything differently now. It's very difficult."
And how can a consultant, release train engineer or SPC actively offer support here to reduce such a fear of innovation and promote more openness? Many one-on-one discussions and persuasion work, he says. And SAFe can help with its references:
"Guys, think about how long this framework has been around. And who is using it. If it was crap, it wouldn't exist anymore."
At the team level, he said, it's again a challenge to establish true agility in the first place. In corporations, he says, you constantly see teams that believe they are working in an agile manner, but are not. This is where you have to start. And in practice, it can be quickly demonstrated that small steps can already change a lot.
Reaction and Adaptation
Finally, Burkhard answers the frequently asked question about process fidelity and stringency with regard to SAFe in Agile scaling. With its extensive process recommendations, isn't SAFe a bit like old wine in new bottles? Occasionally, there is talk of Agile disguised as Waterfall. How closely should the framework be interpreted? How close to the intended process should you stay? Here, Burkhard has a nice image at hand:
"With a framework like this, it's like having a golden cage. It's a bit like having children. In the beginning, you tie the cage very tightly, because it also provides security until they can walk or are fledged and can fly a bit. And then you can set this frame further and further, and you're more and more tolerant. And so I can react and adapt: Where do I make it tight? Where do I leave more room? [...] You can actually find a solution quite well, of which you say: Watch this, this is actually also a good step forward."
Again, thank you very much for this exciting conversation, Burkhard Schmidt! As mentioned at the beginning of this article, you can read the complete interview in our Knowledge Base.
SAFe with Atlassian-Tools: Get to Know Agile Hive Now!
Want to know more about the software-based implementation of SAFe? One solution for this is called Agile Hive. We would be happy to discuss your requirements for company-wide agile product development and product management with you and demonstrate the software's features in a personal session. Please contact us! In our Knowledge Base you'll find details about our Agile Hive implementation projects.
Learn more about Creative Commons licensing and //Seibert/Media
