Agility Alert!

The idea: “Agility” is being marketed as a catch all remedy to a variety of business challenges. Agile processes got their start in a well-defined space, proposing well-defined business processes.  Businesses looking for solutions may exacerbate problems by inappropriately jumping on the “agile” bandwagon without first addressing basic process issues.

If you’re an avid management and business media consumer you may have noticed the words “agility” and “agile” are demonstrating agility. “Agile” and its progeny “agility” are popping up in all sorts of unexpected associations beyond tech development. Strategic agility, HR agility, marketing agility, service provider agility, agile HR, agile supply chains, and the list goes on in seeming endless iterations.

Having read numerous articles in which “agile” or “agility” is proposed as an approach for non-IT scenarios, an important question surfaces: If you understand the history of agile development (a big assumption) then does a firm’s current business reality indicate an agile approach might be a solution? Without considering this question, the unspoken conclusion of those proposing “agile” seems to be: “if you haven’t tried ‘agile’ yet you’re missing the boat.”

A little history to aid in understanding the current agility conundrum. “Agile” as a work construct was born back in 2001 when a group of influential IT developers wrote “The Agile Manifesto.”[1]. For tech work, with its inherent development complications, agile approaches represented a break through idea. Huge projects are broken down into mini projects. Personal and frequent project team communications are valued over excessive technical documentation and rapid prototyping is done to facilitate in-process feedback from end users. All good. What IT agile didn’t do was eliminate project management and documentation; it simply adapted the methods of project management to a new and well defined, agile approach. Projects still had defined outcomes, albeit now open to modification through the in-process feedback mechanism. The conundrum arises when agile techniques are substituted for sound business fundamentals in non-IT functions. Agile is a great process for IT development efforts and is possibly extendable to other project-oriented endeavors; it’s not a one size fits all solution to any business challenge.

Generically speaking, agility isn’t a solution, it’s a reaction to dysfunction in one’s business environment. If the dysfunction originates outside the firm, Michael Porter’s 5 forces analysis seems like a much better place to start investigating before proposing “agility” as a solution. A rigorous 5 forces analysis is hard work and requires time and resources for successful completion. If the dysfunction is internal, for instance, your performance management system does nothing to change performance, then training managers to how to effectively do the hard work of managing performance seems like the place to start. Implementing an “agile” performance management system may simply yield the current unsatisfactory results faster or create new dysfunction.

Much of what is written about agility stems from a desire to better react to changing business circumstances. That begs another question – do changes in circumstances require a change in the execution of a strategy? Firms with poorly developed strategies generally suffer higher levels of reactive behavior, so agility in reaction is appealing. Firms with well-developed, well-articulated and well communicated strategies don’t react, they execute. When circumstances change, firms with sound strategic management tend not to be reactive; they respond and execute consistent with the defined strategy. Some of the proposed applications of agility remind me of nothing more than watching little kids play soccer. Wherever the ball goes, the kids quickly follow. Teams drilled in the fundamentals spread the field and execute plays, albeit in the constantly changing set of competitive circumstances.

What business reality would make an agile response necessary? First, you need to understand what must change. Is process efficiency the problem? Recalling its IT origins, agile might be the solution to process inefficiency. Again, understanding the source of the dysfunction is the first order of business. Perhaps your managers, associates and staff lack working knowledge to execute the work under consideration, they consequently perform the work poorly and then declare the process inefficient. Let’s assume, for the purposes of discussion, that agile concepts have maximum utility when applied to a well-defined process which isn’t working well.

One article on Agile HR[2] references General Electric (GE) as moving from top down financial controls to FastWorks, a lean approach. It might help to review GE’s financial performance in the years since de-emphasizing the management controls approach to emphasizing empowered teams managing evolving projects. GE’s financials over this time horizon are revealing. The desire for agility arises when results are not realized quickly enough (a subjective standard to be sure). Another article[3] references adaptive strategy (aka agile strategy) as a cop out employed to mask deeper structural problems. To quote Thomas Kettering – “A problem well defined is a problem half solved.” Better to train people on root cause analysis and problem definition/resolution than layer on another process like agile.

As it’s generally helpful to get different perspectives, I went to an expert on the subject of agility. This person trained multiple generations in the acquisition and application of agility skills. The agility expert coached football for decades (American football for those of you outside of the US and Canada) and I had the privilege of playing on one of his high school teams. As bonus qualifications, he is published author, consultant, a very well regarded (and lifelong) educator whose doctoral dissertation was “An ethnographic study of change.” These seem like pretty solid qualifications to discuss fundamentals vs. agility so I posed the question: what’s more important to execution, fundamentals or agility? And, I kid you not, he borrowed my pen, quickly drew a couple of offensive and defensive formations, mapped a play flow in dotted lines and patiently explained how agility can only be applied in team sports after a fundamentals-based system is in place. The usefulness of agility is dramatically improved after first establishing the system in which fundamentals live. Businesses (should) have a lot in common with team sports. After this discussion, I had the distinct sensation of watching old game film highlighting that critical missed third down block. If one is considering “going agile” take time to assess how well your team is drilled on process fundamentals and if the system in which those processes live is functioning effectively.

Greg Kaiser Sr.  is a management advisor and would enjoy discussing or debating the above ideas as they relate to your business.

[1] http://agilemanifesto.org/

[2] https://hbr.org/2018/03/the-new-rules-of-talent-management?autocomplete=true

[3] https://hbr.org/2014/05/adaptive-strategy-is-a-cop-out?autocomplete=true