Big news! LibraryThing is now free to all! Read the blog post and discuss the change on Talk.
This site uses cookies to deliver our services, improve performance, for analytics, and (if not signed in) for advertising. By using LibraryThing you acknowledge that you have read and understand our Terms of Service and Privacy Policy. Your use of the site and services is subject to these policies and terms.
Hide this

Results from Google Books

Click on a thumbnail to go to Google Books.

Scrum and XP from the Trenches (Enterprise…

Scrum and XP from the Trenches (Enterprise Software Development)

by Henrik Kniberg

MembersReviewsPopularityAverage ratingConversations
1041188,405 (4.3)None
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.… (more)



Sign up for LibraryThing to find out whether you'll like this book.

No current Talk conversations about this book.

My software friends are talking about Scrum, Agile, Pair Programming and I knew nothing about it. I have a friend who even suggested that Agile could be extended to general organizational design and even leadership!

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. ( )
  ldmarquet | Feb 6, 2013 |
no reviews | add a review
You must log in to edit Common Knowledge data.
For more help see the Common Knowledge help page.
Series (with order)
Canonical title
Original title
Alternative titles
Original publication date
Important places
Important events
Related movies
Awards and honors
First words
Last words
Disambiguation notice
Publisher's editors
Publisher series
Original language
Canonical DDC/MDS

References to this work on external resources.

Wikipedia in English


No library descriptions found.

Book description
Haiku summary

Quick Links

Popular covers


Average: (4.3)
3 3
3.5 1
4 10
4.5 3
5 10

Is this you?

Become a LibraryThing Author.


About | Contact | Privacy/Terms | Help/FAQs | Blog | Store | APIs | TinyCat | Legacy Libraries | Early Reviewers | Common Knowledge | 146,480,273 books! | Top bar: Always visible