Innovation and Scrum
How do we deal with innovation in Scrum processes?
In the past week we broke our normal pattern of scrum sprints with an innovation week where the team works on their own ideas. Everyone knows the stories where Google employees can use 20% of their time for their own projects. Whether this is true can be discussed. You can read more about this at: The truth about Google’s famous ‘20% time’ policy.
Although Scrum can help enormously in getting feedback from users quickly by working cyclically, it does not always offer room for prototypes. In a sprint there is often no time for this and the sprint target runs too much risk. After all, the result of the sprint must comply with the Definition of Done. A prototype often cannot meet these high requirements. However, it can be very useful to make room for this outside the scrum process.
We choose to reserve a number of weeks per year in which developers can work on their own ideas. We have set as the only precondition that the idea must be presented by means of a demo at the end of the week.
You might wonder why these ideas are not on the product backlog. I think this has to do with a number of factors. The most important thing is that users often think in terms of existing software. Such as the famous quote from Henry Ford: “If I had asked people what they wanted, they would have said faster horses.” (The question at all is whether Henry Ford ever said this). I think this does not mean that Henry Ford has never listened to his future users. It only gives a good indication that a problem can often be solved in smarter, nicer, faster or better ways.
The result of our ideas does not always lead to implementation. The process of concretely defining an idea and validating whether “it works” is just as important. Useful knowledge is often gained that comes in handy at other times. Yet it regularly produces gems that can be included as a concrete user story on the product backlog.
An additional advantage is that developers think differently about the future of a product. Often developers are focused on “how” something should be developing and less on the “what”. The “what” stems from a well-prioritized product backlog. As a complete team thinking about what really adds value, product owner and scrum team are closer to each other and ultimately a better product can be developed.
24 March, 2018
by Maarten Urbach
Subscribe to our newsletter
Recieve free updates on new blogs, webinars and tutorials
Let us know how to reach you. We keep you updated on the latest developments concerning test data, test data management, subsetting and masking. You can unsubscribe at any time.