What direction do you need?

Some friends with a little summer house in the beatiful island of Utö, Stockholm archipelago, always invite friends to visit, to stay in one of the two small rooms or in tents. Now they plan to fix their shed down the water to make it liveable.

So they have the idea to bring all friends for a weekend to restore & fix it together with them. Great idea. But ”oh my” my first thought was. A lousy carpenter I am (maybe I don’t know haven’t tried much), anyway with no experience, I can see this crowd of friends standing there with no plan and some tools and starting to discuss where to start, who will do what.  It makes me sick thinking of it. ”I’m more than happy to help out, but please please make sure there is someone gaffer from the start who tells me exactly what to do, and get us going.

This made me think about projects in general, and software projects. A group of people coming together to fix something will for sure gonna be a drain, it there is no direction at all. They’re gonna talk for days. About what and how.

This can work I believe, if you’re really really explicit about that it’s up to the group to decide – everything – and they have easy access to the money – with a sharp deadline and with very direct, personal and visible reward and outcome from the project.

But if it’s not and you just want the shed liveable in the way you want it, and the outcome for the crowd is just ”a pizza and some beers, and maybe access a night or two in the shed during the summer”,  this is not the way to do it.

When knowing nothing about how to build a roof, to do up the windows, fix the floors, install a small kitchen, we for sure need a lot of detailed direction. ”Paint this border of the window, first clean them, with this tool” etc. This will make me productive.

If there are some people in the crowd who knows some  more, they will only need to know ”you take care of the windows, here’s the material, and some guidelines, ok!” to get anything going. Anything more detailed will get them irritated and much less productive.

Someone might be a builder, or have a lot experience from hobby projects, and all she/he will need to know is some constraints ”fix the house” – it can’t be bigger than x m/2, and have to be red, and must include some sort of kitchen area. And this guy will make it. If you give her too much constraints she will just give up ”what’d’you need me for if you know everything yourself!?”

Depending on experience, different sort of direction is needed. Please don’t expect your friends, being there over the weekend, to ”sort it out themselves”. They won’t. They will spend hours talking, discussing, who does what, what should be done, how it should look. Ending up by the rocks having a swim pretty soon..  or at the porch having a beer ”to think”.

Please assign us some roles. ”You’re in charge of the windows” is very helpful even with no experience. Knowing I’d be in charge for window, I’d make sure to gather some people around to figure out what to do. But HOW to do it? With no experience, please give me someone who can give us directions. ”You should start with..”

In software teams, compared with a bunch of friends fixing a shed, we have most often at least some experience or education. No-one is totally rookie. Therefore we start a bit ahead. Still we can’t put together a new group of mixed people expecting a great result without any sort of direction.

Is the product owner’s direction on WHAT to do, enough for software teams?

And the way many project managers, especially less experienced ones, ”direct” a software team, is that really effective? To tell more or less senior developers & team members exactly what to do and how to do it, is that really working?? Or to say ”we’re agile” and with that leave all direction?

Is the HOW so unique and changing so there is no need for any sort of technical instructions? ”You should start with…” Ever?

What level of direction do YOU want and need for yourself? To be able to fix your software shed with pride?

And have you told anyone that?
For example your project manager, CTO, team members or other managers?

Please tell us at least with a comment on this blog, if not anywhere else. 🙂

Stop starting – Start finishing (Lean Kanban Nordic 2013)

Hi!

Back to normal again?
Exhausted after 4,5 months of real planning and 2 days performing of the Stop starting – Start finishing (Lean Kanban Nordic) conference at Hilton Slussen, Stockholm

I should really be going into ”Kvinnofängelset” mode and watching bad tv-series now. But I guess I’m in the ”Whatever” zone as Henrik Kniberg stated in his finishing talk.

Too tired & inspired to write any real content now, so STOP READING.
This is just some personal things that no-one should care about. Just once I decided to save these kinds of thoughts on a blog instead on a local not-backed-up disk.

During these months of intensive planning, coordinating, email-communicating, decision-making I have many times wondered – OH WHY!?

WHY didn’t I just say NO?

I have a full time job, two little kids & husband – aka DJ on the conference Open Night, trying to do some cooking sometimes (with or without them), exercising sometimes, meeting friends sometimes, put a little time in other hobbies sometimes, reading & writing sometimes and NO TIME to add conference planning.

