Real Sprints #3. Expectation and team building
How running a problem framing workshop prior to a Design Sprint helped establish expectation and the effect Design Sprints have on team building.
Each week, we’re publishing real Sprint stories, from people in the field who tell us their story how they applied Design Sprints and their challenges and successes.
Dan Levy from More Space for Light talks about the challenges of running a Design Sprint for the first time in a new department and the effect it has on a teams understanding of their challenge and user.
We were re-engaged to run a Design Sprint with one of our clients Health Direct Australia. They had heard of the success of a Design Sprint that we had run in another department and wanted to try out the process.
This was undoubtedly one of our most stressful sprints, but also one of our most rewarding.
The background to the sprint was a major transformation project migrating an existing legacy system. It was a massive project which could have been broken down into dozens of sprints. Initially, it was being built without much input from the users of the system, the design sprint was an opportunity to engage with stakeholders because thus far the project had been driven by the technical team and they were concerned that they would build legacy issues into the new system. The goal of the Design Sprint was to build and prioritise a project roadmap that would dictate the technical plan.
Prior to starting the engagement, we assumed that the team fully understood how Design Sprints works. They were familiar with the terms and some of the activities but not having been in a Design Sprint they weren’t clear about what could be achieved, so the first step was setting the expectation.
To kick off the process we decided the best approach would be to run a Problem Framing Workshop looking at how this project fits into the long-term goals of the organisation and identify blockers and challenges that would impact the project.
The problem framing was run with the executive team, starting with “The ideal future”, where they wanted to get too. The result of the problem framing workshop was that we were able to set the objective of the project and identify what would make it a success, This also helped everyone to agree on the focus of the upcoming sprint and establish the expectations of what could be achieved in those 5 days.
We then ran the Design Sprint, however, with a different team from the Problem Framing workshop. Due to the change in personal we had to re-align the Sprint Team so they were prepared for the next few days. This was something we were unprepared for and caused a few issues on the Monday morning. Where we came up short was that we should have spent more time on each of the exercises to build a narrative, so they knew what the goal was and how that took them closer to the objective of the day and the bigger picture. Luckily the team committed to the process and this proved not to be such a problem. In the team, we had customer service and support personnel, project managers and someone from the tech team - no designers!
Users and stakeholders were flown in from around the country. Monday’s focus was really on understanding the user. Prior to the sprint only a couple of members of the team had spoken with customers. The team were really surprised at how users were working with the product and these insights provided some really big “Aha moments and produced a lot of HMW’s (how might we), it was so valuable.
What I loved about this sprint was that everybody went outside of their comfort zones. The team had really frank conversations, embraced the process and were super dedicated.
The sketching part was so valuable, you had people on the team who were able to say for the first time what they thought would be valuable to for their users. The customer support members on the team were really insightful and kept everyone on task.
Something that we really believe in at More Space is that there is a level of accountability of the sprint team. In some sprints, the team are responsible only for the first two days, then another team takes over doing the design, build and UX testing, the team then gets given the results and asked: “is that what you wanted?” We make the team do the whole process! We get them storyboarding, building and running the testing.
We started the process prior to the Problem Framing workshop, with a team talking about features, by the end of the Design Sprint they were talking about tasks that the user needed to complete, what was the flow and the logic of the process, why their users were using it and what do their power-users need it to do! The focus had shifted from product to the user.
My big takeaway is always: Just trust the process!
Something that I find remarkable is not just the hack, not just taking 6 months worth of work and condensing it into 5 days, it is seeing people embrace that creative process. Seeing people light up and become able to express themselves and to feel confident that they have a say and impact in the process, where, ordinarily they would not normally be part of that conversation.
One of the things that I love most of all about Design Sprints is how they empower “Non-Designers” to become integral in the design process, taking their creative insights and adding incredible value that would otherwise be lost.
When you have been working in the Design Sprint space for some time, it is tempting to think that everyone understands the process, however, this is certainly not the case. Checking in with your team prior to and during the Sprint, giving them an overview of the exercise they are completing and how they fit into the big picture really helps to motivate the team when they can feel a little lost…
…and of course when you as a facilitator are feeling a little lost…
Just trust in the process!!
Looking to learn more about Design Sprints?
Learn more about Design Sprint 3.0 by joining one of our workshops offered worldwide by Design Sprint Academy and our global network of partners in Europe, North America, India, and Australia.