Scrum as a process tool, does not naturally lend itself toward innovation; high pressure environments across short iterations, meeting commitments made to the product owner. I thought I would share some of my lessons/experiences/tweaks with teams to encourage Scrum innovation.
The Product Owner
The Product Owner can be a key force for or against Scrum innovation. When the role has communicated a clear understanding of the product vision to the team, this creates a scope/bound that actually encourages innovation by focussing the innovative ‘spirits within’. This structure not only galvanises the team’s efforts, but focuses the innovation efforts in line with the strategy for the product. I would recommend a lightweight vision for all Scrum teams (capturing the needs, features, and unique features of the product). Roman Pichler’s definition of a Vision (not prescribed by Scrum, but a worthy addition) has been particularly useful for me.
The Product Owner must also be sufficiently engaged with their backlog so that they can recognise good innovation items from the team for prioritisation within sprints. Teams should clearly mark innovation items for consideration and ensure the potential benefits of the innovation are communicated; when using user stories, the ‘so that...’ extension becomes important for describing the goals of the innovation.
Setting the right message
Unfortunately, not all Product Owners recognise good innovation, or understand the concept of innovation. In such cases, innovation tasks are rarely prioritised high enough against the Product Owner’s other backlog items and this can stifle team enthusiasm to contribute innovative ideas.
To combat this, a paradigm needs to be agreed and communicated across the Scrum team that even risky innovations should be prioritised to utilise the intelligence and experience of the team itself to add value to the product; the resulting innovation hits can set your product apart and innovation failures must be tolerated on this road. Scrum teams should celebrate those innovations accepted by the product’s customers as much as those rejected. A 50% target of successful innovation (against failed innovations) can encourage the right level of risk taking in your product. I would also recommend minimal governance being put in place to ensure that all innovations are in line with the products vision; this could be as lightweight as a published statement of where the innovation fits within the product vision.
If innovation still is proving elusive in your team, I have found a simple yet very effective approach was to agree 10% of the teams time (max) to work on innovation tasks per sprint (taken out of the team’s time during sprint planning). By taking innovation out the prioritisation process, you can free up the team to utilise their talents more efficiently, and motivate them more by allowing them to pursue tasks that interest and challenge them. This could take the form of a 'Freaky Friday', Friday afternoons whereby develops can 'tinker' with their own Scrum innovations.
On the team themselves, the more diverse a team was, the more innovative their ideas were. They brought different life experiences and skills to problems and this improved conversations across the team, which intern improved their innovations outcomes. Many colleagues had ideas, but it was only when they shared the idea with the team that the idea was improved upon and taken forward.
The teams capacity for fun and their ability to self organise also seemed a key component for innovation. Encourage end-of-sprint outings, night outs etc... In addition, during sprint planning, allow some time for tasks to emerge to solve your team’s commitments and try not to be too concerned about the accuracy of your task estimates (this can be a frustrating process for the team and I’ve often questioned the value of estimates, especially when they have been forced from the team to satisfy the process!).
The Scrum Master
Many teams hold the Scrum Master as the lead/head of the team. I prefer the team to be reporting to each other, the Scrum Master simply ensures the process is followed adequately and serves the team. Teams will put enough pressure on themselves due to sprint commitments and expectations from the Product Owner, the Scrum Master won’t need to crack the whip. Too much pressure will stifle innovation in the team and the product.
Information is king
Scrum of Scrums is a great tool to support innovation by sharing information across organisations/departments and seeing if another team’s work can be applied to your own product. In the same way as the Scrum of Scrums, social media tools can be used to publish information on your product that can encourage others to innovate based on work you have done, or their comments on your product (release announcements, new development that you have prublished etc...) might be the spark for a future sprints innovation work in your own product. Blogs, wikis are common place in today’s workplace and are a great tool for supporting innovation when used effectively (colleagues are given time to participate in the tool’s networks, items are tagged correctly etc..).
Another method that has worked well is to extend product review sessions to other product’s Scrum team members (add them into your stakeholder set). Creating wider networks is a great tool for innovation, and having demo’s of products (not necessarily in the same field as yours) encourages conversations to be started that can lead to great innovations.
Inspect and Adapt
I’d be interest to hear any other methods out there that have improved innovation in your teams or if any of the methods above have worked for you (or not).
The below book was an excellent starting point for me while looking to improve innovation.