Scrum helped us to take giant steps

Long live Scrum!

We do Scrum and… — episode 5

Scrum has helped our organization greatly to improve on many points. We are very happy with Scrum.

We weren’t in a great shape. We decided that we had to do something about it. One of the things we did was a re-implementation of Scrum. It brought us a lot:

• It brought us self-organizing teams. The Development Teams are empowered by the organization to organize and manage their own work. This optimizes a Development Team’s overall efficiency and effectiveness. And it gives them a voice.

• It brought us a safe working environment. Roles and responsibilities are properly defined. We have a way of dealing with situations when people ask for short-cuts. The Product Owner has the final say on the Product Backlog and the Scrum Team decides what they pick up. No-one else.
• It brought us an effective improvement process. The Scrum Team reflects regularly how things are going and what can be improved. The most obvious event for this is the Sprint Retrospective. We have implemented practices that helped us improve on many facets (coherence, quality, speed, safety, etc…). Best practices are being shared with the other Scrum Teams and as a result the whole organization benefits.
• It brought us a focus on value. The Scrum Team as a whole has the purpose to optimize valuable. This notion brought us to think about how we can achieve this. It is always part of our refinement sessions, the Sprint Planning, the Sprint Review and often discussed during the Sprint Retrospective.

• It works with Continuous Flow. We started with a complete Sprint Backlog for a 2 week sprint, but through inspecting and adapting we came to a form where we planned 2 or 3 items first and when finished pick up the next most valuable item(s).
• It brought us room to experiment and learn. Scrum is founded on empiricism. This means that we often try something out, a new way of working together, a certain solution to a problem, an experimental iteration. Based on feedback and findings we then change accordingly. Inspect and adapt.

• It brings us DevOps. We aim to have a ‘Definition of Done’ where everything that is required to get things from idea to production is within a team’s control. For us this meant that we needed to change the organisation structure because certain capabilities had to be transferred to the Scrum Teams (deployment to pre-production, User Acceptance Testing, deployment to production, DBA).
• It brought us smaller stories and as a result more flexibility. With the inclusion of other capabilities we needed to look with a critical eye to how big our items were. We brought more steps within our control, but the Sprint length didn’t change. As a result we are reducing the size of the items, which as a result allows us to be more flexible on what we actually want to deliver, what has the most value.
• It brought us effective resolution of organizational impediments. With Scrum we have several moments to inspect and adapt. Some of the topics we wish to address can’t be resolved by the team. These impediments are picked up by the Scrum Master and often brought to our corporate Impediments Wall. At the Impediments Wall we discuss on a bi-weekly basis what holds the teams back and how it impacts the organization as a whole. We vote on the most important ones to resolve and we action those. This bottom-up approach has resulted in a lot of good. We actually are tackling the items that have the biggest negative impact first.

These are all reasons why we are happy with Scrum. It wasn’t easy to get where we are and we still have many things to learn and improve. We have had earlier implementations of Scrum that were less successful. The most important reason why these implementations failed was because the organizational structure did not change at all. Examples are:

• Self-organization was limited
• Product Owner role was all but absent.

I understand why the Scrum Guide says that “Scrum’s roles, events, artifacts, and rules are immutable and although implementing only parts of Scrum is possible, the result is not Scrum.” There’s a reason for every role, event, artifact and value mentioned in the Scrum Guide.

Did you like the article? Then it would be awesome if you’d clap 👏🏻. I am also very keen to learn what you think about this topic.

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