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.