Long term injuries

SAFe Transformation Injuries – the long term injuries of the SAFe transformation which you discover too late, and how to prevent them.

Scaled Agile Framework (SAFe) is fantastic! Never have we seen so much knowledge about agile development collected in one place and put into one coherent framework. A framework that doesn’t just address the needs of one specific team, but instead deals with how to scale agile to the whole enterprise.

It doesn’t matter if I talk to top management or developers and testers – SAFe gets traction on all levels, from the portfolio to the team level. And with the kind of results some companies are shoving, it’s no wonder that more and more companies are starting out on the SAFe transformation journey.

Long term injuries

Whenever you start out on a transformation, there is the risk of long term injuries. It’s like when we take up running after 10 years on the couch. In the beginning all is well. It’s a fantastic new life, we are filled with energy and so happy that we are finally making things better. Problem is, that in our enthusiasm we do too much at once. We simply run too often and too long. And we don’t do any supporting exercises to adapt our body to the new demands. Therefore, after a few weeks, or months, we start to hurt. We have an injury that will take a long time to heal. The most annoying thing is that it was totally avoidable. With the right training advice and program from the start we would have been fine.

It’s the exact same thing, when we implement SAFe! Do it wrong from the start and you will get injured. Something that is much more expensive to fix than to prevent.

Core Values

The people behind SAFe know this. That’s why we have the four SAFe core values. They represent the fundamental beliefs, that are key to SAFe’s effectiveness. Guiding principles that help dictate behavior and action for everyone who participates.

Figure: SAFe Core Values www.scaledagileframework.com/safe-core-values/

The four SAFe implementation injuries

The core values are there for a reason. When SAFe doesn’t work, the root cause is often poor decisions made right at the start of the transformation. Decisions that went against the core values. Or maybe rather the lack of good decisions, properly acted upon. This leads to the four injuries of SAFe long term injuries. One for each of the core values.

Focus on preventing injuries

That’s why I think it’s so important that if you want to use SAFe, you need to get some things right from the start. You need not only to know the injuries, but right from the start, you must implement a structure that helps keep you aligned to the core values.

You can implement such a structure in different ways. However, the size of organizations using SAFe, their geographical distribution and their typically low maturity, going into the transformation, means I almost always recommend the same thing. You need an IT tool that helps you manage work. Sure, you can build it with coaches, post-its and lots of adhesive tape, but in reality, it’s too expensive and not an effective option for a large enterprise.

There are several platforms to choose between. My favorite is ServiceNow, for reasons I will get into below.

But in order to prevent, you must know what can go wrong. So here are the four SAFe implementation injuries and how you can prevent them.

#1 Injury: Self Organititis

Alignment is a SAFe core value. With hundreds of people working towards the same overall goals it makes great sense to be aligned. Both in the way we work and what we work on. If everyone is aligned, we can much easier and faster correct deviations or change direction as we go along. It is fundamental in order to always focus the effort on what is most valuable.

What goes wrong?

You are forming an Agile Release Train. Let’s say it consists of ten teams. Some are existing teams and some are newly formed. Most likely all teams do not share the same building or even the same time zone. Maybe one or more of the teams are from an external supplier. One team uses Jira, one Excel, another TFS and so forth. The mistake that will come back to hit you is to let teams decide which tool they use going forward. We do it with the best of intentions, after all, we want to be agile and let teams self-organize. Problem is that this puts us in a very difficult place. A place where there is no common language and no real time overview of what’s going on. Every team have their own plans, but we don’t really know, if they are aligned. And when something happens (it always does) and we need to change direction, we are in a world of pain in order to quickly aggregate a common status and plan across teams.

Figure: The bridge problem. Thanks to Henrik Kniberg, se the video at: https://www.youtube.com/watch?v=_qIh2sYXcQc

How can we prevent it?

