What do you think?
Rate this book
The Art of Agile Development
Almost every company that develops software today is using something they call Agile. But there's a widespread misunderstanding of what Agile is and how to use it. The Art of Agile Development is a comprehensive guidebook for anyone who wants to improve the agility of their software development team. It provides clear, concrete, and detailed guidance about what to do, why to do it, and when to make trade-offs.
This updated edition provides no-nonsense advice on Agile planning, development, delivery, and management taken from the authors' many years of experience applying Agile and Extreme Programming (XP).
This updated edition provides no-nonsense advice on Agile planning, development, delivery, and management taken from the authors' many years of experience applying Agile and Extreme Programming (XP).
540 pages, Paperback
First published January 1, 2007
172 people are currently reading
1700 people want to read
Ratings & Reviews
Friends & Following
Create a free account to discover what your friends think of this book!
Community Reviews
Displaying 1 - 30 of 57 reviews
Read
October 22, 2019Only took me THREE attempts over five years to get through it, but I feel like I actually picked up a few things.
February 20, 2009
"The Art of Agile Development" by James Shore and Shane Warden is a book that is primarily focused on explaining Agile to people who want to adopt Agile software development practices for their team. The bulk of book is divided into sections based on a categorization on agile practices. There is a chapter on practices that help with thinking, one for collaborating, one for releasing, one for planning, and one for developing. In each of these chapters, there is a section devoted to a specific practice, such as "pair programming". The sections describe how to do the specific practice, what benefits it offers, what challenges you might face when adopting the practice, and so on. Usually it also has some frequently asked questions about the practice (with answers, of course) and some suggestions for alternatives if you have a reason to not adopt the practice.
First and foremost, I need to mention my biggest criticism of the book. It has one of the most misleading titles I have ever read. This is *NOT* a book on Agile. It is a book on XP, one of a few different flavors of Agile. The correct title for this book would be "The Art of Agile Development using XP." This is worth mentioning for a few reasons. First of all, XP's practices are pretty hardcore. XP's engineering practices are all extremely useful, but most of the time when a company or team resists Agile, it's because they are resisting a typically XP practice, such as Test-Driven Development or Pair Programming. Personally, I'm a big fan of XP's practices, but the fact of the matter is that any team that wishes to become Agile will likely find the most resistance if they try to adopt XP, so it seems misleading to sell the book as an introduction to Agile when it is, in fact, an introduction to XP.
That said, this is an excellent book on XP. All of XP's practices are covered in just the right amount of detail - giving you enough information that you can adopt the practice, but requiring that you do additional research about the ones that interest or challenge you the most. This allows the book to be a pretty quick read in general, which is beneficial for a team wishing to adopt XP practices soon. This level of detail does have one disadvantage, though: by staying largely in the realm of hypotheticals and ideals, I often found myself thinking that the authors were being naive and idealistic about how easy some practices were to adopt. This made me somewhat more skeptical of the book than I would have been if more detail had been offered, but ultimately I felt the level of detail was right; I did my own research online about some of the things that challenged me.
One of the most annoying aspects of the book are the "examples" that are sometimes provided. Usually these examples provide a sample conversation between stakeholders as they illustrate the effectiveness of an XP practice. These little micro-plays are so exaggerated that it often felt like reading the script to a bad company training video. After a few, I found myself skipping them.
I learned an awful lot about XP practices, particularly Pair Programming, estimation techniques, and incremental design. I felt that a number of these topics were better covered in other books, but "The Art of Agile Development" seems like it is meant to be an introduction to XP. In fact, every section generally provided a list of books that covered the section topic better.
I recommend this book for a team that wishes to adopt XP as quickly as possible, but I cannot reiterate enough that this would be the first, not the last, XP book you buy if you wish to become an effective XP team.
First and foremost, I need to mention my biggest criticism of the book. It has one of the most misleading titles I have ever read. This is *NOT* a book on Agile. It is a book on XP, one of a few different flavors of Agile. The correct title for this book would be "The Art of Agile Development using XP." This is worth mentioning for a few reasons. First of all, XP's practices are pretty hardcore. XP's engineering practices are all extremely useful, but most of the time when a company or team resists Agile, it's because they are resisting a typically XP practice, such as Test-Driven Development or Pair Programming. Personally, I'm a big fan of XP's practices, but the fact of the matter is that any team that wishes to become Agile will likely find the most resistance if they try to adopt XP, so it seems misleading to sell the book as an introduction to Agile when it is, in fact, an introduction to XP.
That said, this is an excellent book on XP. All of XP's practices are covered in just the right amount of detail - giving you enough information that you can adopt the practice, but requiring that you do additional research about the ones that interest or challenge you the most. This allows the book to be a pretty quick read in general, which is beneficial for a team wishing to adopt XP practices soon. This level of detail does have one disadvantage, though: by staying largely in the realm of hypotheticals and ideals, I often found myself thinking that the authors were being naive and idealistic about how easy some practices were to adopt. This made me somewhat more skeptical of the book than I would have been if more detail had been offered, but ultimately I felt the level of detail was right; I did my own research online about some of the things that challenged me.
One of the most annoying aspects of the book are the "examples" that are sometimes provided. Usually these examples provide a sample conversation between stakeholders as they illustrate the effectiveness of an XP practice. These little micro-plays are so exaggerated that it often felt like reading the script to a bad company training video. After a few, I found myself skipping them.
I learned an awful lot about XP practices, particularly Pair Programming, estimation techniques, and incremental design. I felt that a number of these topics were better covered in other books, but "The Art of Agile Development" seems like it is meant to be an introduction to XP. In fact, every section generally provided a list of books that covered the section topic better.
I recommend this book for a team that wishes to adopt XP as quickly as possible, but I cannot reiterate enough that this would be the first, not the last, XP book you buy if you wish to become an effective XP team.
July 6, 2022
The second edition of James Shore's book has been an amazing book for us to work through at our small software consultancy. While not everything applies at our size, the heart behind the values and practices challenges us to reach for those ideals. We've been trying to be Agile™ for many years, but this felt like the first time it all fit together in a way that made sense, instead of a disconnected set of practices that your can pick up or leave, buffet-style. This book has helped the developers and management get on the same page about where we want to go and what path we want to take to get there.
August 26, 2012
short version: A bit dogmatic, but these dudes have done their homework, and if you can tolerate the preachy "seriously, you need to do exactly what I'm describing" tone of it all, there are lots of valuable gems buried within. The bad news: you're going to need support from management to make all this work, and even with that support, it could be hairy in a big organization and/or with a lot of legacy code behind you.
Also... ALSO: Kanban gets mentioned in here several, albeit not by name--and I felt kind of put off by that.
The good news: not every valuable lesson requires that support. I'm going to be generous here and give it 4-stars rather than 3, but mostly because I support the attitudes that underlie their take on Agile/XP, if not their take on Agile/XP.
----
Not strictly a review, but: you should check out my blog post "Agile for the Introvert", wherein I discuss and critique specific contents of The Art of Agile Development rather extensively. (Also: it's complete with a comment from the author -- which had me more/less totally chuffed.)
Also... ALSO: Kanban gets mentioned in here several, albeit not by name--and I felt kind of put off by that.
The good news: not every valuable lesson requires that support. I'm going to be generous here and give it 4-stars rather than 3, but mostly because I support the attitudes that underlie their take on Agile/XP, if not their take on Agile/XP.
----
Not strictly a review, but: you should check out my blog post "Agile for the Introvert", wherein I discuss and critique specific contents of The Art of Agile Development rather extensively. (Also: it's complete with a comment from the author -- which had me more/less totally chuffed.)
August 24, 2014
Good content. Horrible writing style.
January 16, 2024
At 540 pages, this a massive book with a lot of information that’s both detailed and agnostic, i.e. not reliant on a specific framework. Speaking of which, I really liked reading about the Agile Fluency model again, because it’s the only model I know that says becoming agile takes years.
I also discovered an approach that I had not heard of: Fluid Scaling Technology (FaST). I will definitely check that out! And I also need to brush up on my XP/DevOps skills; there’s lots of examples here.
What else did I like? The book is cross-referenced throughout, so you can basically jump into any chapter and, from there, follow the links that interest you.
Why only 3 stars? Because it’s a tough read that’s only digestible for experts. For novices, I’d much rather recommend The Agile Samurai: How Agile Masters Deliver Great Software.
I also discovered an approach that I had not heard of: Fluid Scaling Technology (FaST). I will definitely check that out! And I also need to brush up on my XP/DevOps skills; there’s lots of examples here.
What else did I like? The book is cross-referenced throughout, so you can basically jump into any chapter and, from there, follow the links that interest you.
Why only 3 stars? Because it’s a tough read that’s only digestible for experts. For novices, I’d much rather recommend The Agile Samurai: How Agile Masters Deliver Great Software.
April 28, 2024
A comprehensive guide which mainly focusses on Extreme Programming which is a strange omission from the title. It champions pair programming, liaising with the customer, and requiring buy-in from the entire team. There's a few places where it seems a bit too broad; eg talks about code in a few sections, and I think since the book was a bit too long; these could be trimmed.
July 5, 2019
I strongly recommend this book if you work in a Agile shop or you are considering moving toward Agile and/or XP. I am a strong advocate of Agile Software Development. The use of pair programming and test driven development have elevated my productivity significantly.
There are some limitations to this book. It is not written in the most inviting manner. Compared to other books, such as the Lean Startup, it is a bit thick to get through some sections. Compared to the Gang of Four Design Patterns it is lightweight summer read. The other downside is the reference to older material. This book is from 2007 mind you. Software ideas and processes are continually evolving. While there is still much to learn from items published last century, without a current version it tends to lose credibility. Read that as a light criticism, I strongly recommend Design Patterns: Elements of Reusable Object-Oriented Software (1995)
Overall, it gives a very good top to bottom review of what Agile and what Agile is not.
There are some limitations to this book. It is not written in the most inviting manner. Compared to other books, such as the Lean Startup, it is a bit thick to get through some sections. Compared to the Gang of Four Design Patterns it is lightweight summer read. The other downside is the reference to older material. This book is from 2007 mind you. Software ideas and processes are continually evolving. While there is still much to learn from items published last century, without a current version it tends to lose credibility. Read that as a light criticism, I strongly recommend Design Patterns: Elements of Reusable Object-Oriented Software (1995)
Overall, it gives a very good top to bottom review of what Agile and what Agile is not.
January 27, 2012
This book reminded me of the guy at the party who had a few too many drinks but really, really wants to tell you all about the new religion/philosophy/band that he has discovered and wants to tell you all about.
In great detail.
I made it about 1/2 way through, and it started repeating itself, so I abandoned it.
The book talks about a lot of stuff that makes sense, the idea of Agile development has some good points, but this book was just a little too sure of itself to be a good overview for a non-practicer.
In great detail.
I made it about 1/2 way through, and it started repeating itself, so I abandoned it.
The book talks about a lot of stuff that makes sense, the idea of Agile development has some good points, but this book was just a little too sure of itself to be a good overview for a non-practicer.
December 13, 2008
I like this book so far, reading it in very on off fashion. I got introduced to agile development a couple of years ago and have since worked with a company who used it to develop a software product for us. The book is quite academic and I feel at this early stage (about 1/3 read) that is another tome from which I will take elements and use in my work. Another methodology like prince -so steal the best bits!
August 15, 2011
Admittedly, this is my first complete book that had anything to do with extreme programming. I'm very familiar with Scrum, but am relatively new to pair programming, TDD and the like. However, where I am in my professional career, this was of the utmost importance. If you are in an organization that is moving to Agile practices, this book is not only helpful, but necessary.
December 13, 2016
I must admit I only skimmed this. It's full of powerful ideas, but I'd already been exposed to many of them through working at ThoughtWorks. Still, I think this would be a really thorough introduction to Agile/XP for someone who hadn't worked in that way before.
May 28, 2008
Just the best book on agile software development methodogy and practices...
Read
March 10, 2010Viele Tipps und konkrete Hinweise zu allen XP-Praktiken und sehr umfassend!
December 4, 2021
Part cookbook, part reference, TAoAD is my GoTo book when doing things Agile.
I take this book and any other on the subject with a pinch of salt. After all the topic is far from technical but deep in human behavior modification. What you will find are recipes, strategies, games, operational hints, and everything else in your mind to make your work be more collaborative in nature. You cannot take it as an implementation guide or a prescriptive manual to change your organization and it is not guarantee of success but it is a very convenient ally to count on during your journey.
It will name patterns, it will propose solutions, it will describe games and techniques. I often use it as a starting point to sort out organizational issues. Kind of a "what does the TAoAD say on this or that matter?". The type of reference book you want it on paper in your company's shelves to pass it around.
You cannot blindly follow its advice though. Every organization is different, old habits die hard and more often you have little or no power in your hands to do things. Also authors on operational methods tend to describe their strategies like silver bullets that works every time (which incidentally make me smile at their optimism). But just its capability to make your aware of the different alternatives makes it a good reference to have in your shelves to visit every now and then or when an itch comes.
No book on Agile Development will guarantee success in the transition or implementation. Human behavior is noisy and each organization is unique but Shore's work is a must read.
I take this book and any other on the subject with a pinch of salt. After all the topic is far from technical but deep in human behavior modification. What you will find are recipes, strategies, games, operational hints, and everything else in your mind to make your work be more collaborative in nature. You cannot take it as an implementation guide or a prescriptive manual to change your organization and it is not guarantee of success but it is a very convenient ally to count on during your journey.
It will name patterns, it will propose solutions, it will describe games and techniques. I often use it as a starting point to sort out organizational issues. Kind of a "what does the TAoAD say on this or that matter?". The type of reference book you want it on paper in your company's shelves to pass it around.
You cannot blindly follow its advice though. Every organization is different, old habits die hard and more often you have little or no power in your hands to do things. Also authors on operational methods tend to describe their strategies like silver bullets that works every time (which incidentally make me smile at their optimism). But just its capability to make your aware of the different alternatives makes it a good reference to have in your shelves to visit every now and then or when an itch comes.
No book on Agile Development will guarantee success in the transition or implementation. Human behavior is noisy and each organization is unique but Shore's work is a must read.
August 3, 2019
Probably my overall favorite thoughtful summary of Agile concepts.
I had stayed away from reading it for a long time because it is XP focused, and XP’s focus on technical practices seems difficult to translate to things that aren’t 100% custom written, mostly greenfield software.
But it does a great job being thoughtful explaining what practices are trying to achieve, why they work, how they work together, and how you should be thoughtful in applying them.
It is not huge or dense, but it is not short or a light read, so it will be difficult to recommend to most coworkers.
A lot of the detail about what sorts of software you might be developing feel very dated, but that is mitigated by always circling back to ideas, not details or prescriptive practices.
I had stayed away from reading it for a long time because it is XP focused, and XP’s focus on technical practices seems difficult to translate to things that aren’t 100% custom written, mostly greenfield software.
But it does a great job being thoughtful explaining what practices are trying to achieve, why they work, how they work together, and how you should be thoughtful in applying them.
It is not huge or dense, but it is not short or a light read, so it will be difficult to recommend to most coworkers.
A lot of the detail about what sorts of software you might be developing feel very dated, but that is mitigated by always circling back to ideas, not details or prescriptive practices.
November 20, 2017
This book is about the XP (Extreme Programming) methodology. But it's useful for anybody working in an agile environment, or looking for applying agile practices. Practices like pair programming, retrospectives, iteration plannings, agile team composition, energized work, informative workspaces etc are described in great detail. It feels like a nice blend between philosophical questions and daily practice.
March 8, 2021
I loved it, from beginning to end. I'm a pretty experienced scrum master, but one that has no noteworthy background in development. I'm convinced that a developer background will make you a better SM, but since I cannot turn back time, I try to reverse engineer, at least up to a level that I understand what they're doing. This book is a rich source of agile practices of which many are from a developer point of view. I'm going to keep this one close to me, on my desk for the coming time
May 14, 2018
Το συγκεκριμένο βιβλίο είναι λίγο παλιό (2008) αλλά σε κάθε περίπτωση παραμένει επίκαιρο. Την εποχή που Scrum και agile είναι οι πλέον παραδεκτοί τρόποι για να τρέξεις IT projects (και όχι μόνο), το εν λόγω βιβλίο αποτελεί ένας πρώτης τάξεως ref doc για οποιονδήποτε θέλει να τρέξει τέτοιου είδους έργα.
February 21, 2020
I went through this book years ago when I started getting into agile dev and I have to admit I wasn't initially thrilled with it. It wasn't as intuitive to me as some other approaches, but I kept slogging away and eventually got to know a little of what I was doing. There are books published since that are probably better, but at the time, there wasn't a huge selection.
February 9, 2021
There are great ideas here. I've not yet been in a situation where the whole approach was used, only parts. The author suggests that the real benefits of Agile paired with XP require going all in, the whole team. I can certainly imagine the results would be much better that way, but wonder how often companies go all in on it.
July 16, 2018
To be honest I didn't read it all, but the chapters that I've read worth the investment of time. I would recommend this book to people that are starting with agile methodologies and in this case XP.
June 5, 2019
Surprisingly relevant for an old book!
February 5, 2020
Bastante extenso e detalhado. Um livro para ter como referência para futuras consultas.
September 6, 2020
Scan through. Details on implementing XP.
January 24, 2021
Really useful and very readable. Has an XP flavour.
August 7, 2016
A newbie to the agile methodology introduced me to my very first book – The Art of Agile Development. Having had a few months of experience in the ‘agile’ environment, this book was a reading pleasure.
The book opens up to briefing about the agile methodology and lists out the inherent thinking behind this practice in the field of software development. Though the focus over the ‘Scrum’ type is almost nil, but the book doesn’t let you lose out on your grip even if you are a practitioner of the Scrum methodology. Most of the talks are described with the Extreme Programming [XP] perspective. But the simple language of the author makes it a lot easier for the reader to comprehend. The author gives insights about how exactly an agile environment operates, how do we fit in such an environment and what makes agile one of the best models of software development. The book further digs a bit into domain modeling, exhaustive testing and the like. It also talks with perspectives of the ‘Product Owner’, ‘Developer’, ‘Tester’ and the business angle(s).
A novice agile developer can easily relate to the concepts and thereby understand the agile functionality at a more granular level. The book isn’t exhaustive at all and aptly describes every bit of it. On the part of the reader, it takes a bit of consciousness and ability to read between the lines and understand the nuances conveyed therein.
Overall, a must read for all working on agile projects. It will help in better segregation of what exactly are the “Do’s” and “Don’ts” in an agile software development.
The book opens up to briefing about the agile methodology and lists out the inherent thinking behind this practice in the field of software development. Though the focus over the ‘Scrum’ type is almost nil, but the book doesn’t let you lose out on your grip even if you are a practitioner of the Scrum methodology. Most of the talks are described with the Extreme Programming [XP] perspective. But the simple language of the author makes it a lot easier for the reader to comprehend. The author gives insights about how exactly an agile environment operates, how do we fit in such an environment and what makes agile one of the best models of software development. The book further digs a bit into domain modeling, exhaustive testing and the like. It also talks with perspectives of the ‘Product Owner’, ‘Developer’, ‘Tester’ and the business angle(s).
A novice agile developer can easily relate to the concepts and thereby understand the agile functionality at a more granular level. The book isn’t exhaustive at all and aptly describes every bit of it. On the part of the reader, it takes a bit of consciousness and ability to read between the lines and understand the nuances conveyed therein.
Overall, a must read for all working on agile projects. It will help in better segregation of what exactly are the “Do’s” and “Don’ts” in an agile software development.
February 9, 2017
An usefully detailed discussion of the roles, processes, practices and principles of agile development. Most of the practices are taken from Extreme Programming, but some have been added. It's hard to explain how different this way of working is from traditional models. Shore explains the roles of programmers, testers, managers, product owners, investors and more. The book is filled with real-world experience, and you come away thinking, "I wish my company could do this!"
February 20, 2012
Lots of good ideas on Agile in general, however the book generally champions eXtreme Programming which occasionally obfuscates some of those good ideas.
There are a sections that are specifically devoted to get XP up and running -- these are basically waste if you aren't going to implement (or participate in) XP. Other sections that covers things like "10 minute build", "Energised Work", limiting yourself to tasks that can be accomplished in a few hours (and avoiding carrying over between days!), creating technical stories when necessary and looking at certain members on your team (only covering programmers, as this is XP, unfortunately) as constraints are particularly interesting.
There are a sections that are specifically devoted to get XP up and running -- these are basically waste if you aren't going to implement (or participate in) XP. Other sections that covers things like "10 minute build", "Energised Work", limiting yourself to tasks that can be accomplished in a few hours (and avoiding carrying over between days!), creating technical stories when necessary and looking at certain members on your team (only covering programmers, as this is XP, unfortunately) as constraints are particularly interesting.
March 10, 2013
Praise for The Art of Agile Development
“Jim Shore and Shane Warden expertly explain the practices and benefits of Extreme
Programming. They offer advice from their real-world experiences in leading teams.
They answer questions about the practices and show contraindications—ways that a
practice may be misapplied. They offer alternatives youcan try if there are impediments
to applying a practice, such as the lack of an on-site customer.
“The explanations do not stop with just the practices. Discussion of people-related issues,
such as strategies for creating trust and team cohesiveness, rounds out the book.”
—Ken Pugh, author of the Jolt-Award-winning book, Prefactoring
“Jim Shore and Shane Warden expertly explain the practices and benefits of Extreme
Programming. They offer advice from their real-world experiences in leading teams.
They answer questions about the practices and show contraindications—ways that a
practice may be misapplied. They offer alternatives youcan try if there are impediments
to applying a practice, such as the lack of an on-site customer.
“The explanations do not stop with just the practices. Discussion of people-related issues,
such as strategies for creating trust and team cohesiveness, rounds out the book.”
—Ken Pugh, author of the Jolt-Award-winning book, Prefactoring
Displaying 1 - 30 of 57 reviews