Customer Reviews

Agile Software Development: The Cooperative Game (2nd Edition)

5 star:		(5)
4 star:		(1)
3 star:		(0)
2 star:		(1)
1 star:		(0)

 

 

Cockburn emphasises a flexible approach to writing code, especially when you have a team of programmers. Unlike other approaches, like CMMI, the methodology advocated by the book seems deliberately informal. Now, certainly, the book does enumerate various steps typical in an agile approach.

For example, we see a list of methodology design principles. One of which is independent of whether you use Agile or not, and which especially caught my eye. It says that larger teams need heavier methodologies. There are several methodologies floating around in the IT industry. And Agile is only one of these. But that particular principle can be very useful. As the text explains, with 6 or less people, say, you can put them in one room, and have little or even no methodology. Because people can just talk and plan things together. But as teams get bigger, and they get dispersed over different rooms, buildings and cities, then you need more elaborate methodologies. And your choice need not even be Agile.

The book also has a writing style with lots of little side notes or anecdotes, that can help some readers assimilate the ideas in the main narrative.

The biggest problem to me with the book is its relatively uncritical acceptance of XP (Extreme Programming). It quotes that the first XP project was successful, in delivering results, compared to a larger team that had failed. But the first XP project that I am aware of, from another text, "Extreme Programming Refactored", was at Chrysler, and it failed to meet its deliverables. That book gave a far more plausible analysis of XP and its brittleness. Cockburn's text does allow that XP can have its limitations if the team gets too big. Because both admirers and critics of XP generally acknowledge that an XP team must intensively share knowledge and coordinate actions, and this just does not scale.

But if we put XP aside, then the Agile approach can be useful.

While I used to review current affairs books on Amazon until years ago, I've never reviewed a software/computer science book until now. I've been in software development for three decades and (like all of us) have owned and read countless books in the field, ranging from the abstract to nuts-and-bolts reference manuals. I have a strong theoretical background that nevertheless is firmly rooted in the reality of having to make a living in the field. So, working in a company that is trying to apply the Agile methodology, I approached this book with some openness to learning about underlying theory but ultimately expecting to learn enough to be able to apply it in a real-work environment.

Wrestling with this book for the last few weeks has been frustrating, to say the least. I was struggling to understand why, after reading on and on I wasn't able to summarize to myself the central message was of what I'd just read, and finding myself at a loss to see the thread in a chapter or see how the chapters built on each other.

I came here to see if others were having the same difficulty with it-- strangely surprised to see praise for quoting the philosophy of Wittgenstein and the still levels of Aikido. Looking back at the reviews of the first edition I found more critical opinions, and it was there that I finally understood why this text just didn't 'jibe' with me.

Paraphrasing another reviewer, he had it right I think describing this book as a text about the formalisms of methodologies. This is not a book about Agile per se, but about how Agile fits into the ontology of methodology. The problem is not that the book is too abstract-- I greatly admire Bjarne Stroustrup, for example, for his ability to use theoretical underpinnings in a practically useful way. The problem with this book is that it is not really about Agile but about 'methodology.'

Ultimately I think this is a book for a very specific audience. Is is probably a fantastic discussion point for those making a living talking about the theory of methodology-- but, unfortunately for me, it is going to be of very little use to a practicioner.

I picked this book up because of the Jolt Award. I was amazed as what I read. I give kudos to anyone who tries to apply game theory to their decision making process. This has grown to be the accepted way economists discuss decisions between agents, so why shouldn't we apply that to architecture or project decisions?
Still more kudos to any author who heavily references 'philosophy' and then correctly references a real contemporary philosopher (Wittgenstein)!
Sadly though, I would have loved to see cooperative game mapped out a bit more. The tools of game theory are there, so we should use them.
My favorite take aways: ShuHaRi analogy, Cooperative Game analogy, Selection of *implemented* project methodologies as starting points, and a methodology to create methodologies. All in All this is an excellent book to get you started in Agile or to bring you up to date with the 'why' questions of Agile.

The book is clearly written, easy to read, and supports people who want to move from either no understanding or an elementary understanding of the topic to a higher level of comprehension and application, from a rigid framework to "what works." This edition is expanded and updated from the first edition and is therefore more highly recommended.

This book is perfect, it tells you which are the key factors that influence the success of the whole team, what is working, what isn't and why. It's not just a "methodology description-like" book, it explains why to do things, it goes to very essence. For me the most useful was the recognizing of the human factor in sw development and the cooperative game theory, shu-ha-ri levels of seeing the world and I can continue and continue. I recommend it to everyone who wants to perform better in sw development area. It's my 3rd book from him, and I can say, that all of them had common properties as easy to read, easy to understand, practical and worth for reading more than once:)

Alistair Cockburn is a tour de force describing the working principles of agility. Interviews and analysis of dozens of agile projects is distilled into a series of powerful observations and recommendations. This is the book you need to guide the tailoring of agile methods to your particular environment and circumstances. Many inexperienced teams lose much of the value of their agile methods by adapting them in inappropriate ways before they understand the subtle interactions between various agile practices. This book helps you to stay in the "safe zone" or the "sweet spot" when you are starting out, and to get the more effectiveness from your ongoing process improvements as you gain more experience and maturity.

The agile model of software development has become an industry leader, making the second updated edition of Agile Software Development: Cooperative Game an even more essential reference. Agile's pioneering developer updates his Jolt Productivity winner to cover all aspects of the agile model, from its applications in an organizational structure to how to blend agile ideas with others. Any needing a basic introduction to Agile principles, history, and construction must have this.

Diane C. Donovan
California Bookwatch