-----
title: "Book Review: Succeeding with Agile"
content-type: article
timestamp: 1272197788
tags: "review|productivity|books|software"
pdf: true
-----

<section class="section">
	<blockquote>
		<p>&#8220;This is not a book for those who are completely new to <em>Scrum</em> or <em>agile</em>. There are
			other books, classes, and even websites for that. If you are completely new to <em>Scrum</em>, start with
			one of those.&#8221;</p>
	</blockquote>
	<p style="padding-left:2rem;">&#8212; Mike Cohn, <em>Succeeding with Agile</em></p>
	<p>Great. That's just great. Good job I started with the <em>Introduction</em> first, otherwise the first
		chapters of this book would have been way too overwhelming!</p>
	<p><a href="http://www.succeedingwithagile.com/"><em>Succeeding with Agile</em></a> is a book that
		<em>doesn't</em> teach you about <em>Scrum</em> or <em>agile</em> methodologies, it won't give you a
		definition of ScrumMaster, sprint, or backlog&#8230; instead, it takes all that for granted and teaches how to
		pragmatically adopt &#8212; or better, <acronym title="Awareness, Desire, Ability, Promotion, Transfer"><span
				class="caps">ADAPT</span></acronym> to &#8212; <em>Scrum</em>, in the context of yourself, your team,
		and even your entire organization.
	</p>
	<blockquote>
		<p>&#8220;[&#8230;] this book draws on my experience with <em>Scrum</em> over the past 15 years, but especialle
			the last 4. For the last 4 years, every evening after I spent the day with one of my clients, I would go
			back to my hotel room and make notes about problems they were facing, the question they asked, and the
			advice I gave.&#8221;</p>
	</blockquote>
	<p>Indeed, this book is a gold mine of information, anecdotes, tips and tricks about everything you could possibly
		want to know about making <em>Scrum</em> work, at any level. If you have some knowledge about <em>agile</em>
		development you definitely have some questions: <em>will it work?</em> &#8230; <em>is it really more
			productive?</em> &#8230; <em>how can I make my boss understant this?</em>. This book has all the answers you
		need. Most definitely, it also answer questions you didn't think of.</p>
	<p>If you don't know what all this is about, then you'd better do your homework first:</p>
	<ul>
		<li><a href="http://www.mountaingoatsoftware.com/topics/scrum">Introduction to <em>Scrum</em> &#8211; An Agile
				Process</a></li>
		<li><a href="http://en.wikipedia.org/wiki/_Scrum__(development)"><em>Scrum</em> (Wikipedia Page)</a></li>
		<li><a href="http://www.scrumalliance.org/"><em>Scrum</em> Alliance</a></li>
		<li><a href="http://www.scrum.org/"><em>Scrum</em>.org</a></li>
	</ul>

	<section class="section">
		<header>
			<h1 id="h_1" class="toc">Overview</h1>
		</header>
		<img src="/images/pictures/succeeding-with-agile.jpg" style="float:left;" />
		<p>The book is organized into five parts of different length, ranging from 20 to over 100 pages. If you read the
			book from the start till the very end, you'll notice that the start of each part is like a new
			milestone in <em>Scrum</em> adoption: first the author makes sure that <em>you</em> are prepared (Part 1),
			then moves on to deal with individuals and initial resistance (Part 2), then teams (Part 3) and finally the
			whole organization (Part 4), until you can finally taste the fruits of you labor (Part 5).</p>
		<p>In a way, you may well want to carry this book in your briefcase every day you go to work, and read it bit by
			bit, as you make progress in your quest for <em>Scrum</em> adoption.</p>

		<section class="section">
			<header>
				<h1 id="h_2" class="toc">Part I: Getting Started</h1>
			</header>
			<p>Part I is about making sure you know <em>why</em> becoming gile is important and beneficial to you and
				your work environment. It will teach you how to promote <em>Scrum</em>, its advantages and challenges,
				and the different ways to go about it: Start Small or Go All In? Stealth or Public Display? Things like
				that. Pointless theory? Not really: everything is well documented, with success stories to support one
				way or the other.</p>

		</section>

		<section class="section">
			<header>
				<h1 id="h_3" class="toc">Part II: Individuals</h1>
			</header>
			<p>This part was very interesting from a psychological point of view: it deals with individuals and their
				possible reactions to becoming <em>agile</em>. You'll meet <em>skeptics</em>, <em>followers</em>,
				<em>saboteurs</em> and <em>diehards</em> &#8212; no hope? Well, of course not: you'll learn how to
				deal with each one of them in the best way possible. This part will also introduce you to new roles and
				responsabilities related to <em>Scrum</em>.
			</p>

		</section>

		<section class="section">
			<header>
				<h1 id="h_4" class="toc">Part III: Teams</h1>
			</header>
			<p>Up next, Teams. You're no longer dealing with single-minded individuals, but with more complex
				groups. New challenges emerge, mostly related to communication and people interactions. I particularly
				enjoyed <strong>Chapter 13 &#8212; The Product Backlog</strong>, which provides invaluable insights on
				this important everyday tool. <strong>Chapter 15 &#8212; Planning</strong> is another interesting read:
				it teaches you a lot about planning vs. estimating, and coming to compromises to meet deadlines.</p>

		</section>

		<section class="section">
			<header>
				<h1 id="h_5" class="toc">Part IV: The Organization</h1>
			</header>
			<p>If you made it up to here, then you're nearly done. You probably know most of the tricks by now,
				but there's still a lot to learn. <strong>Chapter 17 &#8212; Scaling <em>Scrum</em></strong> is
				definitely worth reading, even just for the analysis between <em>formal</em> and <em>informal
					communities</em>, while <strong>Chapter 19 &#8212;Cohexisting with Other Approaches</strong> almost
				feels heretical at times: mixing <em>Scrum</em> with Waterfall? Is that even conceivable? Yes. Sometimes
				it's the only way, especially when you have to deal with compliance to standards like ISO9001.
				Once again, the author has a nice success story on how a company passed an ISO9001 audit by providing
				documentation in form of photocopied notes and by adding a single failing test to persuade the auditor
				that the automated test suite was not rigged. Priceless.</p>

		</section>

		<section class="section">
			<header>
				<h1 id="h_6" class="toc">Part V: Next Steps</h1>
			</header>
			<p>Only two chapters in this part of the book, which mainly deals with (self) assessment and progress
				analysis. Still worth a read, but you can safely leave it out for when you succeeded with
				<em>agile</em>.
			</p>

		</section>

	</section>

	<section class="section">
		<header>
			<h1 id="h_7" class="toc">Technical Analysis</h1>
		</header>
		<p>I'm not exaggerating when I say that this is <em>by far</em> the best book I've read in the past
			few years when it comes to the way it is organized. Start by reading the <a
				href="http://my.safaribooksonline.com/9780321660534?portal=informit">table of contents</a>: if you take
			each chapter out and make a bulletted list of each section you'll end up with a handy (and free!)
			cheat sheet on how to promote and adopt Agile methodologies.</p>
		<p>This doesn't mean the book isn't a worthwhile read, but rather that it can also be used as a
			reference when needed.</p>

		<section class="section">
			<header>
				<h1 id="h_8" class="toc">Formatting and Readability</h1>
			</header>
			<p>From a technical writing point of view, this book is spotless. I should keep it on my desk to remind me
				how technical documentation should be written, except that&#8230; it's not a technical manual of
				course. But the formatting and the way content is laid out can make the most skilled technical writer
				very jealous: there's never a huge blob of boring text, never a series of pointless pictures: Mike
				Cohn (or his editors) did a terrific job composing this book.</p>
			<p>You can start reading it from any point and it still makes sense, diagrams are simple and clear, and yet
				extremely useful, and so are the reference tables and spreadsheets. They never hurt, they are always in
				the right place, at the right time. And bold text is aptly used at the start of list items, so that even
				if you skim through the key concepts will still make it to your brain. Excellent.</p>

		</section>

		<section class="section">
			<header>
				<h1 id="h_9" class="toc">Style and Contents</h1>
			</header>
			<p>Reading this book is like listening to a seminar hold by some charismatic icon like <a
					href="http://en.wikipedia.org/wiki/David_Allen_(author)">David Allen</a> or <a
					href="http://en.wikipedia.org/wiki/JoAnn_Hackos">JoAnn Hackos</a>: you never get bored, and you
				constantly learn something. Mike's informal and conversational style is one of the main reasons
				why you should read this book instead of others on the subject: he is a great communicator, and he knows
				how to make his point across.</p>
			<p>As an added value, Mike also uses two types of <em>boxes</em> throughout the book:</p>
			<ul>
				<li><strong>Things to try now</strong> &#8212; Whenever a new strategy or practice is introduced,
					you'll find one of these boxes containing a bulleted list. <em>&#8220;Commit to running the
						next two or three sprints without any overtime&#8221;</em>, &#8220;Do you understand what
					motivates every other person on your team? If not, find out. How? Ask them.&#8221;, &#8230; these
					are just examples of some of the author's reccommendations to put you in the right track.</li>
				<li><strong>Objection</strong> &#8212; Either actual quotes from customers and employees, or possible
					statements which may come out throughout the process of adopting <em>Scrum</em>. Things like
					<em>&#8220;If the product includes less than what we've planned, no one will buy
						it&#8221;</em>, or <em>&#8220;My team won't self organize; team members are too passive
						and look to me to lead&#8221;</em>, &#8230; of course, what makes these objection boxes valuable
					is not the statement themselves, but the tips on how what to do about them. There's not a
					single one left unanswered: you really feel you're covered in any situation.
				</li>
			</ul>

		</section>

	</section>

	<section class="section">
		<header>
			<h1 id="h_10" class="toc">Final Thoughts</h1>
		</header>
		<p>I really enjoyed this book. It took me ages to read it, not only because it's quite long (450 pages),
			but also because it's very dense of information. Another author could have made it three times longer,
			but I was glad Mike didn't. I'm pretty certain I'll keep it near me and read bits from it
			when I need to: it's pretty much the Bible of <em>Scrum</em> adoption.</p>
		<p>What's wrong with it then? Not much. Perhaps the only thing I really missed was an introductory
			50-page-chapter on <em>Scrum</em> and <em>agile</em>. I know this is not meant to be a book for beginners,
			but some basic glossary or <em>Scrum</em> cheat sheet would have made it accessible to an even wider
			audience, at virtually no cost for the author or the readers, who could have just skipped that part.</p>
		<p>Anyhow, I give it a 9 out of 10.</p>

	</section>

</section>