Today I want to talk about a book I read recently titled ‘Sprint’. It’s a book that explains the procedure ‘Sprint’ which can be used to solve tough problems. To put it simply, a ‘Sprint’ is a 5-day process which is used to create solutions and test them quickly and efficiently.
It’s a neat way in that it can test out various solutions, find what the pros and cons are, and improve the solution along the way. People can all feel involved as everyone has a say and because everyone feels involved, once the solution is decided most would feel satisfied.
My team also tried to implement this method a while back as one of our team members recommended this procedure. To make things blunt, we failed.
The reasons why we failed can be numerous. Maybe it was because people just weren’t as involved. Or maybe 5 days was just too short for us. I tried to organize the reasons why in my own way and I think there were mainly 3 reasons for our failure.
First, hardly anyone has 5 full days to spare at a large company. I’m currently working at one of the largest IT companies in Korea and to get everyone to clean out their calendar for 5 days as recommended in the book is basically impossible. The book explains you need to get 5 days to fully concentrate on the Sprint and create a solution. But in a large company, you’re not just doing one problem but several at once. You have to go to other meetings and communicate with other teams. Because you can’t commit for 5 days, you start to lose track of how things are going during the Sprint and eventually participation rates drop as well.
Secondly, it’s not sustainable. You might be able to do one Sprint to solve a difficult problem. But creating a new service involved hundreds of difficult problems and you can’t simply create a prototype and test it each time. Not only would it take too much time but everyone would be burned out quickly as well. Thus the Sprint might be a good one-time experiment but it proved to be difficult to adopt consistently.
Finally, what I felt was the most important part of Sprints was getting proper feedback from users and use it to reinforce our previous solutions. However, this part seems to be omitted from the Sprint process and is very difficult to apply. Creating a prototype is great but what’s most important to getting feedback on why prototype A is great and B has flaws. Let’s say you made a prototype and everyone hated it. Do you do another sprint? Make everyone clear out another 5 days to make a completely new prototype? The book gives examples of successful sprints but in my experience, a lot of the times the solutions we come up aren’t met with positive feedback. Then we need to do something about the negative feedback and as we have constant meetings and discussions suddenly the Sprint procedure disappears and we work as we used to.
I think the Sprints can be more powerful at smaller companies who have a minimal group of people who are concentrating on one problem. But for larger companies who are juggling various projects at once, I don’t believe it can be something that can be constantly implemented. Of course this is my experience and my opinion and I’m sure there can be others who adopted Sprints fully. I’m curious on how they did so and how they are implementing it currently.