My first sprint was so much fun! We generated some great ideas and solutions and learned a lot.
Get a head start on your first sprint by taking from what I learned in my first sprint. Here are six takeaways from leading my first design sprint.
It's your first sprint, and you're ready to get started!! You've got the right supplies, the right room, the right people, and the right plan... you're ready to go.
You've brought the group together to solve a problem, but does everyone know which problem?
You think this is obvious but go with me for a minute. Remember how meetings typically have topics on the agenda to be discussed without boundaries, context or expectations. Because people are not accustomed to the structured focus of a sprint, you may need to provide these three elements.
The focus of our sprint was to redesign a recruiting event. We were not redesigning the organizations recruiting pipeline are application process, just the event.
Setting this boundary is a bigger picture than choosing the part of the map you'll focus on at the end of the first day. Clarifying the scope at the beginning will help you reel people back in when they venture outside the boundaries of the sprint.
But why did we need to redesign the recruiting event? I assumed this was already clearly understood, whoops.
Halfway through the day, we paused to give some of the backstory. I explained that the event had previously been to recruit for one role within the organization. Now, after a restructuring, it needed to represent multiple roles across teams and departments. Providing this extra context orients your team to the problems they're solving for.
Have you ever been discussing a topic in a meeting where one person thought you were giving an update, another thought you were making a decision and a third thought you were ideating?
In many organizations, meetings like this are ordinary. For an effective sprint, you need to set clear expectations by naming the process.
Early on, people will feel the ambiguity of gathering information without a solution. At first, it will likely feel slow, but then it will feel too fast. As you move through the various steps, you can remind everyone, "this part might feel like we're moving really fast, but that's ok."
I also found it helpful to differentiate between waterfall and agile methodologies. "We aren't going to talk and plan for a really long time and then execute. We're going to execute quickly, get immediate feedback and make adjustments." Before explaining this, one team member was disoriented by how fast we were moving.
It’s easy to spend our day reacting to what comes at us. What if you could be proactive, intentionally making decisions based on your priorities? It is possible!