15 minutes showed me our Scrum was broken

Sometimes it takes the smallest things to show you the biggest problems you have. A humble 15 minute meeting, The Daily Scrum, told me so much about how we needed to change as a team.

I recently joined a new organisation as a Product Owner (PO). It’s a large enterprise company which is well established in its field. I’m pleased to say it’s been a joy so far, with great people and a great culture.

While we had adopted Agile ways of working, the way the team was using Scrum wasn’t so good. I’ll talk about this in future blogs — particularly on the problems we’re working through and our journey to fix them.

In short, our team’s good work was despite our Scrum, not because of it. We were doing Zombie Scrum. It looked a bit like Scrum on the outside. On the inside, it had no beating heart. No soul.

The most surprising thing was I knew something wasn’t right almost straight away. Within my first hour into the new role, I went to our first Daily Scrum. My first one and others since have told me so much about what wasn’t right. Before I share some of the symptoms of our sick Scrum, I found it helpful to go back to what this is supposed to be about. A reminder of what the Scrum Guide says about the Daily Scrum:

The purpose of the Daily Scrum is to inspect progress toward the Sprint Goal and adapt the Sprint Backlog as necessary, adjusting the upcoming planned work.

The Daily Scrum is a 15-minute event for the Developers of the Scrum Team. To reduce complexity, it is held at the same time and place every working day of the sprint. If the Product Owner or Scrum Master are actively working on items in the Sprint Backlog, they participate as Developers.

The Developers can select whatever structure and techniques they want, as long as their Daily Scrum focuses on progress toward the Sprint Goal and produces an actionable plan for the next day of work. This creates focus and improves self-management.

Daily Scrums improve communications, identify impediments, promote quick decision-making, and consequently eliminate the need for other meetings.

The Daily Scrum is not the only time Developers are allowed to adjust their plan. They often meet throughout the day for more detailed discussions about adapting or re-planning the rest of the sprint’s work.

Our problems went further than our Daily Scrum. Though that frequent, short meeting showed many of the symptoms of the problem. Five things told me our Scrum needed fixing.

1. If the Scrum Master or PO didn’t start the meeting, it wouldn’t sometimes happen.

The purpose of the Daily Scrum is for the team to regularly see how recent work contributes to achieving the sprint goal. It’s a moment to inspect and, if necessary, adapt. If the sprint goal is the north star for that sprint, the Daily Scrum allows the team to make course corrections if they start to move away from reaching their destination — a working increment. If the meeting doesn’t happen, the team lose an important opportunity to review and make any course corrections.

The Daily Scrum isn’t the Scrum Master’s or PO’s meeting either. They don’t need to be there. It’s a meeting for the Development Team to run it in a way they think best. As the meeting wasn’t always happening, or often starting late, this also told me the Development Team weren’t self-organising. Another problem for us to fix later.

2. The meetings had no focus.

Even worse, most of the meeting was a social check in, where the conversation around the Sprint Backlog and how things were going was an after thought. Don’t misunderstand me; in these COVID times, it goes without question that we need to be supporting each other and spending more time checking in. I’ve seen first hand the difficulty extended lockdowns have on mental health and people with parenting or caring responsibilities.

However, misusing the Daily Scrum did show me that the team didn’t really understand its purpose or value. Without know its purpose, it’s understandable the team didn’t feel like they needed it each day. The purpose of the Daily Scrum later became one of the first Retrospective sessions in our journey to recovery.

3. The rest of the meeting was a check in/status meeting for the PO.

While I didn’t take the lead in the early days, it quickly became apparent the team had come to expect the Daily Scrum as the PO’s status meeting. Each team member would say what they would be working on today and answer the PO’s questions on the status of individual items.

With this approach, the team is not encouraged to self manage and deal creatively with a solution. The entire meeting rests on the PO, which then also diminishes that role. The PO is a value maximiser, working with the Scrum Team to deliver value to customers or users. The PO should never be a traditional project manager or, worse, a delivery manager. This misses the point of what this role is about.

4. We didn’t discuss anything in a joined up way.

The key way a PO expresses value is through the product backlog. This is an ordered list, with the most valuable items at the top. How a PO determines value, crate backlog items is up to them. It won’t look the same for each team, changing depending on the context.

In our context, the backlog was expressed through single tasks. Build X, create Y, user Z needs AA. The PO would then pull all the items together at the end to create something resembling an increment. This was problematic for several reasons, though in the context of our Daily Scrum, it meant the team never really looked at an outcome as a whole. There often wasn’t an understanding of the value a piece of work delivered back to our customers. The Daily Scrum was, in effect, an update on the daily activities. There was no real collaboration, no view of the bigger picture.

5. The sprint goal was never discussed.

Even worse, we usually didn’t even set a sprint goal. There’s not much more to say here, other than a sprint goal is an essential, non-negotiable part of the Scrum Framework. For a good reason too. If there’s no sprint goal, the team don’t have a clear objective for the sprint. There’s nothing to check and validate decisions being made. Any changes the team make to a sprint backlog is without context.

The best part about joining a team like this is the opportunity to adapt and evolve. I was fortunate enough to join a great team with a Scrum Master committed to improving. Our journey was only just beginning.