Now I know why.

Maybe the same reasons as all the other idealists, crazy people out there, doing all these conferences all the time, over the world.

1. There was really no choice – suddenly you’re just there with the conference date set, and you didn’t know how it happened.

2. There is some mission that you have, that is just stronger than the inbox control robot in your head.

3. Enforcing surroundings from the mates that suddenly also said YES against all their rational mind.

4. The joy you see in many eyes during the conference. Without your no-choice commitment the particular event just wouldn’t have happened.

5. The many new and old friends you have met

6. The opportunity to give away small presents to people you admire in front of a big audience.

7. The draw to keep going out of comfort zone

8. The unavoidable learning you make. By arranging a conference I felt that I was more focused and learned more from the speeches than attending. Also just by arranging the conference you learn about communication, collaboration, organization, planning, trust, emotions, people..

So, to those of you that are in the middle of planning a conference :

YOU have no choice!
And many people will love you for that.

Lots of love to all participants and speakers and DF Kompetens for the Stop starting – Start finishing conference.

And to the sponsors of Open Night, without it, it wouldn’t have been the same conference experience. Thanks Frontit, Athega, KnowIT, IRM & LeanKit!

MAYBE – I will now take up some writing on this blog again. If you find nothing here – you might find something on the SmartBear blog
 I have a hard time deciding when to publish something there or here.. private hobbies & work just doesn’t need to be separated sometimes. Such as enjoying the time with great people at #sssf13 & programme team I can’t really divide in personal or work mates anymore.

See you around!

Get that management support today!

One big lesson learned at Kanban Masterclass in Hamburg this week, feeling a bit naive I haven’t seen it that clearly until now, is the real importance of prioritize to get managment support for implementing Kanban (or any other agile way of working).

As long as you have not introduced your managers and executives to the principles, rules and outcome of Kanban / agile you will stay at proto-Kanban level, where you do see better things happen with your little island of work, but can’t really do so much about the bottlenecks and real issues.

When you’ve got your Kanban board up running, you soon need to find ways and a language which will bring attention from managment.

Recently I’ve been a product owner proxy in a kind of a Kanban team. Our biggest issue, coming up at every retrospective, is the problem of individual work and multi-projects. We see it and do whatever we can to make it better, and it do get a bit better, but we don’t go any further on this.

My top priority for this situation, is now to find a way to get the closest line manager on board. To get her attention on what we’re doing. The line manager seldom care about ”Kanban”, ”Agile”, ”our development process” or whatever. She cares about predictability and fast moving business. How to get her to visit a demo and talk about these issues?

Prepare next demo to focus on presenting stuff that she, the manager, would care about. Not the details in what little features we have implemented last 2 weeks, rather do an ambitious preperation for next demo, with all parts of the team to get to speak.

• what have we accomplished last few months?
• What bottlenecks do we have?
• What is the estimated cost for business because of these bottlenecks and impediments? (qualitative or quantitive)
• What stops high priority marketable features to release at a higher pace?
• What good things have happened for us by limiting work in progress in the area the team control?
• What even better things will happen if management would limit multi-projects and go for team work?
• What would be the necessary changes in current organization of work to make that happen?
• Suggestions and dialogue with managment – with an 1-2 improvement step plan to take with support from manager.

You might have other issues reappearing every week. Is it time to now put an extra effort to involve managment?

That will mean to go out of the comfort zone and take on the shoes of the manager, show some empathy to understand what she needs and really care about, in stead of what I care about.

It would be much more simple to just run another internal team demo with the product owner.

Is it worth it?

Why Swedish organizational culture is still very hierarchal

This insight has recently got very obvious for me.

Swedish management seems to be quite famous, both inside and outside our national borders, for being ”softer”, ”open”, ”inclusive” or less hierarchal than many other countries. This is true when it comes to law and sometimes organizational structure. We don’t get fired for going to our boss telling them what we think. We might get an evil eye or two, but we don’t get fired, which is a huge different from many other cultures.

The law makes it very hard to fire someone, you really need to have very strong motivation.

