Learning Agile to Understand Scrum, XP, Lean, and Kanban by Andrew Stellman and Jennifer Greene

“Learning Agile” by Stellman and Greene is a game-changing resource for anyone looking to level up their project management skills. This comprehensive guide dives deep into Scrum, XP, Lean, and Kanban, offering invaluable insights for both beginners and seasoned professionals.

Ready to revolutionize your approach to project management? Let’s explore the key takeaways from this must-read book.

Genres

Management, Leadership, Corporate Culture, Business Project Management, Internet and Telecommunications, Software Development, Computer Science, Programming, Technology, Technical, Coding, Computers

“Learning Agile” provides a thorough exploration of four major Agile methodologies: Scrum, Extreme Programming (XP), Lean, and Kanban. The authors break down complex concepts into digestible chunks, using real-world examples and case studies to illustrate key principles.

The book starts by introducing Agile values and principles, emphasizing the importance of adaptability and continuous improvement. It then delves into each methodology, explaining their unique features, benefits, and challenges.

Scrum is presented as a framework for product development, highlighting roles like Product Owner and Scrum Master, and practices such as sprint planning and daily stand-ups. XP is described as a set of engineering practices that complement Scrum, including pair programming and test-driven development.

Lean principles are explained through the lens of eliminating waste and maximizing value, while Kanban is portrayed as a visual method for managing work in progress and optimizing flow.

Throughout the book, the authors stress the importance of team dynamics, communication, and continuous learning in successfully implementing Agile practices.

Review

“Learning Agile” stands out for its clarity and comprehensive coverage of Agile methodologies. Stellman and Greene’s writing style is engaging and accessible, making complex topics easy to grasp.

The book’s strength lies in its practical approach. Real-world examples and case studies bring theoretical concepts to life, helping readers understand how to apply Agile principles in various scenarios.

One particularly valuable aspect is the authors’ balanced perspective. They don’t present Agile as a silver bullet but honestly discuss its challenges and limitations, providing a realistic view of what to expect when adopting these methodologies.

The inclusion of exercises and thought-provoking questions at the end of each chapter encourages active learning and reflection, making it an excellent resource for self-study or team discussions.

While the book provides a solid foundation for understanding Agile, some readers might find certain sections too detailed or technical. However, this depth of information makes it a valuable reference guide for ongoing consultation.

Overall, “Learning Agile” is an essential read for anyone involved in project management or software development. Its comprehensive coverage and practical insights make it a valuable resource for both newcomers to Agile and experienced practitioners looking to deepen their understanding.

An introduction to agile.

Learning Agile (2015) is a no-nonsense guide to an often misunderstood concept – agile. The reason for that misunderstanding is simple: all too often, agile is bandied about as a one-size-fits-all solution to every conceivable organizational difficulty. Longtime agile practitioners Andrew Stellman and Jennifer Greene don’t see it that way. For them, agile is a great tool, but you have to know how – and when and why – to use it. And that starts with getting a grasp on agile’s underlying principles.

Customers don’t always know what they want – or need. As Henry Ford once put it, if he’d asked people what they wanted, they would have said “faster horses.”

Of course, Ford gave them cars. But imagine if he hadn’t. Years would have been wasted trying to satisfy that demand. Chances are, by the time Ford’s product hit the market, someone else would have already started selling cheap, reliable cars. His product would have been dead on arrival.

In this summary, we’ll be talking about software development, not cars. But we’ll be looking at the same problem. That problem can be summed up in a single question: How do you deliver a valuable product to your customer, even if they can’t tell you what they really want or need?

One answer is the bundle of practices and principles known as agile. If you’ve heard that word before, you’ve probably also come across some related concepts – like scrum, kanban, XP, and lean. Oftentimes, there’s a temptation to rush into discussing these methodologies right alongside agile.

For Andrew Stellman and Jennifer Greene, the authors of Learning Agile, that risks putting the cart before the horse. There’s no point in getting into the nitty-gritty, after all, if we haven’t shown why you and your organization should even consider agile in the first place. So that’s what we’ll be doing in this summary: looking at the why of agile.

To do that, we’ll follow a project from start to finish. Along the way, we’ll see how agile principles can help a team of software developers work more efficiently and effectively – and deliver a better product.

You can’t design good software in a vacuum.

Let’s talk about e-book readers for a second.

