8 Agile Principles to Drive Innovation in Large Organizations
When we think about product development within enterprise organizations, the phrases “rapid innovation” and “agile development” are probably not the first to come to mind. Frameworks for rapid innovation (such as agile) inherently promote embracing the unknown through a “fail fast” mentality rooted in rapid experimentation and continuous, iterative development. Yet more often than not, doing unproven things can be seen as a threat in large organizations.
But, the world around us changes rapidly. Continuous innovation is necessary to stay relevant in our modern world. Enterprise software companies are susceptible to disruption by new organizations and industries that can sprout up virtually overnight. That’s why enabling rapid product innovation is important, even for enterprise companies.
Today we’ll address a few ways product managers and product leaders can drive innovation in enterprise organizations. Many of our recommendations are rooted in agile principles and philosophies. But we’d like to point out that even Waterfall organizations can be successful with these if they start small. For more tips on innovation, check out our recording of our most recent webinar “Innovating in the Enterprise.”
Can Enterprise Organizations Embrace Agile Development?
Enterprise organizations can absolutely find ways to embrace agile principles and innovate rapidly. But, their approach may look different from agile development in a startup or mid-sized organization. Why?
Startups and small organizations are often still finding their place in the market. Startups in particular are still actively learning about their markets, customers, and searching for the right business models. As a means of defeating uncertainty, they can use agile principles to test ideas, learn new things daily, and course correct.
Meanwhile, enterprise companies typically have established their footholds in their respective markets. They most likely have years of experience and accumulated knowledge to draw from when making decisions. They know what has worked for them historically and can frequently use this knowledge to continue coasting along.
As an enterprise product manager or team with years of experience, there’s often a bit of tension when it comes to experimentation.
This is why innovation starts with culture. In larger organizations, you may need to rewrite years of habits and defeat “but we’ve always done it this way” before you can build a culture that supports innovation. So start small. Below we’ll cover a few small, incremental changes you can make to promote a culture that supports innovation.
Agile Product Development Culture in the Enterprise
Innovation culture within an enterprise organization is often hindered by traditional product development practices (such as Waterfall). Enterprise software product managers may feel pressure from leadership to spend extended periods of time on research and discovery efforts before any development and testing happens. They also may not feel empowered to make decisions quickly out of fear of failure. Here are some tips to create an environment that supports them.
1. Trust and Autonomy Empowers Teams to Innovate
One suggestion Robin Calhoun shared during our webinar is that innovation doesn’t have to be something huge. It doesn’t have to mean new product or new direction. You can start small.
At Jama, she says, product teams have both the power and trust to solve problems in the way they see fit. Once the problem is clearly identified, the team is free to determine the best solution. The team is usually very close to the customer and therefore can make the best judgement calls on what to build and how to build it. Which brings us to our next suggestion.
2. Access to Customers Reduces Innovation Risk
Innovation is far less risky when you start small and get feedback as quickly as possible.
As Jay Badenhope explained, the opinions of people within the four walls of your organization are not always the most important ones. Yet, stakeholders (and yes, their opinions) still play an integral role in enterprise product development decisions. Ultimately being successful in innovation is about knowing what your customers need, not just what stakeholders think they need.
So teams need access to customers. And they should feel empowered to make decisions based on what customers (not just internal stakeholders) actually say.
3. Retrospectives Drive Continuous Improvement
Even Waterfall organizations can benefit from retrospectives. Give your team a safe environment to discuss challenges and frustrations without fear of judgement. If you can foster a sense of psychological safety and a culture of retrospective thinking and iterative improvements, you can start your team off on a path to more rapid innovation. All this, without changing a single thing about your process itself.
Enterprise Stakeholder Management in Agile Organizations
Another challenge for product managers and agile development teams in enterprise organizations is managing stakeholders.
Stakeholders and executives are still in charge of the majority of product decisions, which our webinar survey validated. If your executive team is calling most of the shots, you’re going to have a difficult time driving innovation.
Furthermore, it can be difficult for product managers to get buy-in from executive stakeholders on product strategies that are highly-dynamic and built upon unknowns. How can you get executives to approve product strategies that almost certainly will change? Here’s a few tips that will help you work with stakeholders in an agile fashion.
Stakeholder communication is not an event. It is not a task on your to do list. It is not a box you can mark “done.” Continuous communication with executive stakeholders becomes significantly more important for product teams who want to innovate more rapidly. Transparency builds trust, so rather than withholding information, be forthcoming.
Get buy-in from stakeholders not only before development begins, but also during development as changes are made. Create an ongoing dialogue that doesn’t leave stakeholders feeling left in the dark.
2. Align on the Fact that Priorities will Change
If you’re embracing rapid innovation or agile principles, you need to set the stage for change. Stakeholders should be aware that the product roadmap is not a plan set in stone, but rather a living document that can change. Explain to stakeholders that the further out you’re stepping and planning, the less certainty there is around your strategy.
It may even be useful to point out specific items you’re fairly certain about and those that you are less certain about. Reflect that change is likely within your product roadmap on the roadmap itself. And also, explain why certain items are less certain than others. This will help you build trust and confidence from stakeholders who will understand that upcoming priority shifts are not arbitrary.
3. Remove Specific Dates from your Product Roadmap
Roadmap timeframes and dates are frequent points of friction between product managers and stakeholders. You may find it best to remove dates from your product roadmap altogether. Or, if your executive team still demands dates, you may elect to use “big picture” dates rather than specific deadlines.
When you present your plan without dates, or with more broadly defined timeframes, you take the focus away from the tactical aspects of product development and place more emphasis on the overall strategy. This is the goal of a roadmap in the first place; to communicate high-level strategy.
Your roadmap should not become a “promise” to your executive teams. Instead, it is a depiction of your strategy given the things you know right now.
4. Talk in Broad Themes Rather than Features
Another way to refocus stakeholder attention to more strategic elements of the product roadmap is to simply present “themes” rather than features. Theme based product roadmaps talk in broad themes that tie back to strategic goals. They give product teams more flexibility around the specific things that will be built. Rather than telling stakeholders “here’s a list of the features we’re going to work on,” themes should focus on outcomes. What metrics will be moved by each theme?
5. Evangelize the “Why”
You don’t have to preach the agile gospel, or even say the word agile. But you do need to drive awareness. Be transparent with stakeholders about your intentions when making changes and shifting priorities. It will not only help you build trust, but also help get stakeholders into a more agile mindset. Rapid innovation doesn’t have to be a bad word, but you need to be prepared to enlighten stakeholders about why it isn’t a bad thing.
Ideally you can talk about “why” delicately. Talking about all the shortcomings of the status quo will only make people defensive. Focus instead on addressing the values and benefits of a more agile approach.