Jan Carlzon who got Swedish leadership style famous by introducing the ”flat organization” in the 80’s I believe made a huge difference in his organizations, where transformational leadership was encouraged, teached and spread, where co-workers were supposed to take an active part in the development of the company. How much impact this style had in the 80’s I cannot tell, all I know is that today, in the 2010’s it seems not very common to include co-workers in the actual running and development of business. It’s common with ”co-worker-feedback-meetings” where ordinary employees are allowed to ask questions (often in a big room) and give feedback to managers proposals. And with one or two yearly kickoffs where management try to collect input on goals and vision from their employees. But to actually take an active and trusted part in developing the organization seems less common. I do see signs of change, and the change might go very quick very soon, if we allow us.

For all I know both managers and co-workers in most Swedish organizations have a very very strong culture of pushing all decisions to the one titled ”manager”, it’s managers deciding which projects are having a ”go”, it’s all managers in steering groups (why?? Is anyone actually still believing in that the manager has the most current and relevant information to make good decisions?), the teams always waiting for the manager to tell them they’re allowed to be more agile, get the stuff they need etc. In steering document I read it’s said that the mangers are making the important decisions. Where did the ”flat” structure go?

In the organizational schemes I see there’s always a manager on top of each box, solely responsible for the boxes success or failure. In steering documents it is said the manager(s) are responsible for project success or failure. What happened to the co-workers responsibility? Why aren’t the teams or groups of workers included in organizational charts?

Also, which myself is suddenly very aware of, are we – the co-workers behaving as expected. We never question the manager-run boxes, we go, without even reflecting about it, to the manager for each little decision that needs to be made.  Since we won’t get fired for going to the boss and tell them what we think, it IS very strange we don’t go to them with other questions than ”signing this decision” more often. We are so scared of our feudal leaders, we don’t dare to call them up in the phone and tell them we think the company should do investment A or withdraw investment B.

Someone told me, I think it was Diana Larsen or Esther Derby, that often the boss, the big manager, the CIO, CFO, whatever, actually WANTS the co-worker to knock on the door and ask for a chat. The thing is we’re so into this hierarchal mindset that we’ve never actually think it could be so easy. The separation of classes doesn’t exist anymore in Sweden (though segregation does) but we still act as if it was so, even though you and the boss went to the same school, or have your kids at the same kindergarten or are both members of  the local climbing club.

It’s all about our mindset. We gaze up at the top wondering why they won’t let us do the business. We’ve never even asked for it, and when we get promoted to managers ourselves we forget the intrinsic power we automatically get by title and just go ahead in our meetings with other managers wondering why the organization and business is so slow.

Each day businesses need to make many many decisions. To limit the power of the organization to the manager bottle necks with consequences of slowing down business isn’t this against all business reason and wisdom?

To not make use of the current knowledge, experience and information residing in co-workers to make well grounded decisions in the right time without delay, isn’t this a terrible waste ?

Inject agile by coaching?

Is it possible to inject agile in an organization by hiring an ”agile coach”? To cut lead times, getting to market faster, be adaptive for fast changes, and make your customers happier?

This is what I believe is true about agile coaching:

1. The agile coach as a full member of team

When you put an experienced coach as a full member in a team, in a role where his main assignment is to do some ”real” work like testing, developing, requirements whatever and also has an explicit coaching role there is a good chance the team will getting more agile, if they have the right motivation.

If the coach also have the mission to pass the coaching role on, to one of the team members, there is a chance the team will continue being more agile after the coach is gone.

Being part of a team, doing real work, and passing the coaching role on is crucial for a longer lasting impact of new agile practices.

What else happens when the coach leaves the team?  Good chance of regression to old habits, I’ve seen it quite some times.

If you’ve hired a project manager with assignment to introduce agile, it’s very important to be aware of her power as a ”manager” even though you might not see it. The team may not be committed to the new way of working and the new process might quickly disappear when the project manager is gone.

The project manager also has limited influence on what actually happens at the bottom line – where the work is actually done, in the craft. The project manager needs one team member, someone doing the craft, who is also an agile co-coach, to make stuff happen all the way. And agile stuff needs to happen all the way into the craft, otherwise you’ll soon find yourself in trouble with delivery, defects and budget.

As a project manager you can suggest technical agile practices such as pair programming, test driven development and more but you cannot make it happen unless one craftsman will be your co-coach.

It takes two to tango.

2. Coaching by Kaizen – Continous improvement

If you already have a complete team, don’t need more people on the work, and still want to inject some agile in the organization, I believe an agile coach can do good without being part of the daily work. This by in a disciplined, structured and inspiring way run Kaizen activities, for example retrospectives.

