Why Engineers Hate/Love Scrum
Lately, I've noticed a surge in negativity towards Scrum, particularly from engineers. This strikes me as odd, given that Scrum was designed by engineers, for engineers. However, I recently had the pleasure of chatting with an engineer who sees things differently. We previously worked on a project together, but consulting realities pulled us apart. Fate brought us together again in a pub, where he expressed his gratitude towards me.
"Anton, thanks for giving me the coolest work experience in my 10-year career and for introducing me to Scrum!" he exclaimed, lifting his glass.
In that moment, I recalled all the engineers who detest Scrum and inquired about what made his experience so great. Here are his responses, alongside my reflections.
1. "You explained the Scrum framework to us in just a couple of hours and suggested we try it out for a month. If we didn't like it, we could always revert back." Regrettably, most transformations force people into Scrum without their consent. It's akin to sports - when you choose it yourself, it's enjoyable, but when it's mandatory, it's like those dreaded gym classes in school.
2. "You promised to be with us every step of the way, guiding us through all the events, demonstrating and advising us by example. You were able to show us how to apply Scrum to our specific cases." Once again, most people are handed the Scrum Guide to read or attend subpar internal corporate training, then expected to implement it independently. In the best case scenario, a junior Scrum Master is assigned, who may struggle to connect theory to practice. For example, they may not be able to demonstrate how to slice features thinly enough to fit into a sprint. They just keep saying "It's written in the Scrum Guide".
3. "Our team had one clear goal that drove everyone, and we were all passionate about it." The Scrum Guide mentions the Product Goal, which is often absent or nominal, meaning that there is no unifying factor. In practice, it often turns into "more features for the sake of more features." Maybe the whole story started because of Sutherland's 400% increased velocity (Jeff, they understood only that!).
4. "At each Review, we looked at whether we were getting closer to our big goal and formulated the next Sprint Goal based on that." Another very important element of Scrum is the Sprint Goal - a 2-week milestone on the way to the Product Goal. If there is one, it's like a football team "winning the current game together." If there isn't one, then the story of resource utilization and "I'm a backend developer - I wasn't hired to test - I have paws" begins.
5. "At each Retrospective, we could radically change how we work and find what works for us." Retrospective is an empirical process engine that fills the emerging framework with practices through team members. In most companies, people are not allowed to change almost anything - there are smart managers who have already figured everything out for you, and Scrum has been imposed from above, leaving you only to complain about bad coffee in the kitchen and old 2018 MacBooks.
I won't draw any conclusions this time. I suggest you draw your own conclusions.
Goodbye!
"Anton, thanks for giving me the coolest work experience in my 10-year career and for introducing me to Scrum!" he exclaimed, lifting his glass.
In that moment, I recalled all the engineers who detest Scrum and inquired about what made his experience so great. Here are his responses, alongside my reflections.
1. "You explained the Scrum framework to us in just a couple of hours and suggested we try it out for a month. If we didn't like it, we could always revert back." Regrettably, most transformations force people into Scrum without their consent. It's akin to sports - when you choose it yourself, it's enjoyable, but when it's mandatory, it's like those dreaded gym classes in school.
2. "You promised to be with us every step of the way, guiding us through all the events, demonstrating and advising us by example. You were able to show us how to apply Scrum to our specific cases." Once again, most people are handed the Scrum Guide to read or attend subpar internal corporate training, then expected to implement it independently. In the best case scenario, a junior Scrum Master is assigned, who may struggle to connect theory to practice. For example, they may not be able to demonstrate how to slice features thinly enough to fit into a sprint. They just keep saying "It's written in the Scrum Guide".
3. "Our team had one clear goal that drove everyone, and we were all passionate about it." The Scrum Guide mentions the Product Goal, which is often absent or nominal, meaning that there is no unifying factor. In practice, it often turns into "more features for the sake of more features." Maybe the whole story started because of Sutherland's 400% increased velocity (Jeff, they understood only that!).
4. "At each Review, we looked at whether we were getting closer to our big goal and formulated the next Sprint Goal based on that." Another very important element of Scrum is the Sprint Goal - a 2-week milestone on the way to the Product Goal. If there is one, it's like a football team "winning the current game together." If there isn't one, then the story of resource utilization and "I'm a backend developer - I wasn't hired to test - I have paws" begins.
5. "At each Retrospective, we could radically change how we work and find what works for us." Retrospective is an empirical process engine that fills the emerging framework with practices through team members. In most companies, people are not allowed to change almost anything - there are smart managers who have already figured everything out for you, and Scrum has been imposed from above, leaving you only to complain about bad coffee in the kitchen and old 2018 MacBooks.
I won't draw any conclusions this time. I suggest you draw your own conclusions.
Goodbye!
#agileism
You Might Also Like: