I just finished reading Agile and Iterative Development: A Manager’s Guide by Craig Larson. I am extremely impressed with the amount of meat in the book on Agile methods and how succinctly this information is expressed.

Normally when you look for books on these kinds of subjects for managers, you find a lot of fluff and no real information. Not true with this one. The book starts out with a chapter talking about how software development over the years has been treated much like a factory production line, where everything can be predictably planned, rather than being treated as it should be — as new product development. New product development differs in that you are creating something brand new and do not quite have all the answers yet, so you plan differently than you do making a widget. The process isn’t predictable, because it hasn’t been done before. Now, this is a no brainer to anyone who has actually played a design or development role on a project, but it is traditionally very hard to explain why you can’t quite tell someone how long a feature will take to code because we haven’t done it before. The first chapter of the book covers this subject very well.

Chapter 2 explains a lot of detail on what iterative and evolutionary development are, in ways that a manager can udnerstand it and see the financial benefits (and the people benefits if he is looking for it!). It talks about the evolutionary requirements gathering, evolutionary and adaptive planning, and gives an overview of the few agile methods explained in the book.

Chapter 2 ends with Craigs opinion of what the most common mistake is in application of agile methods to software development, which is one I’m sure we’ve all seen. Changing the names of the waterfall approach to your favorite “agile” name and doing the same thing we’ve always done, with a full blown project plan that details each iteration and everything. . He talks briefly about it here but covers it quite a bit later in the book. If you have tried to implement the UP in organizations before this will bring a smile to your face, as you will have seen Inception turn into requirements gathering, elaboration turn into design, construction turn into, well, constructions (development), and transition turn into deployment to a production environment. Its something most people who try to implement agile methodologies have seen at least once in an organization.

Chapter 3 explains the values built into most agile processes and gives an overview of the methods he will be covering through the rest of the book. The methods covered include:

• Scrum
• Extreme Programming
• The Unified Process
• Evo

Chapters 4, 5 and 6 cover the motivations and evidence for why agile methods exist and why they work better than the traditional waterfall method. Some of the most interesting things in these chapters are the references to government standards that originally started out supporting the waterfall method that later were revised to agile type methods. There is also some history in this section on the waterfall method and it’s “accidental” endorsement as the “right way to do things”. The interesting part about this one is that the definitive paper that describes the waterfall method was actually written to describe an iterative method that had only one iteration. From one misphrasing, the whole software development industry was thrown on it’s ear for decades!

The evidence chapter is also quite interesting, using project failures as the main driving measurement for why agile methods work and predictive methods do not. The chapter goes into a lot of detail here from a measurement perspective and when you are done reading it you never want to plan a 15 month project in detail in the first two weeks again.

Chapters 7-10 cover, in detail, the four agile methods listed above. These chapters are really good explanations of each method, the values that each methods hold, how they mesh with other methods, and the history of their development. These chapters are really interesting reading. For each method, the author goes through value differences with other methods and how each method may clash or be merged with others.

Finally, we get to Chapter 11, Practice Tips. The book goes through some implementation tips in the area of Project Management, Environment, Requirements Gathering, and Testing. The chapter takes common misconceptions and tries to give advice as to how to deael with them.

This book is an invaluable resource for those who need to explain why a move to an agile method of development is needed in an organization. The Evidence chapter in and of itself is worth the price of the book. The added benefit of having the definitions and practices of the individual methods in one book is also great. I highly recommend grabbing this book if you are trying to move your organization to agile development.

Along with being a great resource for helping you explain your position, there are things that are just funny. A lot of us have dealt with many of the arguments outlined in this book, and I know that I have thought that some of the conversations I’ve had could never happen anywhere else. It’s really affirming to know that they do and that the conversations you have about agile development are the same ones had all over the development world. The same goofy mistakes are made and the same misconceptions about what the process should or shouldn’t be are common across this industry.

If you get nothing else out of the book, you will get a sense of comfort knowing that you are not alone. All of the problems you are experiencing right now explaining why agile development is valid, and all of the problems you are having in the way it is applied happens everywhere.

Now you have a reference to help with those conversations that put it in terms even your manager can understand.