Our organisation is constantly changing?-?we manage this with?Scrum

Part 1: forming the Scrum team

Introduction

Our organisation works in a complex environment. We have to adapt constantly to remain technology leaders. Sometimes we have pivotal events that come across as drastic changes (like forming a new organisation structure), but in reality the changes occur organically with pivotal moments that define the current direction.

Our organisation is constantly trying to improve and therefore constantly changes.

Examples of improvement areas are:

• Getting business, developers and operations closer together;
• Improve the processes to handle incidents and changes;
• CI/CD initiatives.

Decision: form organisational improvement Scrum team

With the notion that we are on a constant journey to improve our organisation we decided to form a Scrum team responsible for improving the organisation. These are the reasons for this decision:

• Our environment is complex;
• We wish to make decisions on what is known, not on assumptions;
• We wish to involve our colleagues and verify our progress with them.

We also saw these additional added benefits:

• We wish to be able to improve our way of working and Scrum helps us to do this;
• We wish to align on a daily basis how we are doing to achieve our goal for the sprint.

Creating the Scrum team

After deciding to create a Scrum team we presented our plans to the organisation, a group of around 200 people. Then we asked for volunteers. We told them that they could make a real impact. We also told them that they were expected to be active participants of the Sprint Review where we would share our progress with our stakeholders — their colleagues.

We had 17 volunteers, a higher number than expected. And more than what fits in a Scrum team. But the solution was easy: we would create two Scrum teams.

Some of us were already part of other (Scrum) teams and volunteered to help out. This meant that these people needed to find a solution for their other team. They would spend a certain portion of the time on the Organisational Improvement team, which would be impacting their other team.

Others — mostly management — saw a large part of their work — being servant leaders for the teams by empowering them — structured within a Scrum framework.

Defining a mission

Now that the Scrum Teams were formed we defined a mission. This mission is somewhere in the line of:

“The organisational improvement Scrum teams exist to help optimise the efficiency and effectiveness of our organisation by performing, facilitating or assisting with changes continuously.”

The newly formed teams should help the organisation. They shouldn’t contribute to double work or — even worse — solutions to a non-existing problem or solutions that create another problem.

1 Product Owner — 1 product backlog, 2 Scrum teams

We established 2 Scrum teams, but we still had 1 Product and as a result 1 Product Owner and 1 Product Backlog. This also meant that the two teams would have 1 Sprint Review.

The Product Owner is one of the Directors because he is in the position to make the ultimate call of what is most valuable to the organisation. Having said this: the Director made it clear from the start that the Development team members were allowed to add items to the Product Backlog and to prioritise these items. He would simply keep an eye on the backlog and be involved in the Sprint Planning. This was deemed sufficient to allow the Product Owner to be accountable.

First Sprint Planning

The first Sprint Planning was a bit chaotic. We only had a few items on the Product Backlog, we didn’t know what we would be able to chew and we had many ideas in our heads to be picked up. We were a bit careful and were conservative with our Sprint Goal and accompanying backlog items. Our Sprint Goal was mainly to establish the Scrum teams and to make ourselves known, especially with the Sprint Review.

First Sprint

All of the members of the Scrum teams did have plenty of Scrum experience, so we immediately got into a flow. I think this is one of the big benefits of using a well known framework. The events, roles and artifacts are known to all.

We did not finish everything we planned, but overall the Scrum team was quite happy with what we accomplished. We were all looking forward to the Sprint Review.

First Sprint Review

We made a big announcement and booked the biggest room (the restaurant). We weren’t disappointed about the attendance. Almost 50% of the people came. But it wasn’t very interactive. We did all the talking and we received almost no questions.

We learned that our Sprint Review was not effective in multiple ways:

• It was our first Sprint Review. This event was largely about us finding out if the location and set-up were effective.
• Many stakeholders didn’t know what they could expect. We hadn’t been very clear in informing them what we would be aiming to achieve with the Sprint Review.
• The restaurant is often used for presentations. Many confused the Sprint Review with a presentation and as a result did not feel the urge to interact.
• People had to use a microphone to chip in. It did prevent some from bringing their opinion forward.
• Most importantly: people didn’t see us tackling the items that were really of interest to them. We came to know this after seeking feedback from the people that took the time to come to the Sprint Review. In fact: this feedback was crucial for us to adapt.

Conclusion

During the first Sprint we delivered more than I expected. I was convinced we over-committed. We indeed did, but still we were pretty productive. But we had trouble to bring our message across. So we weren’t super happy. We decided to dive into why we didn’t really engage with the people. Here’s what we found:

• We didn’t cooperate with them to find a solution for their needs;
• We didn’t communicate our outputs before the review;
• We didn’t really touch the heart of what we intended to do. We did only lay the groundwork.

This is why we decided to do the following:

• Work on what the people need most first! This will be the best proof that we take the feedback seriously. And of top of that: they often know best what is holding them back.
• Add the agenda of the Sprint Review to the invite, including the items that will be discussed. This allows people to make an informed decision to come (or to stay away).
• Book a different room that might be smaller, but doesn’t scare people off. The new location could only have 50% of the people instead of 100%. But it would be unrealistic to expect everyone anyway.

To be continued

My next episode will inform you how we put these ideas into practice and how this was received. Once it is ready I will put a link here.

Do you want to share an article in Serious Scrum? Connect with us and make it happen!

Also, you’re invited to the Serious Scrum Slack workspace. Come join the conversation! Follow this link