The Agile Industrial Complex

Agile as a way of working and organizing team activities has spread from software development to other aspects of work and business, from sales management to project management and most points in between, including learning and development (L&D). From my perspective, it’s gotten well out of hand.

In software development, agile demonstrates its worth by delivering robust software with a sharper focus on customer/end-user needs. Requirements, features, and solutions evolve over the life of the project through collaborative efforts among self-motivated cross-functional teams and their customers. Generally, these teams iterate and respond to customer feedback until one of two things happen: they run out of time, or they run out of money. The end result is software that’s more intelligent, sensitive, and responsive to customer desires than would otherwise be possible.

A victim of its success, agile is an industry at this point — specialized conferences, consulting firms, workshops, tools — the whole shebang. Those of us not in software development are experiencing an abject agile disaster because most teams don’t have the same rules, players, and goals as a software development team. Trying to execute agile without these in place may be (in my opinion) partially to blame for catastrophic levels of employee disengagement. Don’t believe me? Please, keep reading!


A critical, but left for dead, principle from the Agile Manifesto is “self-organizing teams with motivated individuals.” Here’s an agile Catch-22, and a rabbit hole that could take this blog to several thousand words. The moment agile is imposed on people who don’t want to work this way, we have lost one of the key success factors. Agile is a work process that works best by invitation, not by imposition.


Here’s the deal — there are many employees focused on things other than software development who don’t want to follow an agile process. Some employees are happier and more engaged when using a linear, objective-oriented, and gated approach to their work. I’ve been out in the world, and I can confirm the rumors that these people still exist.


I’m all for iterating and improving, but there’s a fine line between nimble and chaotic. Non-software groups tend to adopt agile by working on smaller pieces/prototypes and iterating until approval or deadline. This adaptation can work in L&D projects, but an end must still be defined, and we usually aren’t in a position to add features and iterate until we run out of time or money. More typically, our projects have shorter timelines and smaller budgets, at least in comparison to a big software release or website design project.

Realistically, any group of professionals can identify and execute improvements on a subsequent iteration of whatever the “thing” is — including L&D professionals. That said, who determines when something is done, and if an incremental improvement is worth the resource strain required to realize it? At some point, “good enough” has to be the answer, and whatever the “thing” is goes to the end customer or user.

As with anything that gets over-hyped and mainstreamed, the proliferation of the notion and approach of agile hasn’t focused enough on the nuance and the inner workings that ensure its success. If an L&D team truly wants to adopt agile as a way of working, then steps must be taken to embed an agile approach into the culture, team resources (tools and people), and goals.

This certainly is easier said than done. Agile is not ubiquitous, despite the buzz you may have heard, and it works best by inviting and aligning the efforts of self-organized and motivated people.

4 Responses

  1. Susan Fisher

    Great post, Mike! I think that we, as outside consultants, have additional obstacles in following an agile approach… First, our internal team members are working on multiple, different projects and can’t always align schedules to collaborate in real time on a given project. Second, we have little control over the schedules of our external client SMEs and other stakeholders. Third, as you said: tight timelines and budgets! In combination with the first two obstacles, they tend to stymie iteration and collaboration.
    That all being said, I think we should still aim to incorporate at least some aspects of an agile approach whenever we can, mainly to make our learning solutions as closely aligned to learner needs as possible. To do so, we should always look for ways to streamline our design-development process when we start each and every project. ADDIE should be a flexible guide, not a rigid procedure.

    • Mike Blahnik

      Thank you, for the comment Susan. You’re quite the confederate! In future posts, I hope/intend to look at the impact of Agile on different types of teams, projects, etc. In spirit, I agree that aiming to inject elements of Agile can improve project outcomes and positively impact the people teaming on the project.
      P.S. I *love* your last point, RE: rigidity in execution of ADDIE.

  2. Gerret Peters

    Good points, Mike, and I’d like to point out a thread that I think runs under the surface of your observations. Agile developed as a way to manage software projects, where the cost of making changes to code is incrementally very low, and fast cycle times between code/test/alter enable more rapid progression.

    However, the many disciplines that *surround* that development effort have deliverables that carry sometimes significantly higher incremental costs to change. Print marketing is an example of this, as is the development of quality learning programs. When it comes to simple software, strong design will contextualize how to use the software; put another way, when was the last time you read the manual for a Facebook app update on your phone?

    There are certainly opportunities to improve the speed of iteration in nearly all disciplines, but not all. An agile approach to neurosurgery seems dangerous, for example. Apologies to the neurosurgeons in the audience. Sometimes the right solution is thoughtful, deliberate, and get-it-right-the-first-time, because the incremental cost of change is too high. In those cases, the agile software team might best be supported by surrounding teams who are flexible, but not necessarily agile.

    • Mike Blahnik

      Thank you, Gerret. Your point is an important one – in situations where agility is feasible (cost effective, quick, safe, etc.) Agile fits like a glove. As you pointed out, that’s not all situations. In the case of L&D, related teams/support services must be flexible, collaborative, and understanding even if not working Agile themselves. This requires some level of visibility/understanding or what starts as flexibility may begin to feel chaotic or wasteful. Ideally we have some foresight into the feasibility to build the “final” training at certain timing, and can focus on minimum viable products that support the project until the point in time that a product/project is mature enough to build out final training solutions.

Leave a Reply

Your email address will not be published. Required fields are marked *