Who's my boss (anyway) ?

(This is a translated and edited transcript from my talk with the title "Wer ist eigentlich mein*e Chef*in" held at Scrumclub Dornbirn on 14.10.2020)

Just a quick check-in: Who of you is working in an organisation, that has been built Agile or Lean from the ground up? That never had any structure that did not work in an Agile way? And who of you is in the middle of some kind of "Agile Transition"?

During the talk, nobody in the room raised their hand when I asked the first question. Everybody was working in an organisation that is in some kind or other in a "transition to Agile", in various degrees and commitment.

And sometimes, that Agile Transition-thingy is a tad tricky, isn't it? One of the reasons for that is this:

That's the blueprint of a modern organisation. Virtually all companies are organised in such a pattern. Yours too? I bet it is. This particular organigram describes a company dedicated to the making and marketing of stoves. By now you sure have had a peek down and looked at the number written below. Yes, this really is the year when this organigram was created:

1914.

(In the slide deck, I have an additional slide containing just one exclamation mark to point out how utterly silly this fact is.)

How does that make you feel?

This structure is over a hundred years old, and is still the way we organise our companies. The world has changed since then, hasn't it? That's why we created Agile. And Agile Transformation looks like this:

Somewhere down the org hierarchy, someone attaches a little "Agile" Thingy, and expects them to innovate, and work agile, and stuff.

And the way they work is new, and therefore confusing, to a couple of people. It's very confusing for leadership (because this Agile thing works so radically different from our standard mode of operations), and it's also very confusing for individual contributers (because this Agile thing works so radically different from our standard mode of operations).

Specifically, there are at least five things in which an Agile team breaks from the tradition of organisations:

• Self-Organisation instead of Chain of command
• Backlog instead of throwing tasks over the fence
• Team success instead of invidual accomplishments
• Velocity instead of performance
• Pull instead of push

This break with tradition is also a break with traditional leadership, because the right columns actually describe how traditional leaders define their role in the organisation: They insist on chain of command, hand out tasks, praise "high performers", love teams ticking off boxes, and push tasks down the hierarchy.

With all of that gone, leaders might ask themselves what they are supposed to do, but more so, team members start asking themselves: If all of the stuff my boss used to do is now done by me or my team, then:

Who's my boss, actually?

A great question. So, let's have a look at the structure of scrum to see who looks like a boss:

Product owner?

Tells me what to do, and writes it into a long list of things, but that's it.

Scrum master?

Always wants me to attend some meetings or speak up or something, but if I don't do it nothing happens.

Stakeholder ?

I just see them every other week in the sprint review.

The - gasp! - Customers

Let's not go down there, ok?

That's puzzling, because there's no one that even remotely looks like a boss. Is it possible that there is no such thing as a Scrum Boss?

And why would you even need one?

The reason for this need lies in the way the modern organisation is structured. The people who actually know what the problems are, who have to deal with them on a daily basis have no say in how these problems are solved. They are the ones on the edges of the organisation, the smallest boxes the furthest away from where decisions are made.

And the question Who is my boss? actually is the question Who's in charge here?. And the reason we ask this is because we need some change to happen. So, what we actually want to know is:

Whose permission do I need to change something?

The simplest way to find out who your boss is, is to change something - anything. And whoever seems to be most agitated by that change (and you instigating that change) is your boss.

That's a clear sign that you stepped into what they consider to be their sphere of authority.

And the question where the authority of your boss starts has a flipside: Where does your authority end?

That's what you need to find out if you want to get Agile to work. How can you do that?

Go rogue

Change in a transitional organisation is a tricky thing. On one hand, it is expected of you to change things. But on the other, it is also expected that everything is signed off by the "person in charge", which nominally never is someone from the agile team . What you can and have to do is gradually expand your own sphere of authority. Find out how big your authority actually is, and start pushing that boundary outwards. And you can't wait for your boss to sign off on this thing.

So instead, you go rogue. You start doing things, because that's what actually is expected from you. But you do it with "fail-safe experiments". Things you can try out, and where nothing really bad can happen if they don't work.

If you want to tackle the "big issues" first, you will get so much resistance that your chances to instigate real change are practically nil. You might create something I like to call "change theatre", where people pretend something is different now, while they also make damn sure that nothing actually changes.

How do fail safe experiments look like?

They are effective internally, (like the way we meet, or the way we write emails), they don't cost a lot (nothing is best) and they generate evidence - data that they are working. Design them specifically in such a way so that they create data. (e.g. "since we adopted the policy of sending out an agenda before every meeting, meeting time has been cut by 15% and we have 20% less follow-up items in each meeting.")

The reason for creating evidence is that your ideas for change will be challenged, and you will have to defend them. Even if they seem obvious to you, they are not obvious to everyone else. And never underestimate the urge to keep everything the way it is.

That's because everything is the way it is for a reason. And that reason is: Somebody likes it the way it is. And in a typical traditional organisation, that somebody is very high up in the chain of command.

In short, if you want to expand your authority to change things, look right at the edge of your current authority, and push that boundary by:

• Changing something that is effective internally
• Seeking allies
• Doing it under the radar
• Creating evidence

And never forget what Grace Hopper used to say about change:

It's easier to ask forgiveness than it is to get permission.