- Paperback: 420 pages
- Publisher: O'Reilly Media; 1 edition (December 10, 2013)
- Language: English
- ISBN-10: 1449331920
- ISBN-13: 978-1449331924
- Product Dimensions: 7 x 1 x 9.2 inches
- Shipping Weight: 1.5 pounds (View shipping rates and policies)
- Average Customer Review: 4.3 out of 5 stars See all reviews (32 customer reviews)
- Amazon Best Sellers Rank: #73,294 in Books (See Top 100 in Books)
Enter your mobile number or email address below and we'll send you a link to download the free Kindle App. Then you can start reading Kindle books on your smartphone, tablet, or computer - no Kindle device required.
To get the free app, enter your mobile phone number.
Learning Agile: Understanding Scrum, XP, Lean, and Kanban 1st Edition
Use the Amazon App to scan ISBNs and compare prices.
Frequently bought together
Customers who bought this item also bought
Understanding Scrum, XP, Lean, and Kanban
From the Author
- We want you to understand the ideas that drive effective agile teams, and the values and principles that bring them together.
- We want you to understand the most popular agile schools of thought--Scrum, XP, Lean, and Kanban--and how they can all be agile, even though they're very different from each other.
- We want to teach you specific agile practices that you can apply to your projects today--but we also want to give you the framework of values and principles that you'll need to implement them effectively.
- We want to help you understand your own team and company better, so that you can choose an agile approach that matches your mindset (or comes as close as possible)--but also help you and your team start to learn a new way of thinking that will help you become a more effective agile team.
Browse award-winning titles. See more
If you are a seller for this product, would you like to suggest updates through seller support?
Top Customer Reviews
The first methodology they discuss is Scrum. They do this very intentionally because Scrum is probably the easiest Agile methodology to actually "adopt". It has clear practices and more closely resembles "traditional" software development process compared to the other methodologies.
The second methodology they discuss is XP which I have heard is highly influential in the Agile field with luminaries such as Kent Beck and Martin Fowler as early leaders of the field, however to be honest I have never heard of anyone working in a software team they would describe as "XP". The most charitable way to interpret this is that many of the XP values, principles, and practices have trickled down into mainstream "Agile" consciousness. The easiest way to summarize XP is "embracing change" and the authors show you how they support that overarching goal through practices such as unit testing to facilitate refactoring and delaying decisions until the last moment.
The last part describes the Lean and Kanban methodologies which are closely related. In short, they focus on continuous improvement. Before reading the book, I had heard about a Kanban board and the idea of moving tasks around different columns, but the real eye-opener was their emphasis on the importance of Work In Progress (WIP) limits. They show you how vital it is to have WIP limits and why you need to be careful of ignoring it (which oftentimes happen as they demonstrate).
Probably my favorite part of the book is when they describe teams that partially apply Agile methodologies while still retaining much of their legacy software development practice and end up achieving OK but "better than nothing" results. I think it's easy to think of Agile as the end all be all of good software development practice but it's a journey to actually achieving it and I like how they show you the realistic challenges of going from a traditional software development methodology to agile.
But I did find the book really "fluffy". I'm a visual learner and found most of the pictures and diagrams to be of little help. They didn't provide much more clarity than the sentences describing the picture. The book spends a lot of time giving stories and thought experiments to bring a point home, but those did seem a bit cyclic in argument and didn't give much insight. Their Q & A sections do give a lot insight though. And throughout the book, they do give you enough theory to understand the differences between differing philosophies and practices.
Sometimes it was hard to tell who the audience was. Most of the time they speak directly to the developer, empathizing with the needs of the programmer. But sometimes they would unnecessarily elaborate on the basics. For example, giving a multi-page comparison between libraries and frameworks. But with that said, this book isn't too technical so a manager could read it and benefit from it.
I'm used to more technical reads and was looking for something to just give me the philosophy and practices of agile straight. This is not that book. But if you wade through the "fluff" you will defiantly learn a lot about agile. And if you want the more technical stuff, they give you plenty of additional sources to continue your learning. It's defiantly a good starting point.
* cost control / ROI / productivity (having a door is the #1 way to increase an engineer's productivity)
* unending changes that are typically illogical and conflicting
* common team issues that won't be solved
* dishonest comparisons of the worst Waterfall projects versus best Agile projects
* faith over results
* and glossing over programming necessities like Code Refactoring to keep iterative software working over time... while ignoring the large cost that refactoring requires.
That being said, I do recommend this book to everyone that wants to understand more about Agile. It's the least bad of the books out there.
Experienced people should take it with many large grains of salt.
Inexperienced people should be ready to be disappointed when they see this used and abused in reality.
The main drawback is that it doesn't describe well enough the basic practices and ceremonies of Scrum. To use the book's own terminology, it lacks "shu"-level rules, but is way too thorogh with "ha"-level concepts. You may need additional resources to actually get to using Scrum in your work