Consider this a parable of sorts for those building products. I’ll leave it up to the reader to determine its meaning.
Carl is a senior in high school and has a D in Algebra II heading into the last semester. He wants to bring his grade up to a B so that he can qualify for college scholarships. Quizzes and tests make up 80% of a student’s grade. The other 20% consists of completing homework (15%) and classroom work (5%). Carl’s Algebra II teacher, Mr. Smith, insists that Carl catch up on all his missing classroom work first, even though most of that work will not help on upcoming quizzes and tests. Mr. Smith works with his student to create a rather large yet well-defined backlog of all the classroom work Carl needs to catch up on so they can track his progress together. Carl diligently works on burning down that backlog. He finally catches up on the classroom work near the end of the school year. Mr. Smith pats him on the back. Carl’s final Algebra II grade is a D+.
Agile and Lean are old news. Everyone uses and abuses the lexicons. Have a short daily meeting? Call it a daily Scrum. Trying to deliver something in a relatively short period of time? Call it a Sprint or iteration. Have a board with post-it notes in swim lanes? Kanban at your service. Writing some tests? Call it TDD. Attempt to improve a process? Continuous improvement! Use a CI server to run a job here or there? Tell the world you’re doing continuous integration. Code on production? Continuous deployment! Meanwhile, people who list experience with Agile and Lean on their resumes more often than not talk about how painful and all around chaotic it all was. The underlying reason for this bad aftertaste is most often due to the adoption of practices without an understanding of the principles behind them.
The temptation is to read an article, watch a short video, attend a conference session and latch onto a particular Agile or Lean practice without the fuller context. This is especially popular in tech where many (most?) of us have a natural tendency to chase after shiny new objects. Instead of a collection of tools that serve their purpose within a greater context, we latch onto the hammer and start pounding everything in sight. A team struggling on a project decides to try a daily standup because they like that part of Scrum. They don’t realize the nuances behind a daily Scrum. They don’t grasp the commitment demanded by Scrum as a whole, and how the daily Scrum helps enforce that commitment. A standup is easy; building teams dedicated to consistently delivering something tangible in a short period of time is not. Every ceremony within Scrum is there because the principles drive it. Adopt one ceremony out of context and the result is less than satisfying – far short of transformative. Ditto for Lean. The practices are easy to grasp and implement poorly without knowing the “why” behind them.
Wrestling with and forming an understanding of the principles behind Agile/Lean requires perseverance. There are no shortcuts. Trial and error is expected, but not without wrestling with the reason why we’re trying to implement a practice in the first place. Racing from one good idea to the next requires little discipline. Little is learned when a practice is implemented without a grasp of the underlying principles. The failed practice is tossed out and a new one takes its place, awaiting a similar fate. The only way out of this rat race is learning why a particular framework, practice, methodology is the way it is and then identifying and carefully evaluating the problems we’re trying to solve and how the two align (or don’t.) There are no shortcuts. No silver bullets. No buzzwords to save the day.
