contents/articles/reflections-on-management.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 |
----- title: "Book Review: Reflections on Management" content-type: article subtitle: "The key to becoming a true leader" timestamp: 1296942685 tags: "review|books|software" pdf: true ----- <section class="section"> <p>When I was offered to review this book, I was a bit skeptical: a book on <em>management</em>? I normally read and review books on programming and software development methodologies. However, I work as a Documentation Technical Leader, and while I don’t technically <em>manage</em> a whole team yet (damn economic crisis!), someday I may end up doing just that, so I gave <a href="http://www.informit.com/store/product.aspx?isbn=032171153X">Reflections on Management</a> a try.</p> <p><em>It’s short, after all, I’ll probably read it in a couple of weeks and move on</em> — I thought. Well, beware of short books: I thought exactly the same thing when I picked up <a href="http://en.wikipedia.org/wiki/The_Elements_of_Style">The Elements of Style</a>, and it still follows me around everywhere, so that I can re-read bits of it whenever I need to.</p> <p>This short but dense masterpiece by Watts S. Humphrey and William R. Thomas is one those books you always end up carrying around in your pocket (or stored in your favorite ebook reader). It’s a short but very dense collection of tips and tricks to succeed as a leader and a manager — of <em>anything</em>: <q>Your Software Projects, Your Teams, Your Boss, and Yourself</q>, as the book subtitle says. It doesn’t “just” help forging great managers and leaders, it also explains, with practical examples and no-nonsense explanations, how to deal with those annoying people in suits who constantly keep asking you for impossible things…</p> <section class="section"> <header><h1 id="h_1" class="toc">About Watts S. Humphrey</h1></header> <p>Generally, I don’t bother writing anything about the authors in my reviews: you can easily find this kind of information online if you want to. I’ll make an exception in this case, you’ll understand why as you read along.</p> <p><a href="http://www.sei.cmu.edu/watts/index.cfm?WT.ac=watts">Watts S. Humphrey</a> was a true legend in Software Engineering, he’s often referred to as <em>The Father of Software Quality</em>. He worked at <span class="caps">IBM</span> for 27 years and eventually became Vice President of Technical Development. In the 80s, he arrived at the <a href="http://www.sei.cmu.edu/">Software Engineering Institute (<span class="caps">SEI</span>)</a> where he developed some key development processes of our time: the Software Capability Maturity Model (<span class="caps">CMM</span>), the Personal Software Process (<span class="caps">PSP</span>), and the Team Software Process (<span class="caps">TSP</span>). He received many awards, culminating with the <em>National Medal of Technology</em> in 2005.</p> <p>He wrote several books focusing mainly on software development and managing software projects through his <span class="caps">PSP</span> and <span class="caps">TSP</span> methodologies. <em>Reflections on Management — How to Manage Your Software Projects, Your Teams, Your Boss, and Yourself</em> was the last book published while he was alive. <a href="http://www.informit.com/title/0321624505">Leadership, Teamwork, and Trust: Building a Competitive Software Capability</a>, co-authored with James W. Over, was published posthumously.</p> <p>Watts S. Humphrey <a href="http://www.sei.cmu.edu/newsitems/Humphrey_obituary.cfm">died</a> on October 28, 2010.</p> </section> <section class="section"> <header><h1 id="h_2" class="toc">Structure and Organization</h1></header> <p>In many ways, <em>Reflections on Management</em> can be seen as the <em>summa</em> of Humphrey’s work on <span class="caps">PSP</span>, <span class="caps">TSP</span> and management of software projects, condensed in a very readable 288-page-book, co-written with <a href="http://www.sei.cmu.edu/about/people/wrt.cfm">William R. Thomas</a>, Senior Technical Writer and manager of SEI’s Technical Publications Team.</p> <p><img src="/img/pictures/books/reflmgmt.jpg" style="float:right" /></p> <p>I noticed the tech writer’s touch simply by flicking through the pages of the book when I first got it: its structure is impeccable.</p> <p>Organized into four parts, totalling 8 chapters, an Epilogue and an Appendix, this book is a prime example of order and readability: pick any section title (just the title) of any section in any chapter, and you get a clear idea of their content and purpose, and a key principle of management. Examples? Sure:</p> <ul> <li>Chapter 8: Learning to Lead <ul> <li>8.1 How You Behave Affects Your Team</li> <li>8.2 Leaders Set an Example for Their Teams</li> <li>8.3 Learn to Avoid the Symptoms of Poor Leadership</li> <li>[…]</li> </ul></li> </ul> <p>If you print the Table of Contents alone you get a priceless cheat sheet on management and leadership. If you want slightly more detail, each chapter contains a summary table of all its sections, with a two-line summary of its contents. There are no subsections, only first-level sections, which make the book much easier to understand and “digest”.</p> <p>You can read it all at once, then you should keep it readily available for consultation. It will take you only a few seconds to look through the contents and pick the most relevant section in a time of need.</p> </section> <section class="section"> <header><h1 id="h_3" class="toc">Writing Style</h1></header> <p>The book is very clear and simple to read, always. Each section is self-contained, and always aims to make a point, usually expressed right in its title. If I were to find a common pattern in most of the chapters of this book, it would be the following:</p> <ol> <li>Identification of the problem – a particular situation or aspect is described in a way that problems are self-esplanatory.</li> <li>Labeling and classification – the situation is analized and often a set of causes are presented to the reader, often labeled or classified.</li> <li>List of possible solutions – a list possible solutions is presented to the reader, often as a definition list.</li> <li>Solution details – more details are provided to prove the effectiveness of the solution, often including personal anecdotes.</li> </ol> <p>By doing so, the author makes sure that everything he writes about can be easily understood and accepted, because proven by personal experience.</p> </section> <section class="section"> <header><h1 id="h_4" class="toc">Contents</h1></header> <section class="section"> <header><h1 id="h_5" class="toc">Part I: Managing Your Projects</h1></header> <p>The book starts with a general introduction on Software Quality. If you are new to the subject (and you <em>shouldn’t</em> be), this is probably one of the best and to-the-point overviews you’ll ever find, written by the man who almost came up with the concept.</p> <p>The second chapter is about planning. Actually, the whole book is about planning at different levels, so no, you should not dismiss this part. <em>Good</em> plans are important, and they are your best weapon against management, if you excuse the expression.</p> <p>Someone may object that if you’re working in an <em>agile</em> team, you shouldn’t spend a lot of energy in long-term planning, but rather focus on dealing with frequent requirement changes and deliver often and regularly. While this can be true, planning is still important: you won’t produce any rigorous schedule or design documents, but you still have to be able to provide accurate estimates and very often!</p> </section> <section class="section"> <header><h1 id="h_6" class="toc">Part II: Managing Your Teams</h1></header> <p>The second part of the book focuses the <em>Team</em>, the people in it, their roles, their responsability and its leadership. Chapter 3 introduces Tom DeMarco’s concept of <em>Jelled Team</em>, i.e. a team that is more than the sum of its parts, and is characterized by cohesion, challenging goals, frequent feedback, a common working framework and good communication.</p> <p>The Holy Grail. The dream of every team leader and its members. The good news is, it can be done. Any team can jell, and teams <em>like to jell</em> furthermore, if the proper conditions exist, and the three chapter in this third part will teach you everything from being a good team member to becoming a great team leader.</p> <p>In many ways, this was my favorite part of the book. It’s amazing how a lifetime of experience is distilled in just a few pages. Chapter 5 (Leading and Coaching your Teams) is very, very inspiring and very helpful in understanding how to become a good team leader, how to motivate and involve people, and how to manage them rationally.</p> <p>The story of Humphrey’s high school wrestling coach Umbach is a classic example of a truly dedicated, inspiring, and successful leader:</p> <blockquote>“The workouts were so tough that the matches seemed easy. By the end of the year, several of us were undefeated, the team took the 13-state championship, and we were campus heroes. All of this from a ragtag bunch of inexperienced recruits. It was Coach Umbach who made the team.<br /> <br /> Our coach’s dedication, commitment and energy were amazing, but what I found most inspiring was that he really cared about how each of us did. I have always remembered how he made a small band of raw recruits into a championship team and how he fostered the kind of cohesive team spirit that made losing simply unthinkable."</blockquote> </section> <section class="section"> <header><h1 id="h_7" class="toc">Part III: Managing Your Boss</h1></header> <p>The third part consists of a single chapter: <em>Negotiation your projects and defending your plans</em>. It doesn’t matter if you want to pretend otherwise: as soon as you become a team leader and you have to deal with management, you’ll have to deal with complex internal politics.</p> <p>This chapter is about learing to be pragmatically diplomatic and deal with management. It’s about creating good plans that can survive confrontation with your managers, no matter what their demands are.</p> <p>There’s no silver bullet: I appreciated the honesty of the author when providing solutions. Section 6.6 (What to do when a project is doomed) is an example of this:</p> <blockquote> <p>You’re on a project and it’s headeing south. While everubody is trying their hardest, and you’re doing your level best to help, you can feel it in your bones: the project is doomed to fail. What can you do? You have three choices.</p> <ol> <li>Keep plugging away and hope things will improve.</li> <li>Look for another job.</li> <li>Try to fix the problems.</li> </ol> </blockquote> <p>That’s right. Look for another job. That almost made me laugh, but it made me understand that in some extreme situation that may just be the best solution.</p> </section> <section class="section"> <header><h1 id="h_8" class="toc">Part IV: Managing Yourself</h1></header> <p>The last part of the book is about you. I would probably have moved it earlier on in the book, maybe right after the first part, but it serves as a good ending for the book. Chapter 7 (Taking Control of Your Work) is a must-read for anyone. It teaches you how to manage your working life, from time management (The 18 Hour Work Week) to psychological aspects (What Do You Want From Life?).</p> <p>Chapter 8 (Learning to Lead), is a nice writeup on the essence of Leadership, and what it measn to be a good leader rather than a manager. A great read.</p> </section> </section> <section class="section"> <header><h1 id="h_9" class="toc">Final Thoughts</h1></header> <p>Reading certain sections of this book felt a little bit weird at first. <span class="caps">TSP</span>, <span class="caps">PSP</span>, heavy planning and documents… are they still relevant in a “real world” now dominated by <em>agile</em> practices, Scrum, Kanban and similar? Do you really have to provide detailed plans and documentation to convince management?</p> <ul> <li>You may not have detailed design documents, but you still have user stories.</li> <li>You may not be required to plan ahead of 6 months, but you still have to plan frequently and provide accurate estimates.</li> <li>You may not be required to trace and track everything you do, but at the very least you have to monitor your <em>velocity</em> and produce <em>burndown charts</em>.</li> </ul> <p>Yes, you read “<span class="caps">PSP</span>” and “<span class="caps">TSP</span>” everywhere in the book, but they are just labels. The methodologies and processes may change, but <em>the principles</em> will always remain true. This book is about understanding the very essence of management and leadership, and it will remain an invaluable resource for anyone who wants to build a career in the Software Industry.</p> </section> </section> |