Who should read this book?
Agile Coaches who want to coach the CIO or CEO.
CIOs who want to assess the design of their IT organisation
Lean Coaches who want to broader their skill set.
HR managers might like chapter 10 about organisational practices, which covers the STAR model (Task, Structure, Processes, Rewards & People).
Why you should read this book (or not)?
This book covers a very broad range of topics. I found it very insightful to learn about the link between Agile and Lean, system thinking & queueing theory. It also covers Agile as a mindset, how to set-up teams, how to scale agile & various topics on organisational design. The drawback is that this might make the book a bit less accessible.
In my opinion, the title is not a good representation of the content: It is not about scaling lean. It is about how lean concepts are still valid in an Agile Development context (e.g. the authors describe examples of the 7 wastes in software development). For me, the use of “Agile” in the title suggested general Agile. Rather, it explains many aspects of scrum, but Kanban as an Agile practice is hardly covered. Just so you know.
The chapter on Feature Teams contains very insightful information about component versus feature teams (advantages & disadvantages). If you really want to know more about this topic, “Team Topologies” by Matthew Skelton & Manuel Pais describes a more advanced approach.
I loved the chapter on False Dichotomies. It covers both how people without knowledge of Agile perceive Agile as how some people doing agile, misinterpret it.
Another aspect I can appreciate is that theory & abstract concepts are alternated with very practical tips and tricks in the form of “Try …” or “Avoid …” (including some more detailed information) such as
- Try … multi-skilled workers
- Try … open team conflict
- Try … distinguishing between products and projects
- Avoid … phase-based “resource allocation”
- Avoid … stage-gate becoming waterfall
- Avoid … job descriptions
Interestingly, the authors remain very pragmatic. For the “Avoid … job descriptions” they added “If removing job descriptions is not currently an option then at least make them simple, broad, and high level. For example, the description of ‘team member’: A team member has the shared responsibility for the outcome of an iteration. High-level general job descriptions promote thinking, innovating, learning, and doing whatever is necessary to deliver the product, rather than strictly following limited responsibilities.”
You might have guessed that this book does not give you an easy recipe / roadmap to get started with Agile. For me it was a very pleasant book to read as it provided several AHA moments.
Interesting extracts
“ “It depends on common sense.”—A statement sometimes heard in Scrum and common parlance. But what is this? Einstein quipped, “Common sense is the collection of prejudices acquired by the age eighteen.” Taiichi Ohno, the father of the Toyota Production System, said, “[…] miscode tried to be more outspoken than the other and things do not move ahead at all. That is why there was a time when I was constantly telling people to take a step outside of common sense and think by ‘going beyond cnceptions easily turn into common sense. When that happens, the debate can become endless. Or, each siommon sense.’ Within common sense, there are things that we think are correct because of our misconceptions. Also, perhaps a big reason we do some of the general common sense things we do is that based on long years of experience, we see there are no big advantages to doing things a certain way but neither are there many disadvantages to it. … we are all human so we’re like walking misconceptions believing that the way we do things now is the best way. Or perhaps you do not think it is the best way, but you are working within the common sense that ‘We can’t help it, this is how things are’”. “Common sense” is not so reliable when trying to understanding nonlinear systems—such as large-scale product development. ”
“ “Everyone is doing their best yet overall systems throughput is degrading. How can that be?” This is the paradox of local optimization—when a person or departmental decision maker optimizes for the local view or self-interest. The party making the decision frequently believes they are making the best decision, but because ‘best’ is a local optimization, in fact it sub-optimizes overall system throughput. This is a result of “silo mentality,” misunderstanding, fear, limited information, delayed feedback, ignorance, careerism, avarice, and other common organizational learning disorders. (…) For example, the legal and corporate security departments put in place a policy that seems terribly important from their perspective. In the aim of preventing loss of intellectual property (IP), the legal department decrees “no one shall put any information on the walls.” Or, in response to cost-cutting pressure, the facilities management says, “It is important to ensure our walls are not dirty or damaged.” And thus they shut down a practice in lean thinking, visual management (which is usually done on walls), and they inhibit a well-known innovation practice, group whiteboard work. The lawyers may succeed in reducing loss of IP (actually, that is questionable), and the facilities people will succeed in keeping the walls clean—at the cost of inhibiting the product development group from innovating and collaborating. Finally, the company falls behind with less and less IP. ”
“Working in regular rhythms or cadence is a lean principle, both in production and development. A steady heart beat. In lean production, it is called takt time. In development, it is called cadence. The Scrum practice of delivering (and holding predictable meetings) in a regular two- or four-week timebox illustrates cadence. Cadence is a powerful principle in lean product development, so the subject is examined in some detail… There is something basic and very human about cadence: People appreciate or want rhythms in their lives and work—and appreciate or want rituals within these rhythms.”
“And because multiple feature teams will work on shared components, sometimes at the same time, it is essential that the code is clean, constantly refactored, continually integrated, and surrounded by unit tests—as otherwise it won’t be possible to work with. Note a key insight: Feature teams shift the coordination challenge between teams away from upfront requirements, design, and inter-team project management and toward coordination at the code level.”
“Ironically, the reason for breaking up well-working teams is ‘efficiency.’ Efficiency is often incorrectly measured by an “increase in resource utilization” (remember the baton and the runner). But, does this really improve the overall efficiency or is this another local optimization? If you are truly interested in performance, then it is unskillfull to break up high-performing teams. Instead of regrouping teams to fit the work, you can regroup the work to fit the teams.”
“But you might wonder, “Without performance review, how do we know the amount of pay increase?” Toyota, as pointed out earlier, pays everybody the same within a given classification. So, then there is no need for an annual performance review to determine pay increase. The increase is decided for a certain classification and determined by the cost of living and market value of certain skills. How can you know when to promote someone to a higher classification without an annual review? If your managers need an annual review to determine this, there is a lack of Go See behavior. Are organizations without annual bonuses necessarily less attractive to employees? No. Most companies have a fixed compensation budget that consists of salary, incentives, and other benefits. This budget does not need to decrease; instead, the incentive part decreases and the other parts increase. Companies that abolished their incentive pay and performance appraisals frequently pay employees above market-average salaries.”