This is a description of the experiment from the story “How the COVID outbreak accidentally kickstarted SCRUM in our IT department”.
While I was aware that the experiments like “one day sprint” exists, I had never witnessed it myself before this spring. That is when I found out how powerful short sprints really are. Where week or even two-week sprints often hide the true problems the team faces, short sprints are merciless.
This is a story. If you are interested in a step-by-step manual to reproduce the focused sprint experiment, head to my other article.
I am quite biased against all types of SCRUM simulations. I have yet to attend one where the “eureka” moment for developers are be of any long-term significance.
I believe that the problem is the transfer of learnings from the small controlled environment to the day-to-day life in the workplace. This is especially evident when the team is already working in some “dark scrum”, “scrum but” waterfall-ish workflow.
“Yeah, we saw how quick the stand-up was, but we do have stand-ups and we do discuss things. It must be the complexity and not the approach that slows us down.” …
I have observed this pattern in several SCRUM teams. In all team member’s calendars, somewhere in the second half of the sprint, there is a big solid block. Usually, it’s a one or two-hour-long meeting called “Backlog refinement”, “Backlog grooming” or something like that.
And if you have a chance to join this meeting, within 20 minutes after it starts you can see team members occasionally peeping on their phone screens. And towards the end, only one or two members + product owner are actively participating in the meeting while the rest has more important things to do.
More honest team members will admit to you, that they just find the whole thing boooooring. …