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.

Beautiful Architecture: Leading Thinkers Reveal the Hidden Beauty in Software Design

Editors: Diomidis Spinellis and Georgios Gousios Format: Paperback, 426 pages Publisher: O'Reilly Media, Inc.; 1st edition (January 29, 2009) ISBN-10: 059651798X ISBN-13: 978-0596517984 According to Wikipedia, Software Architecture is "the structure or structures of the system, which comprise software components, the externally visible properties of those components, and the relationships between them". Probably, if you need to go to Wikipedia to read the complete definition and background of Software Architecture, you aren't ready to buy this book, but let's see. According to the editors (multiple contributors provided numerous essays for the book's content), Beautiful Architecture is a direct relative to the 2007 O'Reilly book Beautiful Code. Andy Oram and Greg Wilson provided the editing for that work, but the formatting and much of the purpose is identical to the book I'm now reviewing: to allow well-known and not-so-well-known, but innovative software architects to offer their insights in describing their ideas on the process of software architecture. The scope of course, is different; wider and sometimes, less focused than you might imagine. Contributors are given more latitude than authors of technical works are normally provided. The editors and publishers provide the framework, the "architecture" if you will, but each contributor provides his or her (actually, just "his") own vision. Surprises are at least tolerated if not welcomed. Beautiful Code was reasonably well received so it is up to Spinellis and Gousios to provide a text worthy of its predecessor. In terms of the breadth of topics, I think it does quite well. After all, architectures touched upon include Xen, Emacs, and Facebook. If you like variety in the extreme, this book will work for you. But who should read this book? The front matter doesn't provide an answer. The first chapter, written by John Klein and David Weiss, is called "What is Architecture?", so the book does start at the "beginning". The contributors explore what an architecture is, not simply in terms of software and not just with building architecture. Metaphor is the language of this chapter, and the authors of provide sufficient connections to different people from different backgrounds and who use varied methods of conceptualization, in order to describe what an architecture is. An architecture is a framework, skeleton, or context, designed to contain and to define its contents and the purpose of those contents. Otherwise, what you have is a jumble of information, much like a collection of random musical notes without the structure, or a bunch of bricks without a design...or like a collection of essays without a common theme. However, defining architecture is just the beginning. Chapter 2 moves from metaphor to allegory with the article "A Tale of Two Systems: A Modern-Day Software Fable". Actually, the way architecture is described by Pete Goodliffe is in terms of city design (roads, neighborhoods, and so on). Each chapter thus, is an example not only of a principle or conceptualization of software architecture, but of how the authors perceive both the general topics and specific problems associated with the architectural issues at hand. The personality and style of each contributor becomes just as important as the subject they are addressing, since those factors determine what they see as important to communicate. This sort of book can be difficult to review because it isn't a single "thing". Most technical books are written with one vision and one purpose and usually, with one voice, even when there are several authors involved. Reading Beautiful Architecture is much like reading an anthology of works from different classic authors and poets. While there is a loosely associated theme, each essay has its own voice and its own personality. Reading this book in a linear fashion is not particularly useful, depending on your goal. Certainly starting with the first part of the book works if you know little or nothing about software architecture in general, but then again, I don't think this should be your first exposure to the topic. That's not a slam against the book, but it takes some previous exposure to the idea of software architecture to begin to provide the reader with the internal structure necessary to make sense of what's being said. I suppose the best analogy I can use is that one must understand basic art theory before attempting to evaluate masterpieces, or before determining if a work is or is not a masterpiece. By definition, the book is inconsistent. That's what happens when you hire almost 20 different singers to provide their interpretations as to "what is music?". Like art and music, you take away from this book what you need or at least, what you can. That means, I can't tell you that everyone who wants to learn more about software architecture will either love or hate this book. Some of you will think it's a glorious production while others will barely be able to tolerate it. Like Beautiful Code the concept is wonderful, but "pulling it off" is problematic. I think the book works best for the seasoned veteran who is expert in his or her field but is looking for new and different perspectives. When you are that good at something, sometimes, you get locked into your vision and have a tough time seeing architecture from different and particularly radical points of view. If you are newer to software development, you can still gain some good insights from the book, but depending on how linear or global a thinker you are, you can either gather new directions for your craft or learn to become completely confused. I suppose it would be like my anthology analogy where you might like one or two of the contributions to the book but overall, find the entire text disjointed and disconnected. Just as each author's personality is an integral part of their essay, the personality and needs of the reader are a required ingredient in providing the cement that holds each particular article together with the book as a whole.

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.