Innovation and Scrum

Once in a while we break our normal pattern of scrum sprints for an innovation day or week for our team members to work on their own ideas. Everyone knows the stories where Google employees can use 20% of their time for their own projects (The truth about Google’s famous ‘20% time’ policy). Whether this is (still) the case can be discussed, but we like the idea and think it might be very helpful.

Scrum

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 days or even weeks per year on which developers can work on their own ideas. The only precondition set is that the idea must be presented by means of a demo at the end of the week.

Product backlog

You might wonder why these ideas did not appear on the product backlog. 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

The result of our innovative 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.