The solution is one common tool, where you can set the guardrails for self-organization that assures alignment. We want teams to self-organize, but we don’t want sub-optimization, that makes the Agile Release Train slow and weak. Therefore, you want a standard tool, that comes with out-of-the-box functionality for aligning teams’ sprints, plans, backlogs, etc. The teams are then free to self-organize, within the guardrails set in the common tool. The SAFe functionality in ServiceNow assures that teams are aligned and that is the foundation for proactive, quick and strong Agile Release Trains.

Figure: PI Planning across teams in ServiceNow

It takes minutes to set up an Agile Release Train in ServiceNow that follow the SAFe recommendations. And not much longer to implement customizations that fit with your specific processes.

#2 Injury: The Black Box

Transparency is a SAFe core value. Without openness, facts are obscure and decision-making is based on speculative assumptions and lack of data. No one can fix a secret.

What goes wrong?

The Agile Release Train is the key concept of SAFe.

https://www.scaledagileframework.com/agile-release-train

It is genius in its simplicity, to let all the people that have some role in developing and operating a solution, self-organize in one big stable team of teams. When off to a good start, and given the right freedom, the ART quickly learns to optimize and improve value delivery across teams. But freedom comes at a cost. And that cost is total transparency. I’ve seen several examples of Agile Release Trains who want the freedom without the cost. They close ranks against the outside world. They often don’t see it themselves, but you don’t get to decide yourself if you are transparent enough, it’s up to your stakeholders to decide. Stakeholders could be senior management, PMO, Project Managers, Line Managers and others. And to them the Agile Release Train is a black box. A cult of people using a weird language, doing strange things. All the stakeholders really understand is when the Agile Release Train ask for more money. This is not a good long term situation!

Figure: The black box

The freedom to self-organize comes at the price of full transparency. It’s good for the stakeholders but also for the Agile Release Train. Being transparent forces you to do the right thing. It must be real transparency, though. Reports are fine, but really, we want everything out in the open.

How can we prevent it?

By using a tool that is also known and used by the stakeholders. If you want real transparency, you make it possible for stakeholders to see backlogs, Kanban boards, plans and objectives. As well as the daily progress. But you don’t only want to make it possible, you want them to actually use it. Therefore, the threshold must be very low. The stakeholders might not be willing to learn a new tool. Even remembering the password can be too much of a barrier for some. So if you can use a tool they already know, you are a lot closer to success.

In ServiceNow, as in other tools, you can quickly make reports and views that give stakeholders a real time picture of what’s going on. But the real strength of ServiceNow, is that it is widely used in the organization. It’s not just an agile tool, used by some developers in one corner of the organization. User interface and the way information is presented is already known. People can find their way around. And if they need help, it is readily available. This makes the threshold very low. People will actually use it. That means true transparency.

#3 Injury: DevWHAT?

A SAFe Agile Release Train is a Value Stream. A Value Stream is all the work needed to bring value to a customer.

https://www.scaledagileframework.com/value-streams/

The people working on an Agile Release Train should be all the people needed to do the work all the way from idea to implemented functionality used by the customer. SAFe’s core value of Built-in quality is closely connected to the value stream, because quality ‘happens’ at the user, but is built step-by-step all through the value stream.

What goes wrong?

The concept is very straight forward, but still we see it go wrong time and time again. The classic mistake is to focus on development and forget the people supporting and operating the actual solution that the users are using. We see organizations where ‘development’ people are organized in Agile Release Trains and use their own tools and language. In a different part of the organization we have the people who support and operate the solution. Most of the time, these two groups blame all the problems on the other group. And if you only have two groups, you’re actually lucky. In reality there are several groups who spend a lot of time finding faults with each other.

Figure: How different groups view themselves and others

A ”development-only ART” can be ever so fast at developing new features, but if these features are waiting for weeks and months until they can be released, that’s where we need to improve. If we discover a lot of errors in our production environment, that constantly drain our resources, then that’s where we need to improve. Or if new functionality lead to a lot of extra work for support and maintenance, then that’s where we need to improve.

If development, operations and support aren’t connected, these problems become chronic and the situation is far from the SAFe core value of Built-in quality. Those who build the solution must always do it, with focus on where the solution is used.

