Understand Scrum, Understand PDCA

I had the pleasure interviewing James O. Coplein, author of the Lean Architecture: for Agile Software Development for an upcoming Business901 podcast. I seem to learn so much from the software community and had picked up Jim’s book to help provide a framework for parts of the Lean Marketing House (Marketing with Lean). I was so impressed with the book that I contacted him for a podcast. An excerpt from the book:

A good feedback cycle has the appearance of causing problems. It will cause emergent and latent requirements to surface. That means rework: the value of prototypes is that they push this rework back into analysis, where it has more value. And most important, good end user engagement changes end user expectations. It is only by participating in a feedback loop that’s grounded in reality that customers get the opportunity they need to reflect on what they’re asking for. If your customer changes their expectations in the process, you’ve both learned something. Embracing change doesn’t just mean reacting to it: it means providing the catalysts that accelerate it.

Explanations like this proliferate throughout the book. and he builds a complete framework for building a Lean Culture without ever calling it that. In the podcast, we talked about the evolution and interpretation of Lean and/or Toyota Production System (TPS) and their relationship with Scrum. It is interesting how they complement each other. In one sense, it is interesting how Scrum is hardly more than a PDCA cycle. But on the other hand it really enhances the PDCA cycle in the spirit of teamwork and flow.

In this video, the Father of Scrum, Jeff Sutherland, CEO of Scrum, Inc and Senior Advisor to OpenView Venture Partners discusses the evolution of Scrum. Jeff discusses the roles, the meetings and the reporting process associated with Scrum methodology.

This video provides an understanding of Scrum and provides a basis for how a team can operate in an iterative fashion. I was always taught in project management to always look at what was left to do more than what was completed. This is a basic theory of the burn-down chart.

Related Information:
Jeff Sutherland’s Website: http://scrum.jeffsutherland.com/
James Coplein;s Website: Gertrude and Cope