Scrumban
Corey Ladas' groundbreaking paper "ScrumBan" has captured the imagination of the software development world. Scrum and agile methodologies have helped software development teams organize and become more efficient. Lean methods like kanban can extend these benefits. Kanban also provides a powerful mechanism to identify process improvement opportunities. This book covers some of the metrics and day-to-day management techniques that make continuous improvement an achievable outcome in the real world. ScrumBan the book provides a series of essays that give practitioners the background needed to create more robust practices combining the best of agile and lean. Click on the link to purchase the book: http://www.lulu.com/content/3864767
Review By: Jan Scott
11/02/2009If you've ever wondered if workflow management practices could apply to software development or if you just want to learn more about workflow management, then you will find this book interesting. Author Corey Ladas combines a study of Lean software methods with workflow theories from the industrial engineering world. The result is a set of practices that, to me, seem to be a bit arcane but perhaps relevant to those in a high-production software development shop.
The book starts with the concept of a "kanban" also known as a visual board. Think about Starbucks or your favorite coffee bar and how they fill your order. At some places, one person will take your order, ring you up, make your drink, and then give it to you. At others, one person may take your order, mark your cup with the details of your order, then place it in a queue; a second person will make your drink and give it to you. These two examples are different types of workflows. The second is a kanban method where the cup is a sort of visual token that enables the workflow.
The book is all about how to apply kanban methods to the software development workflow of analyzing, specifying, coding, and testing. The book starts with a discussion of how to implement such a system. As an experienced project manager of large corporations, the most interesting and valuable section of the book was the one titled, "Organization". The agile philosophy has embraced the idea that the best organization is decentralized where the do-ers self organize without the involvement (or, as proponents would say, interference) from management. However, this author argues that we expect software developers to be subject matter and technology experts, but it is unreasonable to expect them to be organization experts. Conversely, we expect managers to be organizational experts but not technology experts. So there needs to be a partnership between management and the workforce. This is refreshingly non-ideological.
He goes on to discuss different workflow techniques starting with a simple version with three states: "to do", "in process", and "done". He ends up with a workflow that has broken "in process" down into the various activities and has added a "complete state" for each activity. All these workflows use a surprisingly low-tech technique of sticky notes on a white board. I am not sure how this would apply to our remote teams that are so prevalent today, but the author makes it clear that he is in favor of developers working in physical proximity to one another. The workflows are logically explained with their advantages and disadvantages pointed out. The one weakness was the diagrams that are sometimes unreadable since the print is so small and light.
In summary, this book is an interesting addition to the library of a software development manager, a developer, and a process improvement specialist, or anyone interested in learning about workflow management, especially if you would like to hear a slightly divergent view from the typical agile or Lean practitioner.
Review By: Sunil S. Prasad
11/02/2009The name of the book truly expresses the author's personal point of view about an emerging body of knowledge that is currently brewing within agile software development: Kanban. Author Corey Ladas shares his thoughts about it, Lean thinking, and the theory of constraints. He attempts to explain how most of us may have erroneously over-committed to a specific process that is probably narrow, prescriptive, and rigid.
Even though Kanban and Lean work for certain types of problems, Kanban is more for extreme programming. One of the most important facts about Lean is that it is defined as set of principles and not as a process that can be replicated. For example, the Toyota production system is Lean, but Lean is not the Toyota production system. In the same vein, Kanban is not a process. Kanban is a practice that embodies a principle. This book helps you ask the deeper questions which will help you understand this.
Unlike a manufactured product, software product development is a complicated process. You have to match your current work in progress to your current capacity. Corey suggests even starting with a simple, reasonable process change is difficult. People get attached to their habits and tribal affiliation. People resist changes that threaten their social status. One thing one can do is take the evolutionary approach and keep changes small and incremental whenever possible.
Ladas also gets into the basics of how to set a multitasking limit for individuals and how to plan and prioritize. Suppose your next release has one hundred features planned and you ask your product manager to rank them by priority, then eighty percent of the stories will be high priority.
I believe this book describes Corey’s true search of unconventional inspiration from the worlds of systems engineering, industrial engineering, and product development. It also highlights organizational communication, which is approached from both an organizational design angle and the communication angle.