It’s easy to see why they’re so popular. The object itself is about the size of a regular paperback, but it holds thousands of books. Even better, every text is responsive to you, the reader. You can enlarge the words, change the font, or skip back and forth between the main text and references. With a single click, you can access libraries and catalogs; with another click, you can borrow or download new books onto your device.

In short, this is great software. It’s well designed. Convenient. Intuitive. It satisfies every stakeholder. Readers find it easy to use, and it displays texts accurately, which is important to authors. It also helps booksellers and publishers sell and distribute books.

The first e-book readers didn’t do all these things, though. In fact, it took over a decade of development before the software got to where it is today. Back in the early 2000s, it wasn’t clear what would make an e-book reader valuable. We only know that today because hindsight is 20/20 – which brings us to our little thought experiment.

Let’s go back in time. Imagine we’ve been tasked with developing the software to display electronic books on brand-new handheld devices. How will we approach our task?

Well, we’re actually going to do it in the worst possible way because this isn’t the kind of company that’s exploring new ways of building software. This is an old-school operation, with leaders who lead and followers – that’s us, the developers – who follow. In short, this isn’t the kind of office where you’ll hear the word “agile.” So let’s see how things play out.

The hardware team has already made a prototype. Picture a chunky black tablet with a USB port for loading books and a fiddly little keyboard for interacting with the reader. It’s up to us to build the software that will display e-books on this gadget.

Our company applies what’s known as a waterfall process to its projects. What that means is that projects are front-loaded. All the product requirements are defined at the outset. As we said, leaders lead and followers follow. All the stakeholders – the senior managers, publishing representatives, online retailers, and so on – sit down and and hash out a plan. They outline requirements and come up with a specification that ticks all their respective boxes. Every other stage of the process, from design to development and testing, flows downstream from these decisions just as a body of water flows downstream from a waterfall.

So what’s in the specification? In a word, everything. This e-book reader is going to be revolutionary. It’s going to have tons of features. It’ll capture market statistics for publishers. It’ll have an internet storefront for readers to buy books. Authors will be able to preview and edit their books as they write them. And it’s all going to be ready in 18 months.

Fast-forward a year and a half. Since this is a thought experiment, we don’t have to be realistic, so we’ll say the project is completed on time. And it’s all there – every requirement in the specification has been implemented, tested, and verified. Everyone’s happy.

Can you guess what happens next? The reader hits the market . . . and it flops. Hard. No one buys it.

What went wrong?

The thing is, people’s needs aren’t static – they change with the times. If your only choice is a horse, you want a faster horse. But a horse, no matter how fast, isn’t much use if everyone else is already driving cars. Similarly, the software that people needed 18 months ago isn’t the software they need today. Since our project began, a new industry standard for e-books has emerged. No retailer wants to publish our unstandardized format – it’s too much bother. And so none of our revolutionary features are supported, which means they’re no use to anybody.

This also means we’ve wasted lots of time and money creating software that’s not very valuable. So what should we have done differently?

Release imperfect software today, and you’ll end up with a better final product tomorrow.

Here’s where we went wrong: we were unresponsive. We spent 18 months working in a bubble to implement a plan that was out-of-date before it even reached the market. There were no adjustments. We weren’t flexible. Our project, in short, wasn’t iterative.

An iterative design process doesn’t take place in a vacuum. Instead, it rolls out products quickly, getting them to customers as soon as possible and gathering feedback. That feedback is the basis for improvements, which are then sent back to customers – again, as quickly as possible – so they can provide new feedback. At that point, the cycle restarts. To iterate, after all, means “to perform repeatedly.”

This feedback loop is at the heart of agile processes. Think about the word “agility” as we use it in everyday language. It describes a way of moving quickly and nimbly – of being responsive to the environment and engaging with what’s in front of you. An agile climber, for example, responds to every hand- and foothold they encounter. They make rapid adjustments to prevent slips and fumbled grips. It’s the same with agile in software design. Agile teams use iterative processes to respond quickly and nimbly to bugs and mix-ups as they encounter them. They might not build the software they set out to build, but that’s a whole lot better than building something useless.

So there’s the first principle of agile. We can phrase it like this: The highest priority is to satisfy the customer through early and continuous delivery of valuable software.

Now, let’s break that principle down even further.

Software can only be built in the real world – the world of imperfect humans. Even the hardest working teams miss important details. The most talented developers fail to anticipate vital requirements. The only way we can correct mistakes is to put the software we’re building into the hands of customers – the people who’ll actually be using it. As developers, we’re entirely dependent on their feedback. That’s why we need to release software early.

