Tool Tip - The Change Compass

 If you're looking for a simple, yet efficient tool to help you create transparency on how your team is developing and growing, you may want to try the "Change Compass" in one of your Retrospectives:

The x-dimension is labelled "Calm" vs "Stormy", and the y-dimension "Improving" vs. "Worsening". Like this, it becomes a 2D mood-meter on where your team thinks they're heading.

How to use

Give people one minute to put a marker on the compass in whatever place they feel is most appropriate. Any place on the compass is fine, because we're mostly interested in a direction.

• "Calm" would mean "Nothing is really happening, there's no speed."
• "Stormy" would mean "We're in for a rough ride, faster than we can control."
• "Improving" would mean "Things are getting better"
• "Worsening" would mean "Things are getting worse"

Directional Patterns

When looking at the results, you don't need to interpret every single note. Instead, try to look for some key patterns.

The list of patterns here are the most common ones you can spot, although there may be others.

Making Progress

Our "True North" is positive change at a sustainable pace.

A healthy team undergoing healthy change would place their markers on the top third of the compass, preferably close to the center.

Too far on the left means we're not moving as fast as we could, while too far on the right means we may be overburdening the team, potentially making change an impediment in and of itself.

Comfort zone

When everyone feel that we're neither getting worse nor better, and there's no motion, people operate in their comfort zone.

This is good after a long, bumpy ride, but shouldn't be a permanent condition: There's no change without change, so this might trigger a discussion about where we can improve.

Change Fatigue

Sometimes, people have the impression that we're moving fast, but nowhere.

In this case, it's pretty important to have a conversation about what we're trying to accomplish.

We're losing 'em

When you see this, the team is torn. Some people feel the change is moving too slow, others feel things are moving too fast and/or in the wrong direction.

This would be a great time to have a conversation about what causes the different perceptions. Maybe the people who are uncomfortable see something the others don't - or vice versa?

No clear direction

With this pattern, it's almost irrelevant whether the points are on the left, center or right of the compass.

The key realization here is that people are disoriented - they don't know where they're headed, or what the outcome will be.

Maybe we lack transparency of what's going on?

Business as usual

People are in motion, at a comfortable pace, but nothing is really getting better.

Are we not even trying to change, or are we trying and see nothing coming out?
What do we need to change, so that things actually improve?

Change Theater

We're moving, but not where we want to go.

The further people move their markers to the bottom, the more likely you should stop and entirely reconsider whatever you're doing.

Dealing with the results

As long as you're "making progress", there's not much to discuss, and the exercise could be over within minutes.

In any other case, you need to start an conversation about what the results mean for your team.

The outcome of a Change Compass session should be that you:

• pick up speed when you're in a calm
• slow down when you're in stormy conditions
• Correct course when you're worsening
• Reconsider when you're not improving

In any case, it creates transparency on how your team thinks about your improvement efforts.

Alternative uses

The Change Compass can also be used in stakeholder environments, i.e.:

