UX Hong Kong this year once again proved to be an inspiring and thought-provoking conference. One idea I had, prompted by several of the sessions and various discussions in the breaks, was the potential value of projects having a ‘Sprint -1’.
Why -1?
Most UX projects these days seem to be run in an Agile fashion. There’s an emphasis on short (typically two-week) sprints, rapid development and iteration, and having something tangible at the end of each sprint.
This can work well as a development methodology, but design has often struggled to find its place within the process. There’s a tension between the desire to get on and build stuff, to work things out as we go, versus the time needed to properly consider the design – to gather and assess insights, to ideate and reflect, to discover enough that a coherent design direction can be created – as a framework into which as-yet undefined functionality and content can be added later. The risk is that you end up with a ‘bag of widgets’ – all the required features are there, but they’re not joined up, there’s no overall user interface paradigm, no consistent user experience.
Some projects use a ‘Sprint 0’ as a way to tackle some of the ‘setting up’ stuff that needs to get done before the ‘proper’ sprints can start. Usually this is technical and operational set-up work, but in the UX world it is often used as an opportunity to do some of that design thinking up-front, to get a head start. I’m not convinced it necessarily provides enough time, or properly mitigates the risk described above, but it’s better than nothing, even if it does introduce the new risk of it ‘all getting a bit waterfall’… ;-)
Ultimately, as I’ve written elsewhere, whether or not Agile works really depends on the team, and the individuals therein. You need a strong team whose members work well together, that collectively plays to its strengths, that can have open conversations, that can acknowledge individual or collective weaknesses, and work together to support each other. That of course requires trust, and trust takes time to build.
Yet many projects are resourced with brand new teams, often comprising a mix of staff and freelancers or contractors, who may not have worked together before. Commercial imperative usually means there’s pressure to hit the ground running and get on with producing (billable) outputs as quickly as possible. In terms of Tuckman’s group development model, we’re expected to go straight into Norming – or even Performing – without having first gone through Forming and Storming.
Of course, part of the value a good freelancer brings is the ability to do just that, to quickly find their place in the team, to bond, to build trust, to get on with the job. But I wonder how much time is ultimately wasted, how many wrong turns are taken, and how many mistakes are made, because of assumptions the team members make about each other? Might it not ultimately be more cost-effective to spend some time getting to know each other before the actual work starts?
So that’s the idea of Sprint -1 really. No project work, no deliverables, no backlog or burndown. Just a time for building the team, getting to truly understand each other, removing all those assumptions we subconsciously make about each other’s skills, experience, expertise, personalities, ways of working, and so on. Building trust and respect.
Of course, sometimes teams don’t gel. Sometimes people have incompatible personalities, or rub each other the wrong way, or just don’t get along. That’s not necessarily any one person’s fault. It’s human nature. By recognising it early, we can at worst case re-jig the team before the cost of change, the accumulated project knowledge invested in the team, becomes too great; ideally though we can learn to work around it – we can learn how to approach each other and avoid pressing the wrong buttons.
I’m not sure a Sprint -1 would need to be a full two weeks – perhaps one week is enough. But I do think that time spent up-front building the team – before any of the Sprint 0 stuff (let alone Sprint 1!) gets done – can only pay dividends later, both by creating a more effective team at the outset, and by minimising person- (or personality-) related assumptions and problems later on.
It should probably be a mixture of structured and unstructured, formal and informal activities. Exactly what those need to be would depend on the specific project and people involved, I think. Plenty of possibilities to choose from. Perhaps a good place to start though might be Marco Calzolari’s Talent Canvas – I’ve encountered this a couple of times recently at conferences, and it strikes me as a good tool for both self-reflection and starting a conversation with others.
Whatever approach we take, or tools we use, we ought to be making (truly) building the team as fundamental to the project as contracts, operations, design, development, or delivery. We don’t though, do we? ;-)