Our organisational improvement Scrum teams

Our organisation is constantly changing — we manage this with Scrum

Part 2: our first ‘inspect and adapt’ opportunities

Introduction

This is part 2 of the series:

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 is constantly changing.

This is why we decided to set up two Scrum teams to drive the changes.

Lessons from our first Sprint

As brought forward in my first article we learned a few things from the first Sprint. We would:

• Work on what the people need most first!
• Add the agenda of the Sprint Review to the invite, including the items that will be discussed.
• Book a different room that might be smaller, but doesn’t scare people off. The restaurant — our first option — is often used for presentations. So perhaps people confused our review with a presentation.

We had other observations too:

• We lacked focus;
• Our items weren’t ready to be picked up. Most of them required to be fleshed out during the Sprint, which wasn’t very efficient.
• We didn’t know when an item was ‘Done”.

Focus

Instead of spreading the work randomly over the 2 Scrum teams we decided that a team focused on a theme. An example: team 1 decided to focus on Incident Management improvements. Team 2 would focus on creating a CI/CD proof of concept.

This also meant that we wouldn’t automatically work on the items highest on the backlog. Instead we worked on the most important set of items fitting a theme.

Refinement, Definition of ‘Ready’

We decided to have regular refinement meetings to ensure that we we had mutual agreement on the items high in the product backlog. We found that the people that we have within the teams couldn’t work with refinements ‘on the fly’. These refinements needed to be planned so people could manage their time. The managers in our midst had many meetings to attend, so having the refinement as a predictably planned event helped them. Other team members were also part of another Scrum team where they did their primary job. They needed clarity too.

We found that we needed to determine when an item was ready for the Sprint. This is why we agreed upon a definition of ‘Ready’ (DoR). Here are some things that we decided to be as part of the DoR:

• The objective of the item is clearly described;
• The acceptance criteria of the item are clearly described;
• The item would be sized. We agreed upon three flavours of size: “very small”, “fits in a Sprint”, “too large for a Sprint”. Items that were deemed too large for a Sprint were split into several parts to make sure that they could be finished within a Sprint.

Definition of ‘Done’

We also needed to determine when an item was finished. So we needed to have a definition of ‘Done’ (DoD). We had many different types of work. This made creating a DoD complicated. However we saw a couple of things that the items had in common:

• We needed to communicate the output of the work on the items. The means of communication could vary. For some items an e-mail sufficed, for others a separate session with stakeholders was needed.
• We needed to achieve consent on the output of the items. We weren’t looking for approval from all our stakeholders. Instead we aimed to establish that output was considered to be adding value and that no-one did object to it. We determined that this was vital to allow experiments to be conducted.
• All items needed to be discussed during our Sprint Review.

New Sprint Review setup

I already informed you that our first Sprint Review had many people attending, but almost no interaction. We decided to communicate the agenda of the Sprint Review upfront and booked a training room instead of the canteen.

We started the review with a drop of 50% of the stakeholders showing up compared to the first Sprint Review. Which was disappointing for me. However there was a lot of interaction between the Scrum Team and the stakeholders.

We received great feedback on our work and the stakeholders also brought forward other great ideas to work on. We also saw that several of the items brought a smile on some people’s face. The incident management changes were very much needed and also our CI/CD experiment was a success.

This told me that:

• the people that were truly interested in what we did showed up AND gave us valuable feedback;
• the decision to focus on the items that people needed most was a good one;
• the move from the restaurant to the training room apparently removed some blockers, because there was plenty of interaction.

This doesn’t mean that everything was great:

• the attendance wasn’t as we hoped for;
• we underestimated the time required for the Sprint Review and as a result had to stop before we could address what we’d be doing next;
• we received feedback that we appeared to be working in isolation, forgetting about the existing teams. We didn’t see it like that because we believed that we worked with those teams. However we needed to take this feedback seriously to get to the bottom of it.

Other lessons learned

Our focus did certainly help us to work on items as a team, contrary to how we worked in the first Sprint. The team took ownership to deliver the items that fit the theme.

The new Definitions of ‘Ready’ and ‘Done’ enabled us to be on the same page of what we needed to do and by when we could say we finished the items.

The work for the Scrum teams was still considered to be on top of the normal work. However, considering that a large part of the organisational improvement Scrum team consisted of managers that had this change as a major objective I believe that this shouldn’t be true. On the contrary: the Scrum teams allowed them to be focusing on the next improvement steps constantly with help of motivated people that volunteered to work on this on top of their daily work. They should be embracing the opportunity to focus and the help from the volunteers. What could be a reason? Well:

Perhaps their plates are too full — made transparent because of the existence of the Scrum teams.

Final words

As any other Scrum Team we needed to find our best way to work with Scrum. As Scrum is only a framework it’s up to the Scrum teams to determine many things. Examples are:

• how to do refinement;
• what would be a good way to determine if items are ready to be picked up in a Sprint;
• how to determine the Definition of ‘Done’;
• the importance of the Sprint Review to bring forward what you have created and what you have learned plus the feedback you get from your stakeholders.

Working with Scrum is a journey. You will constantly have to inspect how effective your way of working is and then adapt if needed. We will continue the journey and I will report how we progress soon.

Thanks for reading. Feel free to bang that clap button. You can give up to 50 👏’s. Give it a try if you enjoy this article!

My twitter profile is https://twitter.com/WJAgeling

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

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