Lean gives us the vocabulary of Muda, Muri, and Mura to classify our process bugs as a guide in tracking down the root cause. Practices for debugging software are well established; breakpoints in code can be a powerful means of dispelling ambiguity. Applying equivalent practices to process debugging helps us identify which process improvements are indicated.
Observed vs Expected Behavior
Everyone gets that the point of software debugging is to observe the program in action, to determine the delta between expected and actual behavior, and to understand the causes of observed behavior. Understanding the delta of how we expect work to move across our boards, and how it moves, that would be valuable information.
Preying mantis
Before adopting some “best practice” because it has become the standard way of doing things, we should first make sure we understand the nature of the problems that we’re facing.
Everyone doing their best is not the answer. It is necessary that people know what to do.
— W. Edwards Deming
Card Wall as a Metaphor
The card wall is the standard metaphor for process modeling, so it is the context where process debugging takes place. Many teams do this naturally, for example when they decorate a blocked story with a color sticker, they are engaging in some elementary process debugging. Our goal is a better understand the actual state of affairs at a given point, and the events the led there, using the card wall for debugging the process.
Woman working on Agile card wall
Technical practices are the hard work of establishing the capability of a development organization. Meaningful practices can take considerable time to mature. The decision to commit to one practice also implies the deferral of others, so it very important to choose the practices that are most appropriate to the nature of the team and the work. For an immature team, same basic choices may be obvious, but for a team that is showing some success as well as challenges, making the right practice choice shouldn’t be left to chance: we need to reserve limited time and resources to practice choices that fix the process bugs that we’re facing.
Everyone wants more throughput from their software development team, but when looking for ways to improve, often the spotlight goes on the limitations of the team members rather than flaws in the process itself. Start from the perspective of what delivers value from the perspective of the customer, and the process in place to facilitate that. Don’t try to make the team comply with the process so much as focusing on making the process comply with the value stream. The goal is to identify and remove impediments in the process.
We should learn from each other, and best practices provide a shared idiom to exchange ideas. We need to make sure that the practices we adopt are the best solutions for the problems we’re experiencing. Once we understand the kind of bugs that are common in our process, the right choice of practices become evident to avoid them in the future.
Let's agree to define productivity in terms of throughput. We can debate the meaning of productivity in terms of additional measurements of the business value of delivered work, but as Eliyahu Goldratt pointed out in his critique of the Balanced Scorecard, there is a virtue in simplicity. Throughput doesn’t answer all our questions about business value, but it is a sufficient metric for the context of evaluating the relationship of practices with productivity.
Preying mantis
Woman working on Agile card wall
