Lessons From The Agile Approach To Future Proof Your Organization
In almost two decades, the agile approach to project management (especially software project management), has become strong and is getting stronger. So how is it, that despite the criticism it has received, agile management shows no signs of receding? One reason could be the proliferation of the global software industry itself. Between 2001 and 2019, when technologists put together the Agile Manifesto, the global software industry has grown.
This fact offers observations at many levels, and at each level, organizations can heed lessons that will help them absorb the resilience imbibed by the agile approach.
Market Demand Is Not Perfection: By definition, agile is about flexibility. It advocates iterations and a frequent ‘back-and-forth’ between stakeholders. In other words, the focus is less on planning and more on execution. Larger organizations in particular, are guilty of analysis-paralysis. It is not unusual for organizations to take up to a quarter perfecting annual plans, with five-year “strategy” consuming even more time and resources across the world. The irony is that by the time such plans are ready for execution, market findings have become obsolete: smaller, nimbler competitors have entered the space, USPs are under threat, and the organization must discover ways of battling this new reality. Under the agile approach, ‘getting out there’ takes precedence over ‘getting out there best.’ Agile assumes that the market will continue to define and hone what it expects ‘better’ to be.
Future-proofing demands that the generalist be at the center. Responding well, quickly and consistently to simple changes in a slim product line is healthier than managing an ever-bloating portfolio of complex products. Interestingly, R&D-led industries—chemicals and pharmaceuticals, adapt better. Partly because in practice, the BCG Matrix approach still persists: With a star product, a cash cow, a question mark and a dog. Even if not in theory, we do find the frequent divestments and M&As in these industries reflect a focus on ‘what works’ rather than what doesn’t.
A second interpretation is that MVP has a market. Setting standards with the objective to differentiate, to compete, or simply to outdo can be defeating. In software development particularly, competition is no longer limited by geography or even by known capabilities. Smaller outfits regularly threaten the market space of established leaders, offering to meet the most basic, skeletal requirements of a client with products that require a fraction of the cost and time.
For organizations seeking to future-proof themselves, the lesson here is: Focus on the need, not the product’s marketability. Need isn’t limited to problem-solving. Equally often, it’s about providing utility. So form, time, place and possession: If a product is answering even a small, simple utility amongst these, it is worth testing out. In order to stop seeing disruption as a threat, it needs to be treated as a market force, an operational catalyst, but implementation is hard. One way around this is to encourage intrapreneurship by awarding spontaneity with a viable business case. According to the agile methodology, people direct processes, not vice versa. This doesn’t mean processes must be discarded altogether, but that leaders must design processes that facilitate ideation, not inhibit it. A culture that encourages creativity by making work a ‘safe space’ to experiment, make mistakes and explore ideas is more agile (and more future-proof) than its counterpart where creativity is subservient to hierarchy or must pass through a long chain of approvals before being recognized as such.
The ‘Car Vs Bicycle’ analogy is often used to illustrate the difference between conventional project management and the agile approach. Under the traditional approach, the project sponsor defines a given outcome (i.e. producing a car), and all other steps: Planning, Execution, Monitoring and Control work in sequence to meet that given outcome. The project is incomplete until the car is ready.
The agile approach, by contrast, is more consultative: Users and producers work together to identify the need,and work towards producing the leanest, most efficient product that will meet that need. So instead of a car, the project team produces a bicycle (the MVP), to meet the underlying need of mobility, that the car is supposed to fulfil. In the next sprint, it may add another functionality, like more wheels, and so on, until a car is made. Despite being an iterative process, which accepts imperfection, this approach serves customer needs better. It responds better to changes in customer preference and evolution within the buyer journey.
Profits drive innovation, (not the other way round) is another lesson. Sounds shocking but makes perfect sense under the agile approach. As the bicycle analogy illustrates, agile rationalizes resources, which is not the same as dividing them. When it comes to future proofing, companies fail because they over-invest in one aspect of organization transformation with not enough concrete outcomes planned—or conversely, too many rigid, pre-defined outcomes.
The agile approach is one which advocates a healthy middle ground. It is about experimentation, but not about taking risks. In other words, the scope is controlled and monitored.
Mapping this to organization culture is easy in theory, but harder in practice. It means being clear on the vision and mission of one’s company but being fluid in objectives. In other words, future proofing starts with a clarity of the problem, but not necessarily its solution.