These are completely legitimate questions and concerns. I faced the exact same when I was getting started.
In reality, human beings have been struggling to remain focused for thousands of years. We believe it’s false beliefs that technology and social media are to blame for our multitasking mania. We’re quick to blame new rungs of company leadership that constantly reprioritize, forcing us to shift our product strategy and roadmaps. But leaders have been changing their minds and callously rushing their teams along since the dawn of time – I do it almost religiously. So let’s not count on that changing soon.
And yet, many groups have figured out how to successfully run week-long or, even, multi-week sprints. What you should recognize (and lighten up about) is that everything won’t shift overnight. That’s actually a good thing.
If you’ve been pushing for sprints or, simply, more time for customer discovery, here’s one approach you can take to get your team from 0 to 1. You should expect to see a sharp improvement between sprints 1 and 2 – and certainly between sprints 1 and 10.
First, stop overthinking it and run a sprint. Use a framework to get the gist of sprinting – the app is due for an update but it will do the the job. Whatever you do, don’t compare your process or tools to Google’s, Bornate’s, or anyone’s. No matter, in time you’ll be running your own flavor of sprints that work best for your group and the products you create.
Choose a moderately important project to run your sprint on – something that’s a 5 in terms of priority and complexity. If there’s research to back it, great. It’s more ideal if you can run it in 5 consecutive days. If you spread it out over 2 or 3 weeks, that’s fine too. Don’t let it run longer than that – not yet. Whatever timeline you agree to, don’t budge once people have committed the time. You’ll never get out of the gate if you start moving the dates around before you get started.
Set the expectation – upfront, loud & clear – that this first sprint will be infamously imperfect. This is your design sprint prototype. Still, there will be backlash from leaders and peers. No surprises there. Change is scary. Use the outbursts and anxious sidebars as a barometer – those who lose their shit the most are most in need of a shift. It will just take them longer to get there. Don’t let that sway you – expect it.
The single most important step of your first sprint will be a retrospective. Hold it on the afternoon of the last day of the sprint, right after you wrap up testing and make some decisions about next steps. Don’t leave time in between. Do it while things are hot and fresh. I know you’ll be tired – persist.
Ask yourselves, honestly, what worked well? What surprised you? What needs more exploration? What do you want to try differently next sprint?
Resist blackballing parts and people at this stage. Your customer interviews may have been utterly useless because you picked a poorly framed problem to solve. Your facilitator probably bombed because they have another full-time job and only agreed to facilitate because nobody else would. Next sprint, make some agreed upon adjustments and reflect once more.
If it sounds like you’re taking the same iterative approach you use for designing new products, it is! Running sprints is an experience you’re prototyping and testing. If you approach sprints with the same curious, iterative, empathic principles they’re built on, you’ll learn faster, sprint better, and have much more fun along the way.