Beginning in the software or product domain, there is a belief by some that a software team or organisation can attain 100% agility and become x% agile by a given date. In the raw form of the Agile Manifesto, where the authors sought to redress the balance that had shifted far more towards process, contract and tools and less toward people working collaboratively to deliver value, it is inappropriate to apply a measure. Even in adoption of frameworks such as Scrum, it might be possible to check off the events, roles and artefacts as an initial measure but if the people engaged are still delivering the wrong product then there is no benefit to anyone. Merely replicating practices from the software domain will not achieve the desired business agility.
The question we ask of our clients, therefore, is “what does business agility mean to your business and why would you want to achieve it?” This is a surprisingly challenging question, which some people try to dismiss at first but then put in terms of, “if you don’t know why you want it then you won’t know if you get it and you will waste your investment”, it is difficult to shy away from it. These are some of the words and phrases people come up with:
What should business agility mean to my business (outcomes)?
- Competitive advantage
- Responsive to change
- Delivering greater value
- Getting more from our investment
- Faster to market
How do you know you have it (attributes)?
- We have greater visibility of what we are doing
- There is transparency and honesty about what we are doing
- We can get feedback quickly from customers
- Teams of people feel empowered to make the best decisions to improve the way they do things
- If we are going to fail at something, we fail fast and benefit from the feedback
- There is a constant desire to improve the integrity of what we do
We developed our Business Agility training course to address these outcomes and objectives. We wanted something that was founded upon successful agile adoption but that was accessible by non-technical people.
The first iteration of the course was used with a group of technical consultants in a company where they had apparently adopted Scrum in development. What we discovered was a group of ‘middlemen’ who no-longer understood their role in the company and had little respect for their management or each other. It uncovered the issue but their management failed to take on-board the feedback.
The second iteration for the Business Agility course was with a client who we had helped to truly adopt agile and the senior team said they wanted some of it. The training course helped them to see how they can transform their global operations.
The third iteration was with a relatively new company who just knew they wanted to be different in their chosen market, some of the senior team had seen agile practice in place elsewhere and wanted something similar. An exercise to identify what business agility meant to them, how they would know they have got it and specific actions they needed to take. This was a robust, challenging and very rewarding exercise, which now forms the solid core of the Business Agility training course.
Points of learning:
- Merely copying agile practices from software development and expecting them to be adopted in business will not effect change
- Using evidence from software and other business domains can be helpful to people to understand why achieving business agility is a necessity
- Be clear about what the outcomes will be from the investment it will take to effect change
- Have some clear measures for success
- Take action
