In today’s age many organizations are moving towards implementing Agile as their development practice. This is great, and a great step in the right direction. But “doing Agile” is very different from “being Agile” as the right mindset may not be fully adopted.
“Doing Agile” means adopting and implementing Agile methodologies, ensuring the development team (and partners) follow the Agile principles. By properly implementing Agile, teams can leverage increased transparency, communication and flexibility, therefore reducing the risks associated with building the wrong product, and creating stronger alignment among the organization and its customers.
However, efforts at implementing Agile are often focused on the development team. To reap the benefits of Agile and infuse a culture of agility within the organization, an Agile culture change should not stop at the development team. What is the value of using Agile in development if the process of sourcing new ideas, ideating a new product, and testing new concepts are done in Waterfall? How useful is Agile if after we have launched a new product we fail to connect with our customers and learn from them how the product is performing and how we can improve it?
Being Agile vs doing Agile
To reap the benefits of Agile, align itself with the marketplace, and better satisfy its customers’ needs, an organization should infuse a culture of agility throughout its ranks. Business leaders should adopt the key principles and accept the iterative development model offered by Agile as a way to reduce risk, optimize return, and satisfy customer needs. Executives need to feel comfortable with a (relatively) lack of long-term plans, and instead accept that roadmaps are designed to provide a short-term view and may change dramatically over time. Business leaders should appreciate the value of launching an MVP (Minimum Viable Product) in the marketplace as early as possible, learning from their customers, validating (or invalidate) hypotheses, and improving from it.
Agile should not be limited to development teams. Business teams can adopt it to align on objectives and create stronger collaboration and transparency on the work. I have worked in teams whose work product was a marketing plan, or a training procedure for HR. These teams adopted Scrum, using 2 or 3 week Sprints and using the Sprint Review meetings to share updates with top executives.
Often times executives struggle with adopting Agile because the world they live in is nothing but agile. Quarterly forecast, Wall Street analysts, and shareholders, all expect clear plans and metrics that are met. Customers and partners expect a roadmap that extends well into the future. Agile is perceived as the antithesis of planning and is therefore resisted.
But at its core Agile methodologies are designed to control risk. Isn’t this one of the most important tenets of any business?
Product managers can help their organization become more agile by acting as champions and implementing techniques that enable executives become more comfortable.
Luckily for us, Agile, Design Thinking and Lean Startup methodologies help organizations infuse agility at every step of product innovation.
Agile: build in iterations, one step at a time. Validate each iteration with end users. Adjust and re-prioritize if necessary.
Design Thinking: approach problem-solving with a customer-centric iterative approach based on learning, ideation, and prototyping.
Lean Startup: build-measure-learn cycle focused on early validation and MVP. You strive for market validation of your idea before investing in building it. The key question is what is the minimum MVP? What can you build to validate your idea without a full investment of time and money? Or even better, can you validate your idea without building anything?
