I find it entertaining when people talk about how Agile and Lean and Kanban are all relatively new, untested, and revolutionary concepts. That’s because they’re none of those things — they’re simply descendants of ideas and concepts that have existed in manufacturing contexts for a half-century or more, just pitched in a different way, at a different time, to a different audience. What we talk about now is just an evolutionary adoption of principles of line production that were brought into being by W. E. Deming and his contemporaries at the end of World War II — the concepts of identifying and reducing waste, focusing on just-in-time stock-keeping, and narrowly focused on doing only the work needed to move a product to the next step of the line. Even the empowerment of individuals and teams owes a great bit of gratitude to the Toyota Production System and it’s focus on granting every line worker the power to stop the entire process if there was something wrong or something to improve upon. I think that it’s past time that we not only acknowledged this history but embraced it — and leveraged the long history of success in that domain over into our own work.
Reduce Unnecessary Work
Perhaps most important to the entire concept of lean manufacturing is the idea that we should remove all unnecessary work — if something doesn’t provide some kind of concrete, definable value to the process, it needs to be analyzed, understood, and likely removed from the equation. I hear a lot of Agile teams complaining about the “overhead” that comes along with all of the bookkeeping and meeting management that invariably accompanies an early-stage Scrum adoption. And I encourage these people to take a very close look at what they’re actually doing — and if it’s not bringing value, chop it off. Nobody is going to Hell if your team does standups three times a week instead of every day — so long as you’ve tried the “textbook” way and it hasn’t worked. Similarly with requirements documents, user stories, definitions of done, and everything else — every team should stop once in awhile and assess the things that they’re doing, the documents that they’re creating, the paperwork trail that they’re leaving, and determine for themselves whether it’s too much, not enough, or just the right amount. And if there’s no value, get rid of it — you can always bring it back if something bad happens — but it likely won’t. There’s a lot of stuff that we do just to do it, just to meet external needs, just to check boxes — and all of that takes time, energy, and effort that could be better invested somewhere else. If stakeholders have needs that aren’t feeding your team value, work with them to offset that effort, to move it to where there is value to be had. But don’t blindly do everything the same way you’ve always done it — if you do that, you’ll never improve and you’ll never deliver more or better than you do now.
Reuse the Things That Work
One of the tools that I see very few teams leveraging effectively is the concept of a “Scrum of Scrums” in which all of the Scrum Masters in the organization get together and talk about what they’re doing. Or I do see teams doing this, but the focus is so narrow and tactical that all you really have is a fancy, meta-scrum that’s little different from a daily standup. This neglects the single most important opportunity that you have in your organization to share knowledge and help each other improve — every team should be experimenting on a regular basis, trying new things that come up in retrospectives. But unless we set aside time to specifically share these experiments with others, we’re hoarding the knowledge of things that work (or don’t work) for ourselves, which means that other teams wind up reinventing the wheel when they come upon a stumbling block — and that’s categorically wasteful. If you’re not doing Scrum of Scrums meetings now, start. If you are, but they’re too tactical and down in the weeds, change them up — add some questions about process, about experimentation, about retros, about improvement. By sharing your stories of success (or failure), you’re helping others in your organization to get better at what they do and to help them reuse the tools, processes, or learnings that others have already gained.
Recycle What’s Not Quite There Yet
If we’re doing our work right, and we’re experimenting with new processes, tools, or theories, we’re going to run into situations where the gains that we expect to see don’t quite pan out. And it’s in our nature to want to just toss it all out when it doesn’t meet our expectations — especially if we’re focused on reducing waste. After all, what’s more wasteful than an experiment that has failed? I urge you not to be so quick to throw the baby out with the bathwater, though (geez, isn’t that a morbid metaphor!?), but to stop and critically assess the experiment and its results. Often, what may appear on the surface as a failed experiment really is just one permutation of an infinite set of possible outcomes — and by taking a close look at what we did, how we did it, what the result was, and what the expectation was, we might find that there is an opportunity to improve on the prior experiment rather than simply toss it aside and try something completely new. Maybe your online retro didn’t go so well the first time you tried it, so you’re tempted to just switch back to stickies and white boards forever more. Don’t be so quick, though — maybe it was the tool that didn’t meet your needs, maybe it was a lack of visual connection between the team members, maybe it was a mis-match of expectations within the team. Any one of those possibilities is something you can hypothesize on and create another pass on the experiment to see if you can improve it (in order: try another retro tool, have video cameras set up for the team, or reset expectations when using a new tool). And those experiments might demonstrate the value that you’re looking for — whereas just dropping it like it’s hot would wind up simply falling into old habits.
