Innovating with Scrum

Sometimes I worry that we are wringing all the agility out of Scrum with the high degree of prescription that I see some teams follow. At times I see backlogs rigorously maintained and scrubbed. Product Owners tightly managing how/when/if the backlog items flow out of the backlogs into a team's sprint. And the team maniacally focused on delivering exactly what was specified in each sprint. The irony here is, that more often I am coaching my teams to execute exactly as I just described!

I struggle though with prescriptive scrum on how we can deal with innovation. In my 20 years building software I have seen most interesting innovation come from the individual, not the team. Yes, this will be heresy to the agile zealots. But good Scrum Masters (team leaders) must find a balance between the team and the individual. We must build a culture and environment where not only the team is empowered but where the individual is encouraged to innovate. 

Innovation can be encouraged with varying degrees of formality. It may be that the culture encourages individual innovation in so far as it does not impact the team's velocity and their ability complete the committed work within a sprint. This leaves it up to individuals and team to self-regulate time not spent burning down the sprints story points. This approach will work for some teams but can certainly be abused with individuals "going dark" and leaving the burden of the sprint commitment with the rest of the team.

Another approach I've seen used is an "Innovation Day". This is a plan day (or days) where the team is encouraged to innovate. Its free form. Individual activities may be pursued, or the team may self-organize into sub teams. Have some fun with this. It can be used as a tool for the team to relax and let off some steam after a major development effort. Also, you can have awards for the innovation. Most creative, most utility, most ridiculous, ...

Lastly there is the "Innovation Spike" (a nod to Kent Beck's Architectural Spike here). Jeff McKenna and I came up with this approach over one of the many discussions (therapy sessions) that Jeff and I enjoy together! The innovation spike can be planned and managed in the context of prescriptive Scrum. Here's how it works. Firstly, you've got to decide to perform an Innovation Spike. This will require buy-in and support from management, product owners, and the team. If you can't get buy in, then forget about it. 

Assuming your selling skills are well honed, and you've got buy-in, the first thing the Scrum Master will do is decide how much time to allocate to the innovation spike. Don't over-engineer this. Let’s assume we have a team 9 people that has a velocity 45. The Scrum Master decides to allocate two resources to the innovation spike. The allocation of resources to a spike should be managed as well. The selection should be open and transparent, and an all-inclusive rotation should be established. The Scrum Master will then create a User Story titled "Innovation Spike" for the sprint with a story point estimate of 10 points. The estimate is calculated by dividing the team's velocity by each resource's average contribution to the velocity. This approach will keep the team's sprint to sprint velocity consistent.

So, in review, here are three proposed ways of managing innovation with Scrum:

• Informally
• Innovation Days
• Innovation Spikes

That's great you might say. But what do we do with the cool new code, prototype, mock-up, or whatever that gets produced because of the innovation. Just check it in, right? WRONG! The result of the innovation may be completely thrown away. It needs to make its way into the product using the prescriptive process. It’s evaluated in the context of the other items of the backlog. The Product Owner makes an explicit decision to move it into a sprint. Appropriate User Stories, Unit Tests, and Acceptance Tests are built, it's coded, and finally accepted into the sprint/product.