Cheating On Agile
What innovation has taught us about agile practices
Some years ago my company Iterate pivoted from agile consultancy to venture building. Soon after, we started drifting away from the many agile practices we had spent almost a decade internalising. Nobody around us was doing this — were we setting ourselves up for failure? It felt like cheating. I kept a list, so it would be easier to revert.
Today, I felt like publishing the list, and confessing to our heresy (and sharing some thoughts on what we learned from it). Looking forward to comments and feedback. 🚀✌️❤️
Background
It doesn’t matter if you’re a startup or an innovation project: The world will only want a new product if the right people build the right idea at the right time. We see this cleary in the startup world, where a few root causes are behind most startup failures:
- Wrong market timing — usually this means going to market too early
- Dysfunctional founding teams — entrepreneurship is hard, and a team without the right passion, diversity of opinion and grit stands no chance
- Weak ideas — lack of value makes customers indifferent
Macro economics and founder/investor dynamics also play a role, but those are for future posts.
My prophecy: Winners in corporate innovation will be those who aim to solve this struggle — companies who help the right people come together and help them build the right product, at the right time. Most companies don't however. Instead, they go for the high standard for corporate transformation and digitalisation. They go Agile. Before they know it, they implement practices that could seriously impede innovation. This happens because Agile comes from software development. It's about building. Innovation, on the other hand, is about creating. Mix those up, and you will easily miss out on the best opportunities ahead.
Take time as an example. No agile practice tells you it's valuable to let time go by after you've started working on something. In innovation this can be a great idea. Many successful innovators tell stories about how competitors matured their market for them, before they got out of bed and started building on their own. When Google Glasses was launched in 2013, it faced a number of issues, from immature market — few understood what it was supposed to do — to immature technology. It was discontinued after two years of (agile) development. Five years later we're again seeing similar products emerge, most notably Snapchat's Spectacles. It remains to be seen if they succeed, but in the meantime they're clearly building on learning that for Google is nothing but sunk cost. In agile practices, “wasting” calendar time deliberately is heresy. In innovation it can be the single most important factor for success.
Final warning: If you want to try this, people may get angry with you. Just remember: Learning what works and what doesn't in your context is what an agile mindset is all about.
The list: Agile vs Innovation practices
Time
Agile: Long time from customer need to working solution leads to waste, increased complexity and lost opportunities. The faster the feedback loop, the better. Minimise lead time. Create flow.
Innovation: The more ripe a market, the better. Run your experiments, but keep them at arms length. Don't let the desire to build get the better of you. Elapsed calendar time is your best friend. It's all about market timing. Wait for it.
Context Switching
Agile: The time you spend on context switching is waste. Stay on as few projects / teams as possible — preferably only one at the time.
Innovation: It takes a lot more than skills and experience to qualify people for an innovation journey. Nobody (not even HR) can predict who will form a high performing innovation team. The best way to find one is to let people try lots of different teams and ideas — to allow people to search for true passion.
Backlogs and planning
Agile: Tracking future work, that may not happen, is waste. Keep backlogs short and tight. Don’t plan too far ahead. Prioritise.
Innovation: Bad ideas lead to great ideas. Play around with thousands of them. Build diversity of opinion. Keep track of all ideas. The more ideas the better. Don’t prioritise.
Work In Progress
Agile: As few tasks as possible at a time. Slice work up in smaller packages. Ship right to production. Get things done.
Innovation: Have hundreds of experiments running in parallel. Once a landing page is deployed, just keep it there (perhaps it'll start converting tomorrow, perhaps in six months). Keep your eyes and your options open.
Iterations
Agile: Start with week-long iterations or longer, but aim for shorter and shorter iterations, until you don't need them any longer. The most agile teams usually ship right to production when a feature is complete.
Innovation: When fast experiments are inconclusive, you easily get confused. Short iterations incentivise premature conclusions. Separate work rhythm from feedback moments. Allow time to internalise. Then force the discussion: Pivot or persevere? Do we have enough data to know at this point? Are we still waiting for things to play out? (Still need a number? Six weeks at minimum).
Focus and goals
Agile: Work with one thing at the time. Align the team around a small set of long term goals. Find ways to quantify and measure the outcomes you're trying to achieve. Stay focused.
Innovation: Work in multiple directions at the time. Align the team around a high level vision. Talk to lots of people, also those who don't seem immediately relevant. Find ways to quickly communicate all insights with the team and surrounding advisors. Create optionality.
Feedback
Agile: As early as possible. Fastest learner wins.
Innovation: Not if it leads to “instant validation gratification”. Make sure you climb the highest mountain. Know your vision.
This is not an exhaustive list. There are many more practices. There are also many that make sense in both worlds: Visual communication, autonomous teams, process and product ownership, continuous improvement and other team empowering practices make sense in either context.
Conclusion
We never needed the list: We didn't have to revert our practices. Instead, we ended up with two sets of practices instead of one. A set of practices for early stage innovation, and a set of practices for expansion and growth. Successful ventures at Iterate will transition from one to the other. The whole way they retain a mindset of learning, adapting and challenging their surroundings.
Transitioning is a topic any serious practitioner should learn to master. This post was inspired by Kent Beck’s 3x thinking — on how companies go from explore to expand to extract, and how practices and behaviours could change dramatically along the way.
Still unsure you'll be able to convince others about this? Don't discard this post. Put it in your bookmarks instead, and wait for the right timing to pass it around. Our irony is this: We still think of ourselves as agile — perhaps more agile than ever before.
Innovation is a lonely journey, but time is on your side.
Thx to my extended family at Iterate for being on a quest crazy enough for us to gain these insights. Thx to Kent Beck, for comments and suggestions.
