Oh no! Something is rotten in the state of Scrum (aka ScrumBut)

The intent of this article is to help organizations that were not born in the digital age and are struggling on their change management journey. This article's audience is written for folks who work in more traditional organization and are truly trying and experimenting with Scrum. But senior leadership may have expectations that are not being met. This article is a continuation from the first article where we discussed patterns between Scrum and Kanban. That link is on the bottom. This time we will discuss some ScrumBut recurring observations I have witnessed and the behaviors that can break these anti-patterns.?

Oh! Forgot to mention Scrum.org defines ScrumBut as "Scrum has exposed a dysfunction that is contributing to the problem, but is too hard to fix. A ScrumBut retains the problem while modifying Scrum to make it invisible so that the dysfunction is no longer a thorn in the side of the team."

Here are some Scrum ceremony anti-patterns that should be objectively looked as leading indicators for action if you have change-agent responsibilities in your organization. Try to remember if you are a Scrum Master keep the statement below as your baseline for all your behaviors.

“The impediment to action advances action. What stands in the way becomes the way.” - Marcus Aurelius

Lets get started.

Sprint Planning?

The overhead and coordinating cost for estimating in a ScrumBut environment tend to be very high. Story pointing is a very popular form of estimating in the Agile Community. For those who don't know what it is, it's a form of relative sizing and it is very similar to T-shirt sizing (XS, S, M, L, XL) a work deliverable that has very little details. Just like in traditional Project Management there is zero relationship between the estimate in the early stages of an initiative and the actual cost. So why even do it? I am not inferring you should stop estimating; although you could. But there are other approaches to tackling this problem.

One approach is to identify the type of work the team produces and figure out how many of each type of work they can deliver in x time (aka Throughput). How long it takes once they start working on the initiative / feature (Cycle Time). How long it took to get the feature in the customer's hands for feedback from when they asked for it (Lead Time). In a ScrumBut environment I have constantly observed Scrum Masters and Development Teams get eaten up alive by a low maturity Delivery Manager or Executive when they mention "our capacity is x points". Moving away from points towards time is a way to break this anti-pattern. As time has a funny way of being more trustworthy.

Daily Scrum

The anti-pattern here is it runs like a status call. This one happens a lot. If this is happening, this is your leading indicator that Developers are going to stop attending. This may cause the Scrum Master to address the issue by influencing the Developers to come to the Daily Scrum even though the Developer sees no value. When this happens the Scrum Master is misinterpreting the "sheep-dog" role metaphor when they learned Scrum.

This session needs to be a collaborative where the team is discussing the plan and goal for the day while keeping an eye on if there is any risk to meeting the Sprint goal. The opportunity here is the Scrum Master can be actively listening for any impediments and opportunities.

Sprint Review

The anti-pattern here is it runs like a sales call. One way presentations are being delivered by the Product Owners highlighting the quantity of work being completed. Meaning this turns into a meeting more on output and less on outcome. This type of behavior elicits minimal feedback from the folks representing the customer.

The main purpose of a Sprint Review is to inspect the outcome of the Sprint, collect feedback from all the folks who represent the customer (even better bring the actual customer), and adapt the backlog going forward. When done right, this ceremony can create transparency, foster collaboration, and generate valuable insights.?

Sprint Retrospective

There are two anti-patterns I have consistently observed with Retrospectives. First, its a session where the Development Team is only complementing each other for a job well done and thanking each other. There is absolutely nothing wrong with this pattern. It's actually awesome! The issue is we should be discussing what went well and what did not go well. If this is happening it usually means the trust has not developed yet or there might be a organizational design pattern that is getting in the way of openness and transparency. Second, the Scrum Team is having discussions on the impediments that came up during the Sprint but the improvements being implemented in the next Sprint are only the ones the Scrum Team can implement. Depending on the organizational design and the amount of operational shared services its highly possible these small team based improvements do very little to benefit the customer. The impediments that are outside the Scrum Teams purview tend to be bigger in scope and require senior leadership to lean in. A suggested experiment is keeping an organizational impediment list and meet on a recurring cadence with leadership so they can help.

The Sprint

There are two anti-patterns I have observed with The Sprint constantly in mature organizations. Product Owner is so inundated with meetings they can't give the Development Team the time to answer crucial questions. Product Owner becomes the constraint because they are being pulled in too many directions. Remember, the aging unanswered question will cause Lead Times to go up. The second anti-pattern I call "attack from the flank". Development Team commits to their work in Sprint Planning but they are constantly being interrupted by folks that are not members of the Scrum Team.

Finally, the biggest leading indicator that something is rotten in the state of Scrum is when the the Scrum Team has devolved to the point of they are no longer running x ceremony because either they did not see the value or they just send an email instead of having the ceremony.

We live in a complex world and seeing is very difficult. Remember, we can always connect the dots backwards but never forward.

If you are observing these patterns remember these are wonderful opportunities to implement long lasting change. Feel free to contact me directly if you need help.