Today “agile” is table stakes for software developers. For the majority, the result of “agility” is a copy and pasted account of agile’s value promoted by marketers. Few “agilistas” take the time to dig into agile beyond the agile manifesto, and fewer still embrace the agile values established by the manifesto. Lack of insight into the roots and source materials means many claim agility, or a variant practice like scrum, kanban, XP, without understanding “the why.” Lack of understanding of the root “why” leads to poor execution.
Misconception: Agile encourages teams to “innovate”, which means teams are free to “change the process”.
Defining Innovation
The critical definition at stake is “innovation.” In The Toyota Way, innovation is more closely defined as interpretation within the standard (like jazz). The current Western definition of innovation is “disruption” or “transformation.” The influential Lean Startup defines innovation as a hypothesis, iterate, and test or, in summary, “fail fast.” While this is consistent with lean principles, this oversimplification is often adopted as “if this is not working for me, let’s change it.”
Source materials indicate that scrum intends to provide the team room to solve problems within the framework and increase individual accountability. The expectation that any team member “stop the production line” (pull Andon Cord) when a problem is identified comes directly from The Toyota Production System. What most miss is insight from The Toyota Way. All team members and, in particular, leaders must master the process before “failing fast.”
In seeking the distinction ask the practical “when should one innovate?”
The Toyota Way calls for “kata” or practice, repetition, and eventually mastery. For The Toyota Way, this is commonly seven years of practice and much closer to the 10,000 hours Malcolm Gladwell describes as required practice for mastery. Only after mastery is achieved in repetition and practice should team leaders begin to riff on the standard.
Teams should not wait seven years to pull the ripcord when a process is breaking down, but they should evaluate their relative level of mastery against the scope of the change they are seeking. Teams are entitled and accountable for calling out when the process goes off the rails, but they should not be making changes to rails before they’ve sought mastery.
Teams that “innovate” themselves out of the framework and values of scrum because they lack the knowledge to identify the root causes quickly lose the ability to refer back to agile values and its corpus of knowledge. Bushwacking into a new process and out of scrum means teams will find themselves unique and alone. Figuring things out as though it were the first time when there’s a clear path to greater agile fluency equates to adding complexity and not innovation.
