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

Several weeks ago, Josef (pseudonym), a dad from my son’s school contacted me and sent me a link to this article: “A Before-School Exercise Program May Help Children Thrive”.After reading the article, I talked to Josef and agreed with him that I will take it with the principle and carry it forward.

The next morning, I talked to the principle Oren (pseudonym). I requested to arrange a pilot - MVP - of a sports activity for about 30 minutes. Oren was enthusiastic about the idea. Due to the school’s busy schedule, we planned the activity for the following week.

Add a comment

Have you ever thought what Marathon Running and Product Development have in common?

I started my software development career in 1998 as a developer and along the way I fulfilled various other roles such as R&D team leader, project manager and product manager.

I started training as a long-distance runner in mid-2014 and run my first Marathon in October 2015.

There are several posts comparing product development to a marathon. Clearly, both are not simple tasks.

In this post, I would like to share from my personal software development and long distance running experiences aspects Marathon running and Agile Product development. 

1. Support systems

When getting ready for a marathon, one must get his/her support systems in place. Fore example, match your nutrition with your training plan.

In product development, it is recommended that the organization has upper management buy-in, CI system in place, test automation capabilities and well-defined DoD.

2. Expand your skills

Great athletes train in an additional one or two types of sports every week such as bicycling, strength training, rowing, cross training, swimming or elliptical training helps building core muscles such as abdominal and back muscles as well as hamstring, biceps, triceps muscles etc. 

Agile product development is based on technical excellence. Developers has to expand their skill sets as well as develop their core skills.

Add a comment

Unlike most of my blog posts, this one is not an opinion or some deeper insight or analysis.
It is a description of the result of an evolution of a workshop Ilan Kirschenbaum and i developed that is called a "Retrospective retreat"
The Retrospective retreat is a workshop that is very similar to code\coach retreat in which it is targeted at creating deliberate learning through repetitive practicing  of the Retrospective.

Add a comment