originally by Michael Mahlberg on agile-aspects
Bringing Agile to non-IT work… those who don’t remember history are doomed to repeat it
People tend forget that many of the agile approaches borrowed heavily from the Toyota Production System and its relatives, commonly known under the umbrella term "Lean."
These days we're experiencing an interesting development. People try to bring things they perceive as "typical agile practices" to non-IT work. For knowledge workers —a term coined by Peter Drucker in the 1960s— this might perhaps be a valid approach. Even though I doubt it. For non-knowledge-worker work on the other hand, I would like to point out what happened here. Approaches taken from the Lean context of shop-floor management and vehicle design, related to continuous improvement and optimizing the flow of work, were translated into a very different environment — that of software development. And even the considerable body of knowledge from other fields of expertise that is at the foundation of agile was put into a very specific context here. Actually, the so-called "agile manifesto" is called "Manifesto for Agile Software Development" and thus very specific with regards to the domain it targeted. So nowadays, when people try to "apply Agile to non-IT situations", they basically take the adaptations that have been made to non-IT approaches to make them helpful in Software Development and try to re-apply what's left of them back to non-IT work. Of course the original non-IT approaches have also evolved since the days that –just to pick an example– Ken Schwaber and Jeff Sutherland read 1986 paper "The new new product development game" (sic!), and took parts of those ideas as a foundation of their own agile approach (Scrum). Hence it seems kind of silly to me to derive ideas for modern ways to organize non-IT work from the spin-offs from more than two decades ago instead of going directly to the source.
Of course sometimes re-applying the stuff we learned from agile software development actually works, but I think going directly to the source is a much better idea. Perhaps instead of trying to derive the helpful approaches non-knowledge-worker work from the shadows they cast unto the walls of the Agile world –to paraphrase Plato– it might be a good idea to look at the origins and try to understand the original approaches to non-knowledge-worker work. Of course, oftentimes non-knowledge-worker work was simply called "work", back in the day. Directly adopting from approaches like Lean (from the 1950s) or New Work (which originated in the 1970s) might be an approach to improving work that avoids the 'Chinese-whispers' effect of the indirect approach via "Agile."
To end on a more positive note: the Kanban method is a great example of an approach that targets the challenges of the (non-it) knowledge worker and brings ideas from Lean and similar fields into a new context. And even though many people use the Kanban method in the realm of IT, it has many equally –if not more– effective applications outside of IT. Maybe that's because the Kanban method avoids the triangulation via the older agile approaches and builds directly upon the common ancestors. I guess that is one of the reasons why David Anderson called the Kanban method "post-agile" even back in 2010.
till next time