With regular intervals the agile coach can facilitate retrospective workshops with the purpose of getting the team by themselves suggest what process changes they’d like to see, help them with tools and preparations to do the analysis and action plans and commitments by themselves.

If you hire such a ”kaizen coach” you will let the team decide what will happen. As a manager you cannot decide or foresee the outcome or actions from these retrospectives. Ideas that you never imagined yourself will start to come out after a while of continuous retrospectives. Some ideas you’ll like, and some not – ”We don’t need a manager anymore” could be such a thing. Are you prepared to hear this?

I believe this way of working with agile injection could be the most effective and long lasting way of changing a team or organization. Since they have themselves chosen what changes will be done they for sure will be committed.

If you also believe this could be true, are you prepared to give the team(s) a basis to act on their improvement suggestions? This could mean time (for example 10-15% work time each month just on improvement actions) or money (pay for tools, people or other resources that the team suggests) or politics (changing premises, HR policies or process conventions for example). Are you ready to help the team?

I have seen teams excel by having ambitious retrospectives each week up to each 3rd week. Some people say that just by running a lot of retrospectives or kaizen activities all software teams will after a while come to method suggestions very much like Extreme Programming.

If you’re not working with software I would not be surprised if all teams after a while of disciplined retrospectives will come to more and more agile principles,  values and practices. ”Sit together”, ”Visualize progress”, ”Working closer to customer”, ”Small batches” etc.

Are you ready to walk this path?

The reward will be high performing teams, delivering value fast to market and a healthy and innovative organization.

You will need to invest.

3. Informal coaching

The next coaching style I believe is actually working is personal, informal coaching. Eating lunch together regularly, or having coffee or running a course together or just spend time together in some way. I have mostly in this way learned what all this agile is about and also to see other aspects of this that you cannot read in a book, technical as well as human.

No one told me these people would be my coaches, the coach relationship just emerged lasting long and changing me a lot.

This is deep change. As a manager, if you want this to happen with your people, just pay a little bit attention when you see some informal coaching relation grow between sometimes unexpected co-workers or an outsider. Don’t ask them why they had such a long coffee break today or why they don’t spend more time with the hired coach.

Let it be.

These are the 3 styles of agile coaching that I’ve seen working, heard stories about, and been part of myself in one way or another.

The large scale ”agile process change projects” could work if you focus on the three things above.

Complexity and Feature injection at Agile Lean Europe 2011 Berlin

While reading in news magazine Computer Sweden about all the big companies getting even bigger, and their sometimes so outdated strategies for development and business, I’m ready to agree with Brian Marick (@marick), saying that the only way being agile all the way is to start your own business. Several more people, among them Rachel Davis, said agile just won’t scale.

When companies are that big, you can make agile bubbles inside the company, networking with other agile bubbles in the company and have some changes happen. You’ll soon hit the system – HR, CEO bonuses, incitements, history, education and either you stay happy in your little agile bubble networking with your peers or you quit – and start your own business.

I still believe though you can make things happen with the mindset of the people around you in big business. I like being part of creating these agile bubbles all around, to see creative minds waken up from traditions, to dare to question ”the ways things always been around here”. That’s agile for me. Maybe you can’t turn an oil tanker around by doing Scrum, but you and your closest peers will learn a lot and have a lot more fun on the way and hopefully adding a bit more business value than usual.

Agile is a learning machine!  (Chris Matts quote I think, not good at remembering who said what)

Dave Snowden (@snowded) warned us agile bubble-creators that we’re in a danger zone of change and impact right now. It’s easy to get eaten by the old system when we hit the system right. So, he’s advice is you have to stop selling agile and start talking about it in other words! Now!

And that’s what Bjarne Bogsnes (Statoil) have been doing for a long time with the Beyond Budgeting movement, inspired and maybe strengthened by the spreading of agile thinking. I bring some of his words in my backpack. ”Event driven planning” in stead of ”Calendar driven planning” might speak to business people around there. And the metaphor: Having yearly budgets is like I had only 4 weeks a year where I could ask my bank for money. If it turns out the money is not enough the years consume and investments, I have to wait until next years ”open time” til I can get more money out from the bank, no matter what happens. And I have to spend a wasteful amount of time trying to foresee what will happen the coming year.

