The Essence of Safeguarding

Safeguarding consists of the following:

  • Get a signal that indicates when important problems happen, e.g. bugs or risk-averse choices.
  • Every time the signal fires, examine the specific case to find hazards.
  • Specify a timebox — how much effort is worth spending to prevent problems like this one signal that happened (commonly a person-day or two).
  • Execute remediations within the current sprint — partial improvements of hazards.

That’s really all there is to it. Most importantly, the following are not part of Safeguarding:

  • We don’t look for patterns across multiple instances.
  • We don’t deeply analyze what happened to find all the root causes.
  • We don’t do any work that would exceed our effort timebox or go beyond the sprint.
  • We don’t look for common patterns across teams or try to actively share improvements between teams.
  • We don’t base the effort on the remediations we’re going to perform.
  • We don’t ever block a remediation if the team decides it’s a good-enough idea for the current hazard.

Adding any of these would decrease the impact. We’ve often had to fight to keep people from adding them, because they seem like good ideas. They simply turn out to be bad ideas in practice. These concerted efforts to do the wrong thing come from our near-universal misunderstanding of change, particularly how organizations change.

Real Change Can’t be Managed

We often talk about Change Management. Heck, it’s a discipline, even a job. But Change Management operates from a fundamentally flawed assumption. It assumes that there is such a thing as a change.

In truth, change happens all the time. And there is no Right Change. Rather, any real situation has many different contexts, and the right change in any one of them would be an absolutely terrible idea in several others. To change successfully, the organization needs to change in multiple, opposite directions, at the same time.

As an example, in the bugs case mentioned above, 3 teams identified that they needed to add automated integration tests. That was right for their context. 3 others identified that they needed to remove automated integration tests. That was right for their context. They picked exactly the same measure but needed to make exactly opposite changes. And the other 100+ teams? They didn’t need to do anything with integration tests. Any time spent even reporting that number would be a total waste for them.

This means that any shared goal (or measure) is immediately and obviously stupid to those who are undergoing the change. And that’s why change managers say people fear change.

People Don’t Fear Change

Yet if we look at the real world, we see that all of these people who supposedly fear change are constantly changing themselves. They put a huge effort into change, they get excited by it and happy about it. People don’t resist change: they seek it!

The truth is simpler:

People don’t fear change. They fear being changed in obviously stupid ways.

Additionally, changing any system alters the local context. That’s the whole point. This means that when we define a change project or goal, then get started, the fact that we have started the change will invalidate some or all of the goal. It becomes obviously dumb to keep going after the same goal.

We need to change our goal, and probably what we are measuring. The first ones who will see this are those doing the work; the last to see this are those “leading” the change. Leaders tend to be further from the actual experience and more dependent on the measures and data — which makes it very difficult for them to see when they are measuring the wrong thing.

Thus, change projects with a unified goal and measures create a conflict between those making the change and those choosing what change to make. All of Change Management is an attempt to resolve that tension — usually in favor of those deciding what change to make.

Yet there is a far more effective solution: make it possible for each team and person to make good choices about what success looks like for themselves, then do that. And that’s what Safeguarding does.

How to Safeguard

  1. Pick a bug. Any bug. (90 seconds, individual)
  2. Get together the right people, in one room: (15 min, individual)
    1. The bug finder, the bug fixer, the bug author, others with critical info from the debugging.
    2. Anyone required to approve adding work items to the current sprint (direct manager, product owner).
  3. Hold the Safeguarding meeting, following the agenda (20 min, in meeting).
  4. Add the remediations to the current sprint. (3 min, individual)
    1. Communicate to stakeholders.
    2. Add them to your sprint demo plan, including measures to show.
  5. DO THE REMEDIATIONS. This is really the only step that matters. Everything is just here to set up this step. (time as per timebox)
  6. Demo your results. Follow the demo plan.

Meeting Tips

Start your hazard identification with these 3 prompts:

  1. (The before question): what things increased the probability of the author making this mistake in the first place?
  2. (The escape question): what things made it harder for the author to notice the problem, thus allowing it to escape?
  3. (The recovery question): once we knew there was a problem, what things make it more difficult to find the cause & to repair the follow-on effects?

Require that each remediation meets these 2 requirements:

  1. Partially (not fully) addresses the selected hazards.
  2. Is completable in no more than 1/4 of the timebox.

Define typical budgets before your meeting (how much it is worth investing for a small-, medium-, or large-impact problem). Then pick your budget by simply doing fist of 3 to agree on the impact size.

Integrating With Your Process

Whether you are using one of these four agile frameworks or a different method, the Safeguarding process is agnostic and works well on its own.

Ready to Consider Adoption?

Deep Roots provides an adoption kit for teams to integrate Safeguarding as a part of work! Don’t hesitate to contact us for details.

Meanwhile, we encourage you to perform a series of experiments to both explore how Safeguard would impact work and determine the bigger gaps that your team or teams suffer.

Week 1 – Are you allocating time for your technical waste?

Week 2 – Are you solving hazards or symptoms?

Week 3 – What solutions don’t you see?

Week 4 – Where is your bug analysis inefficient?

Week 5 – What is your incremental work approach?

Week 6 – How do you demonstrate value for your work?