What do you think?
Rate this book
Kanban: Successful Evolutionary Change for Your Technology Business
Book by David J. Anderson
262 pages, Paperback
First published April 7, 2010
About the author
David J. Anderson
26 books61 followersLibrarian Note: There is more than one author by this name in the Goodreads database.
David is an innovator in management thinking for 21st Century businesses. Author and pioneer of the Kanban Method he has more than 30 years’ experience working in the high-technology industry. David previously worked at IBM, Sprint, Motorola, and Microsoft where he developed the Kanban Method to greatly improving business outcomes on an enterprise-scale.
Originator of the Kanban Method, and co-creator of the Kanban Maturity Model, the Fit-for-Purpose Framework, and Enterprise Services Planning. David is a global leader in management training and leadership development for professional services, and intangible goods industries.
He is the author of 7 leading books for modern business with the most renowned being published in 2010 “KANBAN: Successful Evolutionary Change for Your Technology Business” which is in the top 5 best-selling Agile books of all time.
David also founded Kanban University, which includes over 400 accredited trainers and consultants. In addition, he created multiple global Kanban conferences and is the Chairman of the David J. Anderson School of Management which provides training in 21st-century business practices for enterprise agility, business resilience, and organizational maturity.
The group of companies founded by David is held within Mauvius Group Inc. This group of companies is focused on improving the quality of management, leadership, and decision making for 21st-century businesses.
David is an innovator in management thinking for 21st Century businesses. Author and pioneer of the Kanban Method he has more than 30 years’ experience working in the high-technology industry. David previously worked at IBM, Sprint, Motorola, and Microsoft where he developed the Kanban Method to greatly improving business outcomes on an enterprise-scale.
Originator of the Kanban Method, and co-creator of the Kanban Maturity Model, the Fit-for-Purpose Framework, and Enterprise Services Planning. David is a global leader in management training and leadership development for professional services, and intangible goods industries.
He is the author of 7 leading books for modern business with the most renowned being published in 2010 “KANBAN: Successful Evolutionary Change for Your Technology Business” which is in the top 5 best-selling Agile books of all time.
David also founded Kanban University, which includes over 400 accredited trainers and consultants. In addition, he created multiple global Kanban conferences and is the Chairman of the David J. Anderson School of Management which provides training in 21st-century business practices for enterprise agility, business resilience, and organizational maturity.
The group of companies founded by David is held within Mauvius Group Inc. This group of companies is focused on improving the quality of management, leadership, and decision making for 21st-century businesses.
Ratings & Reviews
Friends & Following
Create a free account to discover what your friends think of this book!
Community Reviews
Displaying 1 - 30 of 143 reviews
December 24, 2017
This is a game changer. Agile is a culture, and it has frameworks such as XP, Crystal, and Scrum that are superb at handling software development projects with a clearly defined goal.
But they are not so good at handling support and maintenance work - the stream of random sized bits and pieces. What do you do if that's a major portion of your day-to-day work?
David Anderson has laid out his experience in how to use a very different approach to make workloads visible, limit what's in progress to expose bottlenecks, focus on improving quality, reducing waste, improving predictability, and increasing trust with stakeholders and overall organizational maturity.
It's a dense book there's lots of goodness packed into it. It's also the first (certainly that I've read) that's shown how Kanban can be a complete approach to all software work.
I very strongly recommend this book.
It's a permanent reference on my desk now, and I'm helping a shop of about 50 developers move from Waterfall/cowboy to agile in the face of almost no agreement - their a stodgy lot! But by using Kanban, it's working, and we're seeing improvements and buy-in as people realize the benefits of not being hated by their stakeholders and actually getting home on time!
But they are not so good at handling support and maintenance work - the stream of random sized bits and pieces. What do you do if that's a major portion of your day-to-day work?
David Anderson has laid out his experience in how to use a very different approach to make workloads visible, limit what's in progress to expose bottlenecks, focus on improving quality, reducing waste, improving predictability, and increasing trust with stakeholders and overall organizational maturity.
It's a dense book there's lots of goodness packed into it. It's also the first (certainly that I've read) that's shown how Kanban can be a complete approach to all software work.
I very strongly recommend this book.
It's a permanent reference on my desk now, and I'm helping a shop of about 50 developers move from Waterfall/cowboy to agile in the face of almost no agreement - their a stodgy lot! But by using Kanban, it's working, and we're seeing improvements and buy-in as people realize the benefits of not being hated by their stakeholders and actually getting home on time!
September 26, 2019
I THINK it's a good read. I found it practical and easy to understand, even THOUGH I'm not a big fan of computer books, I'm more into docmuentation and technical manuals.
June 20, 2013
Hi. I'm a software developer. I've been writing software professionally for more than 15 years now. One of my favorite books about the practice of software development for business is Extreme Programming Explained by Kent Beck , which refreshingly upended a lot of conventional wisdom about software development, focusing effort on activities that add value for customers. In the intervening years, many of the practices promoted in that book have become commonplace, mostly notably test driven development. Extreme Programming itself never really got much traction, but many of its ideas were taken up by a family of practices more generally known as "agile". "Agile" itself remains somewhat controversial while also becoming so general that it's not quite clear what it means anymore. Scrum, the most popular flavour of agile, took a lot of the extreme programming practices for organizing teams and placed emphasis on commitment. Scrum-style sprints are commonplace. You guys all know this stuff though. I don't know why I'm even typing it!
So, this is the environment that produced Kanban, which is a fusion of agile methods and lean management principles.
The last place I worked used some Scrum, but honestly, most of the management wasn't really up-to-speed on the finer points of Scrum and tended to rely on experience and organizational inertia to set policies, so it's hard to say that what we were doing was Scrum. Compared to that environment, however, I see a lot to like in Kanban. A basic principle of Kanban is that work-in-progress is limited to a fixed number of items, in order to reduce complexity and increase the predictability of delivery and therefore shorten lead times. One of the effects of this is to highlight bottlenecks, as it is plain to everyone exactly where in the process work is piling up. Then, idle resources (that is, people) can change processes to help work to move through the bottleneck more quickly.
This Kanban book takes extremely high quality as measured in defects and test coverage as something of a given and focuses on work exactly one level up from there. It is assume that the dev. team knows how to do their work, but that they are in danger of being tasked with too much unimportant work. The author discusses what happens on teams very little, and devotes a lot of space to how work is prioritized between different groups within an organization.
Talking about all of this with a helpful colleague recently, he pointed out that all of these methodologies require organizations to have discipline. Managers from top-to-bottom have to be able to make plans and follow through on them, and tirelessly ensure that their efforts align with customer needs. If you can do that, you will be able to implement any of the agile methodologies with success. Without it, you can't implement anything. I can see how something like Kanban can be used to gradually increase trust and communication in an organization until that kind of discipline is achieved, but I've never ever seen this actually happen. Does it ever happen?
I don't mean any of this to be negative, though. There's a lot to like in Kanban. Anderson dispenses with estimation of tasks by and large, replacing it with statistical averages. For a given team, he says, a development task will take between n and m days p percent of the time, e.g., from 1 to 3 days 90% of the time, which is really all the information a management team needs for planning if lead times are short enough. Anderson also eliminates iterations or sprints, which made sense when integration and deployment and planning of the next unit of work were expensive activities. Decoupling deployment from features completion and planning enables a continuous development cadence. Anderson also emphasizes trust instead of commitment. A great deal of the success of a Kanban team seems to stem from the ability of the team to self-organize based on the visualization of the flow of work and the policies.
Separating Kanban the methodology from the book for a moment, well, I think there will be a much better, more approachable book about Kanban sometime in the future, but whoever writes it will probably call the methodology something else in order to control their own brand. That is what I predict.
So, this is the environment that produced Kanban, which is a fusion of agile methods and lean management principles.
The last place I worked used some Scrum, but honestly, most of the management wasn't really up-to-speed on the finer points of Scrum and tended to rely on experience and organizational inertia to set policies, so it's hard to say that what we were doing was Scrum. Compared to that environment, however, I see a lot to like in Kanban. A basic principle of Kanban is that work-in-progress is limited to a fixed number of items, in order to reduce complexity and increase the predictability of delivery and therefore shorten lead times. One of the effects of this is to highlight bottlenecks, as it is plain to everyone exactly where in the process work is piling up. Then, idle resources (that is, people) can change processes to help work to move through the bottleneck more quickly.
This Kanban book takes extremely high quality as measured in defects and test coverage as something of a given and focuses on work exactly one level up from there. It is assume that the dev. team knows how to do their work, but that they are in danger of being tasked with too much unimportant work. The author discusses what happens on teams very little, and devotes a lot of space to how work is prioritized between different groups within an organization.
Talking about all of this with a helpful colleague recently, he pointed out that all of these methodologies require organizations to have discipline. Managers from top-to-bottom have to be able to make plans and follow through on them, and tirelessly ensure that their efforts align with customer needs. If you can do that, you will be able to implement any of the agile methodologies with success. Without it, you can't implement anything. I can see how something like Kanban can be used to gradually increase trust and communication in an organization until that kind of discipline is achieved, but I've never ever seen this actually happen. Does it ever happen?
I don't mean any of this to be negative, though. There's a lot to like in Kanban. Anderson dispenses with estimation of tasks by and large, replacing it with statistical averages. For a given team, he says, a development task will take between n and m days p percent of the time, e.g., from 1 to 3 days 90% of the time, which is really all the information a management team needs for planning if lead times are short enough. Anderson also eliminates iterations or sprints, which made sense when integration and deployment and planning of the next unit of work were expensive activities. Decoupling deployment from features completion and planning enables a continuous development cadence. Anderson also emphasizes trust instead of commitment. A great deal of the success of a Kanban team seems to stem from the ability of the team to self-organize based on the visualization of the flow of work and the policies.
Separating Kanban the methodology from the book for a moment, well, I think there will be a much better, more approachable book about Kanban sometime in the future, but whoever writes it will probably call the methodology something else in order to control their own brand. That is what I predict.
April 5, 2017
Несколько полезных идей есть, но о них скучно читать, нужно пробовать на практике. В остальном такие книги выглядят как вода-вода-вода-используйте стикеры разного цвета-а вот мы в 2005 году добились таких цифр!-спринты-agile-кайдзен-вода.
September 24, 2018
К огромному сожалению всего двойка. Три звезды – это уже "like it". Не могу сказать, что ай лайк ит эт ол! Большое разочарование.
Книга хоть и разбита на главы, но материал подаётся, как одна большая простыня. Без какой-то схемы, как я привык, будучи инженером. Каша! Некоторые главы вообще не понимаю, зачем туда помещены. Например, первые две или три(!) главы просто расхваливают канбан, чуть-чуть приправляя это историями. Ребята, я уже купил книгу про канбан. Зачем мне его рекламировать?!
Больше напомнило какое-то огромное интервью с опытным практиком.
Безусловно, есть очень полезная информация. Но в целом книга – плохая. Разобраться и начать применять канбан по ней сложно.
Книга хоть и разбита на главы, но материал подаётся, как одна большая простыня. Без какой-то схемы, как я привык, будучи инженером. Каша! Некоторые главы вообще не понимаю, зачем туда помещены. Например, первые две или три(!) главы просто расхваливают канбан, чуть-чуть приправляя это историями. Ребята, я уже купил книгу про канбан. Зачем мне его рекламировать?!
Больше напомнило какое-то огромное интервью с опытным практиком.
Безусловно, есть очень полезная информация. Но в целом книга – плохая. Разобраться и начать применять канбан по ней сложно.
August 27, 2012
I could feel my brain getting bigger while I read this book. I agree with the author when he claims that Kanban is the first real major innovation in Agile Software Development in 10 years. This book gave me enough new ideas that I can't wait to get back to work to implement them!
September 21, 2018
Канбан — это гибкий инструмент управления, пришедший от компании Toyota. В последние несколько десятилетий он стал очень популярен в IT-индустрии, наряду с другими гибкими методологиями. Дэвид Андерсон уже 30 лет работает в IT, и многие годы является адептом методологии Канбан. Само название книги «Канбан. Альтернативный путь в Agile» говорит о том, что тут нам расскажут и о методологии, и о лучших способах её применения. Как минимум, таковы были мои ожидания. Тем более, что во всех аннотациях её хвалят какие-то эксперты.
Однако мне книга тяжело давалась с первых страниц. Я всё же дочитал, чтобы мнение было полным, но скорее утвердился в нём, чем изменил.
Начнём с того, что язык книги — очень сухой. Да, это не беллетристика, однако существует множество книг и по менджменту, и по программированию, которые читаются легко и интересно. Эта книга — совсем не такая.
Также примерно на середине книги складывается впечатление, что у автора комплекс, так часто он упоминает, в каких компаниях работал, над какими проектами. Причём повторяет по сути одно и то же. Словно бы восхваляет себя. Вкупе с сухостью текста это воспринимается порой как «Что, вам скучно? Читайте, ведь я же великий ГУРУ Канбана». Большая часть глав начинается с того, что «вот когда я работал там-то, то мы…»
Отдельно стоит упомнять иллюстрации. Их вроде бы и много, но по большей части они бесполезны. Канбан строится на понятии карточек задач. Автор подробно рассказывает, что на карточках стоит писать и как. И приводит примеры в виде фотографий. Только почти везде это фотографии досок издали, где ты видишь, что да, там какие-то карточки. А уж если он говорит, что «вот у нас пример цветового оформления», а на картинке что-то в серых тонах, порой даже один серый от другого не отличить…. ну, как-то странно воспринимаешь. Я уж думал, что это проблема русской версии, ан нет, в западных рецензиях тоже на эту странность обращают внимание.
Ну да ладно, это могут быть придирки. В книге действительно есть полезные примеры использования. Однако всё это подано так, что вот совсем не хочется взять и начать внедрять. Я сам использую Канбан в работе, пусть и не в полную силу. И читал другие книги об этой методологии, не в пример более короткие и более воодушевляющие. А эта книга нагнетает тоску, но никак не воодушевляет вот прямо сейчас пойти и начать внедрять.
Особенно анекдотично выглядит пример самого же автора, что в одной из компаний, где он активно внедрял Канбан, его прекратили использовать сразу же после ухода автора из компании. Если все менеджеры так проникались его идеями, а культура в компании из-за внедрения Канбана стала располагать к доверию, почему же всё вдруг изменилось в один час?
В общем, книгу не рекомендую. Лучше посмотреть иные работы по теме, например, «Kanban and Scrum — Making the Most of Both«. В несколько раз короче, доходчивее, с простыми примерами и значительно менее пафосная. Да ещё и бесплатно распространяемая.
Однако мне книга тяжело давалась с первых страниц. Я всё же дочитал, чтобы мнение было полным, но скорее утвердился в нём, чем изменил.
Начнём с того, что язык книги — очень сухой. Да, это не беллетристика, однако существует множество книг и по менджменту, и по программированию, которые читаются легко и интересно. Эта книга — совсем не такая.
Также примерно на середине книги складывается впечатление, что у автора комплекс, так часто он упоминает, в каких компаниях работал, над какими проектами. Причём повторяет по сути одно и то же. Словно бы восхваляет себя. Вкупе с сухостью текста это воспринимается порой как «Что, вам скучно? Читайте, ведь я же великий ГУРУ Канбана». Большая часть глав начинается с того, что «вот когда я работал там-то, то мы…»
Отдельно стоит упомнять иллюстрации. Их вроде бы и много, но по большей части они бесполезны. Канбан строится на понятии карточек задач. Автор подробно рассказывает, что на карточках стоит писать и как. И приводит примеры в виде фотографий. Только почти везде это фотографии досок издали, где ты видишь, что да, там какие-то карточки. А уж если он говорит, что «вот у нас пример цветового оформления», а на картинке что-то в серых тонах, порой даже один серый от другого не отличить…. ну, как-то странно воспринимаешь. Я уж думал, что это проблема русской версии, ан нет, в западных рецензиях тоже на эту странность обращают внимание.
Ну да ладно, это могут быть придирки. В книге действительно есть полезные примеры использования. Однако всё это подано так, что вот совсем не хочется взять и начать внедрять. Я сам использую Канбан в работе, пусть и не в полную силу. И читал другие книги об этой методологии, не в пример более короткие и более воодушевляющие. А эта книга нагнетает тоску, но никак не воодушевляет вот прямо сейчас пойти и начать внедрять.
Особенно анекдотично выглядит пример самого же автора, что в одной из компаний, где он активно внедрял Канбан, его прекратили использовать сразу же после ухода автора из компании. Если все менеджеры так проникались его идеями, а культура в компании из-за внедрения Канбана стала располагать к доверию, почему же всё вдруг изменилось в один час?
В общем, книгу не рекомендую. Лучше посмотреть иные работы по теме, например, «Kanban and Scrum — Making the Most of Both«. В несколько раз короче, доходчивее, с простыми примерами и значительно менее пафосная. Да ещё и бесплатно распространяемая.
June 1, 2018
A lot of management practices seem somehow oppressive and cultish. TPS reports, Six Sigma, Lean, Agile, and Scrum. I can't say much about those, but I really enjoyed a workshop on Kanban, and this book was in the bibliography.
Kanban is Japanese for signal ticket. The Imperial Palace Garden has a box of tickets equal to the maximum number of visitors, and if there are no tickets, you must wait for someone leaving the park to drop theirs in the entrance. In management practice, Kanban is a pull-system, where the effective throughput of an organization is estimated, and tasks are pulled from initialization to completion. A large whiteboard of tickets (or digital equivalent) serves to self-organize the workflow, identifying blockages, slacks, and bottlenecks, without hefty managerial overhead.
Anderson describes several near miraculous management turnarounds he saw as part of major tech companies (Microsoft, Sprint), and a smaller stock photo company he was part of. Kanban, when properly implemented, increased the speed by which tasks where accomplished, decreased errors, improved moral, and created resilience and constant quality improvement. Kanban, and management by pull and flow, feels counter-intuitive at first, but I can sense a deep elegance to their logical principles.
The problem with this book is, even after attending a Kanban workshop, and even inclined to be generous to the method, I'm not sure that I know enough to actually implement Kanban. Heck, I'm not even sure that I know enough to properly cargo-cult Kanban, aside from sticky notes on a whiteboard. I'm sure it's good management practice, I'm just not convinced this is the book to explain it.
Kanban is Japanese for signal ticket. The Imperial Palace Garden has a box of tickets equal to the maximum number of visitors, and if there are no tickets, you must wait for someone leaving the park to drop theirs in the entrance. In management practice, Kanban is a pull-system, where the effective throughput of an organization is estimated, and tasks are pulled from initialization to completion. A large whiteboard of tickets (or digital equivalent) serves to self-organize the workflow, identifying blockages, slacks, and bottlenecks, without hefty managerial overhead.
Anderson describes several near miraculous management turnarounds he saw as part of major tech companies (Microsoft, Sprint), and a smaller stock photo company he was part of. Kanban, when properly implemented, increased the speed by which tasks where accomplished, decreased errors, improved moral, and created resilience and constant quality improvement. Kanban, and management by pull and flow, feels counter-intuitive at first, but I can sense a deep elegance to their logical principles.
The problem with this book is, even after attending a Kanban workshop, and even inclined to be generous to the method, I'm not sure that I know enough to actually implement Kanban. Heck, I'm not even sure that I know enough to properly cargo-cult Kanban, aside from sticky notes on a whiteboard. I'm sure it's good management practice, I'm just not convinced this is the book to explain it.
March 22, 2016
A lot of the time, this felt like it was written by that experienced coworker who starts every offered solution with, " Well, when I was at Ginormosoft, we handled this by..." After a while, you find someone else to bounce things off of just to avoid the inevitable jaunt down memory lane.
I liked some of the ideas presented, but the presentation was difficult to slog through. I don't know if it's because it seems like a simple system made too complex, or if I just don't understand the system enough to understand the complexities.
Or maybe it's too wordy. Or maybe it says things like "...as is represented by a green ticket in figure 16-1" when figure 16-1 is a smattering of grey tickets. Or maybe it's the bar charts that use white, grey, black, looks like black, and probably is black.
In any case, it seems like the author knows his stuff, but this book just wasn't for me.
I liked some of the ideas presented, but the presentation was difficult to slog through. I don't know if it's because it seems like a simple system made too complex, or if I just don't understand the system enough to understand the complexities.
Or maybe it's too wordy. Or maybe it says things like "...as is represented by a green ticket in figure 16-1" when figure 16-1 is a smattering of grey tickets. Or maybe it's the bar charts that use white, grey, black, looks like black, and probably is black.
In any case, it seems like the author knows his stuff, but this book just wasn't for me.
October 9, 2021
A little on the dry side in some chapters, but also really eye opening as someone who has been involved only in Agile methodologies. Most of the concepts in this book could easily be tweaked to work with Agile, and in fact I've already used a lot of the concepts in my day-to-day (especially the various Kanban KPIs). I would highly recommend this book to Project Managers, Scrum Masters, and Engineering Managers who are in search of improved workflows and ideas for faster product velocity.
October 22, 2018
Super cool! Instant application and one can see a major improvement in the process. The hard part is that the underlying principle is very broad and requires one to read multiple sources of books to understand.
Would recommend to anyone in any field striving for an optimal work-life!
Would recommend to anyone in any field striving for an optimal work-life!
October 29, 2021
Read this book at work and tried out some of the principles. The book itself is a bit repetitive, but I do think there's lots of good ideas for improving team processes.
February 17, 2021
Este, como quase todo livro não literário, pode ser resumido em textos menores com quase todas as mesmas informações. Tecnicamente o ebook Essential Kanban Condensed disponível no site do Lean Kanban (https://leankanban.com/guide) tem o mesmo conteúdo.
Ler este livro é importante para entender porque, mesmo aplicando um conhecimento "by the book", seguindo todas as regras, seu projeto pode fracassar. As pessoas, a empresa e até a cultura do país onde você está importam. Essa é uma das coisas legais do Kanban: o contexto importa. Dado que temos um contexto, como podemos a partir dele, melhorar?
Ler este livro é importante para entender porque, mesmo aplicando um conhecimento "by the book", seguindo todas as regras, seu projeto pode fracassar. As pessoas, a empresa e até a cultura do país onde você está importam. Essa é uma das coisas legais do Kanban: o contexto importa. Dado que temos um contexto, como podemos a partir dele, melhorar?
June 1, 2015
An excellent guide to implementing a kanban system for software delivery, with my preferred mix of theoretical background and practical lessons. Despite having a comic on the cover, this is a pretty serious book with an intended audience of individuals fairly experienced with project management. I read this having worked on a few projects that used kanban but had left me with the open question: how do you go from X to kanban? And this book provides sound answers to that question. Highly recommended.
October 17, 2012
The Kanban method described by the author seems promising as a way to improve the performance of teams. However, I think there was too much anecdotal evidence about the benefits so it would nice to see some more hard numbers.
February 16, 2015
Overly complex for something that should be even simpler than Scrum. It seems also somewhat disconnected from the fact that we are delivering software systems. Explanations are too generic.
December 29, 2017
"It'll take you an afternoon to read this," Matt said. Totally - if an afternoon = one year and three months. My beloved recommended this book on kanban, a change-management/work-flow system that originated at Toyota in Japan in the 1940s, because he's used it successfully in his IT career and thought we could bring it into my work to increase efficiency and alleviate stress. I like the kanban philosophy and enjoyed the real-life examples in this book, but the parts where the author delved deep into business/tech jargon had my eyes glazing over. It was good for me to read outside my comfort zone, though - doubly so because I read it on Matt's iPad and I'm usually anti-ebook for myself. And I learned a lot about Matt's work world and now understand more of his techie lingo, so that's another bonus.
Unfortunately, I don't see my whole office adopting kanban, but I personally would like to implement some of its ideals and principles in my own work and leadership as an editor. My favorite is the Japanese concept of kaizen, or continuous improvement/optimization, and its inherent focus on collaboration and teamwork over the individual. I'd recommend this book to anyone who would self-identify as a businessperson.
Unfortunately, I don't see my whole office adopting kanban, but I personally would like to implement some of its ideals and principles in my own work and leadership as an editor. My favorite is the Japanese concept of kaizen, or continuous improvement/optimization, and its inherent focus on collaboration and teamwork over the individual. I'd recommend this book to anyone who would self-identify as a businessperson.
May 10, 2020
David Anderson is a Kanban evangelist. What follows in the book is a prescriptive step-by-step guide to bootstrapping a Kanban system for a single value chain in an organisation. It is worth noticing that Kanban is not a software development lifecycle process or a project-management process but a change-management technique to the existing processes. Anderson shares know-how with examples of approaches, attitudes, even conversation templates, based on his own observations of working teams. He covers all aspects of the collaborative game of software development. I know this, as I am a software engineer myself. One could find many nitty-gritty exposures of the differences between Kanban and today’s popular Scrum or even traditional project management. Furthermore, it proves that Kurl Lewis was right when saying “there is nothing as practical as a good theory”. If you happen to have something to do with lean software development, then this book is highly recommended for a place on your bookshelf.
June 11, 2021
This year I started to read it from scratch (second chance) And I really found some answers to a couple of doubts about agile. Kanban, unlike Scrum, is a system, it means that it tells you how to implement the complete activities. The card wall, not Kanban board, is the core of the system and the detail level and the careful they manage it is almost religious, too much for me. The objective is to visualize and become transparent the workflow, work items, assignee, status, work type, estimation, blocker points, etc.
In addition to the workflow, the author also covers metrics, variability causes, and continuos improvement.
The only doubt I also have is about how to prevent agile fatigue? Kanban does not include a traditional agile time box that end with a retrospective like Scrum. It could be that working without closing a cycle may give a sensation of a work that never ends.
In addition to the workflow, the author also covers metrics, variability causes, and continuos improvement.
The only doubt I also have is about how to prevent agile fatigue? Kanban does not include a traditional agile time box that end with a retrospective like Scrum. It could be that working without closing a cycle may give a sensation of a work that never ends.
This entire review has been hidden because of spoilers.
December 25, 2017
I was disappointed in this book, but it did have some helpful information about Kanban, how it works, and what its goals are.
My main complaint is that it doesn’t start with the why. Instead, it’s a meandering explanation of the how that’s occasionally accompanied by the why. Given the un-empirical nature of software development process books, this is s huge disappointment.
Kanban seeks to establish predictability and agility in the software development process, above all else. Management and partners value predictability, so they are prioritized. By tracking items according to their type, limiting work in progress, and eschewing a backlog in favor of a queue, Kanban trades throughout for predictability.
My main complaint is that it doesn’t start with the why. Instead, it’s a meandering explanation of the how that’s occasionally accompanied by the why. Given the un-empirical nature of software development process books, this is s huge disappointment.
Kanban seeks to establish predictability and agility in the software development process, above all else. Management and partners value predictability, so they are prioritized. By tracking items according to their type, limiting work in progress, and eschewing a backlog in favor of a queue, Kanban trades throughout for predictability.
June 1, 2018
This is the only book that I have read about Kanban/kanban and it was a good one. Anderson does a great job at explaining all the kanban lingo and giving useful examples of how to implement and overcome common challenges.
Most of the book was clear and explained things in a powerful way. There were quite a few times where I caught myself thinking, "oh...that's how that works."
There were some parts of the book that got a bit dry and escaped my attention, but those were manageable.
I look forward to working with my team to implement his recipe:
"The six steps in the recipe are
1. Focus on Quality
2. Reduce Work-in-Progress
3. Deliver Often
4. Balance Demand against Throughput
5. Prioritize
6. Attack Sources of Variability to Improve Predictability"
Most of the book was clear and explained things in a powerful way. There were quite a few times where I caught myself thinking, "oh...that's how that works."
There were some parts of the book that got a bit dry and escaped my attention, but those were manageable.
I look forward to working with my team to implement his recipe:
"The six steps in the recipe are
1. Focus on Quality
2. Reduce Work-in-Progress
3. Deliver Often
4. Balance Demand against Throughput
5. Prioritize
6. Attack Sources of Variability to Improve Predictability"
August 25, 2018
This book certainly has value, and for maintenance makes perfect sense. Parts can be taken for software projects, but adopting it wholesale... I'm skeptical.
The author also seems to misunderstand Agile, for example saying agile is not about quality, and uses Scrum and Agile interchangeably.
My favourite part is the premise the book is written on that reducing lead-time improves quality, yet has a footnote near the end saying the author hopes this is shown to be true.
It's definitely a book written for managers, and as a developer I prefer simpler, less faffy systems.
All in all, I'm glad to have read it and will aim to adopt parts into my agile team's workflow, but I won't be adopting it wholesale.
The author also seems to misunderstand Agile, for example saying agile is not about quality, and uses Scrum and Agile interchangeably.
My favourite part is the premise the book is written on that reducing lead-time improves quality, yet has a footnote near the end saying the author hopes this is shown to be true.
It's definitely a book written for managers, and as a developer I prefer simpler, less faffy systems.
All in all, I'm glad to have read it and will aim to adopt parts into my agile team's workflow, but I won't be adopting it wholesale.
March 10, 2017
After reading this book I must admit I long undervalued the value of Kanban. I've been in Scrum-teams for over 8 years now, but I will consider Kanban as a worthy, and probably sometimes better alternative.
The book is very valuable in the sense that it contains loads of information that you will need when implementing Kanban. It may feel repetitive from time to time, but each time information is layered with extra info or told from a different point of view.
However, to me, it still feels that if the information was structured different, it would have been easier to learn and remember all aspects of it. Nevertheless a book I can recommend to anyone working in the software business.
The book is very valuable in the sense that it contains loads of information that you will need when implementing Kanban. It may feel repetitive from time to time, but each time information is layered with extra info or told from a different point of view.
However, to me, it still feels that if the information was structured different, it would have been easier to learn and remember all aspects of it. Nevertheless a book I can recommend to anyone working in the software business.
June 28, 2019
Канбан метод описан понятно, примеров немного. Автор много повторяет одни и те же мысли. Упор сделан в Канбан для тех поддержки программного обеспечения. Автор оценивает Канбан как самый зрелый вариант agile методологии, потому что Канбан не требует изменения процессов компании. Автор считает, что самоорганизация команд формируется автоматически при применении Канбана.
Приведены примеры досок разработчиков, примеры внедрения Канбан из опыта автора, примеры отчетных документов. Всё примеры строятся на том, как это делается в командах у автора, на другие источники автор ссылается мало.
Приведены примеры досок разработчиков, примеры внедрения Канбан из опыта автора, примеры отчетных документов. Всё примеры строятся на том, как это делается в командах у автора, на другие источники автор ссылается мало.
February 1, 2021
A good book, the begin is about the history of Kanban and the first applications, i have a little difficult with side stories, i know that is important to reinforce the trust on the content but some stories and parts i think was not necessary, its a 2010 version, i think that is necessary an update with better examples in a version more lean and objective but the content stills are still current with many helpful concepts and applications to improve the delivery of a product and a team performance.
January 16, 2023
The book is good. But: the book between 30% to 70% is quite boring, as author is trying to describe Kanban from different angles and with a lot of unnecessary details. The description of Kanban can be a big blogpost, for now, not a book.
And starting nearly from 70% of the book it becomes extremely interesting, as he start to describe the general theory of project/company improvement. And it is one of the best descriptions from all other similar books. So if you are bored, try at least to go to the general theory in the end and read it.
And starting nearly from 70% of the book it becomes extremely interesting, as he start to describe the general theory of project/company improvement. And it is one of the best descriptions from all other similar books. So if you are bored, try at least to go to the general theory in the end and read it.
February 21, 2023
Interesting read regarding the intricacies of Kanban, how it relates to similar philosophies and the origin of its application in Software Development. A good overview of the benefits and manners of implementing Kanban on organizations, albeit it seems a bit biased in certain parts.
The book makes a compelling argument for testing Kanban in your organization, and offers significant knowledge for doing so, all proven with historical data of the Author’s own adventures using Kanban in his past enterprises.
The book makes a compelling argument for testing Kanban in your organization, and offers significant knowledge for doing so, all proven with historical data of the Author’s own adventures using Kanban in his past enterprises.
June 28, 2019
Kanban is super useful for interrupt driven tasks such as recurring business processes so I wanted to learn more and found this book helpful in understanding the theory of constraints and limited work in progress to achieve the needed outcome. However, the book is a bit wordy and I felt like I was flossing Ofer a lot of it. But I’d say still a good scan for info on how to implement Kanban in an existing organization.
September 20, 2019
The best single book on agile management
Both broad and deep it's valuable for project managers and scrum masters as well as managers who are responsible for organizations that both build and run. It even includes a chapter on Issues Management that treats escalation as a formal process for which policies shoulder developed and agreed to - something I haven't seen treated elsewhere.
Both broad and deep it's valuable for project managers and scrum masters as well as managers who are responsible for organizations that both build and run. It even includes a chapter on Issues Management that treats escalation as a formal process for which policies shoulder developed and agreed to - something I haven't seen treated elsewhere.
July 7, 2020
A great book. It takes the reader into a journey of Kanban evolution from Microsoft XIT to Corbis and beyond, the learnings are invaluable and can be seen in modern teams.
Anderson doesn't claim to know it all, in fact when proposing new techniques that may appear to be opinionated he clarifies that there could be other ways to do something.
This book opened my eyes in many aspects and broke me free of Scrum which frankly doesn't work everywhere.
Anderson doesn't claim to know it all, in fact when proposing new techniques that may appear to be opinionated he clarifies that there could be other ways to do something.
This book opened my eyes in many aspects and broke me free of Scrum which frankly doesn't work everywhere.
Displaying 1 - 30 of 143 reviews