• rm@rmbastien.com

Agile™, Agility, and Adaptability

Agile™, Agility, and Adaptability

There are acclaimed trends surrounding corporate IT that may lead you to believe that fundamental issues that you’re discovering in your journey are about to be solved.  Caution is advised.

Iterating to Avoid Major Failures

The most illustrious trend is, without any doubt, Agile™ methods. They are the result of decades of deep thinking about the effectiveness of large software development projects. Many IT projects were canned after lots of time and money spent, leaving the promoter with nothing but a sour taste in the mouth and huge write-offs.  The Agile™ approach effectively mitigates the risks associated with unknowns of all sorts, including ill-defined requirements. The methods reduce the risks of major failures where too much time is spent before realizing that the team is not going in the right direction.  The idea is powerful, yet simple. Do a small step, stop, and assess rightness. Change direction if required. Then continue with the next small step or stop everything right there if needed.

Who or What Is More Agile

The word agile can get misleading.  Now that you understand what the approach is about, you can better recognize where the agility in Agile™ resides.   Rapidly iterating through the steps of designing and building a product or one of its parts can serve to react to signs of inefficiency and allow for changing the process.  Hence, the team can be quicker to react to changes in its own process, as well as being able to readily adjust the scope and nature of what is delivered.  That’s what makes the team more agile.

Now, before getting ahead of ourselves, we should be clear about what Agile™ really serves and how it impacts:

  • IT speed
  • IT quality
  • business agility

By using Agile™ are your IT teams doing things faster, are they delivering higher quality outputs, and is that making your whole organization more agile?

Speed, What Speed?

If anyone tries to talk you into believing that Agile™ approaches make your corporate IT work faster, give him/her your most skeptical look.  In iterative development, you iterate faster by making each step shorter.  A team of a certain size using an Agile™ method does not deliver the same quantity of usable output in 2-3 week iterations than another team of the same magnitude delivers every six months.  The beauty of Agile™ resides in its ability to change directions more often, hence providing a more adequate end product.   What goes faster is the cadence, not the speed of delivery.    No-one can assume that augmenting the cadence will augment the speed of delivery unless the team continues to deliver the same quantity of results in shorter iterations, which is absolutely not the case.

Agile™ does not make your corporate IT run faster: it makes it work smarter.  Adequacy of the result is the key, not the speed of execution. 

Is your IT function a speedy hare running in all directions, or a tortoise aiming straight toward where the goals are?  What if your IT function is in fact a tortoise running in circles?   Wouldn’t you want your corporate IT to become a focussed hare running on the right path?  No one can answer any of these questions because IT speed is not measured

What About Quality?

Using an Agile™ approach, at the end of each iteration, all that is necessary to guarantee the ultimate objective —something that works— will be done. Extensive performance testing will be performed, and special attention will be provided by all team members in each part of the solution, to ensure that nothing impedes the attainment of the objective. Agile™ adds another layer of confidence because of shorter cycles that enable you to test more often. That’s fine for quality that impacts performance measures.

But unfortunately, entire walls of quality are currently neglected by your IT function. Such laxity is rooted in the nature of the engagement model and how success is appraised. I doubt very much that your Agile™ teams have other measures of performance than the usual ones. That’s why you will not get quality characteristics that are crucial for your business such as resilience, adaptability, or speed. 

Agile™ is a method for the delivery of “something”.  That something can be anything you chose or want, including its quality. 

Agile™ in itself does not guarantee any improvement in the quality of the solution you’re getting.  Making small steps, stopping and assessing, and changing direction before the next step, is an insurance policy against erring in the wrong direction.  If the “direction” with respect to quality is not embedded in the team’s objective, then there is nothing Agile™ has to offer.  A team using an iterative method could be delivering lower-quality products every second week. At the end of the year, the whole adventure could be declared a successful endeavor because no-one ever controlled important under-the-hood quality items.

And Business Agility?

The Agile™ approach came to revolutionize —for better undoubtedly— the way complex problems are approached and how endeavors to solve them are conducted.  It is broken down into methods and processes that outline how people should work together to attain a goal.    These methods help people be more efficient in the process of designing and constructing the desired output.  Agile™ was never intended to prescribe what the goal is —it could be anything.

Will Agile™ methods make your enterprise more agile? To answer the question one must ask the real question: What is the desired output of the teams that use such methods? If the clearly stated product were something like “a new organizational model that makes us truly agile” then yes, maybe. But it’s never the case. Teams that tackle business issues or that create IT solutions using Agile™ concepts are working on much more tactical, technical, or focused objectives. They are working on a new product. They’re revamping the customer experience in some area. They’re digitizing a process. They’re reducing wait times in production lines. No-one is using Agile™ methods to make an organization more agile. The closest it gets to this is that someone in the organization is hoping that such and such endeavor will help business agility. Just hoping.

Agile™ was never intended to make an enterprise more agile, and having dozens or hundreds of small teams agilely delivering their small part gives no guarantee that your organization will react quickly.

Does Agility Make You More Adaptable?

The Agile™ practice implements methods, processes, and tools that enable constant awareness of the relevance of the work being done, rapid decision-making, and safe spaces to change direction.  Aiming for business agility is not the same as aiming for adaptability.  The former implies that the enterprise’s “senses” are focussed on detecting changes in customer wants and needs, that decision making processes are aligned with the frequency of these changes, and that the organization can follow that pace. 

Adaptability entails the capacity of your enterprise to transform in the face of changing conditions in the environment.  It means that the organization can re-invent itself.

Adaptability is not based on luck.  It is a direct consequence of consciously designing for it.   If something changes in the environment, a new version of the enterprise must be carried out, and if much re-engineering effort is required because of the magnitude of the changes, the enterprise is not adaptable. 

To achieve adaptability, designers must challenge the current state of several aspects of the organization and fathom the probability of these features to change, to disappear, or to become obsolete.  Any element of the architected enterprise is coupled with a hypothesis about its permanence.  Elements that are deemed subject to change are designed as if they were effectively going to change, disappear or become obsolete.  When internal or external conditions shift, the amount of work required will be greatly reduced, because it was purposely designed to sustain that transition.  Given the dynamics of social, environmental, political, and competitive environments of the 21st century, I’m convinced that you need the capacity to transmute with as little effort as possible.

Do not, however, make the leap in thinking that agility will make you adaptable.  There is a tangible risk that your agility may get you running in too many directions, burning too much gas at each turn.

Adaptability is measured with the level of effort required to adapt to a new situation.

While agility is about changing directions quickly. Agility and adaptability are both required, but they’re not the same.


Follow me: