Holistic Agile vs. Business Agility
As more organizations discover the benefits of applying Agile methods to areas outside of the walls of software development, they are looking for guidance on how and where Agile concepts can be easily translated for best success.
We are also seeing an evolution of processes and methodology going from Lean manufacturing to software development to day-to-day business activities. In doing so, there are two concepts that have been introduced into the market that hold some similar and yet some differing concepts.
One is called Business Agility. This concept takes the commonly referenced Agile manifesto, principles and practices from the software development world that have become so popular, and attempts to seamlessly translate those practices over into a business-centric environment. Additionally, there have been attempts to create a new manifesto and principles for very specific departmental silos such as HR and Finance.
The other concept is something called Holistic Agile.
Holistic Agile is a set of completely unique principles, apart from the previous software development-based concepts, that focuses on the application of core values that can translate across any organization regardless of work type or department. Holistic Agile doesn't promote any certain software development frameworks but instead encourages more of a mindset-based approach that allows you to cater any process you choose to your unique environment; even to the point of creating your own process.
The reason Holistic Agile was developed was based on feedback from business partners on whether or not they would be willing to apply software development-based concepts to their business problems. The overwhelming answer was no. While they liked the "agility" displayed by those groups, some of the foundational principles and processes aligned too far into the technology realm and they wanted something more globally applicable without having to translate what "working software as the primary measure of progress" means in non-IT terms.
While we tend to agree that a principled way of working generates agility better than pure process or framework adoption, business folks needed a way to have the flexibility to either adopt a known framework, tweak that framework as needed, or create a completely unique one that they could call their own without feeling like they were breaking some martial law of process adoption.
Here's the other concern inherent with "Business Agility". The term itself instantly creates the very label-based segregation within an organization that we've been trying to overcome. For decades, we had the "business" and then we had "IT". We were hoping that Agile methods would help bridge that gap and help blur the lines. I worked with one CIO who loved to say that his IT groups were just another part of the business and that their business was just another part of their technology. His goal was to tear down that 'us against them' wall. By labeling the concept "Business Agility", we simply build that wall back up and mentally create IT Agility and Business Agility.
We're almost back to where we started.
Why should you care?
For the same reason, people began to care about getting more agile with their technology practices. Displaying agility across the entire organization is where the future is headed and rapidly. It's no longer a matter of whether or not a company begins to apply Agile methods to how it works; it's a matter of when. Some say the only constant in life is change. A peer of mine likes to disagree with that concept and proposes that change isn't constant it's increasing in its pace. I have to agree. The rate of change we saw 20 years ago isn't nearly as rapid as what we see today. Imagine what will be asked of us 20 years from now. If becoming a more Agile company is not in the near future, those companies could get left behind very quickly.
That being said, you can either choose to stick with a manifesto and set of principles that haven't changed for a decade and a half and promote the improvement of only one segment of an organization, or you can choose to adopt an evolving set of principles that apply holistically throughout an organization.