contents/articles/succeeding-with-agile-review.html
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 |
----- title: "Book Review: Succeeding with Agile" content-type: article timestamp: 1272197788 tags: "review|productivity|books|software" pdf: true ----- <section class="section"> <blockquote> <p>“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.”</p> </blockquote> <p style="padding-left:5em;">— 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… instead, it takes all that for granted and teaches how to pragmatically adopt — or better, <acronym title="Awareness, Desire, Ability, Promotion, Transfer"><span class="caps">ADAPT</span></acronym> to — <em>Scrum</em>, in the context of yourself, your team, and even your entire organization.</p> <blockquote> <p>“[…] 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.”</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> … <em>is it really more productive?</em> … <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> – 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> — 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 — The Product Backlog</strong>, which provides invaluable insights on this important everyday tool. <strong>Chapter 15 — 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 — 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 —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… 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> — Whenever a new strategy or practice is introduced, you’ll find one of these boxes containing a bulleted list. <em>“Commit to running the next two or three sprints without any overtime”</em>, “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.</li> <li><strong>Objection</strong> — 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>“If the product includes less than what we’ve planned, no one will buy it”</em>, or <em>“My team won’t self organize; team members are too passive and look to me to lead”</em>, … 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> |