I was playing Rummikub with my kids and noticed they were unnecessarily frustrated all the time. In between their own turns they spent the whole time moaning, "You've ruined my plans!" every time another player put a stone down.
It was not a new game to them; they knew the rules well and understood all the advanced tricks. So what went wrong with these motivated players who tried to take their game to a new level?
Planning your moves in advance seems like a good idea at the first glance — don't waste the time between your turns, stay on the game, watch your opponents. Maybe they were taking it too far?
And why I was reminded of work while I was playing with my kids on the weekend?
One of the most popular misconceptions of the teams moving to Scrum or another Agile process is the perceived lack of planning. Will we have to abandon all the good habits? All the road maps, programs, and strategies? Will we live hand-to-mouth, so to speak, only learning about upcoming work during the planning meeting and not knowing what's coming in the sprint after the current one? Our culture values planning; it's considered responsible and prudent. But premature detailed planning can leave the team disappointed and actually harm its progress.
Circumstances change, and the product owner's priorities change (if he or she is any good). In the Waterfall process, it's common to build an expensive change control mechanism to accommodate this reality. We're striving to do better than that. We're also striving to keep the team happy and focused, not frustrated.
Can we search for the middle ground in planning, using the game of Rummikub as an example? With four players, this would be my advice:
- During a turn right before my own, I'd pay attention to most details, trying to evaluate what the changes mean to my options. But even then I wouldn't bother to create elaborate plans for complicated moves that involve breaking three existing sequences and creating five new ones. Even one additional stone from my opponent could make these plans completely irrelevant.
- Two turns before my own, I'd just follow the big picture: Have any new colors been introduced? If I have low numbers and so far only high numbers are on the table, is this player putting down some stones that can help me make connections?
- Three turns before my own, maybe I'd keep an eye on the joker, as it can make the biggest difference in the game.
To do more than that would bring nothing but frustration, as I'd watch my plans be broken constantly.
How does this metaphor translate back to the world of sprints, stories, and tasks? In my opinion, it can be useful to follow this advice if every turn of the game was a metaphor for a sprint:
- During your current sprint, spend some time grooming the backlog: Break down and refine stories for the next sprint, but don't try to list all the tasks.
- Looking ahead at the sprint after next, only change stories if the big picture around you is changing significantly.
- Try to keep epics away from the one after that. More than three sprints down the line, it's perfectly fine to have epics on your backlog.
I think I might try Rummikub for my next Agile training. I wonder if the principle of "plan forward, but not too far forward" applies for other games as well. I can certainly see the same pattern in Scrabble, where premature detailed planning will only lead to frustration. Interestingly, both games have some key properties in common: The outcome depends significantly on skills, but there is also a strong element of unpredictability. Quite similar to software development.