Dave Snowden also gave us another warning and important insight – it’s easy to get idealistic, to in the systems thinking way believe you can edit the process and then expect a certain outcome. That sounds like Lean thinking in my head. Make changes in the process and you should expect a certain outcome. Lean Software Development (and Lean in general) could probably add some complexity theories and improve to stay a relevant for the complex networks we act in, where there’s no one cause and no one effect.

Complex systems need constraints. Self organizing teams need constraints otherwise there is chaos. Compare with a self organizing birthday party for 10 year old kids. As soon as you draw an imagined border and say ”cross this and you’ll die!” team works getting better. Yes, we need management, nothing said about managers, but management. Constraints and Amplify/Dampen actions for the team.

Dave also gave a what we say in Swedish ”känga” (sort of a light kick) to all these Management theory x.0 books and courses. The same of old stuff. Anyway I think the ”Managment theory x.o” fills an important purpose. That kind of language talks to an audience normally not very attracted to ”Agile” ”Lean” ”Complexity theories” or whatever for them abstract and obscure strange name. Some hard core management words are needed to meet a wider audience, as long as we use them wisely. So for all of you that falls asleep when you hear about another Agile titled book, I recommend to buy Jurgen Appelos book ”Management 3.0 – Leading agile developers – Develop agile leaders”  and attend his course ”Management 3.0 – Agilt ledarskap i praktiken” in Sweden 24-25/10 at Citerus. Jurgen was one of the organizers of #ALE2011 and also got us bloggers a bit change management in practice at his talk. We’ll see if I change or not. At least I got the desire injected.

Here are More notes from Snowden’s talk.

Feature injection was a fun session with Chris Matts (@PapaChrisMatts), lovely British IT Risk Manager. dare to call himself a BA. (Am I the only one actually liking BA’s btw? They’re a competence all to often get wasted by putting them away in lonely rooms – not Chris I’m sure but a lot of his profession colleagues.)

”What’s the worst thing that can happen in a presentation?” he had a conversation earlier. What happened..  His session got feature injected by a minute of birthday party thrown by the lovely kid’s programme. Oana, one or two (?) of the kids mother was the happy celebrant.

Anyway Feature Injection, sort of a real application of pull system in systems development. Happy to see there is a theory for something I learned in a project not long ago – maybe a little too late – that YOU have to start with the recipient of your systems output, no matter who this is. This recipient, end customer or reader or whatever end user – has to first pull features developed from the systems. Ooach! This means that I really need to put end user’s first!? Again!? Oh all these end users all the time, please. It’s really challenging to implement this thinking, since the recipient often is a partner, who you don’t have really close development practices or relations with, or end users where the threshold for involving them early early in the process is very high – ”we’re only in pre-study”  ”we’re in such a hurry” ”the money doesn’t cover user recruitment..”

Anyway. Feature injection seems to be best explained by comics. And I love to hear about some real cases in Sweden. Will my case be the first, do I dare? I would for sure need some information/domain modeling expert, since the injection go all the way to the details of implementation.

clip from infoq.com. Whole comic

More about Story Mapping and ALE2011 in next post.

Thank you Caios for helping me out in a tough time
Thank you Tibault for great photos
Thanks to Olaf for spreading humbleness around
Thanks to Birgit for making me think.

Thanks to all people for being so friendly and bringing such a heartly atmosphere around you

What happened more in ALE2011 – Berlin – 7-9 sept

The system is you!

“Changing the system, will change what people do. Changing what people do, will NOT change the system.” (Peter Sholtes)

The system that people work in accounts for as much as 95% of performance, as Edward Deming said.

What Deming and his followers say, is that it’s no point for a manager to try to optimize the perfomance of workers, by pushing them to work harder, more, extensive training etc. Managers and others need to change the system, to make any visible change in performance.

So is there no need for you to change? To start take individual accountability for the environment you work in, and the conditions that stops you from doing what you believe is right?

They do NOT say that individual actions has no effect. Individual actions is another story.

Who created the system in the first place? People.
Who sustains the system we work in? People.
Who has the possibility to change the system? People.

In fact, the system cannot change itself. It has to be changed by people. Managers, co-workers, team members, people like you and me.

When you realize that YOU are the system then it’s easy to see that you can make a difference. By using courage to say NO to useless re-organizations, to suggest better ways or go to agile war.  To say: ”We’re not doing this anymore!”.   All successful organizations, revolutions and break throughs in innovations and working conditions has started with someone not aggreeing with how the system works.