• to conclude a Sprint Review (to see how customers think about the team's progress)
• in management sessions, to see how the "outside-in" perspective on the team is
• to provide management feedback when the team feels things are blocked or going wrong

 "How do we manage risks in an agile setting?" - Agile risk management differs widely from classic project risk management, because we have a different sphere of concerns. Whereas classical projects are mostly concerned with risks related to delivering within TQB (Time, Quality, Budget), an agile environment forces us to consider a much broader sphere of risks:

Agile risk management

There are some general notes on agile risk management that may be unfamiliar or in contrast to the expectations of classic project organizations:

Risk overview

Teams (and in SAFe, ARTs) should be able to have an insight into their most relevant unresolved risks at any time. The assumption is that "if there is no risk overview, there are no relevant risks." Scrum Masters ensure that both of these statements are true.

At a minimum, risks are identified as such to be visible. Some organizations prefer to add additional information, such as severity, occurrence, detection (the FMEA process) and countermeasures, which is only relevant if you have no means of addressing them swiftly.

Risks are treated like regular work items, and move into the backlog as "potential work to do". The teams decide whether new risks are added to the Sprint Backlog or to the Product Backlog - or to the Program Backlog, in a SAFe context.

Live updates

Agile risk management is a constant exercise of evaluating available information and anticipating probable events that should be avoided, then inspecting and adapting the determined course of action. Risk management in an agile setting happens during every event (and during daily work, as well) -

• Lean-Agile Budgets identify financial risks
• Refinement identifies product risks
• Planning and Dailies identify process, delivery and organizational risks
• Reviews and Demos identify delivery and product risks
• Retrospectives and I+A workshops identify all kinds of risks
• PMPO Sync identifies product and delivery risks
• Scrum-of-Scrums (SOS) identifies organizational and process risks

As such, the risk overview is a more volatile and shifting artifact than even the teams' plan, and potentially more ephemeral than the product backlog itself.

Avoid Single Points of Failure

Organizations are most resilient if there is no single points of failure, hence risk management becomes a collaborative exercise. It's better to work with focal areas than rely on a clearly delineated role-responsibility mapping. It is expected that everyone contributes to naming and resolving relevant risks, from the most junior developer to the most senior manager.

Scrum Masters facilitate team risk resolution and create transparency in the surrounding organization on those outside the team's control. Ideally, the team would be able to deal with their own risks even without requiring the Scrum Master to take action.

Risk resolution

Just as every day is an opportunity to identify risks, we should deal with them before they materialize, ideally right when it is exposed. It's the team's decision on how they will prioritize risks against other work.

Risks outside the teams' sphere of control should be adressed via proper channels. In a SAFe setting, the first channel for a team is usually from PO to PM or from SM to RTE who would involve management if required.

Focus Areas

Teams succeed by collaborating and helping each other out, so let's not go into the "sorry not my desk" antipattern. Still, people do different things, and so pay more attention to different aspects. In this context, let us examine the different focal areas of the common agile roles.

Product People risk focus

First and foremost, product people must take care that we build the right thing, and have the resources (both time and money) to do so. Hence, they must be aware of and deal with:

Financial risks

Financial risks are cash flow related. We must secure an initial investment that allows us to develop something, and in order to continue, we need ongoing funding. Within an enterprise, that's typically budget. On the free market, that's revenue, which is usually generated through sales or subscriptions. So the Product people need both the means to understand the current financial situation and to forecast the future, and thereby extrapolate wherein the risks lie.

Common financial risks include exploding license fees, stakeholders withdrawing their support, customers leaving or price wars on the market, but also pretty mundane stuff like equipment breaking down or the need for a bigger office as the team grows.

To manage financial risks, the product owner must understand their cash flow.

Since financial risks are entirely out of scope for classic Kanban, XP and Scrum, there tend to be no standard team-level mechanisms for dealing with them.

Lean-Agile Budgets are one of many SAFe mechanisms to keep the predictable financial risks away from the team.

Product risks

Product risks are related to success of the entire endeavour. We need to build the right thing right at the right time, and ensure we adopt to changing circumstances as rapidly as possible. Hence, "release fast, release often" is essential to minimize product risk. 

Common product risks range from building the wrong product over building it in a way people don't like all the way to the product becoming obsolete or unmaintainable. Hence, product risks can be located in the past, with consequences ranging far into the future. This requires constant attention both to the inner dealings of the team and the outside environment.

To manage product risks, it's essential to look beyond the backlog, into the product itself and the product's market. Metrics can serve both as lagging and leading indicators to discover and track their manifestation.

Refinement workshops, Reviews (System Demos) and Planning events should reveal product risks, both within the team and at scale.

Team risk focus

Autonomous teams have control over both their process and their delivery. Hence, the risks associated to these must be born by them:

Delivery risks

Delivery risks range from not delivering anything all the way to delivering the wrong thing or something that doesn't work, hence they include the huge topic of quality-related risks. Since delivery risks have a price tag attached, called the "cost of failure", these risks consist of more than pure impact - they also have a huge element of choice: we take calculated delivery risks when the benefit outweighs the cost.

Common delivery risks include defects, incidents and problems (in ITIL terms), not being in control over the product's technical quality, not testing right or enough as well as releasing something immature, but also failure to gather fast and reliable feedback that could expose and thereby prevent other risks.

Delivery risks must be managed, but often become visible in real time. They are hard to pre-plan.
If we see any delivery risk in the future, we should devise a strategy to start minimizing it today. Retrospectives address how we dealt with past delivery risks. Team dailies should reveal current delivery risks, and teams should actively collaborate to deal with them.
If they can't be dealt with immediately, they should be made transparent on the Team Board.

Process risks

Usually, a process risk manifests as an impediment towards doing the right thing swiftly. In larger organizations with strict regulations and massive dependencies, process risks are often outside the teams' sphere of control, which, in the worst case, may lead the idea of self-organization and team-level agility ad absurdum. 

Common process risks include handovers, bottlenecks, delays, but also technical aptitude.

Teams are expected to manage process risks within their own sphere of control. Where they lack this control, the Scrum Master must often intervene to drive risk resolution. 

Team Dailies often reveal immediate process risks.
Retrospectives are often the best point in time to deal with long-term risks.

In SAFe, we use the Scrum-of-Scrums and the I+A workshop to address cross-cutting process risks. Additionally, we can resort to Communities of Practice to deal with practice-related risks.

Scrum Master risk focus

One of the Scrum Master's core responsibilities is revealing the things nobody else sees - and that includes risks of all form and types. Sometimes, the Scrum Master actively has to examine risks from the other roles' focus to identify need for change. Additionally, there's a group of risks that will oftentimes require action on behalf of the Scrum Master:

Organizational risks

Organizational risks, in this context, are risks induced by the way the team and its environment is organized. Such risks occur within the team, at the interaction points between the teams and the surrounding enterprise, as well as imposed from outside the teams' immediate horizon. Most of them occur at friction points, that is, where incompatible parts of an organization collide.

Typical organizational risks include asynchronity, miscommunication, bottlenecks, communication gaps or inavailability of individuals as well as mismatching goals or priority conflicts. There is usually a positive correlation between organization size and organizational risks.

Two core activities where organizational risks are identified are Planning and Retrospectives. In SAFe, that would include PI-Planning and I+A workshops where the SM should feed in both input and track relevant action items.

The Magic of Agile

One problem with "Agile" is that it often gets used as an excuse to avoid addressing the real problems in a straightforward matter. People resort to "magical thinking" - hoping that "Agile" somehow does some magic that will make the problem go away. And here's what's happening:

Clarity

In anything we do, we tend to look for predictability: what are we supposed to do, and what will happen as a consequence of what we do?

The coin toss

Let's start with something really simple: tossing a coin. 

You toss it into the air, let it spin, and call "heads" or "tails", and 50% of the time, you're right, 50% you're wrong. Straightforward enough.

Would you believe me if I told you that "if you throw the coin properly, it will turn into a helicopter and fly away?" Probably not. You won't believe me, because you know exactly what a coin and what a helicopter is, and how to toss a coin. There are no Unknowns here, and as such, you wouldn't accept my claim.

But now, let me change the topic:

The Project

Your company has started a project: to toss coins and turn them into helicopters. "Insane", you say. "No," your consultant responds: "we are in the Complex domain - a problem that we don't understand requires an approach you are not yet aware of. Since you can't rely on a familiar approach, you need to use an Agile approach."

Whereas formerly, we would have said "This won't work", now we have "Agile", and the plausibility of success immediately increases!

We have done nothing, absolutely nothing, that would lead to a helicopter as a result, and likewise have done absolutely nothing that would actually help you create a helicopter. All we did was introduce "magic" into the process by reframing the Unknown: "we have no idea how that's supposed to work!" becomes: "Agile will create the result!"

Comfort

Since we know very well that we're not getting a helicopter with a coin toss, we are quite comfortable to state, "That doesn't work." Now, if someone showed us how a coin turns into a helicopter mid-air, we would say, "I see the helicopter, but don't know how that works," (we increased the certainty of the outcome, but not in the approach) - and those of us with a growth mindset would likely say, "I want to learn how to do that!"

If your manager has given you 2 weeks to do it, your nerves would tingle. 

And now your manager tells you that unless you do it, you will be fired? Most likely, you'd be quite willing to try any advice on turning coins into helicopters.

What has happened here?

The further you leave your comfort zone, your willingness to accept magic as part of your mental model increases. When facing an existential threat, you'll more than happily try things you'd call nonsense under normal conditions: the plausibility of the proposal hasn't increased at all, only your perception thereof!

And this quite frequently happens with "Agile Transformations":

Magical Agility

Of course, turning "coins into helicopters" is a joke. Nobody would take that seriously. But what if our challenge was to turn:

• Dissatisfied Customers into Happy Customers
• Poor Time-To-Market into Fast Delivery
• Cost Pressure into Huge Savings
• Tons of Defects into High Quality
• Unhappy Developers into a Highly Motivated Workforce

Someone says, "when you're Agile, you can achieve all these". and now you're all - "Okay, bring on the Pigs in Pokes, let's get this going!" - especially when your job is at stake!

And that's where you get into the realm of Agile Magic. And that's when you need to stop and think.

Let's not get into the nitty-gritty that even if you're agile, you'll still have these problems, just that you will be able to deal with them better, and let's focus on the big hitter:

When your organization has no experience with achieving these, then "Agile" isn't going to change a thing about that unless you start doing your homework!

De-mystifying "Agile"

There is no unknown component that can't be explained. Everything is transparent. We know very well how to relate cause and effect. And where we don't know, we can explore until we do.

Problem -> Approach -> Action -> Outcome. Preferably highly repeatable and reproducible. No silver bullets, no miracle pills.

Where we can't copy+paste a solution from one place to another, succeeding with agility becomes harder, not simpler: we require experimentation and a willingness to fail - and a pretty good understanding on whether failure will lead to growth or be fatal.

There's no Agile ceremony, ritual or incantation that will grant you a magical Great Leap Forward.
You must get to work and clean up the mess you're in. 

Learn what causes you to get the outcomes you currently get, and what you need to do in order to get the outcomes you want. As you learn, you'll catch a bloody nose quite frequently, so bring plenty band-aid. (figuratively speaking)

Mundane agility

Find your own way forward:

Experiment. Fail. Learn. Repeat.

That's all there is.

The only shortcut I can offer: You are probably not the first person who has encountered a problem. Thus, you can often skip or at least reduce the "Fail" part by learning from others before you move ahead.

There are many bodies of knowledge that allow you to accelerate your journey: Engineering Practice. Process Management. Product Management. Quality Management. Supply Chain Management. Team Building. Just to name a few. Make use of whatever knowledge you can get a hold of.

Inspect and adapt until you're clear why you are where you are, and where and how you want to go next. When you don't know, you'll need to figure it out. 

The more you practice this, the more comfortable you become doing it.

The desire to seek magical solutions evaporates.

There is no magic in "Agile.".