Agile & UX: What’s wrong with working one sprint ahead?

Let me start this post by saying I am not a UX expert in anyway, however we have been chatting to Flow Interactive recently about how agile and UX fit together. There seems to be a common pattern that UX runs one sprint ahead. Flow have had great success doing this, but when we heard about the idea it sounded a little mini-waterfallish to us. This blog post is an attempt to explain that gut feeling, and to mention some ideas of how this might work different, all shameless stolen from a nice chat with Adrian Howard 🙂

Working one sprint ahead or behind sounds familiar. Testing used to work one sprint behind, until they found ways to automate testing, test earlier and test smaller chunks. Business Analysts used to (and maybe some still do) work one sprint ahead writing specs and designing solutions. I’d like to think most now see this isn’t optimal and can in fact be done in the same sprint if you learn how to slice work smaller. So hearing about UX working one sprint ahead, just sounds like a discipline still finding a way to work in smaller pieces.

What’s wrong with working one sprint ahead?

The main issue with this is one of focus. If the UX designers work one sprint ahead of the rest of the team, then the UX designers and the team actually never work on the same stuff at the same time. This means they are never focused on the same thing. When this is true a couple of things can happen:

1. It doesn’t make sense to have the same standup meeting because you aren’t working on the same stuff.
2. It’s harder to help each other out because you are focused on finishing different stuff
3. The people working ahead consider their deliverable some interim artefact, not working software, so there is a handover of both knowledge and responsibility.
4. People don’t see themselves as part of the same team, so you end up having a UX team and a dev team. This inhibits collaboration and communication.
5. The people working behind aren’t involved in the decision making that happened without them and as a result they don’t understand the reasons for certain design choices, this often leads to assumptions, and rework.
6. Okay, but we can’t start coding before we know what go build?

I’m not advocating writing code before an UX work has taken place. I’m saying the whole team should be involved in that work. Obviously the UX designer(s) take the lead here, but everyone on the team needs to see users use their product and understand the user journey map. If the rest of the team is busy with other deliverables this can’t happen.

So how can we do this?

I remember when business analysts ran one sprint ahead getting the requirements and specs ready for the sprint. I’ve solved this by having more backlog grooming or refinement sessions with the whole team, and yes that does happen a sprint ahead. i.e. in sprint 1 we refine stories for sprint 2. However we do it but allowing a percentage of time in the current sprint to be spent preparing for future sprints. This means everyone can get involved. The analyst might take point and run the session, but the whole team understands the requirements and decisions made before the sprint starts.

I think UX can be tackled in the same way. In each sprint the whole team should set aside time to look at UX designs for the next sprint, as well as usability testing whatever has been completed. Adrian mentioned that a great way to do this is to have users available every week for a few hours. The team can decide how best to make use of the users the day before, either run a usability test, or interview them about a new idea, or show them paper prototypes. This can significantly reduce the time delays in recruiting users when you need them.

Why is this better?

Like with agile testing, if testers are involved right from the beginning they can ask “how can we test that” early and often prevent bugs. Similarly having developers involved with UX design they might advise when something is difficult to build. They will also understand which parts of the design are crucial because of user feedback, and are then much more likely to implement a solution that adheres to these designs. I believe this will result in less rework, and better designed products, as well as more collaborative teams.