Learning Agile: Understanding Scrum, XP, Lean, and Kanban 1st Edition

For anybody who works in an Agile team or wants to help guide their team to becoming more Agile, I would recommend reading this book. I think the biggest selling point for me was that it actually describes the differences between the various Agile methodologies. With all the different Agile methodologies that exists (and I'm sure there's many more beyond the 4 described in the book), it's easy to feel like you're swimming in an ocean of buzzwords. Luckily, I think the authors recognize the importance of actually "showing" you what Agile looks like and have vignettes sprinkled throughout the book to show you teams that are struggling and eventually teams that are succeeding with AgileThe 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.

I picked up this book in advance of planned Agile training. Our company is moving from Waterfall to Agile and I had no background at all in Agile. I highly recommend this book. The high points: Very readable and thorough introduction to concepts and acronyms. Excellent examples and stories with characters who are working their way through using becoming Agile. AND Unlike most technical books this was something I read in two quick sittings (about 3 hours or so). When I was finished I felt like I understood the why and the what of Agile and was thoroughly prepared for my Agile training sessions. Here is the downside: there is not a lot work-flow process oriented information beyond key concepts and relationships. But, I wasn't ready for that to be honest so the presentation level was perfect in my case. If you are looking to understand how Agile handles very specific things you should probably look for a more advanced book. From my perspective, I couldn't have been more pleased. This was a great place to start.

It's a good book for introductions and easing you into the concepts. The book teaches with a number of different techniques, so it caters to different kinds readers as well. They do repeat themselves a lot, but that only aids in making the concepts stick. You defiantly get a sense that the authors have experience in this stuff and know what they're talking about.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.

It's a highly readable introduction to a couple different angles on lean and agile. And, depending on your team's level of buy-in, you could totally try it.This book is very much through the lens of software development. If you're not in software, some ideas may not transfer that well. But, it's also interesting to think about relative time scales. A mechanical or manufacturing engineer does have a fighting chance to deliver shippable increments of product (simple machines, prototypes, manufacturing cells) every three months, for example, and the ideas driving test-first programming, lean development, and kanban all apply to hardware too.