Learning Agile: Understanding Scrum, XP, Lean, and Kanban
Learning Agile: Understanding Scrum, XP, Lean, and Kanban book cover

Learning Agile: Understanding Scrum, XP, Lean, and Kanban

1st Edition

by
Price
$25.99
Format
Paperback
Pages
417
Publisher
O'Reilly Media
Publication Date
ISBN-13
978-1449331924
Dimensions
7 x 0.95 x 9.19 inches
Weight
1.48 pounds

Description

This book is called Learning Agile because we really want you to learn agile. We've spent the last 20+ years working with real teams building real software for real users day in and day out. We've also spent the last 10+ years writing books about building software (including two very successful books in the O'Reilly Head First series about managing projects and learning to code). This experience has helped us find many different ways to get complex and technical ideas into your brain without boring you to death. We've done our best to take this material and make it as interesting and engaging as possible. We use narratives and illustrations, include key points and coaching tips, and answer many frequently asked questions that routinely come up when teams try to implement agile in the real world on their own teams—and all of these things can help you and your team learn agile quickly so that you can build and deliver better, more valuable software, and do it faster than before. Who we wrote this book for Do any of these scenarios describe you and your team? You tried an agile practice, but it didn't really work out. Maybe you implemented daily standup meetings, and now your team meets every day--but you still get blindsided by problems and miss deadlines. Or you started writing user stories and reviewing them with your team and stakeholders, but your developers still find themselves dealing with just as many last-minute changes to add extra features that continue to pop up. Or maybe your team tried to go agile wholesale by adopting a methodology like Scrum or XP, but it seems somehow "empty"--like everyone is going through the "required" motions, but your projects are only marginally improving. Or maybe you haven't tried agile yet, but you recognize that your team is facing serious challenges, and you don't know where to start. You're hoping that agile will help you with those demanding users who constantly change their minds. Each change your users make requires more work for your team, and leads to "duct tape and paperclips" spaghetti code solutions that make the software increasingly fragile and unmaintainable. It could be that your projects are simply controlled chaos; the primary way software is delivered is through long hours and personal heroics, and you think that agile may offer your team a way out. What if you're an executive who's worried that teams working on important projects will fail to deliver? Maybe you've heard about agile, but you don't really know what it means. Can you simply tell your team to adopt agile? Or will you need to change your own mindset along with the team? If any of those situations is familiar to you, and you want to improve how your team works, this book will help. We explain the agile methodologies: why they're designed the way they are, what problems they address, and the values, principles, and ideas that they embody. By giving you the "why" in addition to the "how," we'll help you to recognize the principles that apply to the particular development problems specific to your team, company, and projects. And we'll show you how to use that information to guide your choice of methodologies and practices. What we want for you: 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 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 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 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. 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. From the Inside Flap Praise for Learning Agile Another amazing book by the team of Andrew and Jennifer. Their writing style is engaging, their mastery of all things agile is paramount, and their content is not only comprehensive, it's wonderfully actionable. --Grady Booch, IBM Fellow The biggest obstacle to overcome in building a high-performance agile team is not learning how, but learning why. Helping teams discover the why is the key to unlock their potential for greater commitment and more creative collaboration. With a focus on values and principles Andrew and Jennifer have provided an outstanding tool to help you and your team discover the why. I can't wait to share it. --Todd Webb, Technical Product Leader at a global e-commerce company As an engineer, I always thought the problems that Agile practices help to solve are a direct hit for the industry. As it turns out, becoming Agile is hard; it's more than just the practices. A piecemeal approach to Agile gives, as the the authors call it, "better-than-not- doing-it" results. If you are just getting started, or Agile is only "better-than-not-doing-it", Andrew and Jennifer have a lot of practical advice on how to read between the lines of the Agile Manifesto and really become Agile. --James W Grenning, Founder of Wingman Software and co-author of the Agile Manifesto If you want to learn about any of the specific approaches to agile, you need to read the specific relevant books. That means you know what you want to do in advance. Not very agile of you, is it? What Andrew and Jenny have done is create an approachable, relatable, understandable compendium of what agile is. You don't have to decide in advance what your agile approach is. You can read about all of them, and then decide. On your way, you can learn the system of agile and how it works. --Johanna Rothman, Author and Consultant Andrew Stellman is a developer, architect, speaker, agile coach, project manager, and expert in building better software. He has over two decades of professional experience building software, and has architected large-scale real-time back end systems, managed large international software teams, been a Vice President at a major investment bank, and consulted for companies, schools, and corporations, including Microsoft, the National Bureau of Economic Research, Bank of America, Notre Dame, and MIT. He's had the privilege of working with some pretty amazing programmers during that time, and likes to think that he's learned a few things from them.Jennifer Greene is an agile coach, development manager, business analyst, project manager, tester, speaker, and authority on software engineering practices and principles. She's been building software for over twenty years in many different domains including media, finance, and IT consulting. She's worked with teams of excellent developers and testers to tackle tough technical problems and focused her career on finding and fixing the habitual process issues that crop up along the way.Andrew and Jennifer have been building software and writing about software engineering since 1998. They founded Stellman & Greene Consulting in 2003, and continue to work with software teams every day to build and deliver software to their users. Other O'Reilly titles they've written include Beautiful Teams , Head First C# , Head First PMP , and Applied Software Project Management . Read more

Features & Highlights

  • Learning Agile
  • is a comprehensive guide to the most popular agile methods, written in a light and engaging style that makes it easy for you to learn.Agile has revolutionized the way teams approach software development, but with dozens of agile methodologies to choose from, the decision to "go agile" can be tricky. This practical book helps you sort it out, first by grounding you in agile's underlying principles, then by describing four specific--and well-used--agile methods: Scrum, extreme programming (XP), Lean, and Kanban.Each method focuses on a different area of development, but they all aim to change your team's mindset--from individuals who simply follow a plan to a cohesive group that makes decisions together. Whether you're considering agile for the first time, or trying it again, you'll learn how to choose a method that best fits your team and your company.
  • Understand the purpose behind agile's core values and principles
  • Understand the purpose behind agile's core values and principles
  • Learn Scrum's emphasis on project management, self-organization, and collective commitment
  • Learn Scrum's emphasis on project management, self-organization, and collective commitment
  • Focus on software design and architecture with XP practices such as test-first and pair programming
  • Focus on software design and architecture with XP practices such as test-first and pair programming
  • Use Lean thinking to empower your team, eliminate waste, and deliver software fast
  • Use Lean thinking to empower your team, eliminate waste, and deliver software fast
  • Learn how Kanban's practices help you deliver great software by managing flow
  • Learn how Kanban's practices help you deliver great software by managing flow
  • Adopt agile practices and principles with an agile coach
  • Adopt agile practices and principles with an agile coach

Customer Reviews

Rating Breakdown

★★★★★
60%
(229)
★★★★
25%
(96)
★★★
15%
(57)
★★
7%
(27)
★
-7%
(-27)

Most Helpful Reviews

✓ Verified Purchase

Reads like a propaganda piece for agile from people who don't understand the SDLC

I'm a software engineer who has been writing code for 38 years and been in the industry for 23 years. I'm certified in the Software Development Life Cylce (SDLC) and proper System Engineering Practices. I work in aerospace, where our products are high-tech and high-price. I'm a SME on Secure Coding, too.

The authors have written this book as if it were a propaganda piece for agile without any understanding of the SDLC, instead treating agile as if it is the greatest thing since sliced bread when it comes to software. The reality is that the authors engage in repeated strawmen arguments about waterfall and SDLC, and in doing so fail to understand that the alleged "agile principles" they talk about are nothing more than best practices for software engineering that are necessary for SDLC, waterfall, agile, or 400 monkeys at keyboards banging away programming Windows 95. The biggest strawmen they use are that waterfall and SDLC teams don't communicate, and even worse, that requirements for a waterfall development are set in stone. Well, the reality is that yes, the teams do communicate, both laterally and vertically, and that requirements for *an iteration* of the software are set in stone, but they can be modified for the next iteration, and usually are. That latter is important, because the authors incorrectly assume that a waterfall approach is only one iteration, when no software worth the electrons it's written in does that.

The reality is that a SDLC, when properly implemented, not only gets the design and CONOPS correct at the front end, but it stays that way for the iteration, and if it changes, it changes in the next iteration--not in the middle of the iteration as the authors incorrectly contend. This illustrates that the authors really don't know what they're talking about when they critique waterfall or SDLC.

Plus, the authors blatantly refuse to acknowledge the obvious shortcomings of agile. For a good summary, please look up "Why Agile and especially Scrum are terrible" by Michael O. Church (not me).

That, and there's something else that the critics of both waterfall and SDLC don't understand, and that's within the SDLC, people specialize in certain areas. System Engineers (SEs) sort out requirements by working with management, customers, developers, and testers to get them right on the front end. The developers interface with the SEs and testers and integrators to get the code correct. The testers interface with the developers, SEs, and integrators to get the testing process correct. Each area has both SKEs and SMEs. That is still simply the most efficient way to build quality software. Agile? It builds low-quality software fast, but not good.

Proper SDLC implementation is a problem, but it is not a problem that requires throwing out the baby with the bathwater by going agile. Agile may make the business bean counters happy, but it's not a good way to build quality software.

As for this book, go ahead and read it, preferably a borrowed copy, but keep in mind the fallacies of the authors that I have mentioned above, and when you go to your daily stand-up to tell the bosses what you did in the past 8 hours of work since the last stand-up (which is why daily standups are so stupid in the first place!), remember that you can be more productive when you aren't stuck in pointless meetings that interrupt getting quality work done just to fill in a Kanban form or shuffle index cards or post-it notes on a whiteboard. And remember to document your work so you can justify the 2% raise the bosses will try to deny you based on bad agile software practices.
40 people found this helpful
✓ Verified Purchase

Surprisingly Useful, Even for Experienced Developers

Given that I've been familiar with Agile for at least 12-13 years and with Lean for nearly twice that long, I didn't expect that an introductory-level book would have a great deal to offer me except, maybe, a refresher course. However, a number of the tools & techniques used in the book provide significant benefit even if you're already familiar with the material:

* Narratives, which do an excellent job of illustrating real-world software development problems and practical means of addressing them.

* The idea of "Better-Than-Not-Doing-It" results, which explains why many Agile implementations plateau after a short time. This is an elegant model that succinctly explains many sub-optimal process improvement efforts that I've observed over the years.

* Comparative methodology. Having a single resource that objectively compares and contrasts various Agile methodologies or "schools of thought" is very valuable. Reading about each approach back-to-back reinforces the common principles in a way that high-level overviews or single-methodology books rarely do.

I also believe that the book will serve the beginner audience well because it's very well-organized and provides many references to additional learning resources. However, with my exposure to the material before reading, I can't state that opinion with 100% certainty.

Similar to the authors' other books that I've read -- "Applied Software Project Management", "Head First C#", and "Beautiful Teams" -- "Learning Agile" is eclectic and has a practical, hands-on focus. Personally, I prefer that approach, especially when it integrates principles and lessons learned from such diverse subjects as the Toyota Production System, the Unix toolset, martial arts, and basketball (via the teachings of John Wooden). The authors even stress that a waterfall process CAN work, given the right conditions, which is rare for Agile-focused material. However, the eclectic/practical approach results in a tome that's probably not particularly well-suited for use as certification prep.

The book takes roughly 8-10 hours to read. I recommend that you read topically-related chapters -- 2/3 (Agile values/principles), 4/5 (Scrum), 6/7 (XP), and 8/9 (Lean/Kanban) -- in the same sitting, or with as little time elapsed between readings as you can manage. The chapter pairs share Narratives, and the second chapter per pair builds upon ideas introduced in the previous chapter. All of the chapters reference and reinforce ideas that were introduced earlier in the book. This is partly because of the book's thematic cohesion and partly the result of a deliberate strategy for improving reading comprehension.

Some suggestions that I think would add value to a future edition, if there is one:

* Further discussion of situations in which Agile isn't a great fit, preferably using Alistair Cockburn's Project Classification Scale [Defect Criticality x Team Size] for determining the process formality requirements of a project.

* More extensive coverage of the types of waste found in software development, bringing in wider-ranging ideas about wastefulness from Lean and other topics like the Unix philosophy, such as: unused employee creativity, over-design / over-specification, & solving the wrong problem the "Right" way.

Disclosure: I was provided with a free review eBook in exchange for my honest feedback. Previously, I was a technical reviewer for "Applied Software Project Management" and co-authored a chapter for "Beautiful Teams" (by the same authors). Also, more than a decade ago, I was a coworker of Andrew Stellman's for approximately a year.
24 people found this helpful
✓ Verified Purchase

Best introduction to agile development. Period.

There are lots of books about agile methodologies and implementation. Usually, when introducing agile into an organization, a handful of books are required to get the gist of all the aspects of agile, from theory to practice. This book aims to collect the best of theory and practice in an engaging way into one book, and succeeds beautifully! I wish I'd had this 6 years ago and would have used it in in 4 different organizations, and will use it everywhere I work in the future.
12 people found this helpful
✓ Verified Purchase

Let's cut the "BS" out of agile development

Writing a book on Agile Development is tough work. We programmers tend to be a very pragmatic bunch, and don't like the kind of conversation that does not have a direct impact on what appears on the screen. Unless it's done by some software legend like uncle Bob, for example :)
Also, the agile manifesto is really all there is to know about agile development, and yes it might take a little explanation, and surely there are some practices like test driven development and pair programming that take a little to digest, but for example , test driven development is something that you have to try to understand. You cannot just read about it in book. So filling a 400+ book about agile development is quite a feat, both in a good and in a bad way. I like the narratives a lot, I am sure the authors have learned a lot about keeping the attention of the learner while working on their head first book, but other than that the book does feel quite bloated.
This book could be cut in half just avoiding useless and painful repetitions, and it would be a better tool to "transmit" the agile mindset, and most of the best practices.
It' s not entirely the authors fault though. The problem is, agile development itself has grown to be quite bloated. And why is that? Because a lot of people are always looking for an opportunity to sell something, be it a methodology, or themselves as "experts", or better yet, "agile coaches". In this regard I strongly, strongly suggest to see Dave Thomas presentation (currently available on youtube) "Agile is Dead".
Still, this book has value, it clearly illustrates the agile development principles, the practices, and what happens when you try to follow the practices without having absorbed the values. I just get annoyed for the occasional over-complication and for how they are try to hide and gloss over the obvious fact that XP, Scrum, Lean, and Kanban are basically the same thing, repeating the same ideas times and times again , just with a different vocabulary. That's not what I call to be intellectually honest. And we need to realize this, before agile development loses its "developer centric", pragmatic, "no bs" core values, and become just a bunch of methodologies.
What Agile Development really is:
1) Find out where you are
2) Find out where you want to go
3) Take a small step toward your goal
4) Adjust your understanding base on what you learned
4) Repeat
For the details, you can look into this fine book.
Just don 't get too bogged down by them :)
11 people found this helpful
✓ Verified Purchase

