Space Invaders analogy against dual-track Scrum

I have an idea for an analogy for iterative design and development that doesn’t slice off the designers as a run-ahead team within a dual-track process; it’s just a brain dump and I’m interesting in your feedback and suggestions.

I’m a strong advocate for a properly integrated design capability in Scrum teams, not sitting outside in a dual-track team where the designers work a week or more ahead of development and hand-over specifications to be implemented. The dual-track approach breaks the desired cyclical nature of agile into mini-waterfalls, excluding non-designers from the design process and reducing the impact of feedback and learning into refining the backlog. A dual-track approach puts designers in the pole position which is not ideal (though as a designer it can be comfortable, but not effective).

Problem is, dual-track is wildly popular because it’s easy. I’m not interested in what’s easiest. I’m interest in what’s efficient, effective, utilises the full collective capabilities and expertise of teams and adheres to the cycle of planning, doing, studying, and acting rather than merely rolling out a pre-determined backlog regardless of impact and benefit.

Space InvadersThe central idea is Space Invaders; every shot wears down an invader, some invaders (level bosses) require a lot of firepower to bring them down and you don’t work sequentially left to right; you might be working on shooting down a dozen invaders at a time.

Of course, an invader is still operational until you completely destroy it, but that doesn’t mean non-fatal shots are wasted.

The parallel with agile is that a team doesn’t have to work sequentially; think of an undamaged invader as an undefined problem or opportunity, the very beginnings of a user story or product backlog item.

The team can choose to focus their “firepower” on one story at a time but more than likely they’ll have a bunch of stories in various stages of destruction, or delivery as they progressively refine the backlog, discuss and workshop epics and stories, thrash out and test concepts.

Varying cascade of features from inception to ready for sprintSome features and user stories might require more discussion, research, testing, prototyping, and technical attention to get them ready for a sprint. Some are straightforward and can go from inception to development in an hour, others might need to be kicked around for a few weeks or more before they’re sufficiently detailed and able to be estimated, delivered, and tested.

The design “requirement” for some user stories might be satisfied with a quick sketch on the back of a metaphorical napkin whereas others – the level bosses – might require an extended game to go deep, research and prototype.

This doesn’t imply dual-track Scrum; like Space Invaders there is one defensive gun, one team. The team chooses what to focus on and where to allocate time and effort. Note that the effort expended on refining a user story or breaking down an epic may not be proportionate to the effort required to deliver those stories.

There may even be some rhythm to how they work; spending time on the closest, most urgent, and nearly-defeated invaders (user stories to be delivered in the next sprint or two), then some time on the middle tier of as-yet untouched invaders (proposed new stories), and some time on the bosses at the rear (the hairy, complex problems and opportunities).

What do you think of this analogy? Is it relevant? Useful? What else is there in this parallel? Are you a supporter of dual-track? Do you think designers should – or shouldn’t – be part of the Scrum delivery team?

Do you think there should be a designer working in the sprints at the point end of delivery and another outside the team working on the longer view product roadmap? One designer doing wireframes for the developers, in turn informed by other designers doing user research?

Or do you think that the design-development mini-waterfall within Scrum where designers work ahead of developers and handover specifications is silly and can be addressed through creative and collaborative approaches? Is dual-track a symptom of teams who don’t quite get it?

If you enjoyed this article please share it with your friends and colleagues.

Leave a Reply

Your email address will not be published. Required fields are marked *