Business Agility is a people-centred, organisation-wide capability that enables a business to deliver value to a world characterised by ever-increasing volatility, uncertainty, complexity, and ambiguity. The business of training, coaching and facilitating agile has never been better, although finding actual statistics is difficult. Most of the big vendors are keeping their cards very close to their chest. However, when one does a Google search for agile training or certification, the picture becomes a little clearer. The business of agile has become big business.

Who cares right? Capitalism is alive and well, and there is nothing wrong with that so why take the time to write this article. To answer that question we need to go back to the beginning of how the agile movement started and what the intention was in starting it. I am sure many of you reading this are already aware of the history, but for completeness sake, I will summarise.

Iterative development has been around since the 50’s, but it was only in 2001 when the Agile Manifesto was produced that the philosophy gained real popularity. The focus of that particular document was agile software development. The distinction is significant to note.

The Framework for Business Agility

Fast forward to where we find ourselves now. To try and make sense of agility for the business world we have various structured or scaled frameworks. The main issue that is very apparent is adopting a framework while simultaneously trying to maintain the same bloated and inefficient corporate structure. The Framework for Business Agility has been created to help organisations survive and thrive in a volatile, uncertain, complex and ambiguous environment. It makes no sense, and by merely changing job titles while supporting the same key performance area bonus structures are going to have little to no effect.

Now, this is where the rubber meets the road. Thrown in this maelstrom of inefficiency and bloated architecture are development teams. Development teams that are trying desperately to adhere to the agile manifesto and build working, deployable software in short iterations of work. Development teams that are working in corporate entities like fish trying to survive on dry land, their creativity and ability curtailed by phrases like “Innovation”, “Agility”, “Return on Investment” and so on. If only those words were used with their intended purpose. In reality, here is what they mean:

• Innovation: “We want you to come up with the specs because we simply don’t get what you do.”
• Agility: “We would like to change our minds about what we want weekly maybe even more often than that and then ridicule you for non-delivery.”
• Return on Investment: “IT is expensive so just do what we tell you. We pay your salary after all.”

You may accuse me of being a bit tongue in cheek but remember many a true word is said in jest. So where does this dichotomy come from? How is it that the business of agility and agility are such worlds apart? Sorry to disappoint you but I don’t have any definitive or scientific answers. However, I will not let a lack of facts stand in my way (I could be a journalist) and will give you my best assessment.

Corporate agility is a myth

The easiest way for me to explain this one is with a word picture. Imagine a large battleship like an aircraft carrier. Now imagine that massive lump of metal the size of a small city trying to do a 180-degree turn to catch a passing speedboat. Did that break your brain? You are not alone.

You see most vendors of agile training and coaching will try and sell agility just like that. The truth is that speedboat that just roared by is a start-up and by the time that aircraft carrier sized corporate has changed direction; it is too late, the game is already over.

The big problem is that selling agility in a way that makes the large corporate believe they can be competitive while remaining as they are is not only complete fantasy it puts unrealistic expectations on the delivery teams. Delivery may increase in the short term as more pressure is applied because we are “Agile” but sadly it is not sustainable. In a few short months or a year, we will hear of another “agile failure”. Developers resigning in droves and a head or two rolling (never the right ones) and back to the way we used to do it.

Sound familiar?

"We use our own version of Agile"

Oh, I love this one. My follow up question is usually, “So what process of continuous improvement and testing did you use to get to your bespoke version?” The blank stare or the waffled nonsensical answer tells its own story.

I am all for adapting agility frameworks to suit your unique blend of staff, industry and secret sauce. However, this should be after time has been spent using bland, tedious, standard frameworks over many iterations and using the retrospective feedback to build something unique. Most skip over this step, implement their own thing which is a sad love child between “agile” and the unholy waterfall or other methods. When this invariably fails spectacularly, then we get the usual “agile” didn’t work for us.

And the poor developers in this sad, sad downward spiral? They are the ones putting in ridiculous hours, rewriting features at the last minute while the testers solemnly try and test “something” hoping the 5-minute window right at the end of the 12-month project will be enough to “go live”.

And the answer is

If you think your 3-month project to firm up your architecture (which you did in sprints just because) makes you agile well then I am completely shocked you made it this far in the article. Agility is pretty simple, and some large, very profitable companies have cracked it.

So what is the formula? Okay, I am about to drop some serious wisdom on you. I have a tear in my eye just thinking about it.

Hire smart people and then let them be smart. Yes, that’s it. Sounds overly simplistic, doesn’t it? It may seem simple but don’t let the simplicity of that statement fool you. You see smart in software development may not be the same as smart in product development or product ownership or accounting or HR. You see you need to find the right smart people and then LET them do what they need to do. You give them a problem statement and let them solve it. They may get it wrong the first time. That’s okay because as they fail, they learn from it and improve. They will keep doing it day after day and week after week, and before you know it, you will be in a place where people want to work. You will hear your company name in the news with words like innovation, market leaders and bold. The real definition mind you, not the business bingo definition.

Shameless Plug

So many of you may be asking how do we start or we need help. I am so glad you asked! You see DVT is a place where smart people hang out and make awesome happen. We have smart people that understand how to implement agile, not just frameworks but actual change your thinking type stuff. We have coaches that can help you develop your teams and identify their strengths and how to communicate with each other. We have architects and developers that live and breathe continuous improvement. Testing that is so next level there isn’t a level (it’s under construction).

So if you can identify with anything in this article, don’t remain in the status quo. Reach out to us and take a step in developing your organisational and personal potential.

Editor's Note: This post was originally published on 2 October 2018, and was updated on 5 December 2023