Look elsewhere

My overall opinion of this book is that its just a long-winded group of short stories about how imaginary development teams used scrum fundamentals to improve their workflow.

I didn't learn anything from reading this book.

I will remember the authors' names so that I will never buy a book from either one of them.
9 people found this helpful
✓ Verified Purchase

by the far, the best use of stories to tell a story that i have seen

“Learning Agile” was an awesome book. It introduces Scrum, XP, lean and kanban nicely with good examples an narratives. This was not your serious “animal series” O'Reilly book. In addition to numerous cartoons and diagrams, I even spotted a Head First style image and two xkcd comics.

What's called Chapter 1 introduces agile followed by what would traditionally be the introduction.Interesting seeing those two reversed. It works though as it shows the points of view of different readers. I like how each chapter ends with FAQs, exercises you can today and ideas to learn more. The key point boxes sprinkled through each chapter were helpful as well.

I'm particularly impressed with how they handled the names of characters in Chapter 2. When I saw the characters introduced I groaned thinking it was one of those books where I would have to keep track of who these people are. But there was enough context for it to be obvious. And when they referred to them at the end of the chapter, their titles were restated. The authors even told us at the end of the story that we wouldn't be seeing them again. After that, I trusted that the narratives would be easy to follows and wasn't disappointed.

I liked the phrases “better-than-not-doing-it” and “magical thinking”. For me, the test of an agile or process book is whether I finish with ideas of new things to try. And I do.

