What I Learned in My First Design Sprint

No devices is a real thing.

Since it was my first time facilitating, I needed my device for the schedule and notes. So I didn't mention the no-device rule, and I quickly regretted it. Inevitably devices came out often. 

When we would change activities, I would say something like, "we don't need computers for this part."  Eventually, I started using the table for the workspace rather than the wall.  This change helped a lot because there was less computer space, but the devices kept returning.  

Print out your schedule and note and start with the no-device norm. It will make a huge difference.

Rapid Feedback.

The whole concept of a sprint is premised on the idea of rapid prototyping and feedback for the product. But after running my first sprint, I'm looking to incorporate rapid feedback for the process as well.  

End of the Day.

In future sprints, I plan to run a process check at the end of each day.  It's a short survey we've used in other meetings to make space for people to give feedback on the process of the meeting.  It's quick and transparent (answers are not anonymous).

You ask everyone to give feedback on six aspects using a scale of 1 to 10.  Here are the categories:

• Meeting Goals and Focus
• Planning and Tracking
• Meeting Participation and Involvement 
• Listening and Communicating
• Member Trust and Openness
• Productivity and Driving Results 

End of the Week.

Once the sprint is over, you want to seek feedback to learn and improve.  Here are some example questions for a feedback survey:

• Did we achieve the outcome of ______?
• What part of the sprint was most helpful?  Least helpful? 
• How would you describe a design sprint to others?
• How willing would you be to participate in a sprint in the future?
• Any additional comments?

This feedback is critical, especially if sprints are new to our organization.  

During the sprint, feedback can allow you to make adjustments along the way to help the group be more effective.  This can be adjusting the process or aligning others to it.  

After the sprint, you can make adjustments for next time, but more importantly, you can understand how people are experiencing the process and essentially work to manage the brand of design sprints within the organization.

Stakeholders coming in and out.

People are busy.  When introducing your organization to sprints, others may not feel the same priority of being there the whole time. They're used to meetings where you talk about all the implications and go around in circles, so if your miss something, it's ok; you'll catch it again later.

So it's Tuesday afternoon, and we're working on the storyboard for our solution (I combined days two and three!)  We're going strong, and I think we'll actually finish early. Three people, though, are currently out of the room. One had been gone an hour, one had been gone most of the day and one the whole day.  

Mike, one of the stakeholders, walks in, and we give him a quick update as he's been gone all day. I can tell he likes the solution, but his mind is going into overdrive with all the conversations we will need to have with various departments and stakeholders.  I let this go for a while because his concerns are valid, and I want him to feel heard before I reorient us to the sprint's focus.  It takes about 30 minutes, and then we get back to work... for about 10 minutes.

Chelsea walks in; she's been gone for all but the first hour of the day. She is thoroughly disoriented by how much happened while she was gone.  Chelsea is a crucial stakeholder who represents one of the departments new to the event.  In her words, "I don't know if I like the solution or not yet, so much has been decided."  

Chelsea, like many others, was used to a process where everything is planned slowly over many meetings, and then ideas begin to be implemented.  We took another 30 minutes to process, and along the way, I explained the difference between waterfall and agile methodologies. Then we get back to work... for about 10 minutes.

Karl walks in; he's been gone for about an hour. He sees Mike and Chelsea and realizes he should engage them as critical stakeholders and get their thoughts on the process so far.  This goes on for about another 30 minutes.

We didn't finish the storyboard that day.

I still think it was the right decision to let these conversations each run their course. They did end up being helpful in alignment and understanding, which wouldn't have been the case if we had just continued ahead and said, "catch up!"  Alignment without extra conversations would have been possible if everyone had just been present the whole time. 

Try to minimize your sprint team from going to other important meetings during the sprint.  If they have to miss part of it, preview what they will miss and where you expect to be in the process when they return.

Implications board

When Mike returned to the sprint, he saw all the implications of the solution we worked on.  His insights were both valid and vital. They just weren't part of the process we were in.  

Mike wasn't alone in this, though.  Throughout the time, team members would say things like, "well there's alot more conversations that need to be had in order to..." or "before you do you that, you'll need to..."

These statements were accurate; someone would need to do most of those things.  But two problems remained:

1. We can't discuss it now. The problem we were working on needed to be solved two years earlier, but part of why meaningful change has been slow was the felt need to go down each of the rabbit HOLES before even considering a solution. We would have spent the whole week in a meeting and have yet to accomplish much.

2. I don't want you to think about it now. When people see these implications, they feel they must either do them right now or remember to do them. This tendency is a problem because I needed all their brain power there in that room.

I needed a place to capture implications that required action so we could acknowledge them and continue ahead. As part of your setup, have a space to capture these concerns, give a specific first step, and assign a person and a due date.

Remember you're working on a concrete solution, so you can then go and get concrete feedback from everyone.

A lesson in organizational culture.

At one point, a stakeholder missed half of the day and 

Remember how when Chelsea came back, she was so surprised by how much progress we had made and what we had already decided? She explained that in project management, you do a lot of planning and then when it's all decided, you begin to execute.  

I took the moment to share the difference between waterfall and agile methodologies and explain that because what we had decided was written with a sharpie on paper, it could still be easily adjusted. In fact, we had already modified it by crossing some things out and writing something new.

It made me think about how organizational culture is formed by methodology.

Earlier in the year, a colleague and I spent about an hour drafting a document to kickstart a conversation involving four different departments collaborating on a common goal.  

We received a ton of pushback about how we had developed a proposal without the input of key leaders. The irony was that the email sent was to all these leaders asking for their input.  

We were literally sixty minutes ahead of them in the process!  

This situation was confusing, and I didn't know what to make of it at the time. Now I realize this response was also informed by an idea that by the time there are concrete facts, the facts are set in concrete and thus unchangeable. 

We knew that asking for feedback on a specific idea would generate better, more specific feedback, but we were unaware of the assumptions that came with being specific.  

In hindsight, it probably would have helped to orient the other stakeholders to the process by saying something like, "we were discussing an opportunity today and wrote this down just this afternoon to get your feedback on them."  

Providing a clear context of the timeline and process could have disarmed the feeling of being left out and avoided the assumption they were just being asked to approve a proposal rather than feedback on an idea.

If design sprints are new to your organization, reflect on how the current methodologies inform your work culture.  You may need to do extra work to translate your new methods, so they aren't misunderstood.

In the end, I was surprised that learning sprints aren't just a personal experience but an organizational one too. What an excellent opportunity to invest not only in your own growth but in the growth of your organization.

‍

‍

‍

‍

Lessons Learned

I knew facilitating my first sprint would be a learning experience, so here are some of the key learnings for you to take away:

• Print out your schedule and note and start with the no-device norm.
• Clarifying the scope at the beginning will help you reel people back in when they venture outside the boundaries of the sprint.
• Providing this extra context orients your team to the problems they're solving for.
• For an effective sprint, you need to set clear expectations by naming the process.
• If they have to miss part of it, preview what they will miss and where you expect to be in the process when they return.
• As part of your setup, have a space to capture these concerns, give a specific first step, and assign a person and a due date.
• If design sprints are new to your organization, reflect on how the current methodologies inform your work culture. 

Sprints are premised on iterative learning. So get out there and go lead your first sprint.  Learn for it. And then do it again.

Here are a few resources if you want to learn more about design sprints,

• What is a design sprint
• Sprint book