Reading and summarizing books on lean software development, so you dont have to. Part 1.
Besides agile philosophy, practices, processes & methods, lean becomes an increasingly recognized topic around software development. At least I can say that about my peer group. After an initial training on the matter in which I learned about the „general lean“ practices from the industrial production area, I had a lot of questions and doubts about its applicability in software development. Of course there are obvious connections and transfers which one could try, but I was wondering about existing experience, studies, research and best practices. So I was checking out the available books and found three. Two of them I already read, and today I want to start with the first (which I actually read second). Please note: I will not provide introductions and details on neither Lean nor Agile, as for such there is a myriad of online resources available, and I assume my readers know at least the agile part very well. Also, as usual in my book reviews, I am less focused on how well-written a book is. My focus is on new thoughts, inspiring ideas, surprising perspectives and generally speaking everything which deserves an application in my professional life (and the ones around me).
„Lean-Agile Software Development – Achieveing Enterprise Agility“ written by Alan Shalloway, Guy Beaver and James R. Trott was published in 2010, which means that in the fast-paced software industry its already quite old. For this book this was not a downside, as I could compare their takes against current state-of-the-art.
In the foreword Alan Shalloway makes an interesting observation:
Too long, this industry has suffered from a seemingly endless swing of
page xviii
the pendulum from no process to too much process and then back to no process: from heavyweight methods focused on enterprise control to disciplined teams focused on the project at hand.
I can confirm this from various scales. On a grand scale this has been true when you look at the software development history, starting decades ago. Enterprise processes, which followed the wild-west of the early days of computing, were replaced by agile practices. Even more, even within an organization down to project-level and individuals, the continued conflict about the „right amount of process“ is probably the biggest philosophical debate around in software development. Shalloway claims that lean principles can „guide us in this“ and „provides the way“. Lets see.
On page xxxviii the authors summarize „core beliefs of Lean“, preceeded by core beliefs of Agile and Waterfall. As all of those are not taken from „canonical“ sources, let me share the lean ones here, as they are a first cood summary:
Even when applied to software development, Lean is not limited to software development teams alone. On page 7 a tables lines out the contributions from all parties:
This is easier said than done. In many organizations both business and management are focused on pushing and tracking the delivery team, but spend too less time on their contributions. Another thing noteworthy here is the notion of the „delivery team“. This is not a team supporting, testing, integrating and generally taking care of delivery, no this is actually the software development team. Hence, this seems a synonym to more widely used terms like „feature teams“. I like the term delivery team, and could think about combinding both in „feature and delivery team“. Each term focuses on one aspect, the former more about the product, the latter more about the activity. In modern software development, I think its crucial to combine both in one team. Diminishing on of both aspects will inevitably lead to a suboptimal efficiency because essential parts are outsourced to other teams.
Lean principles suggest focusing on shortening time-to-market by removing delays in the development process; using JIT methods to do this is more important than keeping everyone busy
page 8
This is very valuable statement. Too often I see engineers getting dragged into task forces just because in the moment they are not overloaded. As a consequence, this leads to a culture in which everyone wants to be perceived or actually be busy all of the time. Continuous busy-ness is not sustainable and leads to growing organizational and technical debt. The cited statement instead clarifies that a lean and efficient process doesnt correspond to a process in which everyone is busy all of the time. Essentially we are talking about different dimensions.
Eliminating waste is the primary guideline for the Lean practitioner. Waste is code that is more complex than it needs to be. Waste occurs when defects are created. Waste is non-value-added effort required to create a product. Wherever there is waste, the Lean practitioner looks to the system to see how to eliminate it because it is likely that an error will continue to repeat itself, in one form or another, until we fix the system that contributed to
page 10
While reading this, it comes to my mind that everything which is not automated which can be automated is also a waste. Manual execution is inherently more error-prone in any software process.
Developers tend to take one of two approaches when forced to handle some design issue on which they are unclear. One approach is to do the simplest thing possible without doing anything to handle future requirements. The other is to anticipate what may happen and build hooks into the system for those possibilities. Both of these approaches have different challenges. The first results in code that is hard to change. […] The second results in code that is more complex than necessary. […]
An alternative approach to both of these is called “Emergent Design.” Emergent Design in software incorporates three disciplines:
- Using the thought process of design patterns to create application architectures that are resilient and flexible
- Limiting the implementation of design patterns to only those features that are current
- Writing automated acceptance- and unit-tests before writing code, both to improve the thought process and to create a test harness
Using design patterns makes the code easy to change. Limiting writing to what you currently need keeps code less complex. Automated testing both improves the design and makes it safe to change. These features of emergent design, taken together, allow you to defer the commitment of a particular implementation until you understand what you actually need to do.
Page 11f
Conflicts around the aforementioned two approaches are indeed quite common. Both sides typically are able to throw business needs into the ring (pragmatism vs. sustainability). Even more, I often observe conflicted parties which did take the opposite position in the last conflict. Hence, emergent design sounds like a promising middle ground. I already have ideas in which conflicts I may bring it to the table.
Table 1.2 lists a good transfer of the industrial production costs and risks to the software world, something my first training on lean was missing out on:
On assigning persons to multiple projects at the same time, the authors cite an interesting study by Aral, Brynjolfsson and Van Alstyne. This study showed that the overall productivity of on person is reduced by 20% for the second and third parallel project, each. This is huge, also considering that often the better engineers are pulled/pushed into multiple projects/teams to rescue them. As a result, the best engineer’s capacity is reduced and thinned.
In the chapter about „Going beyond Scrum“, there is a good summary of Misunderstandings, Inaccurate Beliefs, and Limitations of Scrum:
Misunderstandings commonly held by new Scrum practitioners
- There is no planning before starting your first Sprint.
- There is no documentation in Scrum.
- There is no architecture in Scrum.
Scrum beliefs we think are incorrect
- Scrum succeeds largely because the people doing the work define how to do the work.
- Teams need to be protected from management.
- The product owner is the “one wring-able neck” for what the product should be.
- When deciding what to build, start with stories: Release planning is a process of selecting stories to include in your release.
- Teams should be comprised of generalists.
- Inspect-and-adapt is sufficient.
Limitations of Scrum that must be transcended
page 84
- Self-organizing teams, alone, will improve their processes beyond the team.
- Every sprint needs to deliver value to the customer.
- Never plan beyond the current sprint.
- You can use Scrum-of-Scrums to coordinate interrelated teams working on different products.
- You can use Scrum without automated acceptance testing or up-front unit tests
I will not comment on each point. The first two sections I would confirm entirely. The last section is pointing at some „missing“ aspects in Scrum, but I think just because e.g. test-driven development is missing, its not a limitation. Scrum is not claiming to be describe every aspect of software development.
In general: tables. This book really contains some nice side-by-side comparisons in tabular form. Table 5.1 compares „Scrum and Lean Perspectives“:
The book is also strong in naming typical anti-patterns in agile execution, especially when those anti-patterns clash with lean mindset.
Some common anti-patterns for Scrum teams are
- Stories are not completed in an iteration.
- Stories are too big.
- Stories are not really prioritized.
- Teams work on too many things at once.
- Acceptance tests are not written before coding starts.
- Quality Assurance/Testing is far behind the developers.
Here are questions we always try to use.
page 95f
- Does the team’s workload exceed its capacity?
- When was the last time you checked your actual work process against the standard process?
- When was the last time you changed the standard process?
- Where are the delays in your process?
- Is all of that WIP necessary?
- How are you managing your WIP?
- Are developers and testers in sync?
- Does the storyboard really help the team keep to its work-flow?
- Are resources properly associated with the open stories?
- How much will limited resources affect the team’s work?
- What resource constraints are you experiencing?
- Can these constraints be resolved with cross-training or are they something to live with?
- Does the storyboard reflect constraints and help the team manage them?
- What needs to be more visible to management?
- How will you manage your dependencies
The authors clearly are not satisfied with the amount of guidance provided by and the reality around Scrum. „Going beyond Scrum“, they present their own extended Scrum called „Scrum#“ in two pages. They also introduce Kanban as a simpler framework. A key concept already mentioned in the last citation, even more relevant for Kanban, are „work in progress limits“. WIP limits was a known concept to me since some years, learned from former colleagues. The relationship to lean, however, was new to me and it makes total sense. Focus is soooo important, it cant be overrated. In my own experience it would say around 50% of all issues in software projects originate from lack of focus and too many things going on in parallel. Finally in its comparison of process frameworks, the authors do not forget about Extreme Programming.
Before you write a line of code, set up the following:
page 109
- The product
- The team
- The environment
- The architecture
This sounds simple, still I never experienced a software project in which more than one of those points was clear to a basic degree. Too often, organisations spawn projects with a very fuzzy project idea, an undefined team, unknown environment and a notion of „architecture will be clarified along the way“. The book goes on to provide guidance on how to set up each points before the first development iterations are started. On page 140 the authors present a template for how to draft a product vision statement.
The book also spends a chapter on „The Role of Quality Assurance in Lean-Agile Software Development“. It has, in essence, one key recommendation which is Test Driven Development (TDD). They claim „The role of testers must be one of preventing defects, not finding them“. While TDD has its merits, I think this statement is too simple. It is a bit far from reality to expect testers to have tests ready before every implementation, especially in projects in which even technological basics are not remotely clear. On the other hand, I am not saying TDD is not recommended wherever it can be applied.
If the customer cannot or will not confirm that you have delivered what they want, you should simply state that you believe that the customer does not value the feature; that it is not a high priority. If it were valuable, they would make the effort to specify the tests. Moreover, you should tell your management team that you recommend not building the functionality. If you are required to build it anyway, go ahead, but know that it could well turn out to be a waste of time.
page 164
This is quite some radical take, and it its a bit hard to match to a typical setup in which customers typically do not care about the test cases. However, I can imagine that pushing for a project setup in which tests have such a crucial position that both customers and developer give them utmost priority can nothing but benefit the efficiency of the resulting project. The authors recommend to always keep the question „How will I know I’ve done that?“ in mind, which according to them is an ultimate tool tom avoid waste.
After focusing on the team-scale, the book goes on to widen the scope to full enterprises. Also here they provide some anti-patterns (excerpts):
Page 171f
- Teams are not well formed.
- Large batches of unprioritized requirements are pushed through the organization.
- There is no mechanism to limit work to resource capacity.
- Program managers and business sponsors compete for resources rather than working together to maximize the return on them.
- Automated acceptance testing is not being done. Test-driven development also is not being done. Testing is initiated too late in the development cycle.
- Code quality is left up to programmers’ personal beliefs.
- Finding and removing the root causes of problems is not pursued aggressively. Bugs are tolerated as a way of life in the software world. In fact, many organizations utilize bug tracking as status for release readiness.
- Continuous process improvement is not practiced or valued. Most companies are so busy trying to fix the latest crisis that there is no time to focus on process improvement to avoid causing the next one.
This is a good list, of course its rather examples than extensive or complete. The second item from the top is re-iterated on page 182 when the authors state „For example, it is common for management to track the number of unfixed bugs. It seems like natural approach to assess how a team is doing. Lean-Agile thinking uses a different approach: Instead of worrying about fixing the bugs, we should concern ourselves with what is causing them.“
In my opinion, all or most of the above points originate from a lack of discipline in the management team, leading to evasive activities with the above symptoms. For examples it is much simpler to track bug lists than to solve root causes in the organization. It is mentally simpler to run from fire to fire than to reflect about fundamental improvements for the process. It is simple to request new reports in every escalation meeting than to use existing ones continuously to create a sustainable frame for the development team. Who is to blame? I think its a management culture based on 100% meetings giving almost no time to reflect and short-sighted office politics. It speaks for the authors, when Alan Shalloway write:
Some people are natural managers; I am not one of them. Historically, I have always micromanaged. Because I am good in a crisis (often creating and then solving them), when one occurred I would tend to jump in and tell my team how fix it. I knew that this behavior was inhibiting the team’s growth, so I tried delegating—letting the team figure out how to do things on their own—often with very poor results.
I was really abdicating via delegation. I needed to find a way to let the team figure out the solution but remain involved enough to ensure that it would be a good one. Fortunately, Lean management provides a way to do this. With visual controls, I can see the team’s process—I can see how the team is doing at any time—and I can see the team’s outcomes.
If the team gets into trouble, I can actively coach them to improve their results without telling them what to do. Lean gives me a way to become a better manager without resorting to old habits.
page 190
Already earlier, we have touched on software architecture. In a separate chapter the authors dive more into the question how to find the sweet spot between too much and too less architectural work.
Build only what you need at the moment and build it in a way that allows for it to be changed readily as you discover new issues.
page 204
and
The purpose of software design is not to build a framework within which all things can fit nicely. It is to define the relationships between the major concepts of the system so that when they change or new requirements emerge, the impact of the change s required is limited to local modifications
page 208
Almost at the end the book comes to speak about the origins of lean at Toyota. Interestingly, they are highlighting that
One of the brilliant insights at Toyota was that Lean principles are implemented differently in manufacturing than they are in product development.
This gave rise to another great example of Lean: the Toyota Product Development System, which is a better example for us in software development.
page 215
Now this is one revelation. So far all trainings were about Toyota’s Production System, not the Product Development System. This makes me wonder if our sources are the right ones.
With that let me close this review. This book was a good read, it explained the existing frameworks, showed their flaws and issues both in theory and practice, made concrete recommendations. All in all this book is a recommendation if you want to read how agile and lean can be combined in state-of-the-art software development processes.