Where do we place the responsibility–surely not blame–when things don’t go well on a Scrum team? Who’s responsible for taking action? (A bit of something I wrote on Twitter, lightly edited.)
OK, I’m just gonna mumble here for a few minutes. The basic topic is where we should look for responsibility, action, surely not blame, when things don’t go right on a Scrum team. Is the problem rooted in Scrum? In certification? In some teacher somewhere?
Does responsibility lie in some organization like the Scrum or Agile Alliance? Is it in the Product Owner? The Dev Team? The Scrum Team? The one, holy, catholic, and apostolic church? The commies? But I digress …
Of course, if Scrum ran over your dog, then you hate Scrum, and it’s the fault of Scrum, the certification machine, the trainers, the coaches, pretty much anybody who’s well out of sight of the actual problem.
However, one of the very few elements of Scrum is that you’re supposed to Inspect and Adapt. You probably can’t get out of a Scrum classroom, book, or 16-page guide without learning that Scrum identifies problems and the Scrum Team is supposed to solve the problems.
You don’t get to stick a complaint in a Scrum slot somewhere and then go on suffering. You’re supposed to deal with the issues. That is quite literally all that Scrum is about at base: a small framework with rapid feedback, identifying problems for you to solve.
Is your Product Owner insisting on a single ten week story? Well, Scrum actually does help you with that, because you are required to break your work down so that it’ll fit into two-week(ish) Sprints. If the Product Owner demurs, it’s your problem, not Scrum’s!
What should you do? Well I’m not there, so I don’t really know. But my first guess is that you have a “failure to communicate” between Product Owner and team, and likely a failure of the Product Owner to understand their job.
Maybe your ScrumMaster should do her job, which includes making sure that the Product Owner understands how Scrum is to be done. She might ensure that by talking with the Product Owner, by helping someone else talk with the Product Owner, or maybe just by empowering the team to sit on their hands saying “We can’t undertake things that are this big, help us”.
I don’t know what the particular solution is. But the proximate solution needs to take place in that room, not in the Grand Ballroom of the Scrum Alliance Headquarters in The Hague. Inspect, adapt. Observe the issue, fix the issue. Repeat.
Now that’s not all, certainly. Scrum’s description could perhaps be even more clear, if anyone read it. Courses could make it even more clear. Coaches could. People whining on the internet could. Me, I actually am trying, with my Dark Scrum articles, hills articles, etc. Still, I could do better.
But in the end, and this IS the end, for now at least, the Scrum Team is explicitly expected and required to retain responsibility for seeing and resolving the problems that show up in their work.
It’s not just Scrum that’s like that. Life is like that.