Scrum is mostly associated with software development, but in the search of a more agile methodology we stole the design process from software developers, and tweaked it for physical inventing. Here is why we wanted a new method and why we went with Scrum.
When we founded Lolle & Nielsen Inventions back in 2010, we used the Stage/Gate project management methodology – a traditional waterfall method for product development we had learned in school.
Stage/Gate and Waterfall are linear frameworks that move forward in stages: Start out by doing research. When the research is done begin conceptualization. When conceptualization is done start embodiment – and so on.
Our problem with Waterfall was, that it works best if the whole project and process is planned in the beginning. As we tried to invent radical new solutions, we couldn’t really do that.
We found ourselves researching long and deeply before moving on to conceptualization, but further on in the process we always ended up in one of those scenarios:
– “Wouldn’t we have discovered this even without spending so much time on research?”
– “Why have we spend time on researching stuff we won’t be using at all?”
– “This new thing we’ve discovered means we need new inputs and research – we have to take a few steps back in the process”
In other words we found the traditional processes a bit too rigid, and we wanted a more agile framework, where we could do the research in iterative steps.
Why Scrum over Waterfall?
The Scrum process was originally invented in the early 90’s for software development. It’s based on the idea that software development is a complicated and unpredictable process – more a controlled black box than a planned process.
Contrary to Waterfall this means that in the Scrum process you don’t know all the requirement in the beginning of the process, the requirements you know can be changed during the process and the framework accepts that some parts of the process will be unknown before you start making it.
A simple diagram showing the Scrum process. If you want a little more explaination this 7-minute video is a good place to start: https://www.youtube.com/watch?v=XU0llRltyFM. Diagram by Mountain Goat Software.
Even though Scrum wasn’t exactly widely adopted in product decelopment at the time, we decided to give it a shot, as it had some of the agile attributes we wanted; The project can start anywhere, we can change to another stage when we feel it’s neccesary – we can mix the process up and research when we need it.
Experimenting with Scrum
When we started adopting the software framework into physical inventing back in 2011, we were some of the first to do it in Denmark. This means we never got any proper training in Scrum, but just grabbed the framework and started experimenting.
In the beginning we wanted to do it textbook style, but it turned out to be a little difficult, as there are a minimum three roles in a Scrum-project – at the time we were only three people in the company, so the group dynamic wasn’t really what Scrum aims for. For that reason we started picking the things we liked and improvising the rest.
Some of the concept was an instant succes. The daily Scrum-meeting was adopted from day one (maybe because we were a little sloppy at updating each other on what we did, and this was the perfect way to fix that in an efficient way) and we also quickly started breaking our process into smaller tasks and manage them visually.
Other things like the ‘product backlog’ has been tested and changed a lot over the years, and we’ve constantly been tweaking our version of Scrum as the size of our team and the amount of active projects has been growing.
The main thing is however, that we’ve changed our mindset as well as process management from linear to agile. How we have more specifically applied it, we will talk a bit about in the next post.
About the series: In the search of a more agile project management methodology we stole the Scrum design process from software developers and made it our own. By turning our back on the traditional and linear waterfall methods we’ve achieved a more dynamic, cost efficient and successful way of inventing.
In this series we want to explain why we made the change to Scrum – and how we’ve applied it.
This is part 1 of 3. Next part will be published next week. If you want to be reminded, you can sign up for our monthly newsletter.