Releasing software early isn’t just an antidote to perfectionism – it delivers value for customers. If they have a single feature today, however buggy, they can do something they couldn’t yesterday. By actually using a product, they can clarify their needs. That means they’ll be able to give us a clearer idea of what they want a product to do. And once we’re locked into this feedback loop, we’re on the road to creating a final product that actually satisfies those needs.

Embracing change is all about adopting the right mindset.

So there’s the answer to the question we asked earlier – what we should have done is put our software into the customers’ hands, so they could actually use it and give us feedback. If we’d done that, we would have realized there was a problem and changed course. That would have saved us the time, effort, and money we put into building an expensive dud.

Of course, changing course midway through a project is easier said than done. In practice, it’s usually a painful and unpleasant experience. You’ve made the difficult decisions. You know what you’re building. You know what your customers expect. Your workflow is established. It’s not plain sailing, exactly, but you’re making progress. And then someone from outside the project comes along and says that you’ve been on the wrong path the whole time. That all that planning and work was for nothing. That you have to circle back and start again. Worse, the person telling you to change course is the same person who put you on that path in the first place! They told you to build one thing, and now that you’ve built half of it, they’re telling you to do something else. It’s demoralizing – disrespectful, even. No wonder you get defensive and resist making changes.

Understandable? Sure. Helpful? Not at all. The important question is though, how can you get past this feeling?

Well, it’s a question of mindset, and it has two parts. The first is accepting that it’s really hard to build valuable software if you’re not constantly checking – and revising – your priors. Yes, changing course halfway through a project is frustrating, but it’s nowhere near as deflating as reaching the end of a project and realizing you’ve built a piece of junk.

The second part is about perspective, and it takes the form of an exercise.

This isn’t always an easy exercise – it requires a cool head and more empathy than you might want to extend to the person who’s just ruined your day. But it can be illuminating. Start by asking yourself these two questions: First, did your customer deliberately send you down the wrong path? Probably not, right? And second, how did they feel when they realized they screwed up and cost you months of work? Chances are, they were pretty embarrassed. They probably didn’t want to come to you and admit their mistake. It’s a good thing that they did, though – they’ve just saved you even more wasted time! And it’s not just your deadline that’s been blown. Your client’s timeline is delayed now, too. Their company is spending good money to build software that meets its needs, and this mistake means the project isn’t delivering. In other words, this is frustrating for everyone.

When you get down to it, you’re both in a difficult position. The only way you could theoretically avoid screwups would be to read your customer’s mind. Your customer, in turn, would have to be able to predict the future. In an ideal world, you’d both be able to do those things. But software isn’t built in an ideal world; you won’t be working with telepathic clairvoyants. Accept that, and mistakes – along with the changes they bring – will be much easier to deal with.

Iterative processes keep you in touch with your customers.

OK, let’s go back to where we started. How can the agile principles we’ve explored help our troubled e-book reader project? Let’s find out by running the project again.

First, let’s remind ourselves why that reader flopped. It lacked some important features used by competing e-book readers, like supporting an industry standard format. Note, however, that this problem couldn’t have been predicted – or avoided. When our team went to work, there was no industry standard. Our emphasis, then, has to be on the team’s responsiveness to what it finds out once its work has already started.

This time, the project is going to be agile. We’ll start with a big meeting where we’ll hash out the requirements and specifications, but we’re not going to stick to that plan for 18 months straight. Instead, we’ll divide that year and a half into one-month sprints – a single cycle of the feedback loop we discussed earlier. Put differently, we’re going to update our design in response to feedback every month.

There’s not going to be much to test at the beginning, of course, so we’ll fast-forward to the fourth sprint. When the project manager, team, and stakeholders meet, one of the developers reports that there’s a new industry standard for e-book formats. The team incorporates this new information into its next sprint and builds a library that supports the new format. By the sixth sprint, it’s ready to incorporate that format into the reader’s user interface.

As you can see, each sprint roughly maps onto each iteration or version of the software the team is building. So let’s skip to month eleven – the eleventh sprint and the eleventh iteration. We now have a working build, which can be loaded onto the prototypes the hardware team came up with. It’s buggy, but it’s good enough for real-world testing, which is exactly what the team wants. When the project manager talks to the software’s early users, she learns that they’d like to be able to email newspaper articles and PDFs to their devices. That’s the focus for the team’s next sprint.

