I haven’t read your blog post, but I agree with your comment.
Unfortunately, Scrum is often misused. Why? Often, I think people don’t understand the problems that Scrum is trying to solve. So people implement Scrum poorly. And, when evaluation time comes, they blame everything but their lack of knowledge and skill regarding Scrum.
But Scrum is actually a framework to help you solve very common problems.
If you understand that, then Scrum becomes useful.
There’s a set of problems that teams will always have to deal with: how to choose what to work on, how to coordinate, how to know when something is done, how to see if your work actually solves the problems you’re trying to solve, how to deal with task-switching costs, how to deal with cognitive load, how to deal with complexity…
And those problems can be solved with Scrum. Or Kanban. Or any other Agile way of working.
Yeah, this is probably going to sound like a truism, but to avoid shitty Scrum, you need to resist management trying to alter the processes, but you should absolutely tweak the processes to account for the needs of the devs.
Basically, yet another reporting meeting does not help deliver the software faster. But more (or less) meetings for devs to sync what they’re working on, that can help, depending on your team’s specific needs.
I haven’t read your blog post, but I agree with your comment.
Unfortunately, Scrum is often misused. Why? Often, I think people don’t understand the problems that Scrum is trying to solve. So people implement Scrum poorly. And, when evaluation time comes, they blame everything but their lack of knowledge and skill regarding Scrum.
But Scrum is actually a framework to help you solve very common problems.
If you understand that, then Scrum becomes useful.
There’s a set of problems that teams will always have to deal with: how to choose what to work on, how to coordinate, how to know when something is done, how to see if your work actually solves the problems you’re trying to solve, how to deal with task-switching costs, how to deal with cognitive load, how to deal with complexity…
And those problems can be solved with Scrum. Or Kanban. Or any other Agile way of working.
What’s important is that it works.
Yeah, this is probably going to sound like a truism, but to avoid shitty Scrum, you need to resist management trying to alter the processes, but you should absolutely tweak the processes to account for the needs of the devs.
Basically, yet another reporting meeting does not help deliver the software faster. But more (or less) meetings for devs to sync what they’re working on, that can help, depending on your team’s specific needs.