Eliminate Waste is one of the core tenets of Lean Software Development.
By definition, the most efficient process is one in which there are no wasteful activities.
By learning to spot different types of waste, it is possible to start eliminating the activities that make our software development processes inefficient.
The lists below are intended as a starting point, to help us spot waste in our own software development processes.
Common Sources of Waste
Mary Poppendiek identified 7 common sources of waste in software production. She mapped each of these to one of the 7 wastes “muda” wastes in lean manufacturing.
- Partially done work (work in process)
- Extra features (over production)
- Relearning (extra processing)
- Task switching (handoffs)
- Waiting (delays)
- Handoffs (motion)
- Defects (defects)
I have noticed several other wastes that are common in the field:
- Unnecessary complexity (a form of over production, one that is especially common in software systems)
- Missed automation opportunities (a form of extra processing)
- Over-management (another form of extra processing)
A reflection on my agile journey.
Stage 1: The Ordinary World
Doing what we’ve always done.
Stage 2: The Call to Adventure
The feeling that there must be a better way.
Stage 3: Refusal of the Call
There are many reasons to turn back:
- Uncertainty and self-doubt.
- Fear of change.
- Too busy chopping down trees to take the time to sharpen the axe.
- Lack of support.
Stage 4: Meeting the Mentor
Seeing that other people have taken this journey before you, and taking inspiration from them.
Stage 5: Crossing the First Threshold
Formally adopting Lean / Agile. Often involves adopting a framework such as Scrum.
You may have to defeat the threshold guardians, e.g. colleagues who are resistant to change, managers etc.
Stage 6: Tests, Allies and Enemies
Making changes within your team to make Lean / Agile work for you.
Stage 7: Approach To The Inmost Cave
A sense of foreboding. An inkling that you’ve missed something important. A feeling that Lean / Agile is flawed, or that you’re doing it wrong, or it has been over-sold.
Stage 8: Ordeal
Facing up to the fact that Lean / Agile hasn’t lived up to its promise.
Stage 9: Reward
A deeper understanding of Lean / Agile; not just its practices, but its deeper principles.
Stage 10: The Road Back
Adopting a Lean / Agile mind-set.
Stage 11: Resurrection
A complete re-evaluation of what you’re doing from your new vantage point. A new enthusiasm and energy. Addressing long-standing issues.
Stage 12: Return with the Elixir
Encouraging others to take the Lean / Agile journey for themselves.
This is my review of “Practices of an Agile Developer: Working in the Real World” by Venkat Subramaniam and Andy Hunt.
Aside from introductory and closing chapters, each chapter of the book describes one of 45 practices that are important in achieving an Agile development environment (one reviewer suggested it be renamed, “45 Habits of Highly Effective Developers”).
Each practices includes:
- A practice number and title, for easy reference.
- An explicit statement of the reasons why we might resist the practice described (the Devil’s temptation)
- A discussion that explains the rational behind the practice and how to apply it practically, typically backed up by real-world examples
- A summary of the key message of the chapter (the Angel’s advice)
- The emotional outcomes of following the practice (What it Feels Like). This encourages emotional buy-in.
- Notes on how to maintain perspective (“Keeping Your Balance”)
The language, typography and layout make it an easy read.
The division of the book into 45 practices means that:
- You can read it in digestible chunks
- You can dip-in to interesting chapters
- It is a good reference book
The thing I like most about the book is the emotional awareness of the authors. They recognise that development is as much an emotional experience as it is a technical one, and that communicating good practice needs to discuss the readers’ emotional needs as well as their practical ones. This applies to both the presentation and content of each chapter. As a result, I felt good about reading this book, and I feel good about trying out the ideas presented.
One thing I disliked is that some of the “practices” described in the book are much more abstract than others. For example, practice #7 (“Know When to Unlearn”) is quite abstract in that it deals with a general attitude that you should adopt towards your existing practices. In contrast, practice #6 (“Invest in Your Team”) is much more concrete, in that it deals with the specifics of how to set up”Brown Bag Sessions” with your colleges. Now, there are both advantages and disadvantages of this variation in tone. On the positive side, the variety makes for a more interesting read, and if you’re taking a pick-and-mix approach to Agile it means that you are more likely to find a practice that you can experiment with at a level appropriate to your current team. On the other hand, it makes the practices a little more difficult to introduce in a systematic way.
The biggest failing of this book is that it does little to integrate the various Agile practices. Now, these practices can adopted independently, and this book does a lot to help you explore them individually. Clearly, then, suggesting that they are reliant upon each other would have been a mistake. On the other hand, getting everything working together isn’t always easy: a little more guidance in that direction would have been very welcome.
I wouldn’t want this to be my only book on Agile Development: you’ll need something else to help you integrate these practices into a system. It is well written, however, and would be a good reference for someone new to Agile Development. Experienced Agile developers will find many of the practices rather basic, but might still be inspired by this book to try new things. In my view this is a 4-star book.