What do you think?
Rate this book
Lean from the Trenches: Managing Large-Scale Projects with Kanban
Lean from the Trenches is all about actual practice.
Find out how the Swedish police combined XP, Scrum, and Kanban in a 60-person project. From start to finish, you'll see how to deliver a successful product using Lean principles.
We start with an organization in desperate need of a new way of doing things and finish with a group of sixty, all working in sync to develop a scalable, complex system. You'll walk through the project step by step, from customer engagement, to the daily "cocktail party," version control, bug tracking, and release. In this honest look at what works--and what doesn't--you'll find out how to:
Make quality everyone's business, not just the testers. Keep everyone moving in the same direction without micromanagement. Use simple and powerful metrics to aid in planning and process improvement. Balance between low-level feature focus and high-level system focus.
You'll be ready to jump into the trenches and streamline your own development process.
Contents
Foreword
Preface
PART I: HOW WE WORK
1. About the Project
1.1 Timeline 5
1.2 How We Sliced the Elephant 6
1.3 How We Involved the Customer 7
2. Structuring the Teams
3. Attending the Daily Cocktail Party
3.1 First Tier: Feature Team Daily Stand-up
3.2 Second Tier: Sync Meetings per Specialty
3.3 Third Tier: Project Sync Meeting
4. The Project Board
4.1 Our Cadences
4.2 How We Handle Urgent Issues and Impediments
5. Scaling the Kanban Boards
6. Tracking the High-Level Goal
7. Defining Ready and Done
7.1 Ready for Development
7.2 Ready for System Test
7.3 How This Improved Collaboration
8. Handling Tech Stories
8.1 Example 1: System Test Bottleneck
8.2 Example 2: Day Before the Release
8.3 Example 3: The 7-Meter Class
9. Handling Bugs
9.1 Continuous System Test
9.2 Fix the Bugs Immediately
9.3 Why We Limit the Number of Bugs in the Bug Tracker
9.4 Visualizing Bugs
9.5 Preventing Recurring Bugs
10. Continuously Improving the Process
10.1 Team Retrospectives
10.2 Process Improvement Workshops
10.3 Managing the Rate of Change
11. Managing Work in Progress
11.1 Using WIP Limits
11.2 Why WIP Limits Apply Only to Features
12. Capturing and Using Process Metrics
12.1 Velocity (Features per Week)
12.2 Why We Don’t Use Story Points
12.3 Cycle Time (Weeks per Feature)
12.4 Cumulative Flow
12.5 Process Cycle Efficiency
13. Planning the Sprint and Release
13.1 Backlog Grooming
13.2 Selecting the Top Ten Features
13.3 Why We Moved Backlog Grooming Out of the Sprint Planning Meeting
13.4 Planning the Release
14. How We Do Version Control
14.1 No Junk on the Trunk
14.2 Team Branches
14.3 System Test Branch
15. Why We Use Only Physical Kanban Boards
16. What We Learned
16.1 Know Your Goal
16.2 Experiment
16.3 Embrace Failure
16.4 Solve Real Problems
16.5 Have Dedicated Change Agents
16.6 Involve People
PART II: A CLOSER LOOK AT THE TECHNIQUES
17. Agile and Lean in a Nutshell
17.1 Agile in a Nutshell
17.2 Lean in a Nutshell
17.3 Scrum in a Nutshell
17.4 XP in a Nutshell
17.5 Kanban in a Nutshell
18. Reducing the Test Automation Backlog
18.1 What to Do About It
18.2 How to Improve Test Coverage a Little Bit Each Iteration
18.3 Step 1: List Your Test Cases
18.4 Step 2: Classify Each Test
18.5 Step 3: Sort the List in Priority Order
18.6 Step 4: Automate a Few Tests Each Iteration
18.7 Does This Solve the Problem?
19. Sizing the Backlog with Planning Poker
19.1 Estimating Without Planning Poker
19.2 Estimating with Planning Poker
19.3 Special Cards
20. Cause-Effect Diagrams
20.1 Solve Problems, Not Symptoms
20.2 The Lean Problem-Solving Approach: A3 Thinking
20.3 How to Use Cause-Effect Diagrams
20.4 Example 1: Long Release Cycle
20.5 Example 2: Defects Released to Production
20.6 Example 3: Lack of Pair Programming
20.7 Example 4: Lots of Problems
20.8 Practical Issues: How to Create and Maintain the Diagrams
20.9 Pitfalls
20.10 Why Use Cause-Effect Diagrams?
21. Final Words
A1. Glossary: How We Avoid Buzzword Bingo
Index
Find out how the Swedish police combined XP, Scrum, and Kanban in a 60-person project. From start to finish, you'll see how to deliver a successful product using Lean principles.
We start with an organization in desperate need of a new way of doing things and finish with a group of sixty, all working in sync to develop a scalable, complex system. You'll walk through the project step by step, from customer engagement, to the daily "cocktail party," version control, bug tracking, and release. In this honest look at what works--and what doesn't--you'll find out how to:
Make quality everyone's business, not just the testers. Keep everyone moving in the same direction without micromanagement. Use simple and powerful metrics to aid in planning and process improvement. Balance between low-level feature focus and high-level system focus.
You'll be ready to jump into the trenches and streamline your own development process.
Contents
Foreword
Preface
PART I: HOW WE WORK
1. About the Project
1.1 Timeline 5
1.2 How We Sliced the Elephant 6
1.3 How We Involved the Customer 7
2. Structuring the Teams
3. Attending the Daily Cocktail Party
3.1 First Tier: Feature Team Daily Stand-up
3.2 Second Tier: Sync Meetings per Specialty
3.3 Third Tier: Project Sync Meeting
4. The Project Board
4.1 Our Cadences
4.2 How We Handle Urgent Issues and Impediments
5. Scaling the Kanban Boards
6. Tracking the High-Level Goal
7. Defining Ready and Done
7.1 Ready for Development
7.2 Ready for System Test
7.3 How This Improved Collaboration
8. Handling Tech Stories
8.1 Example 1: System Test Bottleneck
8.2 Example 2: Day Before the Release
8.3 Example 3: The 7-Meter Class
9. Handling Bugs
9.1 Continuous System Test
9.2 Fix the Bugs Immediately
9.3 Why We Limit the Number of Bugs in the Bug Tracker
9.4 Visualizing Bugs
9.5 Preventing Recurring Bugs
10. Continuously Improving the Process
10.1 Team Retrospectives
10.2 Process Improvement Workshops
10.3 Managing the Rate of Change
11. Managing Work in Progress
11.1 Using WIP Limits
11.2 Why WIP Limits Apply Only to Features
12. Capturing and Using Process Metrics
12.1 Velocity (Features per Week)
12.2 Why We Don’t Use Story Points
12.3 Cycle Time (Weeks per Feature)
12.4 Cumulative Flow
12.5 Process Cycle Efficiency
13. Planning the Sprint and Release
13.1 Backlog Grooming
13.2 Selecting the Top Ten Features
13.3 Why We Moved Backlog Grooming Out of the Sprint Planning Meeting
13.4 Planning the Release
14. How We Do Version Control
14.1 No Junk on the Trunk
14.2 Team Branches
14.3 System Test Branch
15. Why We Use Only Physical Kanban Boards
16. What We Learned
16.1 Know Your Goal
16.2 Experiment
16.3 Embrace Failure
16.4 Solve Real Problems
16.5 Have Dedicated Change Agents
16.6 Involve People
PART II: A CLOSER LOOK AT THE TECHNIQUES
17. Agile and Lean in a Nutshell
17.1 Agile in a Nutshell
17.2 Lean in a Nutshell
17.3 Scrum in a Nutshell
17.4 XP in a Nutshell
17.5 Kanban in a Nutshell
18. Reducing the Test Automation Backlog
18.1 What to Do About It
18.2 How to Improve Test Coverage a Little Bit Each Iteration
18.3 Step 1: List Your Test Cases
18.4 Step 2: Classify Each Test
18.5 Step 3: Sort the List in Priority Order
18.6 Step 4: Automate a Few Tests Each Iteration
18.7 Does This Solve the Problem?
19. Sizing the Backlog with Planning Poker
19.1 Estimating Without Planning Poker
19.2 Estimating with Planning Poker
19.3 Special Cards
20. Cause-Effect Diagrams
20.1 Solve Problems, Not Symptoms
20.2 The Lean Problem-Solving Approach: A3 Thinking
20.3 How to Use Cause-Effect Diagrams
20.4 Example 1: Long Release Cycle
20.5 Example 2: Defects Released to Production
20.6 Example 3: Lack of Pair Programming
20.7 Example 4: Lots of Problems
20.8 Practical Issues: How to Create and Maintain the Diagrams
20.9 Pitfalls
20.10 Why Use Cause-Effect Diagrams?
21. Final Words
A1. Glossary: How We Avoid Buzzword Bingo
Index
178 pages, Paperback
First published December 14, 2011
84 people are currently reading
2016 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 83 reviews
July 29, 2012
I could not stop reading this book.
With Scrum and XP from the trenches, Henrik wrote one of the most important books in the agile literature. He did not write big theory, he wrote what he did and what worked for him. He did the same for Scrum and Kanban from the trenches. With Lean from the trenches he went a step further, he wrote about one specific project.
A lot of people in the agile world are asking for horror stories, to learn when things go wrong. Henrik wrote about what he did to make things right. No fancy glorified things, just plain and simple what the team did.
After I read the book, I tweeted, "I could not stop reading Lean from the trenches" and now a few months later I can say, and I have already used a few of his ideas.
What I like about Henrik, is that he does not attempt to change the world by selling idea's he invents. He "simply" makes good use of the tools that are available to all of us. Now let there be no mistake, I'm sure it sound much easier in the book then it really was. I don't mind. Lean from the trenches shows me a big project can be run in a lean and agile way.
For people in the trenches of large enterprises, stories like this make a huge difference.
Henrik thank you for writing them.
With Scrum and XP from the trenches, Henrik wrote one of the most important books in the agile literature. He did not write big theory, he wrote what he did and what worked for him. He did the same for Scrum and Kanban from the trenches. With Lean from the trenches he went a step further, he wrote about one specific project.
A lot of people in the agile world are asking for horror stories, to learn when things go wrong. Henrik wrote about what he did to make things right. No fancy glorified things, just plain and simple what the team did.
After I read the book, I tweeted, "I could not stop reading Lean from the trenches" and now a few months later I can say, and I have already used a few of his ideas.
What I like about Henrik, is that he does not attempt to change the world by selling idea's he invents. He "simply" makes good use of the tools that are available to all of us. Now let there be no mistake, I'm sure it sound much easier in the book then it really was. I don't mind. Lean from the trenches shows me a big project can be run in a lean and agile way.
For people in the trenches of large enterprises, stories like this make a huge difference.
Henrik thank you for writing them.
March 7, 2019
It was a great read. Zero theory, just a case study why and how things from Lean and Agile were implemented in managing a big project. High signal to noise ratio.
April 30, 2013
I just wanted to read the first one or two chapters to get in the mood for work this worning. Well, I couldn't stop until it was finished. A great book with a lot of practical advice. This definitely is one of the best books on Lean/Agile that I've read so far. Highly recommendable (like pretty much everything by the author.)
And now I have to get some work done...
And now I have to get some work done...
July 12, 2014
One of the more down to earth, real world looks at lean and agile that I've come across. In the first half of the book, Kniberg outlines how his team used lean/agile to implement a software system for the Swedish police. He describes how the process evolved, what worked, what didn't, and why. There is no preaching and minimal buzzwords. Everything is explained through practice, trial and error, and experience, including the parts they had not figured out how to solve. It's refreshing to see a book like this with a real world account instead of an attempt to market the agile or lean concepts.
The book contains photos and diagrams that help visualize the concepts. The second part of the book has "in a nutshell definitions" if a few concepts, including scrum and xp.
Some nice quotes from the book:
I don’t claim that our way of working is perfectly Lean. Lean is a direction, not a place. It’s all about continuous improvement.
The key to minimizing risk in large projects is to find a way to “slice the elephant,” that is, find a way to release the system in small increments instead of saving up for a big-bang release at the end.
The project board is probably the single most important communication artifact in the project. It provides a high-level picture of what is going on in the project and illustrates flow and bottlenecks in real time.
The speed of a project is largely determined by how well everyone understands what’s going on. If everyone knows where we are right now and where we’re going, it’s much easier for everyone to move in the same direction.
If people can agree on a goal that they believe in, this has an immensely positive effect on self-organization and collaboration. Conversely, if people don’t understand the goal or don’t believe the goal is achievable, they will unconsciously disassociate themselves from the business goal and focus on personal goals such as “have fun coding” or “just get my part of the work done and go home.”
One of the classes in our code base was getting way out of control and needed some significant refactoring, but there was some resistance to spending time on that. So, one of the team leads printed out the whole class and laid it across the conference table! It was more than 7 meters long (23 feet)!
Our process was discovered rather than designed.
The nice thing about gut feel is that it often is a leading indicator of a problem that’s about to occur, while hard metrics often show a problem only after it has occurred.
Perfection is a direction, not a place!
A great process isn’t designed; it is evolved. So, the important thing isn’t your process; the important thing is your process for improving your process.
The book contains photos and diagrams that help visualize the concepts. The second part of the book has "in a nutshell definitions" if a few concepts, including scrum and xp.
Some nice quotes from the book:
I don’t claim that our way of working is perfectly Lean. Lean is a direction, not a place. It’s all about continuous improvement.
The key to minimizing risk in large projects is to find a way to “slice the elephant,” that is, find a way to release the system in small increments instead of saving up for a big-bang release at the end.
The project board is probably the single most important communication artifact in the project. It provides a high-level picture of what is going on in the project and illustrates flow and bottlenecks in real time.
The speed of a project is largely determined by how well everyone understands what’s going on. If everyone knows where we are right now and where we’re going, it’s much easier for everyone to move in the same direction.
If people can agree on a goal that they believe in, this has an immensely positive effect on self-organization and collaboration. Conversely, if people don’t understand the goal or don’t believe the goal is achievable, they will unconsciously disassociate themselves from the business goal and focus on personal goals such as “have fun coding” or “just get my part of the work done and go home.”
One of the classes in our code base was getting way out of control and needed some significant refactoring, but there was some resistance to spending time on that. So, one of the team leads printed out the whole class and laid it across the conference table! It was more than 7 meters long (23 feet)!
Our process was discovered rather than designed.
The nice thing about gut feel is that it often is a leading indicator of a problem that’s about to occur, while hard metrics often show a problem only after it has occurred.
Perfection is a direction, not a place!
A great process isn’t designed; it is evolved. So, the important thing isn’t your process; the important thing is your process for improving your process.
March 26, 2017
By far my most favorite kind of agile-related books. Maybe even a example of the only kind of agile books worth reading (once you get through classics).
Shortly speaking, this whole book is a case - a story of particular endeavor Henrik took part in. Some may call it project, it's good enough approximation. Henrik has sliced the whole thing into chapters about organization, most important challenges, process, learnings, etc. All the chapters are very "to-the-point", zero bullshit & contain some actual project visuals to help you get the essence.
Henrik seems very honest - I mean, I can't verify whether things he describes happened in exactly the written way, but what I can say is that:
* he doesn't pretend they did anything in the most zealous, "evangelic" way
* he emphasizes that mechanism that have been worked out were the result of evolution, not a generic prescription
On of key points of this book (IMHO) is to show that you'll get the best results if you truly understand the meaning & true reasons behind lean & agile values, not just frameworks & methods. Tailing, customizing & thinking on your own are much more important than having "100% of Scrum in Scrum".
Decent read, if you're really into the topic.
Shortly speaking, this whole book is a case - a story of particular endeavor Henrik took part in. Some may call it project, it's good enough approximation. Henrik has sliced the whole thing into chapters about organization, most important challenges, process, learnings, etc. All the chapters are very "to-the-point", zero bullshit & contain some actual project visuals to help you get the essence.
Henrik seems very honest - I mean, I can't verify whether things he describes happened in exactly the written way, but what I can say is that:
* he doesn't pretend they did anything in the most zealous, "evangelic" way
* he emphasizes that mechanism that have been worked out were the result of evolution, not a generic prescription
On of key points of this book (IMHO) is to show that you'll get the best results if you truly understand the meaning & true reasons behind lean & agile values, not just frameworks & methods. Tailing, customizing & thinking on your own are much more important than having "100% of Scrum in Scrum".
Decent read, if you're really into the topic.
January 23, 2020
Best agile-like book i had a chance to read. It's not a book for religious people that think Scrum is only when its 100% Scrum and when we have XP its XP... Its a book about practice, real-life example and how agile is agile.
That by driving a change by a need can lead to optimized version of agile for the current team, project, or company. And that we should just not blindly follow stupid rules when they are stupid. Charts? the heck with them if they are not providing value. You can't do X? why? if it works and it helps I can.
Highly recommended for anyone even not it related people. Books show how agile can help manage process of change and it's adaptable to current needs and requirements.
That by driving a change by a need can lead to optimized version of agile for the current team, project, or company. And that we should just not blindly follow stupid rules when they are stupid. Charts? the heck with them if they are not providing value. You can't do X? why? if it works and it helps I can.
Highly recommended for anyone even not it related people. Books show how agile can help manage process of change and it's adaptable to current needs and requirements.
December 18, 2020
Ce livre est écrit par un coach agile – n’arrêtez pas la lecture de cet article tout de suite, attendez de lire la suite. Il s’agit d’un ponte dans le domaine Henrick Kniberg. Comme l’indique la mention du titre From the Trenches il n’est pas question de nous abreuver de théories – et de techniques de collage de Post-It, oui ça existe – mais de nous faire vivre de l’intérieur l’organisation et la méthodologie mises en oeuvre dans le cadre d’un gros projet mené, pendant 3 ans, par la police suédoise afin de se doter d’un puissant logiciel qui devrait – on ne sait jamais avec l’informatique – leur permettre d’améliorer le coeur de leur activité – la rédaction des procès verbaux. Le sujet ne fait pas vraiment rêver, mais bon, j’adore ces histoires industrielles, je trouve qu’elles sont toujours riches d’enseignements. Pour les amateurs, je pense à
- Dreaming in Code qui raconte l’histoire d’un projet open source,
- The Goal qui est un roman graphique illustrant l’optimisation d’une usine,
- The Phoenix Project qui en est le digne successeur.
Ici, il s’agit avant tout d’un livre technique qui ne met pas en oeuvre les artifices d’un roman, mais qui s’attache à exploiter ce retour d’expérience pour en extraire les recettes méthodologiques qui ont contribuées à son succès.
Au centre de ce dispositif il me semble qu’il y a l’organisation autour du Kanban qui a été particulièrement travaillée pour aboutir à un résultat séduisant qui devrait pouvoir être réutilisé sans peine dans le cadre d’un autre projet informatique. La démarche de mise en oeuvre de la méthode est elle aussi fondamentale. On voit que la méthode a été mise au service du travail à réaliser et non l’inverse. Elle a donc servis de canevas, de base ou de référence – selon comment on souhaite nommer les choses – mais a été en permanence remaniée, corrigée et adaptée pour coller au mieux au besoin du projet et de ses intervenants. Il illustre également d’autres éléments plus classiques comme limiter le travail en cours (WIP pour Work In Progress et le fameux “Stop starting, start finishing”), mais toujours avec une approche plus pragmatique que dogmatique – en évitant toujours d’appliquer la méthodologie uniquement pour l’appliquer. Cette approche pragmatique se retrouve aussi par exemple dans la définition des métriques pour le suivi du projet qui se trouvent réduits à la substantifique moelle – less is more
- Velocity in features per week: Pas besoin d’être plus précis.
- Cycle time in weeks per feature: Combien de temps requiert la livraison d’une fonctionnalité.
Il est intéressant d’observer que le temps nécessaire à la fourniture de bout en bout d’une fonctionnalité est souvent 5 à 10 fois le temps nécessaire à sa mise en oeuvre (par exemple si une fonctionnalité requiert 5 jours de travail il faudra de 25 à 50 jours calendaires pour la livrer au client final). Grâce à ces mesures il est donc possible de mettre en évidences les goulets – ou goulots – d’étranglement. Ces mesures sont inspirées de la loi Little faisant partie de la théorie des files d’attentes.
Enfin il prouve que l’agilité ne doit pas faire oublier l’essentiel comme la structuration des équipes ou le respect des différentes phases de développement[1]. Une lecture éclairante pour soit se familiariser ou soit prendre du recul avec les méthodes agiles en bénéficiant d’un vrai retour d’expérience.
----
[1] Le livre se termine par des rappels méthodologiques concernant les principaux éléments méthodologiques abordés, l’une des plus intéressantes étant le diagramme de cause à effet ou A3 thinking.
Également publié sur mon blog.
- Dreaming in Code qui raconte l’histoire d’un projet open source,
- The Goal qui est un roman graphique illustrant l’optimisation d’une usine,
- The Phoenix Project qui en est le digne successeur.
Ici, il s’agit avant tout d’un livre technique qui ne met pas en oeuvre les artifices d’un roman, mais qui s’attache à exploiter ce retour d’expérience pour en extraire les recettes méthodologiques qui ont contribuées à son succès.
Au centre de ce dispositif il me semble qu’il y a l’organisation autour du Kanban qui a été particulièrement travaillée pour aboutir à un résultat séduisant qui devrait pouvoir être réutilisé sans peine dans le cadre d’un autre projet informatique. La démarche de mise en oeuvre de la méthode est elle aussi fondamentale. On voit que la méthode a été mise au service du travail à réaliser et non l’inverse. Elle a donc servis de canevas, de base ou de référence – selon comment on souhaite nommer les choses – mais a été en permanence remaniée, corrigée et adaptée pour coller au mieux au besoin du projet et de ses intervenants. Il illustre également d’autres éléments plus classiques comme limiter le travail en cours (WIP pour Work In Progress et le fameux “Stop starting, start finishing”), mais toujours avec une approche plus pragmatique que dogmatique – en évitant toujours d’appliquer la méthodologie uniquement pour l’appliquer. Cette approche pragmatique se retrouve aussi par exemple dans la définition des métriques pour le suivi du projet qui se trouvent réduits à la substantifique moelle – less is more
- Velocity in features per week: Pas besoin d’être plus précis.
- Cycle time in weeks per feature: Combien de temps requiert la livraison d’une fonctionnalité.
Il est intéressant d’observer que le temps nécessaire à la fourniture de bout en bout d’une fonctionnalité est souvent 5 à 10 fois le temps nécessaire à sa mise en oeuvre (par exemple si une fonctionnalité requiert 5 jours de travail il faudra de 25 à 50 jours calendaires pour la livrer au client final). Grâce à ces mesures il est donc possible de mettre en évidences les goulets – ou goulots – d’étranglement. Ces mesures sont inspirées de la loi Little faisant partie de la théorie des files d’attentes.
Enfin il prouve que l’agilité ne doit pas faire oublier l’essentiel comme la structuration des équipes ou le respect des différentes phases de développement[1]. Une lecture éclairante pour soit se familiariser ou soit prendre du recul avec les méthodes agiles en bénéficiant d’un vrai retour d’expérience.
----
[1] Le livre se termine par des rappels méthodologiques concernant les principaux éléments méthodologiques abordés, l’une des plus intéressantes étant le diagramme de cause à effet ou A3 thinking.
Également publié sur mon blog.
February 20, 2017
This book gives a great insight on how to run a project in an agile way: I recommend reading it while taking notes on what to apply to your projects. It covers a project for the Swedish police where a large-ish team of 60+ people were able to deliver a project changing how the police would do arrests on the go, from the laptops in their cars. They would do this using Kanban and a set of multiple physical whiteboards, together with following a series of good practices.
There were a number of things that I didn't like:
1. The agile coach writing the book arrived late into the project. While this doesn't invalidate his reasonings, it weakens them a bit
2. He is a clear advocate of collocation. I agree that collocation can be beneficial, but at this point and in this field, working remotely should be a valid choice
3. The size of the teams covered in this book is quite large, 60+ if I recall correctly. Adapting this into smaller teams could still work, but won't match 100%
4. The book covers a project developed for a known, internal customer: the Swedish police. In my experience, it is easier to deal with internal customers, while doing in-house development than with regular external customers
5. The writer proposes not tracking bugs, and instead fixing them ad-hoc, as part of the feature development. He also proposes dropping bugs if there are too many. While I agree with closing bugs as WONTFIX in order to prioritise work, there should be very good reasons for that
There were many great tips:
1. Engage, have a goal. If the goal is unrealistic, people will disassociate themselves to avoid failure. This is so true! Having impossible goals is one of the best ways to kill morale.
2. Come up with real actions to reach these goals (and no: working longer hours or working harder doesn't count).
3. Continuous testing! This is a must.
4. Automate testing to save time when testing time grows too long.
5. Use cards and point assignment when doing retrospective (e.g. every person is allowed to assign 3 dots. This is a good way to prioritise).
6. Process improvement proposal. This was a great idea. Basically the team should feel encouraged to come up with proposals, but these proposals should make clear what they are addressing, what they are fixing, and how they are doing it.
7. Measure velocity and cycle time. This is one way having a healthy Kanban can allow you to plan releases and estimate when a feature will be ready.
8. Backlog grooming: spending time (project leader & product owner) dropping / prioritising the backlog items, deciding which ones should be handled next.
There were a number of things that I didn't like:
1. The agile coach writing the book arrived late into the project. While this doesn't invalidate his reasonings, it weakens them a bit
2. He is a clear advocate of collocation. I agree that collocation can be beneficial, but at this point and in this field, working remotely should be a valid choice
3. The size of the teams covered in this book is quite large, 60+ if I recall correctly. Adapting this into smaller teams could still work, but won't match 100%
4. The book covers a project developed for a known, internal customer: the Swedish police. In my experience, it is easier to deal with internal customers, while doing in-house development than with regular external customers
5. The writer proposes not tracking bugs, and instead fixing them ad-hoc, as part of the feature development. He also proposes dropping bugs if there are too many. While I agree with closing bugs as WONTFIX in order to prioritise work, there should be very good reasons for that
There were many great tips:
1. Engage, have a goal. If the goal is unrealistic, people will disassociate themselves to avoid failure. This is so true! Having impossible goals is one of the best ways to kill morale.
2. Come up with real actions to reach these goals (and no: working longer hours or working harder doesn't count).
3. Continuous testing! This is a must.
4. Automate testing to save time when testing time grows too long.
5. Use cards and point assignment when doing retrospective (e.g. every person is allowed to assign 3 dots. This is a good way to prioritise).
6. Process improvement proposal. This was a great idea. Basically the team should feel encouraged to come up with proposals, but these proposals should make clear what they are addressing, what they are fixing, and how they are doing it.
7. Measure velocity and cycle time. This is one way having a healthy Kanban can allow you to plan releases and estimate when a feature will be ready.
8. Backlog grooming: spending time (project leader & product owner) dropping / prioritising the backlog items, deciding which ones should be handled next.
August 16, 2012
I liked this book, yet expected much more from it.
My definition of "large" is different from the one in the book (afai remember it was 70 developers on that project).
My definition of "lean" would not necessarily include the concept of a "project" in the first place...
Most of the ideas I've read about were not new to me—and this is obviously very subjective.
So while I did not learn as much from the book as I wanted, it still was worth the time, as Henrik's writing style is entertaining, and he tells a good story.
Among the many books out there which claim to give you a basic introduction on how to run an agile or lean endeavour, this still is one of the best (similar to Henrik's other books).
So while I only give it 3 stars, I know a lot of people to whom it will be a clear five: go and see for yourself.
My definition of "large" is different from the one in the book (afai remember it was 70 developers on that project).
My definition of "lean" would not necessarily include the concept of a "project" in the first place...
Most of the ideas I've read about were not new to me—and this is obviously very subjective.
So while I did not learn as much from the book as I wanted, it still was worth the time, as Henrik's writing style is entertaining, and he tells a good story.
Among the many books out there which claim to give you a basic introduction on how to run an agile or lean endeavour, this still is one of the best (similar to Henrik's other books).
So while I only give it 3 stars, I know a lot of people to whom it will be a clear five: go and see for yourself.
May 4, 2016
I picked this book to refresh my Kanban-fu, in order to help some co-workers with it. It's definitely work reading. Half of it is a case study – Kniberg goes over how they implemented a lean approach in a government project. I find this extremely interesting – knowing the principles is one thing, but applying them in context is a very different ordeal. I did learn a lot from it and I picked a bunch of great ideas. The rest is essentially a summary of all the "agile" ideas – Scrum, Lean, etc. They are useful, if you want a concise summary of the ideas you want to check every now and then. The caveat is that if you don't know anything about those, it will be too tricky to understand them, as he doesn't go into a lot of details and examples.
January 2, 2014
A great case study that shows how a real team working on a real project used agile, how they modified it as needed. It makes a strong case that your actual process isn't as important as how you incrementally improve your process. Also, each attempt at improving your process should be viewed as an experiment, and experiments are expected to fail sometimes; it just means you need to re-examine your hypothesis and try a different experiment.
Overall, the book had a lot of insights that could be applied to any team on the agile spectrum. It's an easy and enjoyable read, so there's really no downside to picking it up.
Overall, the book had a lot of insights that could be applied to any team on the agile spectrum. It's an easy and enjoyable read, so there's really no downside to picking it up.
January 9, 2016
Read it quickly to get the general idea of the process. I'm not a software developer so not in the best position to judge how helpful the specifics are but felt that the process itself was well conveyed and clear. The pictures and cartoons were good too, it felt like a good balance of theory and practice.
April 26, 2012
We have applied some topics such as synch meetings, cocktails meetings and kanban workflow covered on this book and results are being fantastic. on the other hand, metrics chapter should be better explained.
March 10, 2016
Excellent case study of a large scale agile project. Many practical advice with well explained and convincing rationale behind. Shows a good mix of scrum, XP, lean and kanban principles and practices.
August 20, 2012
In this book Kniberg shares his experience in applying agile.
While reading his experiences I've had many good insights of things to try with my own team.
While reading his experiences I've had many good insights of things to try with my own team.
October 11, 2016
Awesome good on Kanban method(agile dev). If you are a project manager this book will be really helpful.
January 23, 2019
Writing a book on software project management methodologies is not something to be taken lightly. One runs the risk of not satisfying anyone while trying to cater to the wishes of everyone. Even though the title and cover pages are 100% buzzword compliant, which is a warning sign by itself, Henrik Kniberg seems to have achieved a satisfying result in his book 'Lean from the Trenches: Managing Large-Scale Projects with Kanban'.
The good parts
The book is short. In 150 pages you cannot go into details and start theoretizing, and this is good because Kniberg promises to do one thing well and he delivers it: A case study of a 60-person software development team who used a mixture of Kanban, Agile (Scrum) and XP methodologies.
His explanations are generally clear and his definitons are sharp enough for practical purposes. He does not preach and never takes a 'here is the absolute truth, use it as it is' approach. He tells the his team's story and does not hide the parts that are still evolving.
The chapter 'Agile and Lean in a Nutshell' is one of the best chapters. In only 10 pages, this chapter succeeds to provide the reader with the essence of those methodologies. The subsection 'One Day in Kanban Land' is a very nice example of using simple visualizations and storytelling to explain a concept in very concrete terms.
The core ideas such as 'why WIP (Work In Progress) should be limited', 'how to reduce the test automation backlog', and 'cause effect diagrams' are very well explained. I have also liked the chapter where the author justifies their use of physical Kanban boards and how they scaled those boards to 60 people.
The bad parts
The book is short. Do not expect to find detailed theoretical and historical discussions on the different methodologies mentioned. You will definitely need at least a few other books to fill in the gaps.
At that page count, it is probably normal that the author did not go into the direction of deeper analysis, and especially talk about the details of problems they have solved, as well as other challenges he and his team encountered. Nevertheless, I believe enriching the book in that direction would only prove to add more value to the book.
The photographs, screenshots, diagrams, and index could be better, in color and titled. In its current form, they help to form the impression that the book has been very much rushed into production. That may be fine in terms of lean book production, or Agile Book Writing, or using Kanban to write a book, but the readers deserve more than that when they hold a book in its final form. Moreover, simply dropping footnotes at the end of a page and not creating a short References chapter is annoying because it prevents you from easily skimming those resources.
Conclusion
As a case study of a successful, real-life software development project that utilized Lean, Agile and Kanban, this is a book with very valuable lessons. It will probably be more helpful for decision makers such as software team leads and/or software project managers. It is not the reference for any of the software methodologies, but it stands as a very good evidence describing the daily operations of a relatively large team.
The good parts
The book is short. In 150 pages you cannot go into details and start theoretizing, and this is good because Kniberg promises to do one thing well and he delivers it: A case study of a 60-person software development team who used a mixture of Kanban, Agile (Scrum) and XP methodologies.
His explanations are generally clear and his definitons are sharp enough for practical purposes. He does not preach and never takes a 'here is the absolute truth, use it as it is' approach. He tells the his team's story and does not hide the parts that are still evolving.
The chapter 'Agile and Lean in a Nutshell' is one of the best chapters. In only 10 pages, this chapter succeeds to provide the reader with the essence of those methodologies. The subsection 'One Day in Kanban Land' is a very nice example of using simple visualizations and storytelling to explain a concept in very concrete terms.
The core ideas such as 'why WIP (Work In Progress) should be limited', 'how to reduce the test automation backlog', and 'cause effect diagrams' are very well explained. I have also liked the chapter where the author justifies their use of physical Kanban boards and how they scaled those boards to 60 people.
The bad parts
The book is short. Do not expect to find detailed theoretical and historical discussions on the different methodologies mentioned. You will definitely need at least a few other books to fill in the gaps.
At that page count, it is probably normal that the author did not go into the direction of deeper analysis, and especially talk about the details of problems they have solved, as well as other challenges he and his team encountered. Nevertheless, I believe enriching the book in that direction would only prove to add more value to the book.
The photographs, screenshots, diagrams, and index could be better, in color and titled. In its current form, they help to form the impression that the book has been very much rushed into production. That may be fine in terms of lean book production, or Agile Book Writing, or using Kanban to write a book, but the readers deserve more than that when they hold a book in its final form. Moreover, simply dropping footnotes at the end of a page and not creating a short References chapter is annoying because it prevents you from easily skimming those resources.
Conclusion
As a case study of a successful, real-life software development project that utilized Lean, Agile and Kanban, this is a book with very valuable lessons. It will probably be more helpful for decision makers such as software team leads and/or software project managers. It is not the reference for any of the software methodologies, but it stands as a very good evidence describing the daily operations of a relatively large team.
December 2, 2018
I've liked it mainly for two reasons:
1) It's not 'religious' or black and white only. We can read about different methodologies or techniques for project management, but nothing is treated as a silver bullet. Everything has pros and cons and author states it clearly
2) It has 'this worked for us because' parts. There are many books that say you should do XYZ because it's good. But they don't try enough to explain why. Here you have a story of existing project. You can read what worked, what not and how they have tweaked things along the way.
1) It's not 'religious' or black and white only. We can read about different methodologies or techniques for project management, but nothing is treated as a silver bullet. Everything has pros and cons and author states it clearly
2) It has 'this worked for us because' parts. There are many books that say you should do XYZ because it's good. But they don't try enough to explain why. Here you have a story of existing project. You can read what worked, what not and how they have tweaked things along the way.
February 24, 2019
Despite being short and simple the book is really great for both starters of Agile and people who are practicing it and looking for more answers. First part consists of 1 big example running a project under certain circumstances. For starters it helps to grasp a picture what Agile is and for practices - gives broader spectrum of tools/techniques to apply. Second part is short and consists of theory of what Agile is. Most probably would be useful only for starters.
July 2, 2020
I am not a programmer, but work fairly closely with our small company's engineering team. This was quick, accessible, and helpful read. Some of the technical stuff was just a little bit over my head or not directly relevant to my role, but it all helped me understand our planning and release processes better and gave me some ideas for better optimizing my team's projects and processes using Trello (a digital Kanban board tool).
November 17, 2022
A lot of content is very superficial, can not establish a system
For example, the daily station meeting is said to follow the scrum kind of questioning, but what are you going to do today, what did you do yesterday, what problems you encountered, these can be directly known from the github, station meeting should focus on the overall progress, not personal progress
I recommend reading Lean Priduct Development by 何勉(only the Chinese version)
For example, the daily station meeting is said to follow the scrum kind of questioning, but what are you going to do today, what did you do yesterday, what problems you encountered, these can be directly known from the github, station meeting should focus on the overall progress, not personal progress
I recommend reading Lean Priduct Development by 何勉(only the Chinese version)
July 25, 2018
among all the books on lean,xp and scrum this is the most down to earth book i've read.
there are a lot of examples and experiences shared by the author and these are helping a lot to understand how things are working in practice.
i highly recommend it to anyone who is just starting to learn about these topics or wants to improve his practice of them.
there are a lot of examples and experiences shared by the author and these are helping a lot to understand how things are working in practice.
i highly recommend it to anyone who is just starting to learn about these topics or wants to improve his practice of them.
March 10, 2019
Light and useful read
Just like with his previous success Scrum from the trenches this book gives you a practical example of how to approach Kanban. It's written well but informally making it a light and instructive read.
As it's not a huge investment and provides good practical experience to draw from, a definite recommend
Just like with his previous success Scrum from the trenches this book gives you a practical example of how to approach Kanban. It's written well but informally making it a light and instructive read.
As it's not a huge investment and provides good practical experience to draw from, a definite recommend
February 9, 2018
This is a nice book on how to put agile principles, specially Kanban, into software development practice. Content is very pragmatic and easy read. Highly recommended and can be referred again and again.
February 3, 2020
Very concise book with practical examples and a lot of explained techniques. Great summaries for lean, agile, scrum, xp, kanban.
Highly recommended.
- Know your goal
- Experiment
- Embrace failure
- Solve real problems
- Have dedicated change agent
- Involve people
Highly recommended.
- Know your goal
- Experiment
- Embrace failure
- Solve real problems
- Have dedicated change agent
- Involve people
July 8, 2020
A case study of PUST software builds for Swedish police using Agile. For me the biggest take was on defining "Ready and Done" and you don't need fancy software to implement to follow agile. A good quick read for the beginner.
June 13, 2017
A useful case study on implementing Kanban into a software development company. Holds many advices.
October 14, 2017
Very practical, but the focus isn't clear to me. It's a case about success with kanban and scrum in a big (very big) project
August 11, 2018
A good practical book from Henrik Knieberg (who has a lot of knowledge on Agile) how they've used Kanban for a big project. Recommended to people who like Kanban.
October 22, 2018
Cool case study written in quite narrative style. Hands-on and useful! Love it!
Displaying 1 - 30 of 83 reviews