Agile Project Management: Creating Innovative Products

Author: Jim Highsmith Format: Paperback, 432 pages Publisher: Addison-Wesley Professional; 2nd edition (July 20, 2009) ISBN-10: 0321658396 ISBN-13: 978-0321658395 I'm at a slight disadvantage in not having read or reviewed the first edition of this book. Based on the reviews of the first edition though, it seems to have been very successful with its readership. This second edition is touted to have been updated with newer techniques for larger projects. I can only imagine that was some of the feedback from people who liked the previous incarnation, but wanted to apply it to broader contexts. We'll see how this edition presents to the first time reader. This book is part of the publisher's Agile Software Development Series. That means, while this book can stand on its own, it is part of a larger body of information regarding agile development in general. The target of this book, is the application of agile development to product development. That would seem sort of like a "duh", since the idea of the agile process in general, is to become more effective at developing applications as products. I imagine however, that this book is specific to the "nuts-and-bolts" of Agile in the real-world environment, as opposed to pure "theory". There doesn't seem to be a way to read or review this book without mentioning the connection to the Agile Alliance. Author Jim Highsmith "is a founding member of the Agile Alliance, co-author of the Agile Manifesto, and director of the Agile Project Management Advisory Service for the Cutter Consortium", according to his bio on the book's back cover. Like most technical books, the author has leveraged his "day job" heavily to produce the book now sitting beside my keyboard as I create this review. In fact, this "leveraging" has been infused into virtually every part of Highsmith's text. My first piece of advice is "hands off" this book, if you don't have the faintest idea about software development in a production environment. Maybe I'm being too harsh, but if you are the casually curious sort, who thinks it would be "cool" to learn about Agile, you may find yourself in way over your head, if you tackle this book cold. I can see Highsmith's text being more aimed at the development team at my day job, since portions of this book remind me of conversations I've had with some of the programmers there. This book is best used by an individual or group, that has a business need to develop or enhance an Agile process in a production environment (and if, at this point, you need to ask what Agile Software Development is, take some time, do some research, and come back when you're ready). Despite the nuts-and-bolts promo, Chapter 1 does start out at a high level, explaining concept and process. The Agile Alliance and Agile Manifesto are referenced heavily, as are some practical business examples. Agile is presented both as a process and as a movement in this chapter, and the reader who is part developer and part business manager will have the greatest ability to benefit from the material. The book operates like a set of building blocks, constructing the structure of Agile, one chapter at a time. Don't look for a quick fix or speedy reference guide here. This book is meant to be read cover-to-cover, consumed like a multi-course meal. Nothing can be skipped, particularly if you develop software products and are serious about integrating Agile into your world. Each chapter ends with a "Final Thoughts" section, summarizing the content. The content itself is hardly what you'd call "entertaining" (some books are written that way), so I recommend not only a strong interest in this topic, but reading it while your mind is alert, or at least fully caffeinated. On the other hand, each chapter begins with a hypothetical conversation between two project managers, so Highsmith does provide a more personal element for your consideration. The "Principles to Practices" section in Chapter 4 got my attention, because that's what this book is all about, and not just regarding the development of a software product. Agile is as much about people and teams as it is about what they create. In fact, it's all about the flow of information and activity between the different groups and stakeholders in the process. I was very appreciative of how the book took time to describe and illuminate the interaction between the products, the players, and the principles of Agile development. While on the one hand, I experience this book as well rounded, on the other hand, and I've mentioned this before, it has its biases. That isn't bad, but it does mean that not everything Agile is included. Agile Project Management (APM) is greatly emphasized as a framework, but that means other Agile frameworks aren't available in this text. The book teaches its own flavor and brand, rather than a truly generalist approach. This particular "brand" may or may not work for any given reader's particular business needs or organization. Of course, that's like saying, Microsoft Windows may not be a good fit for a particular company's business model (and it may not). Biasing content isn't to be avoided. Just be mindful that you're looking at only one neighborhood in a larger community. I suppose that's why this book is part of the Agile Software Development Series. The prudent reader will want to sample other series items. Some months ago, I reviewed O'Reilly's The Art of Lean Software Development which, if you don't feel up to Highsmith's book at the moment, might be more appropriate as an introduction of both theory and practice. That said, project and development team managers should be well-positioned to take advantage of the wisdom and experience presented in Agile Project Management, as a way of garnering a better understanding of Agile methodologies in project management.

Review: The Art of Lean Software Development: A Practical and Incremental Approach

Authors: Curt Hibbs, Steve Jewett, and Mike Sullivan Format: Paperback, 142 pages Publisher: O'Reilly Media, Inc.; 1st edition (February 2, 2009) ISBN-10: 0596517319 ISBN-13: 978-0596517311 What is Lean Software Development? Fortunately, that's an OK question to ask if you are reading this book. It's not written for developers who are well versed in "lean" or "agile" development. That's good for the rest of us. For instance, in my "day job" we are slowly moving towards a more Agile development model. I suppose if some folks around here weren't all that sure what "agile" meant, reading up on it would be helpful. That's the sort of role this book hopes to fill relative to "lean", with the understanding that the "pro-lean subculture" is well associated with Agile development. The book is lean. I mean that in the plain meaning of the word. It's a short book at only 142 pages and each of its nine chapters is less than 20 pages long. The idea, according to the Preface, is to avoid "padding our chapters with useless fluff". Like a string held taught between two tin cans or a tightly focused laser beam, the book attempts to describe the shortest distance between two points; between start and destination. Actually, the last sentence in the last chapter states, "Remember, Lean is a journey, not a destination", so I guess my review is already somewhat inaccurate. "Lean" then is the string or the laser beam. As you may have guessed by now, the process of Lean development is to make software development..."lean". That is, it's what government is always proposing to do; to use less resources and produce superior results more effectively (I'll avoid my usual commentary on the whole "stimulus package" theory of "lean" or "anti-lean" in its case). The first chapter in the book establishes why lean is a good idea and where it came from. In order for you to be interested in the book, the authors must first sell the reader on the desirability of lean development. The use of the term "subculture" a few paragraphs back was not really a euphemism. Lean development even has it's own "glossary" of sorts, which is also presented in Chapter 1. Like any philosophy, it comes with it's own "mindset" and "world view" relative to software development (and beyond). Considering its Japanese origins, the ideal of group cooperation in any endeavour is both espoused in the lean development vision and within the pages of this book. Certainly the authors wrote their book with that philosophy in mind and it makes sense. The short definition of Lean development is to reduce a series of tasks to the simplest set of steps possible. Why use two words to say something when you can do it with one? At the same time, accuracy and making the product work can't be sacrificed for the sake of simplicity of design or speed of delivery. It's interesting that one of the values of Lean development is respecting people (which is also a very Japanese value). You wouldn't normally think of the humanity of software development, but coders are human too, as are the rest of the employees of any software development outfit, and as well as their customers. That also works (at least in theory) across the boundaries between management and line staff; hiring people who know what they're doing and then trusting that they'll do their jobs. I know a few "micromanagers" who could benefit from reading at least this part of the book (no one I've worked for recently, thankfully). At this juncture (or before), you may have asked yourself, "What's the difference between agile and lean"? Apparently, not much, according to the authors, at least on the surface of the goals. Both philosophies and methods claim to do what all managers want to do with their companies; make a superior product more efficiently, using less time, personnel, and money. The underlying "mindset" is where the two paths diverge. Agile is more focused around the specific process of software development, while Lean casts a wider net and includes software development within the larger business context. The book functions as a beginner's primer on Lean software development, describing the philosophy and basic design of Lean development. It's not easy to describe a philosophy using a lean process since the concept of philosophy tends to be somewhat long winded (not unlike myself). The book is sprinkled with little real-life examples, like bread crumbs, from the lives of the authors, briefly illustrating the points to be made along the trail of the book's pages. That's good, because such content doesn't easily lend itself to longer tomes, such as the 430 pages of Shore and Warden's The Art of Agile Development (it's a good book, but you have to really want or need to read it). The benefit of the last chapter, "What's Next?" is that it allows the book to be "lean" and at the same time, doesn't leave the reader hanging in mid-air. Actually, it's the resources listed in the Appendix that shows the reader the roadmap to the next part of the territory, based in the book's bibliography. Despite the "Using Code Examples" section in the Preface, this is a book about concept and not about mechanics. In other words, there are no code examples and no supplementary website for the book. The book is a brief template to be applied to your actual practice, not the practice itself. I can take philosophy in limited doses before I must return to my bolts and my wrenches. Fortunately, Hibbs, Jewett, and Sullivan had people like me in mind when they wrote this book. If you are a manager who is considering moving to a more focused software development model and is wondering if "lean" is for you and your company, it wouldn't hurt to have your first introduction to Lean software development be The Art of Lean Software Development: A Practical and Incremental Approach. At least you will find out fast if you want to explore that path more completely after sailing through the book.