Several weeks ago, I had the opportunity to talk to Rob Keefer of Pomiet about his experiences with Agile UX. Rob shared several techniques that he’s had success with over the years, including the Sprint Ahead/Behind approach. Several others I’ve talked to have used this as well.
For those of you who haven’t heard of this before, here’s how it goes: You start with a sprint zero which gives Design time to get out ahead of development. As development gets started setting up environments and infrastructure, design continues to craft design documents that can be handed off to development in a subsequent sprint.
After a feature has been developed, design comes back around and performs usability testing and iterate. The trick is that in sprint 2, you will be designing for sprint 3, testing what was developed in sprint 1, as well as working with development as they build what you designed in sprint 1. Oh, and iterating the design in your free time.
I’ve run this gauntlet myself in different organizations. In my experience it’s not pretty. There are plenty of late nights as you try to keep the pipeline full for the team of developers who are all waiting for your deliverables. You’re running so fast that there is little time available to make iterative changes. Even if you are lucky to have multiple designers on the project, there isn’t time to collaborate and make sure that the designs are consistent in their direction. The sprint ahead/sprint behind approach misses the sustainable pace that agile is supposed to provide.
Did you catch that? If you are designing a sprint ahead of your developers, that means you are not designing collaboratively with them. If developers and other disciplines are not brought into the design process, you will continue to have territorial disputes about the implementation. Since you don’t start a sprint with a shared understanding of where you’re going, design needs to create deliverables to hand (over the wall) to development. Creating deliverables takes time, it creates barriers and misunderstanding.
Overall, the staggered sprint approach just condenses the waterfall into smaller timeframes addressing functionality across a few sprints. It doesn’t provide much benefit to the process or the team. Designers get less time to think and execute. They have to split their focus in three directions at once. It leaves features undone for longer, straddling sprints. This increases the duration of risk.
It sounds like some, Rob included, have had success with this way of working. That’s great and I’m not trying to tell them that they are doing things the wrong way. I’m not looking to engage in religious battles. What I’m after is a way of doing UX work collaboratively, closely trading ideas and learning with a cross-discipline team. Staggered sprints just isn’t going to get me there.