-----
title: "Book Review: Leading Lean Software Development"
content-type: article
subtitle: "A lean leadership framework"
timestamp: 1293455745
tags: "review|books|software"
pdf: true
-----

<section class="section">
	<p>If you already heard the names Mary and Tom Poppendieck, chances are that you already know what <em>Lean Software
			Development</em> is. If you don&#8217;t, start from <a
			href="http://en.wikipedia.org/wiki/Lean_software_development">this Wikipedia page</a>. Mary and Tom coined
		this term with their first book on the subject <a
			href="http://www.amazon.com/exec/obidos/ASIN/0321150783/poppendieckco-20">Lean Software Development: An
			Agile Toolkit</a>, that was followed three years later by <a
			href="http://www.informit.com/store/product.aspx?isbn=0321437381">Implementing Lean Software Development:
			From Concept to Cash</a>, and finally by this book: <a
			href="http://www.informit.com/store/product.aspx?isbn=0321620704">Leading Lean Software Development: Results
			Are not the Point</a>.</p>
	<p>Unlike the two other books, this one is focused about making lean software practices succeed. In some way, it can
		be compared to <a href="/articles/succeeding-with-agile-review/">Succeeding with Agile</a>, but while Mike
		Cohn&#8217;s book focuses entirely on Scrum, this book has a much broader scope. Moreover, the book contains a
		lot of digressions and stories &mdash;even not directly related to software development&mdash; aimed at
		understanding particular aspects of Lean Software Development and the Lean movement in general.</p>
	<p>The focus is, as the title suggests, on leadership: how can you be a good leader in these difficult,
		ever-changing times? How can you be agile without loosing your team? How can you improve the existing processes
		so that they can help you achieve your goals? If you ever asked yourself these questions, this is the right book
		for you&#8230;</p>

	<section class="section">
		<header>
			<h1 id="h_1" class="toc">Structure and Organization</h1>
		</header>
		<p>This book is extremely well-structured. Its Table of Contents follows some very rigid rules which make this
			book one of the most organized texts I&#8217;ve ever come across. It is divided into six chapters, each
			organized as follows:</p>
		<ul>
			<li>A <em>snapshot</em> or an introductory story for the chapter&#8217;s main topic</li>
			<li>Four <em>frames</em>, each describing a lean practice or personal quality</li>
			<li>A <em>portrait</em> of a leader</li>
			<li><em>Your Shot</em>, i.e. some questions and exercises for the readers</li>
		</ul>
		<p><img src="/img/pictures/books/leadingleanswdev.jpg" style="float:right" /></p>
		<p>In total, the book contains 24 frames constituting the &#8220;Big Picture&#8221;, which is actually a very
			powerful framework for lean software leadership. You can read the book&#8217;s <span class="caps">TOC</span>
			<a href="http://www.poppendieck.com/llsd.htm">online</a> on the Poppendieck website and read the
			book&#8217;s Introduction (<a href="http://www.poppendieck.com/pdfs/LLSD_intro.pdf"><span
					class="caps">PDF</span> link</a>) on the whole concept of <em>framing</em> (yes, both the authors do
			love photography!).</p>
		<p>When I started my career as a technical writer I used to love carefully-structured, simmetrical manuals.
			After a while, however, I understood that such rigorous structuring can even be dangerous if it becomes an
			obsession: you end up adding extra &#8220;padding writing&#8221; to make sections roughly match in length,
			or you start cutting down some other parts, for the same reason. Writing well-balanced books is hard, but I
			must say that the authors do a very good job with this book: it flows very naturally while keeping to its
			rigorous structure.</p>

	</section>
	<section class="section">
		<header>
			<h1 id="h_2" class="toc">Chapter 1: Systems Thinking</h1>
		</header>
		<p>The first chapter is about customers, what they want and the goals of your system. It describes some
			interesting high level concepts like <em>failure demand</em> and <em>policy-driven waste</em>, and how to
			spot opportunities to improve the process.</p>
		<p>What I found particularly interesting was the usage of <a
				href="http://www.cps.gov.uk/publications/finance/process_mapping.html">process maps</a> to analyze an
			existing process and find bottlenecks or leaks (in terms of time). I was instantly sold on this practice
			after reading the success story of how a company manage to reduce the overall time to process and solve
			customer issues simply by connecting customers directly to developers instead of tech support engineers.
			This is something you can&#8217;t apply everywhere, but after creating a process map for that specific case,
			the solution was evident.</p>
		<p>More generally speaking, this chapter provides a recipe/checklist outlining the sequence of the phases of
			process improvement and problem solving:</p>
		<ol>
			<li><em>Understand</em></li>
			<li><em>Observe</em></li>
			<li><em>Visualize</em></li>
			<li><em>Evaluate</em></li>
			<li><em>Implement</em></li>
		</ol>

	</section>
	<section class="section">
		<header>
			<h1 id="h_3" class="toc">Chapter 2: Technical Excellence</h1>
		</header>
		<p>This is the only chapter focusing primarily on technical topics and knowledge. It starts with a very lengthy
			digression on the history of programming methodologies, aimed at understanding <em>what works and what
				doesn&#8217;t</em>. Some examples of IT stuff that worked include the Internet, PCs and &#8230;Open
			Source Software.</p>
		<p>This chapter provides a general overview on Software Development as a whole. It contains some interesting
			information on software complexity and dealing with architectural dependencies, comprehensive sections on
			testing and continuous integration, and just a half page on refactoring (understandable, seeing that there
			are already plenty of excellent books on the subject).</p>

	</section>
	<section class="section">
		<header>
			<h1 id="h_4" class="toc">Chapter 3: Reliable Delivery</h1>
		</header>
		<p>The <em>Race to the Sky</em> section at the beginning of Chapter 3 is by far the most fascinating of the
			non-IT stories included in this book. It describes the construction of the Empire State Building in 1930,
			how it was planned out, what strategies were followed, and why it succeeded (why <em>the construction</em>
			succeeded: the building itself remained totally unprofitable for quite some time).</p>
		<p>There are <a href="http://en.wikipedia.org/wiki/Empire_State_Building#Further_reading">plenty</a> of books on
			the subject, but Tom and Mary Poppendieck well summarize the key points of this modern-day epic achievement:
			how to build the tallest skyscraper in the world in a single year. This story teaches us how to work under
			very tight deadlines, by designing a system to fit constraints, rather than estimating up-front.</p>
		<p>This story was perfect to introduce, in the same chapter, concepts like <a
				href="http://en.wikipedia.org/wiki/Kanban">Kanban</a>, <em>pull scheduling</em> and <em>adaptive
				control</em>, which only recently have been seriously considered in the world of Software Development
			but they are becoming more and more relevant.</p>

	</section>
	<section class="section">
		<header>
			<h1 id="h_5" class="toc">Chapter 4: Relentless Improvement</h1>
		</header>
		<p>Chapter 4 starts with a brief history of the checklist, which was invented in 1935, to be used by airplane
			pilots. It then moves on to its usage in hospitals, describing how checklists helped dropping infections
			caused by inserting central venous catheters incorrectly. Why all this? To focus on the concept of
			<em>process standards</em>, or better, how <em>we</em> can improve processes to accomplish our goals.</p>
		<p>Basically, this us what Toyota does: regulations should not be written on stone, but they should reviewed and
			updated frequently for continuous improvement or <a href="http://en.wikipedia.org/wiki/Kaizen">Kaizen</a>.
		</p>
		<p>Finally, this chapter also briefly introduces a few different ways to perform root-cause analysis, such as
			using <a href="http://en.wikipedia.org/wiki/Ishikawa_diagram">fishbone diagrams</a>.</p>

	</section>
	<section class="section">
		<header>
			<h1 id="h_6" class="toc">Chapter 5: Great People</h1>
		</header>
		<p>This chapter and the last one are actually focused on people and management. In this chapter, an unusual (for
			this kind of books, that is) but intriguing analysis on different countries using the following dimensions:
		</p>
		<ul>
			<li>power distance</li>
			<li>individualism</li>
			<li>masculinity</li>
			<li>uncertainty avoidance</li>
			<li>long-term orientation</li>
		</ul>
		<p>Turns out that individualism is abundant in the Western world but not so much in the Far East (who would have
			thought!), but the opposite applies to power distance. A bit stereotypical, if I may, but not too much: the
			results are not surprising, especially when it comes to considering different cultures as a whole. Once
			more, the focus is again on Toyota&#8217;s Kaizen and their culture of <em>respect for the people</em>.</p>
		<p>On page 198, the meaning of the subtitle of the book (Results Are not the Point) is revealed: <q>developing
				the people and the system so that together they are capable to achieve successful results is the
				point</q>. Agile is precisely about this: focusing on the people.</p>
		<p>But what about leaders? This is an aspect of the whole Agile philosophy that I keep stumbling upon: if you
			want <em>The Team</em> to be in charge, what happens to leadership? As I found out myself working in and
			with Agile Teams, often there&#8217;s a serious lack of strong leaders. <q>Leadership needs to be gently
				refactored into Agile</q>, that&#8217;s what Mary and Tom recommend. How? It depends on each specific
			case, but it must always be done <em>gently</em>.</p>

	</section>
	<section class="section">
		<header>
			<h1 id="h_7" class="toc">Chapter 6: Aligned Leaders</h1>
		</header>
		<p>The final chapter begins with the history of <em>Agile@IBM</em>, or how to turn the biggest software company
			in the world into a massive agile machine. It wasn&#8217;t a top-down decision, the <span
				class="caps">CEO</span> didn&#8217;t just wake up one morning and decided that everyone should go Agile.
			Quite the opposite: it was something that was <em>pulled</em> by developers rather than <em>pushed</em> at
			them.</p>
		<p>In cases like this, companies should be focusing on developing people, including good leaders, instead of
			particular initiatives and processes. Leaders in turn should shift their focus from details to more
			high-level decisions. When it comes to facing changes, leaders should look at the <a
				href="http://www.bbrt.org/beyond-budgeting/bbprinc.html">12 principles</a> of the <a
				href="http://www.bbrt.org/"><span class="caps">BBRT</span></a> leadership model.</p>
		<p>The final portrait, <em>Leaders at all Levels</em>, well summarizes the key to successful leadership:
			<q>leadership is about example, coaching and helping others to achieve their goals</q>.</p>

	</section>
	<section class="section">
		<header>
			<h1 id="h_8" class="toc">Final Thoughts</h1>
		</header>
		<p>If you&#8217;re looking for a manual on implementing Lean Software Development in detail, this is probably
			not the best book on the subject. If you&#8217;re a developer at the start of your career, with no
			management responsibilities, you&#8217;d want more technical juice, so probably you should read the other
			two books by the Poppendiecks on the subject first.</p>
		<p>On the other hand, if you have been working in IT for a few years, and maybe you already started to climb up
			the corporate ladder, reading this book could make the difference between being successful leader or not.
			This book does not go very in-depth with any particular methodology or process, but it does provide an
			excellent overview of a lot of them.</p>
		<p>To get the best out of <em>Leading Lean Software Development</em>, you should read it a least once
			sequentially, skipping the parts that are not relevant to you (right now), taking notes on the more
			interesting frames, and then go back over them to digest them properly. Do <em>not</em> skip the
			introduction of each chapter though, for one because they are always pleasant to read between frames, and
			also because they do teach some very important values or strategies that you <em>must</em> assimilate.</p>
		<p>The general message that stands out when reading this book is <em>focus on people</em>. Customers, of course,
			but also employees: every single successful company mentioned in this book, from Toyota to Southwest
			Airlines, became successful because they always focused on developing people <em>first</em>, and
			<em>then</em> products.</p>

	</section>

</section>