---
Disclosure: I received a copy of this book from the publisher in exchange for writing this review on behalf of CodeRanch.
9 people found this helpful
✓ Verified Purchase

This is a truly fantastic introduction to the major Agile methodologies for software professionals ...

Andrew Stellman and Jennifer Greene have been there, seen that, bought the T-Shirt, and now written the book! This is a truly fantastic introduction to the major Agile methodologies for software professionals of all levels and disciplines. It will help you understand the common pitfalls faced by development teams, and learn how to avoid them. The writing style is straightforward and approachable, and their advice is justified with copious examples of situations which will be familiar to many of us. Highly recommended even if you think you already practice Agile.
9 people found this helpful
✓ Verified Purchase

There's a lot of good ideas in "Learning Agile"

There's a lot of good ideas in "Learning Agile", things that have been used for decades but didn't have a flashy name until the Agile group thought of one. But... the book drowns in koolaid while ignoring Agile's failings in:
* 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.
7 people found this helpful
✓ Verified Purchase

It's ok...

Stellman and Greene do a good job explaining Agile concepts, but they spend too much time bashing Waterfall and bashing everything that isn't Agile. Both Agile and Waterfall are great lifecycles and both have their application. It would be much more helpful if this book explained how/when Agile can be applied.
6 people found this helpful
✓ Verified Purchase

This is by far the best resource I've found for gaining a deep understanding of ...

This is by far the best resource I've found for gaining a deep understanding of Agile methodologies. I first learned about Agile years ago, and immediately saw its promise. But I found that learning about Agile was the easy part. Getting your organization to understand and embrace Agile is the hard part. This is where Stellman and Greene's book is exceptional. Their many examples, anecdotes and first hand experience take you beyond the theory and will help you put that theory into practice. Pay particular attention to the examples which highlight potential pitfalls that will sabotage your efforts. I can say from experience that they are very relevant. I would avoided considerable heartache if this this book had been written sooner.
6 people found this helpful

Related Books