I want to know what would you recommend to read for Scrum and XP. I've got Scrum and xp from the Trenches, but I would like to see around some more references that are worthwhile.
5 Answers
Regarding agile, I don't think any team can do without "Agile retrospectives". Retrospectives are the backbone of any team and running them properly is far from trivial.
I also recommend "Coaching agile teams". I'm currently reading it and about half-way. It can be a bit fluffy from time to time, but it provides many excellent insights - for me at least.
(Later edit: I meant "coaching agile teams", not "agile coaching".)
-
1+1 for Agile Retrospectives. Retros are one of those things that most teams don't spend enough time focusing on and then wonder why their sprints have a certain "Groundhog Day" feel to them. It's amazing what adopting just a couple of the techniques in that book can do for a team's morale and sense of ownership of the process... – H.Y. Mar 10 '11 at 00:39
Agile Software Development with Scrum was the book I read for my CSM course. I've found it pretty useful so far (our team is just starting it's third sprint). I really recommend reading several books on the subject, preferably by a range of different authors. That should give you a nice idea of where the differences are, and thus what things you really need to think about and come to your own conclusions on.

- 10,038
- 1
- 36
- 45
Scrum and XP from the Trenches is a very good book on the subject. Unlike other books it describes how one company did scrum from scratch. It is more practical book, that gives you a flavor of HOW scrum can be done. And the book is FREE.

- 2,720
- 17
- 24
-
like I said, I already got this one, but yes I like this book too! It also has a list of books you could read, but I wanted to know what would you recommend – Goows Mar 10 '11 at 18:50
Agile Software Development: The Cooperative Game (2nd 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 original introduction.
Alistair Cockburn begins by updating his powerful model of software development as a “cooperative game of invention and communication.” Among the new ideas he introduces: harnessing competition without damaging collaboration; learning lessons from lean manufacturing; and balancing strategies for communication. Cockburn also explains how the cooperative game is played in business and on engineering projects, not just software development
Next, he systematically illuminates the agile model, shows how it has evolved, and answers the questions developers and project managers ask most often, including
- Where does agile development fit in our organization?
- How do we blend agile ideas with other ideas?
- How do we extend agile ideas more broadly?
Cockburn takes on crucial misconceptions that cause agile projects to fail. For example, you’ll learn why encoding project management strategies into fixed processes can lead to ineffective strategy decisions and costly mistakes. You’ll also find a thoughtful discussion of the controversial relationship between agile methods and user experience design.
Cockburn turns to the practical challenges of constructing agile methodologies for your own teams. You’ll learn how to tune and continuously reinvent your methodologies, and how to manage incomplete communication...

- 21,442
- 29
- 112
- 288

- 46,427
- 16
- 160
- 185
For Scrum, I'd go with Mike Cohn's "Agile Estimating and Planning".
It covers Scrum from the basics to some of the more complex topics and also addresses some of the more common questions than come up when starting with Scrum. For example:
- story points vs. ideal days
- velocity
- what to do in the event of a failed story (do we get partial credit or do we carry the points over)
- story splitting strategies
- dealing with bugs/defects
- whether to re-size/re-estimate stories
- how to groom a backlog
Cohn also goes into some topics from the perspective of a Product Owner - how to prioritize a backlog, different approaches to arriving at a measure of that ever elusive "business value", incl. the Kano model for product development. Not all of it may be relevant to somebody in a strict dev role (I have a whole other rant for whether "strict dev role" is even a good thing), but it's always helpful to have some context. Indeed, I'd argue that context is essential for long term success.

- 611
- 3
- 2