Innovating with Scrum

Sometimes I worry that we are wringing all of 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 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 an 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 efforts.  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.  Lets 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 as a result of the innovation.  Just check it in, right?  WRONG!  The result of the innovation may be completely throw away.  It needs to make its way into the product using the prescriptive process.  Its 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.

Comments

[David Clarke]

John:

Interesting ideas. Your statement from the post "In my 20 years building software I have seen most interesting innovation come from the individual, not the team.", made think of a book I just read on innovation in making films. It was the individuals with a vision that drove changes to the Hollywood system and ended the reign of the system that had controlled film making for decades. The traditional film 'developers' adhered to knowing exactly what the film would look like before a single dollar was spent and created elaborate spreadsheets, story boards and project plans to attempt to accurately and rigidly control the production process.

The innovators were the ones that broke this mold; maintaining that much of the story (application?) could not be fully understood until the process itself began to unfold. By driving forward with a singular vision and relinquishing the top-down control resulted in much greater creativity from all the individuals involved in the creation of the films. Again the analogy holds; developers and testers are far more creative in an Agile process that is both guided by a vision but also enables them to make significant contributions as opposed to a tightly controlled design process that results in developers being 'mere coders'.

This new approach drove the studio (waterfall?) people crazy, but the ones that persisted against the system made the movies "Bonny and Clyde", "The Graduate" and "In The Heat of the Night", all Oscar nominated and multiple award winners. From that year on (1968) film production changed forever and laid the groundwork for what we now call Independent Film.