If all people believed that individual action has no point, that it’s all about ”the society” to change by itself, women would still have no voting rights, dictators would still sit comfortably in northern Africa, we would still have feodal rulers everywhere, slavery would still be legal.

These are big changes that has happened. In the agile IT community we’re talking about much smaller changes. Like how our work places are arranged, how the team sits, what tools and routines we’re instructed to use or what internal politics says is right or wrong to do for you as a co-worker. So of course there is much easier for us to make changes. Small change – small revolution.

Have you allied with your team members lately? Do you want to use Kanban, but the project manager doesn’t? Do you want to do retrospectives, and your project manager doesn’t? You want to automate tests? Your manager says you don’t have time? Need a product owner on site? No one will give you that unless you do ask for it persistently, creatively and humble with a decisive look?

Get allies, as the labor unions did. When you’re 6 out of 9 in a team that really wants to throw out the document heavy process and put in face 2 face communication or whatever agile technique or method you like to have – it’s easy to organize yourself and make changes!

It’s a bit ironic how often I hear agile minded team members (sometimes myself even) say that they need the project manager to change before they can go agile. You need a manager to get self-organized, is it so?

You are the system. You cannot change it all by yourself. But sure is, you can be the first to say NO!

If you first get friends with the one that stops you from doing whatever agile thing you like to do, by inviting him or her to lunch and show some interest and respect for his passions, then the NO will for sure be much easier to turn into a YES – we will change our little world, our little system to a little better place to be in.

Thx to friends at Agila Sverige conference for making me think.

Leadership in agile organizations

While reading leadership theories there are some patterns that fits well with agile values, principles and ways of work.

In The Starfish & the Spider (Brafman, Beckstrom) the role of the Catalyst is prominent. The one who just acts in the background, connecting people, make changes by full attention listening, true interest in the other person (team member for example) and respect. A quote from the book: ”If you have a boring conversation with someone at a dinner for example, it’s just you who haven’t asked the right questions yet”  That’s the way of thinking of the catalyst, always finding something interesting about a person, worth of respect.

In As One (Baghai) two leadership archetypes are outstanding, fitting with agile way of work – Community Organizer & Volunteers  and
Captain & Sports Team

A short quote from the summary: ”Community Organizers ignite volunteers’ interest through compelling storytelling and opportunities for volunteers to join in.[…] Volunteers themselves are drawn together by a rallying cry, or out of a sense of enlightened self-interest; they gain their power through a strength-in-numbers approach.

The Captain & Sports Team pairing operates with minimal hierarchy and acts like a single cohesive and dynamic organism, adapting to new strategies and challenges with great agility as they appear. […] There is strong camaraderie and trust among the sports team – the collective good outweighs the needs of the individual – while captains are there, on the field as part of the team, to motivate and encourage.

and more reading:

Ken Blanchard observes, “The key to successful leadership today is influence, not authority.”

In ”How to extend your influence” Rockwell talks about the necessity for a modern leader to leave isolation to have influence on others by building communities:

”Community building contradicts isolation and means:
1.    You join their team before they join yours.
2.    They win before you win.
3.    They influence you before you influence them.
4.    You, “Seek first to understand and then to be understood,” Stephen R. Covey.
5.    You give before they give.
No one freely joins your community when they believe you’re in it for yourself.”

This way of  leadership style I believe is what you need to do if you want to introduce agile and get the full effect of the agile models.

The Dao De Jing famous quote ”Of the best leaders the people say – ‘we did it ourselves'” says exactly what the agile leadership is all about.

You need to get your people to buy in by themselves, by finding what’s their glow , by letting them fail forward, learn and try. Back off, and be there for them when they need you and asks for your help.

About the problem solving role that many project managers I know have, love and are much appreciated for – there is an option for being the catalyst community builder type. Going Andon.

At the production line at Scania Sweden they have something called an ”Andon person”. Inspired by Toyota of course. This is the role I wish all you problem solving lovers out there will have in the near future . The Andon is someone the team calls upon when they can’t fix a problem by themselves. They pull a signal and the Andon shows up.

The Andon corresponds to ScrumMaster but is a somehow more comfortable and easy to explain role in my opinion.

The leadership is changing for sure. Maybe all of us need to change.