What do you think?
Rate this book
Agile Software Development Series
Agile Software Development
Presents sound advice for bringing difficult projects to successful conclusion with a minimum of stress. Written for developers and project managers, comparing software development to a game. Softcover.
278 pages, Paperback
First published October 19, 2006
Ratings & Reviews
Friends & Following
Create a free account to discover what your friends think of this book!
Community Reviews
Displaying 1 - 20 of 20 reviews
October 16, 2007
This is a fantastic book and Agile development and the theories behind it.
If you don't understand Agile after reading this, you need to re-read it.
So, what is Agile?
It's more of a process, than a strict set of rules.
The Agile Manifesto declares the following:
"Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on
the right, we value the items on the left more."
The principles:
"We follow these principles:
* Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
* Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
* Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
* Business people and developers must work together daily throughout the project.
* Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
* The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
* Working software is the primary measure of progress.
* Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
* Continuous attention to technical excellence and good design enhances agility.
* Simplicity--the art of maximizing the amount of work not done--is essential.
* The best architectures, requirements, and designs emerge from self-organizing teams.
* At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly."
"Fine, fine," you say "But what does it mean?"
The goal of Agile is to make working software that meets customer specification as quickly as possible in tested iterative cycles, each cycle setting up the next cycle for a win-win game-play.
There is a fine balancing act of keeping the procedures and methodologies pared back to get things done in a systematic way without getting in the way of getting software done.
Cockburn explains the whys of Agile by blending his experiences, anecdotal evidence, cited references, interviews spanning years and analogies.
He makes it very clear that people at the center of any project. And people need to communicate. A good deal of the book examines how to improve communication between everyone involved in the project.
Agile puts the focus back on developers and their skills instead of trying to make people 'plug-and-play' because of heavy methodologies.
I strongly recommend this book to anyone in the software development industry, even if you have no intention of going 'Agile' in your shop.
If you don't understand Agile after reading this, you need to re-read it.
So, what is Agile?
It's more of a process, than a strict set of rules.
The Agile Manifesto declares the following:
"Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on
the right, we value the items on the left more."
The principles:
"We follow these principles:
* Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
* Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
* Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
* Business people and developers must work together daily throughout the project.
* Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
* The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
* Working software is the primary measure of progress.
* Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
* Continuous attention to technical excellence and good design enhances agility.
* Simplicity--the art of maximizing the amount of work not done--is essential.
* The best architectures, requirements, and designs emerge from self-organizing teams.
* At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly."
"Fine, fine," you say "But what does it mean?"
The goal of Agile is to make working software that meets customer specification as quickly as possible in tested iterative cycles, each cycle setting up the next cycle for a win-win game-play.
There is a fine balancing act of keeping the procedures and methodologies pared back to get things done in a systematic way without getting in the way of getting software done.
Cockburn explains the whys of Agile by blending his experiences, anecdotal evidence, cited references, interviews spanning years and analogies.
He makes it very clear that people at the center of any project. And people need to communicate. A good deal of the book examines how to improve communication between everyone involved in the project.
Agile puts the focus back on developers and their skills instead of trying to make people 'plug-and-play' because of heavy methodologies.
I strongly recommend this book to anyone in the software development industry, even if you have no intention of going 'Agile' in your shop.
March 10, 2017
Still relevant more than a decade after the second edition was published. The idea that an Agile development methodology can be customized to meet the special needs of a particular group and project was very insightful all those years ago and the fact that many folks in the Agile world are just now beginning to see that one size does not fit all is a testament to how far it was ahead of its time.
The best part of this book was the explanation of the nature of software development as a uniquely human endeavor in spite of all the trappings of technology.
The best part of this book was the explanation of the nature of software development as a uniquely human endeavor in spite of all the trappings of technology.
May 15, 2013
Despite its theoretical approach, Alistair Cockburn is my favorite author, thinker and inovator on the Software development field, and this book (its second and revised edition) explains a lot of the questions that make Software development an Art and a Science at the same time. Cockburn does the best job to understand the chaos of the game, whether the human interaction component or the technological solutions that development struggles to concrete.
July 19, 2020
As a book on the psychology of the workplace and the barriers to smooth software development, I think this is one of the best books I've read. However the industry is not what it was when the book was written and essential ideas like automation and focus on delivery are not really covered.
December 27, 2011
De filosofie van Agile Software Development
Ik ben de laatste maanden intensief bezig geweest met het boek Agile Software Development – The Cooperative Game van Alistair Cockburn. Meestal lees ik boeken veel sneller maar dit boek dwong me steeds om te reflecteren, gaf me continu ideeën voor toepassingen. Maar nu is het boek uit, en dus is het tijd voor een bespreking. In deze eerste blog de filosofische basis.
Deel 0 van het boek begint filosofisch: “wat kunnen we eigenlijk weten?”, wat is “knowable”, en wat kan je wel of niet communiceren en documenteren? Alistair’s antwoord is dat perfect weten en communiceren niet mogelijk is, maar dat dit niet betekent dat we helemaal niets meer kunnen doen. Het geeft tegelijkertijd wel aan dat we niet onze ‘ziel-en-zaligheid’ moeten koppelen aan een bepaalde methode of document, want het zal altijd beperkt zijn.
Het beschrijven en aanleren van methoden kan het beste gebeuren aan de hand van de Shu-Ha-Ri aanpak vanuit Aikido. In de Shu-fase, kopieert de leerling exact het voorbeeld van de leraar. De leraar geeft eenduidige instructies, alsof er maar één goede methode bestaat. In de Ha-fase neemt de leerling afstand van de leraar, reflecteert op het geleerde en komt zodoende tot een dieper begrip van het geleerde. Hier wordt duidelijk wat de beperkingen van de methoden zijn, en wordt helder dat er meerdere goede methoden zijn om een taak uit te voeren. Tenslotte in de Ri-fase gaat de leerling boven het geleerde uit. De leerling wordt ‘practitioner’. De leerling volgt de methode niet meer, maar weet intuïtief wat de juiste werkwijze is in iedere specifieke situatie.
Ik herken dat vanuit mijn eigen praktijk. Als ik een cursus geef, bijvoorbeeld mijn “Intro Agile/Scrum” dan laat ik heel veel weg, houd ik het heel simpel en beschrijf ik meestal maar 1 manier om het werk te doen. Terwijl ik, als ik als consultant een afdeling of project begeleid,
veel meer variatie aangeef. “Je zou het zo kunnen doen, maar ook anders, probeer eens wat je het beste bevalt”.
Bijlage B wordt echt filosofisch, in een bespreking van het werk van Pelle Ehn wordt software ontwikkeling besproken in termen van het werk van achtereenvolgens Descartes, Marx, Heidegger en Wittgenstein.
Software ontwikkeling volgens Descartes bouwt een zo exact mogelijk model van de externe werkelijkheid. Als we werken in de stijl van Marx stellen we allereerst de vraag naar wie profijt gaat hebben van het te bouwen systeem. In de lijn van Heidegger is het systeem een tool dat de gebruiker zo min mogelijk moet zien, maar dat hem zoveel mogelijk moet ondersteunen. Wittgenstein is bijna tegengesteld aan Descartes. De bouw van een design is een taalspel dat zich gedurende het ontwerpen ontwikkelt, er worden steeds nieuwe woorden/begrippen aan de taal toegevoegd.
Cockburn ziet software ontwikkeling als een spel (a cooperative game of invention and cooperation), en volgt daarin dus de lijn van Wittgenstein.
Wittgenstein ziet de taal die we gebruiken om een design of requirements vast te leggen als ‘reminders for our reflections’. Die uitspraak doet me sterk denken aan de definitie van een ‘user story‘; ook dat is geen definitieve beschrijving van het systeem maar een verhaaltje dat ons helpt herinneren aan de discussie die we daarover hadden met de gebruikers. Ook het gebruik van metaforen past prima in deze denkwijze.
Een prachtig voorbeeld van de (on)mogelijkheden van taal komt ook weer van Wittgenstein: “vergelijk eens wat je kan weten en zeggen over (1) hoe hoog de Mont Blanc is, (2) hoe we het woord ‘spel’ gebruiken en (3) hoe een clarinet klinkt”. Zeker dat laatste valt niet of nauwelijks in woorden uit te drukken! Zo zijn er ook veel aspecten van een ontwerp die niet of nauwelijks te documenteren zijn, zeker niet voordat er een concrete vraag gesteld wordt over hoe een systeem uitgebreid zou kunnen worden.
Ik ben de laatste maanden intensief bezig geweest met het boek Agile Software Development – The Cooperative Game van Alistair Cockburn. Meestal lees ik boeken veel sneller maar dit boek dwong me steeds om te reflecteren, gaf me continu ideeën voor toepassingen. Maar nu is het boek uit, en dus is het tijd voor een bespreking. In deze eerste blog de filosofische basis.
Deel 0 van het boek begint filosofisch: “wat kunnen we eigenlijk weten?”, wat is “knowable”, en wat kan je wel of niet communiceren en documenteren? Alistair’s antwoord is dat perfect weten en communiceren niet mogelijk is, maar dat dit niet betekent dat we helemaal niets meer kunnen doen. Het geeft tegelijkertijd wel aan dat we niet onze ‘ziel-en-zaligheid’ moeten koppelen aan een bepaalde methode of document, want het zal altijd beperkt zijn.
Het beschrijven en aanleren van methoden kan het beste gebeuren aan de hand van de Shu-Ha-Ri aanpak vanuit Aikido. In de Shu-fase, kopieert de leerling exact het voorbeeld van de leraar. De leraar geeft eenduidige instructies, alsof er maar één goede methode bestaat. In de Ha-fase neemt de leerling afstand van de leraar, reflecteert op het geleerde en komt zodoende tot een dieper begrip van het geleerde. Hier wordt duidelijk wat de beperkingen van de methoden zijn, en wordt helder dat er meerdere goede methoden zijn om een taak uit te voeren. Tenslotte in de Ri-fase gaat de leerling boven het geleerde uit. De leerling wordt ‘practitioner’. De leerling volgt de methode niet meer, maar weet intuïtief wat de juiste werkwijze is in iedere specifieke situatie.
Ik herken dat vanuit mijn eigen praktijk. Als ik een cursus geef, bijvoorbeeld mijn “Intro Agile/Scrum” dan laat ik heel veel weg, houd ik het heel simpel en beschrijf ik meestal maar 1 manier om het werk te doen. Terwijl ik, als ik als consultant een afdeling of project begeleid,
veel meer variatie aangeef. “Je zou het zo kunnen doen, maar ook anders, probeer eens wat je het beste bevalt”.
Bijlage B wordt echt filosofisch, in een bespreking van het werk van Pelle Ehn wordt software ontwikkeling besproken in termen van het werk van achtereenvolgens Descartes, Marx, Heidegger en Wittgenstein.
Software ontwikkeling volgens Descartes bouwt een zo exact mogelijk model van de externe werkelijkheid. Als we werken in de stijl van Marx stellen we allereerst de vraag naar wie profijt gaat hebben van het te bouwen systeem. In de lijn van Heidegger is het systeem een tool dat de gebruiker zo min mogelijk moet zien, maar dat hem zoveel mogelijk moet ondersteunen. Wittgenstein is bijna tegengesteld aan Descartes. De bouw van een design is een taalspel dat zich gedurende het ontwerpen ontwikkelt, er worden steeds nieuwe woorden/begrippen aan de taal toegevoegd.
Cockburn ziet software ontwikkeling als een spel (a cooperative game of invention and cooperation), en volgt daarin dus de lijn van Wittgenstein.
Wittgenstein ziet de taal die we gebruiken om een design of requirements vast te leggen als ‘reminders for our reflections’. Die uitspraak doet me sterk denken aan de definitie van een ‘user story‘; ook dat is geen definitieve beschrijving van het systeem maar een verhaaltje dat ons helpt herinneren aan de discussie die we daarover hadden met de gebruikers. Ook het gebruik van metaforen past prima in deze denkwijze.
Een prachtig voorbeeld van de (on)mogelijkheden van taal komt ook weer van Wittgenstein: “vergelijk eens wat je kan weten en zeggen over (1) hoe hoog de Mont Blanc is, (2) hoe we het woord ‘spel’ gebruiken en (3) hoe een clarinet klinkt”. Zeker dat laatste valt niet of nauwelijks in woorden uit te drukken! Zo zijn er ook veel aspecten van een ontwerp die niet of nauwelijks te documenteren zijn, zeker niet voordat er een concrete vraag gesteld wordt over hoe een systeem uitgebreid zou kunnen worden.
August 10, 2016
Agile Software Development is a book from Alistair Cockburn part of the mythical group who gathered together and signed on the Agile Manifesto. The second edition, published in 2007 contains several updates to the first one published several years earlier.
A big chunk of the book concentrates around the more abstract points around the challenges of communication, how software is a game of cooperation, analysis of the peculiarities of individuals and teams and finally methodologies. These chapters will be of interest to the readers more inclined around the psychological and innovation aspects of software development, as well as the analysis of interactions. They are certainly quite abstract and require a fair degree of patience and willingness to digest them in order to get the most value out of them.
The last two chapters are much more practical and in my opinion are, especially Chapter 5, worth the entry price. In it Cockburn illustrates the mindset which with you should approach specific situations to adapt your Agile process to the circumstances and characteristics of the project. In the first version (the one which was part of the first edition of the book) he discusses the essentials (barely enough documentation, collocated teams, fully automated tests, presence of the business and how important is to have the best developers), but he doesn’t shy away of tougher topics like virtual teams, how to reflect / introspect adequately (and how important it is!). It is however the 2nd edition update which I found really interesting. In it he dispels quite a few myths about agile, illustrates how different Agile flavours have evolved, discusses how different practices fit into the picture, tackles the big questions (how much process, commercial engagements, standards compliance…) and even conveys how Agile has worked out of the software world, although I must say this is really Lean which was there way before the software Agile practices started to take the world by storm.
Chapter 6 is an explanation of a few of the Crystal methodologies designed by the author all very well illustrated with different case studies.
Finally a few appendixes with seminal articles like an annotated version of the Agile Manifesto, Peter Naur’s “Programming as Theory Building” (which I find at the level of Brooke’s “There is no silver bullet”) and Ehn’s “Wittgenstein’s Language Game” which I personally found too profoundly philosophical and abstract for my taste and I must admit I had to give up on.
In summary, I think this book is worth spending some time with regardless of your role if you are interested in Agile and / or in delivering software, and not just for a single read but as a resource to refer to. I would strongly recommend to read Chapter 5 and 6 first, and if it manages to whet your appetite go to the initial chapters to read about the more philosophical / psychological aspects. I strongly believe, and as a practitioner can attest for the main principles advocated by the author:
- There is no single one size fits all and approaches should be adapted to the characteristics of the project
- Software building and in general any complex, innovative endeavours are all about communication
- You need to keep iterating, same as you do with your products, on the practices and behaviours you are seeing as you go along so that you can adapt and improve (this goes right to the Kaizen philosophy)
- Having the best developers gives you orders of magnitude of advantage - it is not linear!
- Any tool or process can be valuable as long as you know not to overdo it - it is about doing just enough to be able to move onto the next phase
- Automated testing and customer feedback. I have grouped this together as I believe that in a sense they are both sides of the same coin
A big chunk of the book concentrates around the more abstract points around the challenges of communication, how software is a game of cooperation, analysis of the peculiarities of individuals and teams and finally methodologies. These chapters will be of interest to the readers more inclined around the psychological and innovation aspects of software development, as well as the analysis of interactions. They are certainly quite abstract and require a fair degree of patience and willingness to digest them in order to get the most value out of them.
The last two chapters are much more practical and in my opinion are, especially Chapter 5, worth the entry price. In it Cockburn illustrates the mindset which with you should approach specific situations to adapt your Agile process to the circumstances and characteristics of the project. In the first version (the one which was part of the first edition of the book) he discusses the essentials (barely enough documentation, collocated teams, fully automated tests, presence of the business and how important is to have the best developers), but he doesn’t shy away of tougher topics like virtual teams, how to reflect / introspect adequately (and how important it is!). It is however the 2nd edition update which I found really interesting. In it he dispels quite a few myths about agile, illustrates how different Agile flavours have evolved, discusses how different practices fit into the picture, tackles the big questions (how much process, commercial engagements, standards compliance…) and even conveys how Agile has worked out of the software world, although I must say this is really Lean which was there way before the software Agile practices started to take the world by storm.
Chapter 6 is an explanation of a few of the Crystal methodologies designed by the author all very well illustrated with different case studies.
Finally a few appendixes with seminal articles like an annotated version of the Agile Manifesto, Peter Naur’s “Programming as Theory Building” (which I find at the level of Brooke’s “There is no silver bullet”) and Ehn’s “Wittgenstein’s Language Game” which I personally found too profoundly philosophical and abstract for my taste and I must admit I had to give up on.
In summary, I think this book is worth spending some time with regardless of your role if you are interested in Agile and / or in delivering software, and not just for a single read but as a resource to refer to. I would strongly recommend to read Chapter 5 and 6 first, and if it manages to whet your appetite go to the initial chapters to read about the more philosophical / psychological aspects. I strongly believe, and as a practitioner can attest for the main principles advocated by the author:
- There is no single one size fits all and approaches should be adapted to the characteristics of the project
- Software building and in general any complex, innovative endeavours are all about communication
- You need to keep iterating, same as you do with your products, on the practices and behaviours you are seeing as you go along so that you can adapt and improve (this goes right to the Kaizen philosophy)
- Having the best developers gives you orders of magnitude of advantage - it is not linear!
- Any tool or process can be valuable as long as you know not to overdo it - it is about doing just enough to be able to move onto the next phase
- Automated testing and customer feedback. I have grouped this together as I believe that in a sense they are both sides of the same coin
December 26, 2022
I think I'm just not a fan of Cockburn's writing :(
While there are a lot of interesting thoughts in this book, it's juuuuuussssttt tooooooo looooooong.
Maybe if you are new to all this, maybe...
I don't know, I would have preferred a massively edited down version, not this 500 page tour de force. And while I am a sucker for academic theory on top of practical topics, some of the stuff Cockburn references just feels like so far removed from reality that it made me cringe and smile at the same time. I mean come on, quoting Wittgenstein, in a book that appears to have practical relevance?
And oh man, is he labouring examples...
It feels like either Mr Cockburn was seriously bored and was looking for some intellectual fun (and I can see why it could have been fun writing this) or he just needed to write yet another book (man has to pay the rent and all that).
Also, with Crystal, it feels like there is yet another methodology, regurgitating the same themes over and over again.
I think I'm so disappointed with this, as I feel that a compressed version would have been so much more helpful and impactfull. This way I feel like I was wasting a lot of time sifting out the relevant bits...
Somehow I felt this was more like BDUF rather than EDUF...
While there are a lot of interesting thoughts in this book, it's juuuuuussssttt tooooooo looooooong.
Maybe if you are new to all this, maybe...
I don't know, I would have preferred a massively edited down version, not this 500 page tour de force. And while I am a sucker for academic theory on top of practical topics, some of the stuff Cockburn references just feels like so far removed from reality that it made me cringe and smile at the same time. I mean come on, quoting Wittgenstein, in a book that appears to have practical relevance?
And oh man, is he labouring examples...
It feels like either Mr Cockburn was seriously bored and was looking for some intellectual fun (and I can see why it could have been fun writing this) or he just needed to write yet another book (man has to pay the rent and all that).
Also, with Crystal, it feels like there is yet another methodology, regurgitating the same themes over and over again.
I think I'm so disappointed with this, as I feel that a compressed version would have been so much more helpful and impactfull. This way I feel like I was wasting a lot of time sifting out the relevant bits...
Somehow I felt this was more like BDUF rather than EDUF...
April 18, 2014
I know that Alistair Cockburn is supposed to be one of the founding fathers of the Agile movement, but I disagreed with a lot of what he said, and this book is
very
philosophical.
In Chapter 1 he compares software development to the precepts of Aikido.
In Chapter 2 he says that software development is like a community writing epic poetry together.
A bit later on he says that software development is 'a game within a game.'
That's funny, fellow software engineers always thought that it was like shelling peas or making widgets on a production line. The most self-aggrandizing that I could stretch to would be making hand-made shoes (there is some element of craftsmanship there, but probably more in making shoes than in writing software).
Perhaps I am too old a dog. These flag-waving, inspiring, prophets of change are proliferating these days. But more often than not there is sizzle but no sausage.
Having said that, I read the whole book, carefully and thoughtfully, and with an intent of getting whatever useful out of it that I could.
In Chapter 1 he compares software development to the precepts of Aikido.
In Chapter 2 he says that software development is like a community writing epic poetry together.
A bit later on he says that software development is 'a game within a game.'
That's funny, fellow software engineers always thought that it was like shelling peas or making widgets on a production line. The most self-aggrandizing that I could stretch to would be making hand-made shoes (there is some element of craftsmanship there, but probably more in making shoes than in writing software).
Perhaps I am too old a dog. These flag-waving, inspiring, prophets of change are proliferating these days. But more often than not there is sizzle but no sausage.
Having said that, I read the whole book, carefully and thoughtfully, and with an intent of getting whatever useful out of it that I could.
November 23, 2021
With all of the books with “Agile” in their title today why would anyone want to single out Agile Software Development in particular? My reason was the author Alistair Cockburn. Alistair has been a part of the agile movement being both an original signatory on the Agile Manifesto and the proponent of the Crystal Clear methodology. In other words, the resume isn’t bad.
Click here to read the full review
Click here to read the full review
August 24, 2016
Good reading for learning the principles and philosophy behind agile methodologies. With amusing anecdotes and interesting analogies from disparate sources such as the Lockheed Skunkworks and the Chrysler C3 Project, the author shows how group dynamics between stakeholders can influence the success or failure of a project, indicating the pitfalls that undermine the so-called information flow and showing how they can be avoided to bring in to fruition a project of this nature.
July 30, 2008
This is an interesting take on agile software development. I heard Alistair speak to this book at a local IEEE Computer Society meeting. He likes to use analogies for relating experiences in software and this is very effective.
September 26, 2014
This book gave a good overview of the concepts of Agile and provided some useful techniques for making Agile methodologies work. Towards the end of the book, it gets a little more "salesman" with the author making a case for his particular methodology, but up to that point, it was a useful read.
March 6, 2009
Having a tough time with this one. It's challenging a lot of foundational beliefs I have about the way I do my job. The writing is good so far...
Read
March 10, 2010Fast schon "philosophisch", aber sehr gute Einführung und Grundlage, tiefgehend. Eigentlich Pflichtlektüre
September 23, 2013
good starting, messy ending
Want to read
June 24, 2011from scott berkun's 'making things happen'
This entire review has been hidden because of spoilers.
December 3, 2013
Software development is a cooperative game. Highly Recommended for anyone who wants to understand the fundamental human processes involved in developing software.
March 12, 2014
A more broad overview of agile techniques than most books provide. The only drawback I see is it is a little dated.
March 8, 2015
A must read for anyone who delivers software.
Read
December 26, 2017well balanced and full of good information!
Displaying 1 - 20 of 20 reviews