Read any book, article or blog about implementing change in organisations, and you’re sure to come across the term agile. Particularly in the software development world, rightly or wrongly, agile and evolutionary techniques are seen as the antidote to some of the often cited problems with more linear waterfall techniques. A well-executed agile project provides the opportunity to deliver business value sooner, by focussing on the most critical set of features and functions first, then adding to them incrementally. An experienced agile team often works like a well-oiled machine, gaining momentum and getting into the rhythm of delivery.
Clearly, both types of methodology have pros and cons, and discussing these in detail is beyond the scope of this blog article—but sufficient to say that as practitioners we add value by ensuring the right approach is taken in any given scenario.
Yet a challenge we face is what I like to call the ‘buzzwordification’ of agile. The term has become diluted, and worse still, it has significantly different meanings to different people. Our stakeholders may mistake agile (as a project or software delivery lifecycle) with organisational agility. This can lead to some unexpected outcomes, none of which are the fault of the agile team itself.
Imagine the following fictional scenario: An organisation’s Head of Sales wants to improve client relationships and spot additional opportunities for selling to existing customers, so a new Customer Relationship Management (CRM) package is selected. It is delivered using an agile delivery methodology, with additional modules being added in increments over a period of time. Two key stakeholders from the sales team are involved throughout the project, and provide their view on how the system should work. Yet, twelve months after the initial system is delivered, it transpires that sales have not increased and the CRM system is hardly being used at all.
When the Head of Sales investigates, he finds that the members of the sales team who were initially very keen supporters of the system, now feel that it has become an ‘administrative burden’. When he speaks with the people who were involved in the project, they explain that the system is very good – it provides the exact functionality that they asked for – but they just don’t have time to use it.
The Head of Sales digs further. He finds that the team is targeted and rewarded on closed sales – irrespective of whether they were logged in the CRM system – so there is no incentive for them to use it. A suggestion had been made to align the rewards with the data on the CRM system, but a key manager had deferred the decision and had formed a committee to discuss the issue further. Not only this, where the system had been designed to surface and display opportunities for additional sales, an inadvertent fear had emerged that other sales staff might ‘grab’ opportunities to make up their quota – creating an implicit incentive to keep things off the system.
Additionally, when the Head of Sales investigates further he finds that the separate Telesales team operates a rigid set of processes that were never changed. They use a different IT system entirely to capture new sales leads, and it was considered ‘too difficult’ to integrate this with the main CRM system. Worst of all, none of these processes or systems were ever documented—and none of this was uncovered or predicted in advance.
In this scenario, the ‘agile’ delivery of the core CRM software system was the easy part. However, changing the way that people work, integrating with existing technology and assessing the wider process implications was the hard part. This fictional example highlights just one example of how some types of problems may emerge.
Organisational Agility
Delivery of change is often hard, and whilst agile delivery methodologies may help us design and deliver elements of change, the organisation itself needs to be agile enough to adapt to those changes. To achieve organisational agility, companies need to consider the very fabric of their business architecture. Collecting and analysing data about the external business environment becomes essential. This data can help the organisation to make informed decisions and can help it know whether its strategies and tactics are working. This will help shape the change projects that are adopted – decisions can be made based on data and insight more than ‘gut feel’. With more reliable data and information, decision making becomes quicker and clear-cut – avoiding the slow and ponderous multi-layered decision making that can suffocate some organisations.
The ability to quickly pivot and make changes becomes important. When quick change is needed, the type of processes and technology that you use become key things to consider. Perhaps software is scaled up using cloud based solutions during peaks. Perhaps ‘off the shelf’ software is favoured over ‘build it yourself’. Perhaps a new business function is needed—and a decision is made to outsource it (or insource it). Either way, easy integration and the ability to quickly change or add to the IT and process landscape becomes key. Having documented business architecture and being able to assess the impact of potential changes becomes imperative.
One significant way we can help our projects and clients to succeed is to maintain a holistic view of the business, and consider not just the agility of the project, but also the agility of the organisation. If the organisation doesn’t have the desire, will or capabilities required to absorb or leverage the proposed change, then we should shout!
What is your take on ‘agile’ vs organisation agility? I’d love to hear from you, please leave a comment below.
If you’ve enjoyed this article don’t forget to subscribe.
This post was brought to you by IBM for Midsize Business and opinions are my own. To read more on this topic, visit IBM’s Midsize Insider. Dedicated to providing businesses with expertise, solutions and tools that are specific to small and midsized companies, the Midsize Business program provides businesses with the materials and knowledge they need to become engines of a smarter planet.