This approach isn’t just about testing and incorporating new features, however – some features can also be discarded. For example, maybe that internet storefront doesn’t make sense. There’s a standardized e-book format, after all, so we don’t have to create a unique platform of our own. That’s handy because it frees up time to work on other, more important features.

This version of the project is much more likely to end well. We’ve been continuously releasing software for real-world testing and making timely changes in response to those tests. The big difference here is that we’re in touch with customers and users. When we used the waterfall process, we were completely sealed off from these groups once the project’s requirements had been approved. This time, though, we haven’t lost sight of our ultimate aim: building valuable, working software that satisfies real needs. And that’s the why of agile.

Summary

You’ve just finished our summary to Learning Agile, by Andrew Stellman and Jennifer Greene.

The key message here is that:

There are lots of ways of working agile, but every approach rests on the same core principals. The first is responsiveness. Agile processes are all about feedback. You don’t wait until the end of a project to test the software you’ve built – you get it out there as soon as possible. Real-world testing identifies problems early and helps your customer clarify what they need that software to do. The second principle? There’s no such thing as the perfect plan. Every project will require ad-hoc fixes, changes, and redesigns. But that’s a good thing – it’s how the best software gets built.

About the author

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.

Andrew Stellman | Twitter @AndrewStellman
Andrew Stellman | mastodon @andrewstellman

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.

Jennifer Greene | Twitter @JennyGreene

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.

Andrew and Jennifer | Building Better Software

Table of Contents

Foreword xiii
Preface xv
1 Learning Agile 1
What Is Agile? 2
Who Should Read This Book 7
Our Goals for This Book 8
Getting Agile into Your Brain by Any Means Necessary 8
How This Book Is Structured 12
2 Understanding Agile Values 15
A Team Lead, Architect, and Project Manager Walk into a Bar… 16
No Silver Bullet 19
Agile to the Rescue! (Right?) 22
A Fractured Perspective 26
The Agile Manifesto Helps Teams See the Purpose Behind Each Practice 33
Understanding the Elephant 39
Where to Start with a New Methodology 45
3 The Agile Principles 51
The 12 Principles of Agile Software 52
The Customer Is Always Right…Right? 53
Delivering the Project 55
Communicating and Working Together 64
Project Execution-Moving the Project Along 74
Constantly Improving the Project and the Team 78
The Agile Project: Bringing All the Principles Together 81
4 Scrum and Self-Organizing Teams 87
The Rules of Scrum 89
Act I I Can Haz Scrum? 92
Everyone on a Scrum Team Owns the Project 94
Act II Status Updates Are for Social Networks! 109
The Whole Team Uses the Daily Scrum 110
Act III Sprinting into a Wall 119
Sprints, Planning, and Retrospectives 120
Act IV Dog Catches Car 129
5 Scrum Planning and Collective Commitment 137
Act V Not Quite Expecting the Unexpected 138
User Stories, Velocity, and Generally Accepted Scrum Practices 140
Act VI Victory Lap 159
Scrum Values Revisited 160
6 XP and Embracing Change 175
Act I Going into Overtime 176
The Primary Practices of XP 178
Act II The Game Plan Changed, but Were Still Losing 187
The XP Values Help the Team Change Their Mindset 189
An Effective Mindset Starts with the XP Values 195
Act III The Momentum Shifts 200
Understanding the XP Principles Helps You Embrace Change 201
7 XP, Simplicity, and Incremental Design 219
Act IV Going into Overtime, Part 2: Second Overtime 220
Code and Design 222
Make Code and Design Decisions at the Last Responsible Moment 237
Incremental Design and the Holistic XP Practices 245
Act V Final Score 260
8 Lean, Eliminating Waste, and Seeing the Whole 269
Lean Thinking 270
Act I Just One More Thing… 279
Creating Heroes and Magical Thinking 280
Eliminate Waste 283
Gain a Deeper Understanding of the Product 288
Deliver As Fast As Possible 295
9 Kanban, Flow, and Constantly Improving 315
Act II Playing Catch-Up 317
The Principles of Kanban 318
Improving Your Process with Kanban 325
Measure and Manage Flow 339
Emergent Behavior with Kanban 358
10 The Agile Coach 369
Act III Just One More Thing (Again?!)… 371
Coaches Understand Why People Don’t Always Want to Change 371
Coaches Understand How People Learn 376
Coaches Understand What Makes a Methodology Work 380
The Principles of Coaching 382
Index 387