- Series: Enterprise Software Development
- Paperback: 140 pages
- Publisher: Lulu.com; 1 edition (October 4, 2007)
- Language: English
- ISBN-10: 1430322640
- ISBN-13: 978-1430322641
- Product Dimensions: 6 x 0.4 x 9 inches
- Shipping Weight: 9.4 ounces (View shipping rates and policies)
- Average Customer Review: 20 customer reviews
- Amazon Best Sellers Rank: #561,482 in Books (See Top 100 in Books)
Enter your mobile number or email address below and we'll send you a link to download the free Kindle App. Then you can start reading Kindle books on your smartphone, tablet, or computer - no Kindle device required.
To get the free app, enter your mobile phone number.
Other Sellers on Amazon
+ Free Shipping
+ Free Shipping
+ $3.99 shipping
Scrum and XP from the Trenches (Enterprise Software Development) Paperback – October 4, 2007
Frequently bought together
Customers who bought this item also bought
An immensely practical guide to getting started with agile.
Henrik's book is a starter kit of basic practices that help teams move beyond trying to do Scrum to executing Scrum well.
Henrik goes on to describe some of the more difficult - and rarely covered - aspects of working in an agile organization, including coordinating the efforts of multiple Scrum teams.
A great contribution to the body of Agile knowledge, and a fun read!
The most useful book on agile development that I've read, and I've read lots of them!
From the Back Cover
The tricky part to agile software development is that there is no manual telling you exactly how to do it. You have to experiment and continuously adapt the process until it suits your specific situation.
This book aims to give you a head start by providing a detailed down-to-earth account of how one Swedish company implemented Scrum and XP with a team of approximately 40 people and how they continuously improved their process over a year's time.
Under the leadership of Henrik Kniberg they experimented with different team sizes, different sprint lengths, different ways of defining "done", different formats for product backlogs and sprint backlogs, different testing strategies, different ways of doing demos, different ways of synchronizing multiple Scrum teams, etc. They also experimented with XP practices - different ways of doing continuous build, pair programming, test driven development, etc, and how to combine this with Scrum.
This book includes:
- Practical tips and tricks for most Scrum and XP practices
- Typical pitfalls and how they were addressed
- Diagrams and photos illustrating day-to-day work
- Testing and test-driven development
- Scaling and coordinating multiple teams
- Dealing with resistance from inside and outside the team
- Planning and time estimation techniques
- Forwards by Jeff Sutherland and Mike Cohn
Top customer reviews
There was a problem filtering reviews right now. Please try again later.
I read Henrik Kniberg's book, Scrum and XP (Extreme Programming) from the Trenches, on his suggestion and, well, he's right!
Kniberg's book is a concise "how to" on how his company implements Agile in their software development business. It's chock full of great ideas and details that come only from those that have actually practiced something. As such, I gained a good insight into how Agile and Scrum work, and you will too.
What I want to explore more, however, is the idea that Agile can be applied as a model for leadership, or, more precisely, how can the practices of Agile be applied more broadly to knowledge workers? I think the best way to think about it to briefly recap the points of Agile and at every point where you see the word "product" think "culture." Let's see how that works.
1. The Agile process starts with describing stories about how the product should work. The focus is not on how things aren't working but how they should work. Process step 1: collect stories.
2. In preparation for the sprint planning meeting, have the product backlog (the list of stories about how we want our culture/product to be) in shipshape. This means being clear about the outcome including an defined "when done." This invokes the element of clarity and measurability. When we do workshops on changing culture this reminds me of the step where I ask, "...and how would we know...."
3. Have the sprint planning meeting with the team. Allow the team to determine the scope of what projects will be included in the upcoming sprint. Principle: give control, don't take control. Corollary: move authority to information, not information to authority.
4. Determine overall sprint goal prior to closing the planning meeting. This ensures the necessary supporting condition of clarity is in place.
5. Launch the team and get managers, coacher, owners, out of the way. Again, giving control to the people who know (the coders, testers, developers).
6. Always test the product with a demo before saying "done." This emphasis on actual products is very helpful, especially when changing business cultures where sometimes there is a tendency to think in terms of vague changes in mindset. Instead, we should focus on specific behavioral changes that we can observe and measure.
7. Conduct an assessment of how the Sprint went and measure team velocity. This would apply to following up on whether behavioral changes are sticking or not?
OK, well, that seems clear enough but when it came down to it, what was the leadership team actually working on -- the parallel to the code the developers were writing? Well, I think the code (sometimes I call it the DNA) for the company's culture is written in the policy documents that give authority for making decisions and detail how we will interact with each other. The cultural "coders" work on these policy documents in the same way the software developers work on the code.
First, you can decide to support the author and purchase the paper book, like I did, or you can download the free version from: [...]
Then, the book itself. It's structured fairly logically. It starts with looking at the Product Backlog, from there goes over all the Scrum meetings in chronological order. For every meeting, the author describes how he did it in his company, what other things he tried and what his conclusions were.
After all the Scrum meetings, the book dives in a couple separate topics, like combining Scrum with XP practices, having breaks between sprint and some other topics. It ends with scaling and distributed teams, common questions.
The book is basically a how-to book, though its very clear that it just gives an example, to make Scrum more concrete, but does recommend for everyone to look for "their Scrum" instead of blindly copying the suggestions in the books. This is also the books strength, it provides very concrete tips without saying "this is how it must be done".
I have different experiences than the author in some areas, which makes me frown sometimes, though I enjoyed Henriks explanations. They helped me gain a different perspective on some issues.
I was doubting between 3 and 4 stars for this book. 3 stars would be since the book doesn't offer more than it promises. It is an experience story of Henrik and didn't add much surprises or extra content. Also 3 stars since its so small. 4 stars would be because there is probably not any more concrete Scrum story than this one. If you are wondering about concrete implementation after reading Ken Schwaber's books, then this is the book for you! Also 4 starts because its small, which is also an advantage. There is no unnecessary blah blah in the book, Henrik tells how it is!
A recommended book for Scrum practitioners and people starting with Scrum to learn about "How Henrik did it!" :)
Kniberg's writing style is informal, taking a conversational approach, which I found refreshing and somewhat humorous.
Most recent customer reviews
I have bought this book but it is one-time reading one.
The content of the book is good. But the quality is very poor. Pages just fall of from the book.