Overscrummed by Design

Posted on Jan 19, 2024

Words about Scrum

Loud titles about how Scrum ruined Agile cause boredom or disgust. But in the environment of satirical folklore of ScrumButs, ZombieScrums, and ScreamGuides, we can observe the negative side of the framework. Let’s try to go step by step about the good and bad parts of Scrum.

Scrum is often called an “Agile framework” or “methodology”, which is wrong. It’s the list of values, roles and meetings. The values don’t match the original Agile’s. As referenced in Scrum Guide: “Scrum is a lightweight framework that helps people, teams and organisations generate value through adaptive solutions for complex problems”. There is no word Agile on the page. Even if Scrum founders don’t consider it Agile, we can accept it the same way.

What is even more destructive than the applied Scrum wrongly in the wrong place is many imprecise interpretations around it. I had a few talks with people who understand better what Scrum is and what is not, and we often have misconceptions in mind and misusages far from Scrum boundaries. But can we blame only ourselves here? Let’s take a look.

Autonomous

One of the good Scrum points is the requirement for autonomous cross-functional teams of developers. It is a team of developers where everyone can participate in teamwork, not QA, DevOps, business or system analysts. Be aware that if you have these roles and their work depends on each other, don’t use any sprints. It will be one of the frustrating points connected with sprint length and described more below.

Sprint fixed scope

One of the unuseful mind things is the fixed scope of sprint backlog tasks, like team sprint commitment. But it is also wrong. Scrum advertises inspect & adapt, which sleeps from the mind. Here the guide says we plan a dedicated sprint goal. The whole team should focus on achieving the single chosen goal without getting anything which can interrupt the team from achieving it. So we can learn of problems experienced and reframe the tasks and sub-problems to accomplish the goal.

But the goal is the one, and If you now have doubts about how one team is working on a few products, you can choose the one goal for sprint and grow a few products simultaneously.

I will continue through the list of Scrum activities.

Standups or Daily Scrum

“Each event in Scrum is a formal opportunity to inspect and adapt Scrum artefacts. Daily Scrums improve communications, identify impediments, promote quick decision-making, and consequently eliminate the need for other meetings”. Here we get a choice between regularity vs non-regularity. Can you choose only the best one from these two solutions? No. But in regularity, we can get an idea to avoid problems to discuss until standups. But we don’t need to wait until the formal event to come and bring things. So we could make the synchronisation loop faster but chose to lead every team member by hand through the tasks and problems. In other “regularity” cases in different team environments we need to think about the following questions:

How to make meetings fast and not bore everyone? How to make everyone keep listening to everyone’s information?
Things become more complicated if we keep teams strongly connected for a long time. How many people do we need to involve? DevOps? QA? Analysts? All members from other teams with which we communicate?

Questions could be better because the problem below them is accurate and arose from daily regular meetings decisions. If someone can’t go with the problem to anyone anytime, you have much bigger problems with the trust atmosphere. In this way, grown and conscious teams don’t need daily standups.

Sprint Planning

Prioritisation is a good thing. Reframing problems is also good. We get an original idea from the product side or customer and work. We don’t wait for the detailed written solution in the paper. We discuss things. It gives us faster inspect & adapt.

But other things lead to dysfunctions. We should answer at the meeting: “Why is this Sprint valuable”? The team must finalise the Sprint goal. As mentioned above, we should have a dedicated, fixed Sprint goal. But it’s sporadic cases when you can mob the whole team only to solve this.

Estimation. We are trying to estimate problems solving in the timebox. But without task estimation, as told by Jeff Sutherland.

So there is no estimation officially. But there are things which are often considered commitments and deadlines. And the developer should respond yes, no or maybe to commitments. “Selecting how much can be completed within a Sprint may be challenging. However, the more the Developers know about their past performance, their upcoming capacity, and their Definition of Done, the more confident they will be in their Sprint forecasts.” Many negative things with biases happen here without real business value. We also need to remember to add capacity to critical bugs. And add budget to tech debt.

We need to divide tasks if they are not fit in the timebox sprint boundaries and edit the definition of done. What are the requirements for the Definition Of Ready for the job? Do we postpone the sprint start? If we miss one day or two days after the sprint. Don’t we need the results in any case? But calendar times for Scrum meetings should be regular.

These all are difficult choices when we have these time boundaries. Many questions and tricks started to be used just after the decision to divide the flow into timebox boundaries called sprints. It’s unnatural.

Sprint Review

Do we need to release once per sprint after the demo? No, you can release any time during the sprint. Faster releases faster customer feedback cycle loop from customer through development and back.

Sprint Retrospectives

Inspect & Adapt is good. Bad implementations can be the problem. The main point is pretty simple like at standups, why postpone problems to retro? Inspect & adapt as fast as you can.

Also, we can have different problems with retrospectives outputs: If we have no issues:

Do we need to change the retro format to find the?
Or we understand that the system can’t recognise problems about itself without learning and information outside. Suppose we have too many problems. We can’t solve them because of significant backlogs. Why don’t we solve them? Or our solutions lead us away from worse problems and make worse situations. The problem is that it can be tough to understand the reasons below. Without understanding how things work or at least communicating with stakeholders. The latter can be very short: “Team performance has to be better!” or “Why do we estimate sprint so badly?” So we need to add action items to plan and estimate better.

Metrics

It’s not part of Scrum. But metrics are often considered near. Team performance, velocity estimation of finishing on sprint. Burndown charts make no sense if you are not making details in the factory. If metrics are easy to count does not mean it makes sense. Be careful with metrics. Trying to measure something in the system might change system behaviour.

Conclusion

Finally, despite advertisements, the scope of Scrum usage is very tiny. Generally, it leads to dysfunctions and designs that need to be more concise and natural for general purposes. So why do we use the framework where we can easily understand badly and need highly experienced and payable consultants to work?

And if we agree here. What to do instead? I have no short answer but give references to other possible approaches.

Can be further steps or not

Make teams more autonomous, and understand what interaction has to be among them. Smooth out time boundaries to be less stressful. Try to manage prioritisation and flow, not the problems and tasks dividing.

What is good with Scrum can be some values. And for emergencies and focusing on the one-day Sprints. The very mobbing emergency thing for a short period.

Kanban methodology is less destructive. It least starts with things you have. But here, you also need the professional’s help. The more founders develop Kanban, more complicated and certified it becomes. Winning the dragon, you become the dragon gradually. The short notice: Kanban methodology is not Agile because it has other values. Barrouz, Anderson and other Kanban evangelists will underline it.

Also, we can go out of complicated things over complicated rituals. Keep systems and communications simple. We can derive many things from keeping things simple and making faster feedback loops I referenced in one of my previous articles.

If you want metrics, try with a client’s whole customer feedback loop through development and back, which is better. We should be customer-oriented, not maintaining processes-oriented.