With the current issue, a software development method has officially reached the pinnacle of executive influence by capturing a lead article in the Harvard Business Review recommending Agile methods for business transformation.  Talk about software eating the world!  (https://hbr.org/2016/05/)


Software development definitely has much to teach business executives, and not just because software pervades daily experience.  Because software only operates on data, software developers must represent all business processes as data abstractions.  Seeing the world as data abstractions gives software people a perspective on business processes that is uninhibited by physical experience:  What if the car had no driver?  What if the customer service representative was a chatbot?  Virtual reality is perhaps the logical conclusion of the software way of thinking about the world.  So why not business transformation too?

Certain tools originally developed purely for software development are now crossing over into general business use as work processes become more and more about manipulating data:  For example, Slack and its competitors were originally designed to facilitate software team collaboration, but they are now seeing wide adoption across all business functions.

A more sober assessment of Agile for transformation is needed.

But over-hyping the applicability of Agile methods, which is only useful for some types of software, has its risks — especially when hyped by true believers.  The authors do publish a reasonable “don’t use Agile if xxx” list, but a more balanced assessment of the pros and cons of agile for general business awaits.  A few bullet points of my own:

  • Agile is not a cost optimized methodology.
  • Works poorly with fixed schedules.
  • Fast moving Agile projects get stuck easily when dependent on slower moving business processes (or slower moving Agile projects, for that matter.)
  • Encourages a lack of up-front research in favor of rapid learning, which may enhance innovation … or enhance risk, depending on the circumstances.
  • By discouraging documentation, can limit learning to just a few people and inhibit organizational scaling.  After all, writing things down is still the principal way we learn or train a wider audience.
  • Every company practices Agile differently, because Agile is a set of best practices, not a prescriptive methodology.
  • There is no well-established methodology for large programs consisting of many teams.

It will be interesting to see how the consulting world adapts Agile methods to a domain it wasn’t intended for.  After all, who would want to admit they are not agile?