Where does your “innovation” happen?
In the software industry, I see “innovation” put on a pedestal and celebrated separately from the daily grind by senior leadership. It’s a public recognition that they think there is zero innovation in their software teams. Which is exactly because they don’t let them innovate! Then, they delegate it to a few blessed individuals who they think are thinkers and make it their jobs to innovate. This takes many forms: A think tank, an idea incubator or even the popularly named innovation lab. (Please know I hold no grudges against people in these roles, I actually love the work innovation labs do. But bear with me, because I think there’s a better way to accomplish the same thing)
Do you see your leadership demanding higher productivity from the teams? Maybe even comparing teams? These are symptoms of the same larger problem. If your company has embraced agile, you should believe in self-managing and autonomous teams. And if you believe in self-managing, autonomous teams, and if you trust the people you’ve hired to do their jobs, then there should be some trust afforded to those teams to do what you’ve asked them to do. This is where the innovation should be happening. Right inside the products you’ve already decided to invest in.
Oh wait, you do actually decide what to invest in deliberately right? You know, that central portfolio funding process that transparently tells the organization which teams are working on which products. The same place where you make trade-offs to decide which products (or projects or programs) you think make the most sense to serve your customers and your company’s vision, mission, goals and objectives. If you do that… then you have a place to decide where to experiment and where to invest, in the context of your greater priorities. No separate innovation department required.
For experiments that are full-on products, this is easy. You weigh them just like anything else you decide to work on. Presumably though a lean business case or cost of delay prioritization strategy. And if you have a team available to work on it, or you can afford to spin up a new team, off you go, innovating.
But here’s the trick: some of those experiments aren’t at the product or project level but instead are features inside of products you’re already building. How do you think that should work? I hope your answer is Product Management! But, admittedly, this is where I think there’s some grey area. I’m assuming you’ve got a central Product Management function with Product Managers defining the vision of your products and on-team Product Owners working directly with your teams to prioritize the day-to-day decisions. The reason I think there’s some grey area here is because some innovation is so small, it’s just regular day-to-day experimenting that your Product Owner and team should have full leeway to play with in their backlog and development schedule. A small feature-level experiment should be based on a hypothesis and have a customer-feedback-loop to validate it as soon as you are able. This is probably something you do alongside other work inside a single sprint, maybe two.
But a large enough feature-level idea might rock the roadmap a little. You will have to judge how sensitive your organization is to shifts in schedule or how adamant they are about long term milestones and delivery dates. If the product team wants to add a significant enough sized feature that is worthy of being mentioned in the roadmap, then it should probably also go through the portfolio approval process, because the organization should consider its weight and customer value in comparison to other investments.
Personally, I can’t imagine doing it another way. Creating an innovation thing “on the side” is essentially admitting that you are unable to prioritize your investments well enough amidst the daily chaos to make room for innovation. What’s worse, in my opinion, is that in order to carve off this separate budget for the side-venture, you invite additional risks and redundancies with separate development efforts, prioritization efforts, vendor negotiations and possibly much much more.
Now, some organizations rationalize it a different way. “This is different”, they’d say. They might be exploring an entirely new market, a new vertical, a new geography or even looking into a new industry entirely. And I get it, these do sound super different. Just ask yourself, if the technology, the process, the product management and the delivery justifies duplicating anything or amplifying risks in any way. Maybe you need people with different skills, different backgrounds or connections to different customers, but I believe firmly you can and should manage this within the confines of how you’ve designed your organization already. And if you’re not ready to hire into those new skillsets or markets, perhaps all you need are some contractors or an outsourcing arrangement but I’d suggest the prioritization and investment decision should all fall within your existing portfolio.
It is possible that an experiment does generate such positive results and the impact to the organization is so disruptive that you decide to spin off an entirely new company to pursue the new direction. But that is probably a very rare event and it too should follow an agile mindset, waiting for the last responsible moment to figure out how to address that problem if and when it happens.
Someday, managers and executives will realize they should trust the people they hire, all of them, to be innovators following a common vision, mission and mindset, allowing some breathing room on their existing investments in products and projects to just let it happen. Until then, I know, we all struggle to find greater business agility and simple processes to manage our daily chaos. I will keep talking about these things though and am happy to help nudge the world slowly in this direction. Let me know if I can help you and your organization think about how to do these things!
About the Author: Brian Link is the author of AgileMisconceptions.com (also available on Amazon) and the owner of Practical Agilist, LLC. Brian provides leadership and coaching services as an Agile Coach at LeanDog. Follow Brian on Twitter @blinkdaddy or LinkedIn, and subscribe to his newsletter.
