Don't separate the technical and non-technical members of the team.
Shorten iterations (1 month is too long) and focus on end-to-end cycle time.
Use smaller tasks instead of task estimation.
Make tracking visible in the workspace.
Quality engineering practices are not optional.
Process leaders should make themselves unnecessary.
I totally agree that 1 month is too long for an iteration. When I first started doing Scrum, we used 30-day sprints and I quickly saw student syndrome set in. We tried 2-week iterations and had some improvement but I still saw people take their foot off the gas in the first week and then struggle to make it up in the second week.
You can't beat 1-week iterations. They force everything to be smaller. Complexity is broken down by smaller user stories and they can be estimated with less inaccuracy. A great visual indicator of progress is a steady rise in running tested features as stories hit the done column every day. Planning games are shorter because you do less in a week. And by the time you start you need to be thinking about finishing because iteration reviews come fast, so communication is more intense. You get to inspect and adapt every 7 days, and celebrate success 4 times in a month as opposed to once. And this builds momentum.
I'm not sure that the Scrum Master role isn't always necessary, though. I agree that the coaching/process-leader role can become redundant when a team achieves the ability to self-organise. But the facilitator role that the Scrum Master also fulfils remains important even within a self-organising team.
Previous Topic
