----- 
:type: article
:tags: 
- review
- productivity
- books
- software
:permalink: succeeding-with-agile-review
:title: "Book Review: Succeeding with Agile"
:summary: "A review of Mike Cohn's Succeeding with Agile. Possibly one of the most well-organized technical books I came across."
:toc: true
:pdf: true
:date: 2010-04-25 14:16:28.099000 +02:00
-----
&:[book|_Succeeding with Agile_]
&:[author|Mike Cohn]
&:[url|http://www.succeedingwithagile.com/]
&:[S|_Scrum_]
&:[ag|_agile_]
&:[links|
* =>[http://www.mountaingoatsoftware.com/topics/scrum|Introduction to &[S] - An Agile Process]
* =>[http://en.wikipedia.org/wiki/\/&[S]_(development)|&[S] (Wikipedia Page)]
* =>[http://www.scrumalliance.org/|&[S] Alliance]
* =>[http://www.scrum.org/|&[S].org]
]
&:[l_book|=>[&[url]|&[book]]]
%:[=pt|
	interpret %{section[@title[Part #{param(0)}: #{param(1)}]
		txt[#{param(2)}]
	]}
=]
--[-----------------------------------]
textile[
bq. "This is not a book for those who are completely new to &[S] or &[ag]. There are other books, classes, and even websites for that. If you are completely new to &[S], start with one of those." 

p(((((. -- &[author], &[book]

Great. That's just great. Good job I started with the _Introduction_ first, otherwise the first chapters of this book would have been way too overwhelming!

&[l_book] is a book that _doesn't_ teach you about &[S] or &[ag] methodologies, it won't give you a definition of ScrumMaster, sprint, or backlog... instead, it takes all that for granted and teaches how to pragmatically adopt -- or better, ADAPT(Awareness, Desire, Ability, Promotion, Transfer) to -- &[S], in the context of yourself, your team, and even your entire organization.

bq. "\[...\] this book draws on my experience with &[S] 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."

Indeed, this book is a gold mine of information, anecdotes, tips and tricks about everything you could possibly want to know about making &[S] work, at any level. If you have some knowledge about &[ag] development you definitely have some questions: _will it work?_ ... _is it really more productive?_ ... _how can I make my boss understant this?_. This book has all the answers you need. Most definitely, it also answer questions you didn't think of.

If you don't know what all this is about, then you'd better do your homework first:
&[links]
]

section[@title[Overview]

image[@style[float:left;]$[site.root]/img/pictures/succeeding-with-agile.jpg]
txt[

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 &[S] adoption: first the author makes sure that _you_ 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).

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 &[S] adoption. 
]

	pt[I|Getting Started|
Part I is about making sure you know _why_ becoming gile is important and beneficial to you and your work environment. It will teach you how to promote &[S], 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. 
	]	 --[End of part I]

	pt[II|Individuals|
This part was very interesting from a psychological point of view: it deals with individuals and their possible reactions to becoming &[ag]. You'll meet _skeptics_, _followers_, _saboteurs_ and _diehards_ -- 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 &[S].
	] --[End of part II]

	pt[III|Teams|
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 *Chapter 13 -- The Product Backlog*, which provides invaluable insights on this important everyday tool. *Chapter 15 -- Planning* is another interesting read: it teaches you a lot about planning vs. estimating, and coming to compromises to meet deadlines.

	] --[End of part III]

	pt[IV|The Organization|
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. *Chapter 17 -- Scaling &[S]* is definitely worth reading, even just for the analysis between _formal_ and _informal communities_, while *Chapter 19 --Cohexisting with Other Approaches* almost feels heretical at times: mixing &[S] 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.

	] --[End of part IV]

	pt[V|Next Steps|
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 &[ag].

	] --[End of part V]
] --[End of Contents section]

section[@title[Technical Analysis]
txt[
I'm not exaggerating when I say that this is _by far_ the best book I've read in the past few years when it comes to the way it is organized. Start by reading the =>[http://my.safaribooksonline.com/9780321660534?portal=informit|table of contents]: 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.

This doesn't mean the book isn't a worthwhile read, but rather that it can also be used as a reference when needed.
]

section[@title[Formatting and Readability]
txt[
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... 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. 

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.
]
]

section[@title[Style and Contents]
txt[
Reading this book is like listening to a seminar hold by some charismatic icon like =>[http://en.wikipedia.org/wiki/David_Allen_(author)|David Allen] or =>[http://en.wikipedia.org/wiki/JoAnn_Hackos|JoAnn Hackos]: 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. 

As an added value, Mike also uses two types of _boxes_ throughout the book:
* *Things to try now* -- Whenever a new strategy or practice is introduced, you'll find one of these boxes containing a bulleted list. _"Commit to running the next two or three sprints without any overtime"_, "Do you understand what motivates every other person on your team? If not, find out. How? Ask them.", ... these are just examples of some of the author's reccommendations to put you in the right track.
* *Objection* -- Either actual quotes from customers and employees, or possible statements which may come out throughout the process of adopting &[S]. Things like _"If the product includes less than what we've planned, no one will buy it"_, or _"My team won't self organize; team members are too passive and look to me to lead"_, ... 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.
]]

]

section[@title[Final Thoughts]
txt[
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 &[S] adoption. 

What's wrong with it then? Not much. Perhaps the only thing I really missed was an introductory 50-page-chapter on &[S] and &[ag]. I know this is not meant to be a book for beginners, but some basic glossary or &[S] 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. 

Anyhow, I give it a 9 out of 10. 
]
]