I am huge believer in the scrum master role as a leader without authority.
Strong scrum master(s) can change the world, or at least the organization. Bad scrum master(s) team can keep the organization standing still, or getting worse.. 

During my work as an agile coach I have identified certain things that many great  scrum masters / people leaders do. 

While writing this blog post, I wanted to make you, the reader, think on the following questions:  

  1. Are my scrum masters / People leaders fit this description?
  2. Do I fit this description?

If the answer is "Yes": Great! You have been reinforced.

If the answer is "No": Where is the gap? Would you like to improve in this area? (If yes, I probably can help you here, let's talk). Maybe you disagree? 

I would be happy for you to share your thoughts, and receive feedback, after you complete this 3 minutes read.

 

Add a comment

Based on real life experiences.
Although the names and events in this story are not real, they are based on numerous agile transformations I have encountered. Followed by a remedy - lightweight, simple to understand and difficult to master - just like Scrum.

The hype at the beginning of the agile transformation at Iguazu Mobile Technologies was inspiring. The HR business partner of Mobile Search, the department to pioneer agility at IGT was fully on board, helping with copywriting of cool slogans and treats and fun games at the office space.

Willy, the general manager of the group was very crisp on his message at the All-Hands meeting: “We are embarking on a journey to replace the operating system at IGT, and we are the pioneers of this transformation. We have set goals to improve quality, as measured by fewer bugs and dramatic improvement in automation. Reduction of Time To Market as measured by  under three months releases. We also have a goal of happier people, as measured by honest smiles as we get to work all through going back home”. Willy had that magnetic style that kept everyone engaged and hardly no cynicism was noticed in the room.

Freddy, the chief transformation officer was smiling with everyone, and enjoying the gourmet snacks. But as people emptied the hall, a few wrinkles returned to his forehead. “Look Willy, your talk was awesome, and I enjoyed how you honestly conveyed your view that we will all make mistakes - and correct them. The thing I am still uncomfortable with is our approach to the stabilization period at the end of each release. I fear teams will revert to our old Waterfall ways when most of the work is testing and bug-crunching. We should be explicit on the notion that stabilization is in the same rhythm as any other Scrum sprint”.

“Relax, Freddy, enjoy the beer. This is a day of celebration, not concerns”.

The weeks flew by, and most teams were becoming increasingly happy. The Scrum Masters have set up a Smart-Up - their own brand of a SM community of practice. Two of teams were struggling, and IGT sadly had to part with a few highly experienced engineers, who didn’t fit into the new model.

Towards the designated release date even the two struggling teams began to show signs of improved satisfaction, and, shortly after, their throughput began to modestly increase.

Freddy scheduled a meeting with Willy. Scheduling such meetings was regularly a challenge, and this meeting was no exception.

“What are the current plans for releasing the new version?” Freddy asked after the initial small talk.

“We’re not aiming for a 3 months release. We just have too little scope delivered, and we promised much more. We will release in 3 months when the teams finish our Search Reinvented initiative”.

Freddy could feel the rug pulled from under his legs. He knew from the burn-down charts that there is hardly any chance of delivering the entire Search Reinvented in 3 months. He also kept communicating to Willy and his staff that this is hardly likely to happen, and that it’s better to release a smaller version to start getting feedback from early adapters. He also knew that the most prominent Scrum Masters kept delivering this message to Willy's staff.

“In our last staff meeting we raised concerns that the stabilization period will be too long for such a small scope, and prefer to do it once and good rather than repeat the same mistakes twice”.

Freddy pulled all the agile coaching rabbits from his hat, but he knew this was a losing battle. In 3 months the release will still not be ready, there will be many more features, and more integration and scale issues will get uncovered. Stabilization will be long and teammates motivation will get impaired. 

Four months down the line Willy held an All-Hands meeting, declaring that they will release the two mega-features that are ready for Mobile Search. There will be a single stabilization sprint, after which they will release. The other Work-In-Progress features will be halted, and they will commence a new version for Mobile Dreamweaver.

Freddy was aghast. It didn’t happen to him often, but after all the talk and all the promises and all the tons of empirical data screaming in the face of Willy and his staff, he was damn right disappointed. He could see all this coming from miles away, but in real-time this event overwhelmed him.

Of course, stabilization sprint turned into two, then two into three. At the fourth stabilization sprint some compromises were made on priority of bugs. Out of the window goes quality, together with 3 months release. Needless to say that both quality and time to market lagged behind motivation, which flew out of the window and hit the ground at hyper-terminal speed.

By that time, most teams held some kind of disheartened daily meetings. Half the teams didn’t retrospect once through stabilization period. By stabilization sprint 4 none of the teams held a planning event, and none held any review event.

The Sprint Review Bazaar that everyone raved on early in the transformation seemed like a distant dream from another era.

As the new release commenced, Willy held another All-Hands to kick off the new Mobile Dreamweaver version.

Sprints came back to life, planning events, refinement meetings, Scrum Boards in the rooms. But the spark has gone off the transformation. It’s as if a zombie colony was practicing Scrum.

Agile transformation at Iguazu Mobile Technologies was, by now, dead.

Do yourselves a kind favor - don’t do stabilization sprints. If you must (because you have some sort of an UnDone Department to handle before release), treat them at the same vigilance as any other sprint - Planning Part I+II, Refinement, Sprint Review events, team and overall retrospectives - the works.

We’ve seen that Stabilization Spiral Downfall movie before, and it does not have a heroic Hollywood ending.

 

Add a comment

Site search

How can we help?

Email:
Subject:
Message:
multiply one and three and get

Register to get notified about new blog posts