A journey of improvement
At Brightec, we’ve facilitated a lot of workshops; for enterprise clients, startups and anything between. Continuous improvement is one of our core values and we are always on the lookout for ways to improve our methods. This is just another chapter in our journey of improvement.
A friend recommended the ‘Sprint’ book by Google Ventures about a year ago and since then I have heard a lot about it.
The premise is simple - over five consecutive (and intense) days you tackle a large problem and the sprint concludes by testing those ideas on real users.
Reading the book was exciting and eye opening. I recognised a lot of the techniques described, many of which we were already using. What makes it unique is the prescriptive nature of the design sprint - working through the activities in order and towards a specific goal.
Here at Brightec, a new project was about to start and it had some definite design challenges. This gave us the perfect opportunity to try a sprint out (thanks to our gracious client who allowed us to experiment with them).
We ran the sprint in the first week of 2017 and it worked beautifully. Here are some highlights:
- It was great fun.
- We gained a deep understanding of the client's project and business in the quickest time ever.
- Five users tested a well thought out and reasoned prototype.
- We finished with some great insights to take us into the rest of the project.
All of this in only 5 days. Epic.
We learnt a lot on our first sprint. Some things we’ve picked up have had a relatively small impact, helping us to validate or challenge our current processes. For example:
- Discovering the ideal pens and post-it note sizes for sketching
- Times and durations for sessions and activities
- The importance of healthy snacks for blood sugar levels
- Starting with a long-term goal that we can form everything around
- Dedicating a room to be the ‘brain’ of the sprint
- Ensuring the sprint is uninterrupted as far as possible
We’ve also seen some of our sprint learnings have a much greater impact on our organisation and we’ve taken them forward into our day to day work.
Meetings can always be better! Particularly in our industry, working with developers and designers (with often differing skill sets and characters), the stakes are high and it’s not an easy job to find meeting techniques that work well in our environment.
The reasons why are explained perfectly by Paul Graham on his blog.
One reason programmers dislike meetings so much is that they’re on a different type of schedule from other people. Meetings cost them more. — Paul Graham
During the design sprint, we learnt two techniques that have helped us transform our meeting processes.
1. The Time Timer
It’s a great device. Period.
I have a young daughter and helping her to understand the concept of time is difficult. In doing so, I often try to use phrases, such as; “when the big hand reaches this position”, “as long as an episode of Paw Patrol” and “until the alarm goes off”.
These are abstract concepts and difficult to understand. The Time Timer makes that simple by visually counting down time.
An innovative, simple time management tool designed to “show” the passage of time through the use of a patented red disk — timetimer.com
We now use the time timer in our meetings, enabling our team to easily gauge how long they have to discuss something.
No longer do you have to remember what time you started or rely on someone else to let you know when you have 5 mins left to wrap something up. Instead we have an easy to use visual representation of time. Our team love it.
2. Straw Polls
The second technique we have adopted is straw polling for making quick decisions as a team.
This technique is now used to help us decide anything, from what to focus on for our R&D days to where we are going for lunch.
The process is simple (transcribed from the Sprint book):
- Give each team member a piece of paper and a pen.
- Everyone takes three minutes and quietly writes down ideas.
- Everyone takes two minutes to self-edit his or her list down to the best two or three ideas.
- Write each person’s top ideas on the whiteboard.
- Everyone takes two minutes and quietly chooses his or her favourite idea from the whiteboard.
- Going around the room, each person calls out his or her favourite. For each “vote”, draw a dot next to the chosen idea on the whiteboard.
- The Decider makes the final decision. As always, she can choose to follow the votes or not.
The structure of this decision making is helping us a lot. It makes for some pretty efficient decision making.
Our first design sprint has been a major success
We loved it, our client loved it and the benefits it brought to the project is amazing. If you haven’t read the book then go do so! gv.com/sprint