Scrum Myth #3 Spillover Is The Worst
HTML-код
- Опубликовано: 8 сен 2024
- Today we are busting the myth that the spillover is the worst thing that can happen in Scrum.
Follow me on LinkedIn and let's bust those myths together: / mariachec
We will also take a look at some Sprint spillover anti-patterns that lead to spillover obsession:
-The team must finish all the stories in the Sprint
- Spillover is bad, don’t do spillover
- On Sprint Planning, the teams plan just enough to make sure they finish all the work what adds slack time and results in some important items being left out
- No priority or objective, no Sprint Goal
- Close all unfinished stories and create new ones for the new Sprint
My video conversation with Maarten Dalmijn on Sprint Goals:
• S2E1 On Sprint Goals w...
📇 Read more on Substack - mariachec.subs...
Follow me on Social Media:
LinkedIn: / mariachec
Substack: mariachec.subs...
Instagram: / agilestateofmind
--- ⏱ Chapters ⏱ ---
It's like you read my mind and created a video on it! I'm a design lead, but Product Owners and Scrum Masters in my organization do all of the dysfunctional behaviours you mentioned, and not focused on outcomes, but outputs and delivery. I wish everyone would watch your video, but thank you for making it!
Thank you for this! I'm trying to make the videos as practical as possible, so glad to see they reflect the reality. Sorry to hear you are struggling there. It is a very common (mis)practice. We have this tendency to just occupy ourselves with "busy" work and sometimes lose sight of the goal and what we actually want to achieve at work. Hope it'll get better for you! Maybe you can share the video with them ;)
Hi, do you see any Myth regarding the QA/Tester positioning within the team ?
A couple of those. Do you have one to share?
How about this: all the pbis are needed says the customer. The customer don't give a damn about increments, internal problems or anything. They want a set of features by a certain date. It is in contract, it is what they want. Or they won't buy our stuff. If we start talking about complex problem space and predictability, they say no problem, xy company said they could do this that we can't. We have to submit if we want to keep our jobs.
Oh, I'm sorry for you. That's probably why many agencies and consultancies struggle to embrace Scrum. It is a complex problem and starts with the account managers who talk to the customers and who ussually don't have much of an Agile mindset. Unless the company wants to change, be agile and deliver high quality products, the only answer for your use case is to stick with waterfall and perpetuate the frustration on all sides. Sorry to be this negative...🤷♀
@@AgileStateofMind When I started my journey as a Scrum Master a couple of years ago I read a lot of posts from "broken" people who stated that "this whole agile thing has one fatal flaw and ultimately this is why it doesn't work for most companies and businesses": everybody must be onboard with the idea.
@@Rekettyelovag that is true that people need to be onboard. However, they won't get there alone. Even though the change is the most permanent thing on earth, for some reason we, the humans, greatly resist it in our lives. I consider it's our job, of the Scrum Masters and Agile Coaches, to be the change agent and slowly yet persistently work with people to show them better ways of working. It requires a good strategy and a tone of patience but can be done! One step at a time. Good luck!
Sure you can promise a date. The problem with that is when you promise a hard date you can't guarantee the quality especially if things are changing through development of the project which agile welcomes to ensure what your building matters. One way to frame it is sure we can build xy for you this way in the same amount of time as the other company, but you also can't change your mind. If you would like that flexibility which we actually encourage to build a better product then that's an advantage we offer and we can even work with you to determine a potentially useable product faster than they can and iterate on that to get to everything that solves your problem
Maria is correct in stating this is a tough shift for consulting companies and agencies which typically deploy a more mercenary way of working.