Is Agility Making You Less Innovative?
It has now happened four times in the last 9 months: A Senior Executive of a company called us up because they were unhappy with their Agile (typically Scrum) practices. It has taken a bit of time to understand the pattern, but I think we’ve got it: Agility is making some companies less innovative. Let’s explore some of the reasons why this can happen and how to fix it.
The Slippery Slope to Less Innovation
When an executive calls us looking for help, we typically ask a few broad questions. Executives at organizations who have been practicing Agile for some time usually report that quality is greatly improved, the development organization is happier, releases are more predictable, and the overall organization, including such things as putting software into production, just runs more efficiently.
So what’s wrong? When I ask executives “Are you being innovative?” – meaning – are you creating and delivering “big chunk” innovations that continue to establish or maintain market leading positions, the executives typically exclaim “That’s it! We’re more Agile, but we’re less innovative!”. In one case, an executive admitted that he didn’t think they’d delivered anything genuinely innovative in over a year. That’s unacceptable, and it was a good thing that this executives “spidey sense” tripped.
The slippery slope to less innovation begins when teams adopt many common – and very good agile practices: Creating and prioritizing a backlog and producing potentially shippable, working software in 2-4 week time boxes (in Scrum-speak, a Sprint).
Sounds good, right?
Well, it can be more than good. It can be great. Teams creating working software in predictable chunks? What can be better than that?
Innovation is Not Predictable
One problem is that innovation isn’t predictable. It is a bit messy. As your teams gets better and better at hitting every iteration, they can inadvertently start to favor small pieces of work that always get done. Heck – we tell people that SMALL stuff is good and have a wonderful acronym invented by Bill Wake: INVEST. So, people create small stuff. Big chunky innovations get dropped. They are, after all, risky. They don’t always work. They can negatively impact velocity. In fairness, it is entirely understandable that teams start focus on small, safe stuff.
From a product improvement perspective, customers do indeed enjoy small, incremental improvements along a number of dimensions. My friend Jeff Patton teaches this brilliantly when he explains why iterations are critical to successful Agile development.
Unfortunately, while customers often enjoy small, incremental improvements, what they really want are “big chunky innovations” to solve their ever-changing landscape of hard problems. And big chunky innovations are not small, incremental, are not iterative, and don’t fit into one sprint. (And don’t waste your time flaming me about the idea that customers enjoy small improvements. Sure, we all enjoy small improvements to our favorite applications. But that’s not enough. And you know it.).
Epics are NOT big, chunky innovations
The Agile community has readily adopted the term “epic” to mean something that takes longer than a sprint. Typically decomposed into many user stories and related requirements (in creating our online Innovation Games® some of our own epics have exploded into more than 50 user stories and even more related requirements), epics are important for capturing big pieces of work.
But epics are not equivalent to the big, chunky innovations that I’m talking about.
Roadmaps capture big, chunky innovations
The big, chunky innovations that I’m talking about are best captured by your roadmap. Which is needed, because your roadmap is your antidote to the lack of innovation that can creep into Agile teams.
Which brings me full circle to the start of this post. Inevitably, when executives tell me that their Agile teams are being less innovative, they also tell me that they don’t have a roadmap, or that their roadmap only extends a meager 6 months into the future.
Keep all the power and greatness of Agile AND maintain your ability to deliver big, chunky, innovations into your market. Create a market-driven agile roadmap, make sure it captures big, chunky innovations, and use it as the first step in setting the direction of your team.
Finally, don’t get so hung up on “perfect” velocity. In fact, if your teams are always hitting “done, done” in every iteration, start to worry.
PS. Thanks to my friend Ron Lunde for pointing out much needed edits to the original post.
March 24th, 2010 at 24 Mar 2010
Yes, we completely see this in video game development. So true. Like evolution, innovation seems to be “punctuated”. Good insight. Thanks.
March 24th, 2010 at 24 Mar 2010
Luke,
I like that you want to maintain product road-map and product backlog as two separate entities. The road map is populated through market-research or by playing games as ‘Prune the Product Tree’. The product backlog is derived from the product road map and is written in language which is close to the product and can be understood by end-users and developers. May be we need to play the game again to have the customer’s input on the release defined features and to get its feedback on the proposed innovation.
My understanding about innovation is that it is something that the user can not state as requirement. He likes when he sees it. It’s something that has to come from the product development organization through experience, market research and strategic design. Toyota’s Chief Engineer is the person responsible on the features (including innovation) of the car model. It would be interesting to read about the profile of the Chief Engineer.
Thanks for the excellent post.
March 25th, 2010 at 25 Mar 2010
I think that one of the challenges that “agile” teams face is that they adopt the simplistic Scrum rhetoric at face value and effectively park their brains at the door. Disciplined agile developers adopt techniques from a variety of agile methods, including Agile Modeling. Agile Modeling, www.agilemodeling.com, promotes the concept that you need to do initial envisioning to explore the scope and potential solutions, to do model storming throughout the project to explore the details. Particularly during envisioning you want to consider innovative ideas, but you’ll also do so during other modeling efforts throughout the project. Most agile modeling occurs between a few people around an inclusive modeling tool such as paper or whiteboards to help promote the involvement of everyone there.
The best advice that I can give is to think outside the Scrum box (egads, be innovative in your approach to agile!) and consider the true needs of the situation that your team faces. Consider the full life cycle. Consider how to address the scaling factors that your team faces (such as team size, distribution, domain complexity, and others). Go beyond the narrow confines of your certified mastery. To get you thinking along these lines you may find my paper about the Agile Scaling Model (ASM) to be of interest.
March 26th, 2010 at 26 Mar 2010
Luke,
Thanks for a post full of insight. I also see the risks you are pointing out.
When implementing Agile, I often see the need for a product vision, and The need for long term planning. Your thoughts is valuable complement to what I have learned through years of working in product management.
March 31st, 2010 at 31 Mar 2010
Great Post. I agree that a lot of Scrum-in-Practice and Kanban is very much focussed on delivering working software in small bites. I would contend that Scrum with 1 month Sprints, big goals, and a culture that supports failure can deliver innovation. Maybe what these companies need is a workshop on Artful Making to get creativity going.
March 31st, 2010 at 31 Mar 2010
Michael, we contend that big goals are necessary but not sufficient. You need roadmaps.