Scrum has been around since the mid-eighties, so why is it that some companies make it work so beautifully while others end up in such chaos that they run back to old methods? Maybe those companies that flounder or fail do so because they stray too far from the “Scrum Recipe.”
Companies prefer to put their fingerprint on their version of scrum, not dissimilar to today’s health-conscious, substituting all kinds of things for ingredients in Grandma’s tried and true recipes. They substitute butter with apple sauce, cream cheese with cottage cheese, and sour cream with yogurt.
Although the substitutions may make sense, sometimes they don’t work out, and you’re left with a plate of cookies that should probably just be thrown out. The same can be said for Scrum substitutions.
Much like cookies that sit uneaten on the plate, in many cases too many ill-advised substitutions have been made to the Scrum recipe, thus impacting its success.
Let’s take a look at some substitutions that may be impacting your successful Scrum environment.
IT Product Owners for Business Product Owners
Some companies think IT Product Owners and Business Product Owners are the same things. That is not true.
The whole point of the Business Product Owner is to bring customer-facing insight into the development process. The two are measured by different things. The business owner is driven by growing the reach of the product in the market where IT management is measured by things like up-times, responsiveness, speed, and stability.
If the product has users and a business owner in charge of strategy and direction of that product, that Scrum Product Owner should not reside in technology.
The equivalent of this substitution in the cooking world is tantamount to substituting a professional chef with a short-order cook. Are they familiar with food? Yes. Can a short-order cook do with food what a chef can? Not usually.
Make sure Product Owners are part of the group that sets the direction for the product. In the case of multiple business product owners driving the direction of the product, a single product owner can be identified in technology to manage the multiple requests and lead the other business owners in the prioritization effort, but the direction should still be driven from a business standpoint. What does it help to have a product that is fast at doing something the users didn’t care about?
Allowing Changes During a Sprint
In the rush to get changes out the door, many companies ignore the directions in the Scrum recipe that state no changes after sprint planning. For some reason, they believe they can do it without repercussions when others before them have failed.
This practice is equivalent to having started making chocolate chip cookies only to switch to brownies. You may not have the resources you need, the work done may have to be thrown out, and worst of all, the team has been impacted negatively.
There’s a rhythm to a sprint as well as a trust that the agreement made in planning will be kept and everyone is working in the same direction. Making changes to a sprint, especially when it becomes habitual, damages the trust and impacts the sprint rhythm, never allowing the team to succeed to the best of their capability. It also means you might never get those chocolate chip cookies.
Making Scrum Teams Too Large
Scrum team size recommendations vary, with most somewhere between seven to nine team members.
Some companies decide, usually based on previous team size or reporting structure, to have large teams. Initially, this seems an innocent substitution, but over time the issues become obvious. Stand-ups can’t be completed in 15 minutes; collaboration across the entire team is difficult, and quieter team members lose their voices along with many other complications.
Seven to nine is recommended to allow the team to have enough expertise but still be nimble. This is equivalent to the age-old reference to too many cooks in the kitchen. If too many people are trying to do something, even the smallest task becomes more complicated.
Stick to the Basics First
When trying a recipe for the first time, it is best to stick to the recipe. The same goes for Scrum. Sticking to the recipe doesn’t mean you can’t change it in the future and make it your own, but it’s best to get the recipe right before you start making changes.
With Scrum, start with the Scrum tenets. As your teams learn Scrum and are empowered to offer improvements through channels like the retrospectives, the substitutions made will make a positive impact.
Before too long, the Scrum environment will be running smoothly and will have nuances incorporated that work for the company without impacting effectiveness.
![[Case Study] Lessons from descaling 25 Scrum teams](https://www.agilealliance.org/wp-content/uploads/2024/12/descaling-teams-1200x630-1-150x150.jpg)
![[Case Study] Lessons from descaling 25 Scrum teams](https://www.agilealliance.org/wp-content/uploads/2024/12/descaling-teams-1200x630-1-300x158.jpg)
