Business agility, it's all in the mind

Agility is one of the great buzzwords of the day so I paused for thought when I saw this tweet from @flowchainsensei (aka Bob Marshall)  ”What is *Business Agility*? It’s ability to respond to changes in your business environment: markets, competitors, regulators, tech, etc.

Picture credit: chris5aw

Picture credit: chris5aw

Well that doesn’t sound like agility to me. Bob’s definition reads more like a description of responsiveness, which is simply a complement to agility – not the thing itself.

So what is agility then?

I prefer to define agility as: facility of mind-set. So I tweeted my definition, which elicited a clarification from Bob: The term “Business Agility” has begun to assume a specific (limited?) meaning in the Agile, Lean community context.

Which kind of illustrates an interesting paradox – the Agile community is narrowing the definition of agility, in the direction of responsiveness.

My own view of business agility takes a different perspective:

Business Agility is in the mind of the individual [or organization] and comprises an absolute willingness to constantly monitor and refine one’s position, in a timely and appropriate manner – not just the ability to respond quickly.

You may also like to read:

  • Pingback: Tweets that mention Business agility, it’s all in the mind | Fighting the Trillion Dollar Bonfire -- Topsy.com

  • http://twitter.com/flowchainsensei Bob Marshall

    Given the term “Business Agility” is primarily about Marketing (imo), and about appealing to senior Execs in particular, it seems less important what the actual definition is, and more important to ask: Does the (undefined) phrase “Business Agility” sound to an Exec like something they might want? Once we cross that particular Rubicon, surely it’s prudent to define the term (if asked) in terms that don’t raise objections to the “sale”?

  • tuomoks

    Thanks Bob, my idea of “agile” also. Today it’s a marketing term, agile business, agile development, agile whatever has existed forever. And you are correct, the definition really has moved only to execution, unfortunately. Agile in itself is great – used to be called flexibility, adaptability, etc, now it often means glossy brochures, endless meetings, sales speeches full of buzzwords. Business agility has always been part of successful business but should not be taken as a framework or whatever.

    About “senior executives”, maybe I know wrong types / persons but they don’t really care of buzzwords, marketing, etc – they just don’t have time for that, they have a work to do. So “Business Agility” has to be geared to middle to lower management? A great way to sell something, seen that a little too often.

  • http://www.kanbanblog.com David P

    I’m not totally convinced about agility being in the mind. Surely, at the end of the day, it’s all about action not thoughts?

    • http://www.colin-beveridge.com Colin Beveridge

      but David, action without thought is dangerous :-)

  • Terence Freedman

    I see agile as a response to the slow delivery of monolithic systems no longer meeting the requirements of an organisation living in a dynamic (agile?) world. This is the appeal to the executives.

    At a low level, as in Xtrememn programming, this is feasible. It is even easier to effect as the documentation support is now low: the code is its own documentation. But does code describe the purpose of the program? But I digress.

    At higher levels there are issues of structure, integrated and meaningful models, scope creep, data quality, the cost of documenting changing systems and, at a premium these days, security.

    A degree of flexibility needs to be built into design to cope with market and legislative changes.

    The higher level concerns are not a reason to abandon agile approaches but should be considered when trading off the market advantages of agile against the extra costs of its implementation and use.

  • http://blog.davidpeterson.co.uk David P

    In answer to Terence’s side question (“Does code describe the purpose of the program?”) in eXtreme Programming it is automated tests that describe the purpose of the program. The tests are written at varying levels of abstraction – from unit to system. System level acceptance tests do indeed describe the “what?” and “why?”. Take a look at “Concordion” ( http://www.concordion.org/ ) for an example of an acceptance testing framework that does just this.

    The key difference between agile methods and traditional methods is the size of the batch. Done right, smaller batch sizes let you get feedback more quickly (so you can adjust before you go too far down the wrong track) and start generating a return more quickly. There is obviously a trade-off in certain environments the overhead of releasing makes it much harder to use small batch size. But in many, many environments (especially ‘internal use only’ applications) it can work a treat.

  • http://blog.irenestauffer.com/ tuomoks

    Great answers but the question was “business agility”? IT is not all, often not even the main part of the business, it’s a support function for business. Yes, the buzzword agile was made famous in IT but agile means much more that just process, execution, etc. It means (IMHO) that you can adapt, not be bound to some fixed track, can change middle of the process, and so on. For business, some do, some don’t.

    Agile business might have saved us and many companies / corporations / enterprises from current economical problems. Bad or good – new flexible (agile) businesses are taking over, who adapts (can change the old or maybe not old but just going “wrong way”) fast enough will survive and prosper.

    In my mind, IT has a little poisoned the meaning of agile – it has come a mantra, a new strict and rigorous process just to replace whatever was the previous buzzword. Works great for management who wants to protect their turf but in reality, what has changed? Do you still have meetings when there are no real issues to talk, do you have a plan or just go day by day, do you still fill the hourly worksheets, etc – a long way to go until we have an “agile” process.

    Agile (as some see it) is not for every business function, of course. A service has to be there when promised, etc – it is a mindset that maybe next time we can do better, be agile!