Doing Scrum can feel like a rat race: Sprint leads on to sprint leads on to sprint. There is no untracked time. That’s intentional. It helps you find time sinks aka waste.
But after sprinting for quite a while our developers pointed out the following problems:
- No time for technical innovation out of the development team
- That includes trying out new technologies as well implementing cool new project ideas
- No time for knowledge transfer between teams
- At least 50% of planned work (!= sprint commitment) gets kicked
- Some stuff might not have been vital to begin with, but other stuff is important maintenance that cannot be delayed forever
The interwebs know several remedies:
- Leave time between sprints
- Depending on your sprint duration, leave 4h up to 2 days between ending the old sprint and planning the new one
- Might solve all three problem
- 6×2 + 1
- After 6 2-week sprints, you have 1 week to recuperate and tie loose ends
- Might solve all three problems
- Mike Cohn described this first
- Developer’s Friday
- Developers have 1 day per week to work on pet projects
- Meant to address problem 1 (innovation)
- Ascribed to Google
- Gold Cards
- For every iteration, each developer gets a token that grants her a day to do whatever she wants
- Might solve problems 1 (innovation) and 3 (planned work)
- http://www.agilecoach.co.uk/Articles/Motivation.html (towards the bottom)
- FedEx-Day
- Once per quarter all developers gather for 1 1/2 days to implement cool new stuff
- Meant to address problem 1 (innovation)
- http://confluence.atlassian.com/display/DEV/Atlassian+FedEx+Days
To top it off, the scrum masters reported one more problem:
- No time for the developers to reach cross-team consensus
(The hardest kind of impediment: those that require discussion and votes)
During the last four sprints we tried a variation of “Developer’s Friday” to address all four problems. Behold:
- NDS-Thursday
- The first day of each new sprint is developer’s day
- Devs can do anything they want that’s somehow work-related: research, maintenance, pet projects, impediment meetings, …
- The name is completely random. We wanted to keep everyone’s minds as open as possible.
- The day itself
- In the morning we meet in a huge circle and everybody says what they’re planning. Maybe someone wants to join.
- Those who don’t have ideas of their own may work on stories as a last resort. (Hasn’t happened yet.)
- In the evening we repeat the circle and everyone tells the results of their work. We provide cake to celebrate 🙂
- There’s an spreadsheet in which the developers can track their work as a memo to themselves and for future reference by others
It’s a little early to pinpoint trends, but in the beginning activities were mainly innovation-centered, whereas now they’re mainly maintenance-centered. It’s definitely a bad sign that we need that much maintenance. We need to make sure that the NDS doesn’t mitigate problems rooted in our development process. But it would be a shame to lose the NDS as it has been great for developer morale and motivation.
I can only advise not to introduce slack when you’re just starting out with scrum. We scrum for a year now and it might have been too early for us, at least with this special variant. We’ll inspect the NDS soon, so stay tuned for how it turns out…
PS: Right after I named this blog post, I stumbled across a reference to “Slack” by Tom DeMarco. Seems like it’s the book for those not yet convinced that slack is needed.