All in continuous improvement
I finally took the time to read Donella Meadows’ Thinking in Systems: A Primer. It is obviously a primer on terms and concepts - not on the how to’s. There are great thoughts throughout the book on how to incorporate systems thinking and the value behind it. Even at the outset, Meadows says something to the effect that it is only useful to do this analysis if it will help solve real problems.
When I heard about Dan Markovitz’ The Conclusion Trap, I knew it was right up my alley. the book gives us a straightforward guide to thinking better about "problems,” rather than jumping to the first solution that comes to mind.
Albert Einstein: “It's not that I'm so smart, it's just that I stay with problems longer.”
Root causes on the mind, clearly. This time an article from the Farnam Street blog talks about the difference between proximate and root causes.
A lot of people struggle to identify the “real” problem they have. Some thoughts about the typical challenges with problem statements and ways around them.
I listen to the Gemba Academy Podcast, and a recent entry reflects back to a blog post from one of their contributors, Why Can’t We See the Financial Impact of Continuous Improvement? I love the list of mistakes people make that make CI efforts seem to vanish on the balance sheet.
My review of Gene Kim’s upcoming book, The Unicorn Project: A Novel about Developers, Digital Disruption, and Thriving in the Age of Data (due at the end of November). It’s an interesting read, describing a path to an amazing turnaround of a doomed technology inside a traditional business. The Five Ideals are a nice encapsulation of many of the ways people talk about continuous improvement with a notable addition of Psychological Safety.
Johanna Rothman and Mark Kilby’s new book From Chaos to Successful Distributed Agile Teams is a fairly quick read, loaded with guidance and recommendations for teams that aren’t co-located apply the Agile Software Development principles. They even carve out specific instances of the principles as applied to distributed agile teams.
Mike Dalton has been writing a series about “the growth equation” and innovation management at Innovation Week. The last one is The Growth Equation: Upping Your Market Impact (6 Steps for Focusing Your New Product Efforts on High-Impact Opportunities). In it he takes the questions for technology and adds some thinking about how financial measures might be added into the questions. It’s always those last questions that trip up change efforts though.
How about an article that tries to apply Theory of Constraints to the arena of hockey? A post on a New Jersey Devils blog describes the Five Focusing Steps and then applies them in a couple scenarios - one on the ice and another in scouting / recruiting.
No, I don’t want to give up on this topic. But I want to clarify something: Multitasking is an effect - a result of the system in which we find ourselves. In order to “stop multitasking”, the system has to change. And this is where we get to apply some thinking - what can we change in the system?
An interesting video of a presentation from the Skype team on how they used the first of the Five Focusing Steps from Theory of Constraints to identify their constraint to delivering value.
I came upon Richard Sheridan and his writings only recently. He clearly loves what he does at Menlo Innovations, and this comes shining through in his book Joy, Inc (from 2013) that I devoured recently.
Gary Klein’s 2013 book “Seeing What Others Don't: The Remarkable Ways We Gain Insights” is a good read, as I’ve found with his his other books. He likes to explore a topic from stories and search for corroborating links to draw together new conclusions. And as this book is about insight, the overall story of this book describes his journey of discovery as he delved into the topic. I particularly liked his discussion of the challenges that organizations face in gaining and using insights.
Systems thinking guides us to step back and look at the system. What created the environment in which the error occurred? Even beyond “errors”, what makes the system operate in some way that we find objectionable? What is the system that we are describing? What do we WANT from the system? Then we can dive in and look for understanding behind what is creating the undesirable results. It is incredibly rare that the root cause can be placed at the foot of an individual. It’s the system.
Mark Graban has written a great book on statistics, Measures of Success: React Less, Lead Better, Improve More. He focuses on Process Behavior Charts that help highlight the natural variability of a process and can really show when there has been a change in the underlying system. He does a nice job (for me) of simplifying the concepts and the underlying reasoning. He’s even put the math at the back of the book, in favor of providing clear reasoning and project flow.
The latest DevOps Enterprise Summit (DOES) wrapped up last week in Las Vegas. Amongst the videos and tweets and blog posts that have come out of the event was a quick interview with Gene Kim on the Agile Amped podcast with Greg Bledsoe of SolutionsIQ.
My review of Kevin Kohl’s Addicted to Hopium - Throughput: Using the DVA Business Process to Break the Guesswork Habit. The book is a fictionalization of the long history that Kohls has had in bringing Theory of Constraints and related approached to GM and other organizations. Kohls gives us the story of MegaCo and engineer Andrew Wright and their journey from barely being able to keep their heads above water to applying a strategic approach to improvement, thanks to the impetus of a guru in the form of a possible customer.
In essence, this book is about taking the Lean Startup concepts and applying them much more broadly - inside companies, non-profits, governments, and or even a lemonade stand. Most of the ideas and proposals in the book make a lot of sense, and it is useful for me to have them collected in this fashion.
I came across this quote from Ernest Mueller in doing some reading on DevOps, and it stopped me in my tracks. “Automation is the exercise of power.”