How can we prevent it?

The DevOps concept was invented to address this problem. DevOps is all about Development and Operations in one unbroken value stream. It’s really about building a common culture across silos. But in order to do that we must have some common ground and common behaviors. Work, information and opportunities should be able to flow freely between development and operations.

The easiest way to promote one culture across the value stream is to have the same tool for all the work. ServiceNow is the leading platform for ITSM and ITOM. If you are starting up Agile Release Trains it’s a no-brainer to extend the ServiceNow platform to that work as well. Especially since it comes with out-of-the-box SAFe functionality. With the entire value stream in one tool, you’ll be able to measure the flow of value and focus on optimizing the whole.

Figure: All the work on one platform

#4 Injury: Program Excuses

Program Execution is a SAFe core value. At the end of the day, SAFe is about executing and delivering on our objectives. If SAFe doesn’t help you execute significantly faster, with better quality, you are not getting the value out of it.

What goes wrong?

Stephen Covey’s book ‘Seven habits for highly effective people’ has sold in over 25 million copies all over the world. Here, he talks about the circle of concern and the circle of control. Covey wants us to stay in the circle of control, where we can make a difference, and don’t spend time worrying about things we can do nothing about.

SAFe should be a fantastic framework to promote this. There are roles and specific guidance for everyone. Small teams each have their backlog of work. Just go do! Well, in reality we often see something else happening. It’s in the human nature to worry about things and also to spend time talking about those things, rather than execute on your tasks. SAFe has a major pitfall built in for this. The fact that SAFe addresses the whole enterprise, that everything is described, gives us an endless opportunity to focus on what everyone else should be doing, rather than what I should do. The result is waste. Waste of time and waste of energy. Instead of working on their tasks, people waste time in the circle of concern.

Figure: Circle of influence vs. circle of concern in a SAFe organization

How can we prevent it?

The solution is all about making the daily plan-do-check-adjust cycle work. A large initiative doesn’t suddenly become six months late. It happens little by little, every day. Or, to turn it around; even the largest initiatives are executed one day at a time.

You want to break your large initiatives down into more detailed deliveries, until you get to tasks, that take no longer than a day to execute. For those of us, who might otherwise procrastinate or go work on something else, it helps to have our daily tasks in front of us, reminding us what we need to do today, in order to meet our overall big goals.

In ServiceNow, all this comes out-of-the-box. We break down work from large initiatives, or epics, into features, then stories and finally tasks. Minimum once a day, as the teams do their daily standup, you have a real time update on plan vs. actual for all you large initiatives. This daily Plan-Do-Check-Adjust cycle is fundamental for succeeding with SAFe. All our big plans and goals rely on the daily planning cycle and if that isn’t disciplined and structured, don’t waste your time on strategies and roadmaps. In order to succeed with the SAFe core value of program execution, you absolutely need a tool that connects strategic goals to your daily tasks.

Injury free SAFe transformation

We can help you avoid long term injuries, when implementing SAFe. Our engagement always begins with a Vision & Scope Workshop. This is where we agree on, where you are, where you need to go and how to get there as fast and effectively as possible. The fastest way is always to avoid injuries and that’s why we see the proper tooling as an important pillar of a successful implementation. Alongside top class training and coaching.


Vil du vide mere om SAFe og andre agile metoder? Så hent vores gratis e-bog “Det agile landskab” her!

Læs mere om Scaled Agile Framework (SAFe): www.scaledagileframework.com

Skrevet af Jonas Högstrand

Jonas er underviser, agile coach, seniorrådgiver i projektledelse og lead trainer for SAFe®-kurserne i Metier. Han er certificeret underviser i PRINCE2®, PRINCE2 Agile® og SAFe®, certificeret P3M3® Assessor og har været reviewer på den officielle PRINCE2 Agile®-manual.

0 Svar

Skriv en kommentar

Want to join the discussion?
Feel free to contribute!

Skriv et svar

Din e-mailadresse vil ikke blive publiceret. Krævede felter er markeret med *