11–20 of 42 posts
It was popularized as a way to micromanage developers and drive them to produce more.
I think we can argue about whether that 'more' has been quality or not, the right output or not, whether developers and other workers deserve dignity or not, etc., but I think it continues to deliver on its core goal -- tighter management control of and domination of workers, with all the benefits for management and ownership and investors that brings.
If you ask if scrum is good then I read it "if working in iterations with PO and regular checkups is good" and my answer is yes. But you can achieve the same with kanban or any agile workflow.
There is a lot of misconceptions about what is and what isn't scrum. Eg. the fact that all scrums I've seen come automatically with estimations is Cargo Cult to me. From my experience, problems with scrum don't really relate to scrum, but rather these Cargo Cults or "our scrum incarnation", which comes down to misunderastanding it.
Why would I trust something like that instead of something organic?
However as one commenter said, it's not about quality. Big companies have to feel that sweet, sweet cash, as soon as possible, at the cost of the devs.
As a product owner, I find Scrum to be limiting. It does not empower me, it restricts me. We can't just tell a talented dev to go figure something out, we need to break it up into the right sized pieces and fit it onto a board. That does not give me "something to do", it actually burdens me with micromanagement. I just want to lay out what needs done, then let the engineers do it.
In that, you are correct - Scrum does not fulfill the main goal of product management, of building the right product. It does make the dev process more predictable. But I've never known a good product person who care more about the predictability of the dev team than they do about the quality of the product. Standard cliché here - be careful what you measure, as that it what you will improve.
So yes, Kanban is better. I can lay out details, devs can work it, and it takes the time it takes. Maybe Scrum does give better charts and graphs to our leaders. But we get things done. We research what needs researched with freedom to find the right solution... not just a solution that fit into the timebox on a Jira card.
No, I would have told you if there are blockers. Just because there aren’t don’t mean this is “easy”, and while I realize you need to explain to the stakeholder why it’s taking longer, neither of you are going to understand anyway, so it’s a waste of everyone’s time.
I think it’s somewhat of a solution in search of a problem. Every company I’ve worked for, regardless of their Scrum religion level, seem to end up in the same place - the PM nagging for updates (even if we just had our scrum an hour ago) and constantly asking if there’s anything they can do to help or if there’s anyone else on the team that can help. No, I would have told you if there are blockers. Just because ther…
Scrum is a reasonable baseline starting point for an agile team to iterate on for process. Like any process, it is bad as an inflexible, canned process instituted as a rote ritual. > There is so much jargon and cruft around it; planning poker, story points, scrum master etc Neither planning poker nor story points (nor even stories , which are a prerequeisite for planning points to be “story points”) are parts of Scru…
Exactly this. Scrum is supposed to be agile. Being agile by following a rigid process is an oxymoron. If you can't tweak the process, you're not agile, and are therefore doing it (including scrum) wrong.
Scrum could be a consequence of a goal it shouldn't be the goal.