Facilitating Change Process

Disclaimer: all credit to me writing this goes to Vasco Duarte. We recently recorded an entry for his Scrum Master Toolbox podcast (I highly recommend listening!)

Here is where Vasco asked me for a real-life team story of a change process that I had been involved with, what happened, and, of course, what I learned from this experience. What were the tools, and techniques developed based on that experience, that we all could take and apply today? 

As Scrum Masters we are responsible for changing the organisations we work with. And for that we need to develop our change leadership skills. 

In the story I am telling, over time a quite big team planning sessions had become half-day marathons. Why? there were so many tasks to run through which meant there was only enough time to raise a handful of questions and challenges. It had become almost impossible to predict any feasible outcomes in their cycle.

After all, any great team want to have predictability of cadence and come together with every short cycle to craft their plan of attack. And as Eisenhower reminds us: plans are useless, yet planning is indispensable!

We needed to tweak that, to become more effective.

After some influencing and convincing we did one of my favourite things to solve a challenge:

Throw people into a room:

Yes, a virtual room also works! The importance of visuals and the ability for all to draw/contribute is key.

Part 1 - Awareness

We held a session where fifteen themes of work were presented; for each area we all discussed the benefits and how each theme contributed to the company's vision. Cross-functional teams don't just care about implementing features but also how those features can go through the value stream all the way to production/market without chaos and disruption so that becomes of value. Hence the importance to reinforcing which bundles (themes of work) we were setting ourselves out to tackle and WHY!

Part 2 - Boost

In the next part of the session, the full team of forty people each then ranked these themes from 1 to 15 based on their skills and their interests. Number 1 being assigned to the area they were most interested in getting involved with and 15 the least interested in being involved with. 

After all life is perishable, as humans we want to spend it in meaningful interesting stuff. Having a good level of pursuit, challenge and also perseverance (not all can be a happy clappy fairytale)

Part 3 - Coordinate

The team then grouped the fifteen different themes by context and desired delivery quarters ahead. 

Because, as we know, not everything can be done at the same time, it is actually much better to enable focus. So that we can finish things, it's the finished things in the hands of users that bring value; many things in progress do not. the latter also produce deviation and waste, including but not solely by context switch.

From that 5 groups of work emerged, we called them "Goodie Bundles"

Part 4 - Deduce

Lastly, they self-appointed and defined the teams that would tackle each of the grouped bundles of work. 

From the ranking exercise it became obvious that there were some more interesting bundles than others, so we asked the question: How could we group the bundles for a fair balance?

After a few rounds, the team reshuffled things to a point they were happy to give it a try.

Part 5 - Elevate

The team was A team that over the years have grown organically. Even with forty people was a team that functioned smoothly, no one wanted to mess that up!

By organising themselves into more manageable focus groups (bundles), they knew they could evolve the architecture, requirements and designs from each one of the grouped themes, because the direction and themes of work had been set as a group.

That was only the beginning. The Plan, The Plot and The Process was reviewed and tweaked throughout as new information emerged. I'd be naive to think one can draw the future in a straight line and expect for that to actually happen.

A general tip for Scrum Masters:

Learn what works first, then for tweaks do not impose, instead Co-Create.