Product Description
“Agile Software Development is a highly stimulating and rich book. The author has a deep background and gives us a tour de force of the emerging agile methods.” –Tom Gilb The agile model of software development has taken the world by storm. Now, in Agile Software Development, Second Edition, one of agile’s leading pioneers updates his Jolt Productivity award-winning book to reflect all that’s been learned about agile development since its orig… More >>
Agile Software Development: The Cooperative Game
Tags: Agile, Cooperative, Development, Game, Software
#1 by Midwest Book Review on March 20, 2010 - 1:25 am
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
Rating: 5 / 5
#2 by Dale Schumacher on March 20, 2010 - 1:29 am
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.
Rating: 5 / 5
#3 by W Watson on March 20, 2010 - 3:59 am
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.
Rating: 5 / 5
#4 by W Boudville on March 20, 2010 - 5:17 am
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.
Rating: 4 / 5