Five aspects of company policy as causes of waste

I’m currently reading Mary and Tom Poppendieck’s new book, Leading Lean Software Development, and I’m blown away. There, strategic insights are compiled with a light hand and made comprehensible. If we have the Scrum glasses on, for example as ScrumMaster, we start the consideration with the team, help the team to work effectively and secure an environment that ensures such effective work permanently. Sometimes the consideration stops there, too, and you summarize the rest as “organizational impediments.”

The Poppendiecks start at the other end: they look at the process, how to optimize it, how to eliminate its problems. They then also come to the team and optimal agile working techniques, but often justify them differently. For me, this approach is such a valuable addition to my Scrum glasses because it often gives me surprising new reasoning for scaling Scrum at scale or for embedding it in organizational processes at all. In this case, they make the case for looking at the system as a whole (“systems thinking”) and identify five aspects of conventional life experience that have become a problem as processes or ways of doing things.

• Complexity
• Misguided scaling
• Separate the decisions from the execution
• Wishful thinking
• Technical debts

Too much complexity

Many software systems contain far too many features and the complexity of the software increases more than linearly with it. And of there are conditions under which it is suggested that the scope of the systems cannot be negotiated. At some point, reality hits and you have to make a decision: Postpone the deadline or reduce the scope. But then the child has already fallen into the proverbial well: Time and work have gone into features that are not yet or never used. Another reinforcing factor is metrics that further support such behavior: Measuring productivity in lines of code or function points suggests success even in the production of useless features and starts a disastrous feedback cycle.

Misguided scaling

or: thinking in batch-and-queue is already burned into us so firmly that we often don’t even recognize it when we find it in the soup. In complex developments, it is not a matter of optimally utilizing resources (here: people), but of optimizing the flow. This leads to a process that responds very poorly to surprises, where work must be interrupted and multitasking and useless stress are endemic. This also and especially applies to the practice of annual budgets for developments that cannot be seriously estimated in any way, but which are often accepted with a shrug of the shoulders as “that’s just how it’s done”.

Separating decisions from execution

There is still a misconception that managers don’t need to understand what their employees are doing. Such Manage also can not give any help and contribute to the learning process. On the other hand, in such cultures, often the only way to move up is to let one’s technical expertise lie fallow and take on personnel responsibility. If that’s not a waste…

Wishful thinking

In development, we all too often approach tasks with an almost naïve, unscientific attitude. We don’t test the usefulness of a new tool, we don’t produce prototypes, we don’t have a systematic way of gaining knowledge from our work. But even Frederick Taylor knew that much.

Technical debts

We tolerate unfinished code, force developers to work to unrealistic schedules, skimp on refactoring, and then wonder about maintenance costs and inadequate quality.

Scrum and the waste

If you now swap the Lean view with the Scrum glasses again, you will recognize all these descriptions:

• Too much complexity is combated with a rigorous prioritization in the Product Backlog
• Scrum counters a misguided sacrification with a self-organized team that delivers a finished increment at the end of each sprint.
• Many decisions and execution are in the hands of the self-organized team
• We prevent wishful thinking by uncovering it in a retrospective after each sprint and taking consequences
• Technical debt only occurs when you haven’t produced potentially deliverable code after the sprint

My consequence? It is always worthwhile to think outside the box. Sometimes nothing changes in the work, but there are new ideas and reasoning. And in this case, on top of that, it’s really a good book.