Learning Agile

Chapter 1. Learning Agile

The most important attitude that can be formed is that of desire to go on learning.

John Dewey, Experience and Education

It’s an exciting time to be agile! For the first time, our industry has found a real, sustainable way to solve problems that generations of software development teams have been struggling with. Here are just a few of the solutions that agile promises:

• Agile projects come in on time, which is great for teams that have struggled with projects delivered very late and far over budget.

• Agile projects deliver high-quality software, which is a big change for teams that have been bogged down by buggy, inefficient software.

• Code built by agile teams is well constructed and highly maintainable, which should be a relief to teams accustomed to maintaining convoluted and tangled spaghetti code.

• Agile teams make their users happy, which is a huge change from software that fails to deliver value to the users.

• Best of all, developers on an effective agile team find themselves working normal hours, and are able to spend their nights and weekends with their friends and families—possibly for the first time in their careers.

Agile is popular because many teams that have “gone agile” report great results: they build better software, work together better, satisfy their users, and do it all while having a much more relaxed and enjoyable working environment. Some agile teams seem to have finally made headway in fixing problems that have vexed software teams for decades. So how do great teams use agile to build better software? More specifically, how can you use agile to get results like this?

In this book, you will learn about the two most popular agile methodologies, Scrum and Extreme Programming (XP). You’ll also learn about Lean and Kanban, and how they help you understand the way you build software today and help you evolve to a better state tomorrow. You’ll learn that while these four agile schools of thought focus on different areas of software development, they all have one important thing in common: they focus on changing your team’s mindset.

It’s that mindset shift that takes a team from superficially adding a few token agile practices to one that has genuinely improved the way it builds software. The goal of this book is to help you learn both sides of agile: the practices that make up the day-to-day work, and the values and principles that help you and your team fundamentally change the way that you think about building software.

What Is Agile?

Agile is a set of methods and methodologies that help your team to think more effectively, work more efficiently, and make better decisions.

These methods and methodologies address all of the areas of traditional software engineering, including project management, software design and architecture, and process improvement. Each of those methods and methodologies consists of practices that are streamlined and optimized to make them as easy as possible to adopt.

Agile is also a mindset, because the right mindset can make a big difference in how effectively a team uses the practices. This mindset helps people on a team share information with one another, so that they can make important project decisions together—instead of having a manager who makes all of those decisions alone. An agile mindset is about opening up planning, design, and process improvement to the entire team. An agile team uses practices in a way where everyone shares the same information, and each person on the team has a say in how the practices are applied.

The reality of agile for many teams that have not had as much success is quite different from its promise, and the key to that difference is often the mindset the team brings to each project. The majority of companies that build software have experimented with agile, and while many of them have found success, some teams have gotten less-than-stellar results. They’ve achieved some improvement in how they run their projects—enough to make the effort to adopt agile worth it—but they haven’t seen the substantial changes that they feel agile promised them. This is what that mindset shift is all about; “going agile” means helping the team find an effective mindset.   

But what does “mindset shift” really mean? If you’re on a software team, then what you do every day is plan, design, build, and ship software. What does “mindset” have to do with that? As it turns out, the practices you use to do your everyday work depend a lot on the attitude that you and your teammates have toward them.

Here’s an example. One of the most common agile practices that teams adopt is called the daily standup, a meeting during which team members talk about what they’re working on and their challenges. The meeting is kept short by making everyone stand for the duration. Many teams have had a lot of success adding a daily standup to their projects.

So imagine that a project manager is just learning about agile, and wants to add the daily standup to his project. To his surprise, not everyone on his team is as excited about this new practice as he is. One of his developers is angry that he’s even suggesting that they add a new meeting, and seems to feel insulted by the idea of attending a meeting every day where he’s asked prying questions about his day-to-day work.

Figure 1-1. A project manager who wants to have the team start holding a daily standup is surprised that not everyone is immediately on board with it.

So what’s going on here? Is the developer being irrational? Is the project manager being too demanding? Why is this simple, well-accepted practice causing a conflict?

Both the project manager and the developer have different—and valid—points of view. One of this project manager’s biggest challenges is that he puts a lot of effort into planning the project, but when the team runs into problems building the software they deviate from the plan. He has to work very hard to stay on top of everyone on the team, so that he can make adjustments to the plan and help them deal with their problems.

The developer, on the other hand, feels like he’s interrupted several times a day for meetings, which makes it very hard for him to get his work done. He already knows what he needs to do to get his own code built, and he doesn’t need another person nagging him about plans and changes. He just wants to be left alone to code, and the last thing he wants is yet another meeting.

Figure 1-2. Both people seem to have a valid reason for their attitude toward the daily standup meeting. What effect will this have on the project?

Now imagine that the project manager is able to get everyone—even this reluctant developer—to start attending a daily standup meeting. What will that meeting look like? The project manager will be thinking mainly about how people are deviating from his plan, so he’ll concentrate on getting status from each person. The developer, on the other hand, wants the meeting to end as quickly as possible, so he’ll tune out everyone else while he’s waiting to give his update, then say as little as possible when it’s his turn, and hope that the whole thing ends quickly.

Let’s be clear: this is how many daily standups are run, and while it’s not optimal, a daily standup that’s run this way will still produce results. The project manager will find out about problems with his plan, and the developer will benefit in the long run because those problems that do affect him can be taken care of sooner rather than later—and the whole practice generally saves the team more time and effort than it costs. That makes it worth doing.

But what would happen if the developer and the project manager had a different mindset? What if each person on the team approached the daily standup with an entirely different attitude?

For example, what would happen if the project manager felt like everyone on the team worked together to plan the project? Then the project manager would genuinely listen to each team member, not just to find out how they’ve deviated from his plan, but to understand how the plan that everyone on the team worked together to create might need to change. Instead of dictating a plan, handing it to the team, and measuring how well the team is following it, he’s now working with the team to figure out the best way to approach the project—and the daily standup becomes a way to work together to make sure everyone is doing the most effective thing possible at any given time. As the facts of the project change each day, the team uses the daily standup to work together to make the most effective decisions they can. And because the team meets every day, changes that they discover in the meeting can be put into effect immediately so they don’t waste a lot of time and effort going down the wrong path.

And what if the developer felt like this meeting wasn’t just about giving status, but about understanding how the project is going, and coming together every day to find ways that everyone can work better? Then the daily standup becomes important to him. A good developer almost always has opinions not just about his own code, but about the whole direction of the project. The daily standup becomes his way to make sure that the project is run in a sensible, efficient way—and he knows that in the long run that will make his job of coding more rewarding, because the rest of the project is being run well. And he knows that when he brings up a problem with the plan during the meeting, everyone will listen, and the project will run better because of it.

Figure 1-3. When every person on the team feels like they have an equal hand in planning and running the project, the daily standup becomes more valuable—and much more effective.

In other words, if people on the team are in the mindset that the daily standup is simply a status meeting that must be endured, it’s still worth doing, but it’s only slightly more effective than a traditional status meeting. But if everyone on the team shares the mindset that the daily standup is their way of making sure that everyone is on track, they’re all working toward the same goal, and they all have a say in how the project is run, it becomes much more effective—and also more satisfying. The developer has the attitude that this meeting helps him and his team in the long run. The project manager has the attitude that when each person on the team can contribute to the plan, the project gets better results. And when everyone shares these attitudes, the daily standup helps them all work faster, communicate more directly, and get things done more easily.

This is just one small example of how the mindset and attitude of the team have a big effect on how well they’ll adopt agile practices. An important goal of this book is to help you understand how your own team’s mindset affects your projects and your own agile adoption. By exploring Scrum, XP, Lean, and Kanban, you will learn both sides of the agile coin—principles and practices—and how they come together to help you build better software.

Who Should Read This Book

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.

There’s one other sort of person we wrote this book for: the agile coach. Teams and companies are increasingly relying on agile coaches to guide them in adopting agile methodologies and practices, and to get each team member into the right mindset. If you’re an agile coach, we will give you tools to help you better communicate these ideas to your team, and to overcome some of the challenges that you face every day when helping a team become more agile.

Our Goals for This Book

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 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.

How do all the different agile methodologies and practices give you better software? Why do they give your team the ability to handle change better? Why are these things agile? Does it really matter that you’re using, say, index cards for planning, or that you’re standing up during meetings? These questions are difficult and often confusing for people just starting their path to agility. By the end of this book, you’ll be able to answer them for yourself.

If you look at many of the blogs and articles out there discussing agile software development, one of the first things you’ll read is that “Agile is good, and waterfall is bad.” Why is agile “good,” and waterfall “bad”? Why are they in conflict with each other? Is it possible to work on a team that follows a waterfall process and still be agile? By the end of this book, you’ll able to answer those questions, too.

Getting Agile into Your Brain by Any Means Necessary

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...but we need your help to do it. Here are the tools and techniques you’ll find throughout this book to help make these ideas stick in your head:

Narratives

Denoted by the icon. Think about the last technical book that you read. Can you remember all the major topics it covered, and in what order? Probably not. Now think about the last movie you saw. Can you remember the major plot points, and the order in which they happened? Almost certainly. That’s because your brain is wired to remember things that cause you to have an emotional reaction. In this book, we use that to our advantage. We’ll use narratives—with people, dialog, and conflict—to show you what it looks like when real people encounter agile. These people will run into problems.

What we need from you: Try to imagine yourself in their situation, because that will give you an emotional connection to these ideas, and make it easier for you to remember and understand them. Keep an open mind about these narratives, especially if you’re the sort of learner who doesn’t like to read fiction. There’s real learning in each narrative, and they’re part of the core material in this book.

Illustrations

Different people learn in different ways. Some people are more visual learners, and ideas will “click” much more easily for them when they see a picture. We want to give you as many tools as possible to learn, so we included many illustrations throughout this book. In some cases, we rely heavily on visual metaphor, like using geometric shapes to represent different features, or gears to represent complex software.

What we need from you: If you’re not a visual learner, some of the illustrations may seem superfluous at first, and you may find yourself thinking that a specific illustration doesn’t make sense. This is a good learning opportunity for you, and if this happens then you should take a minute and try to figure out what someone who is a visual learner might get from the illustration. That will help you gain a deeper understanding of the concept.

Redundancy

Most technical books introduce an idea, describe it completely, and then move on to the next one. That’s an effective way to get as much information into a book as possible, but that’s not how our brains work. Sometimes you need to see the same concept more than once before you get that “aha!” moment. This is why we will sometimes come back to the same concept several times within a chapter, or in different chapters. This redundancy is intentional—we do it to help you get to that “aha!” moment.

What we need from you: When you run across a concept for the second or third time, you might be tempted to think, “Didn’t they already cover this?” Yes, we did, and it’s really good that you noticed it! There are other readers who didn’t notice it, the same way you probably won’t notice every time we use redundancy. It’s all done to help you learn.

Simplification (at first!)

Sometimes it’s easier to understand a complex subject by first just scratching the surface, and letting that sink in. We do that many times in this book, introducing a simplified (but still technically correct!) version of a concept, and elaborating on it later. This works on two levels. If it’s an idea that you already understand in depth, then you’ll recognize the simplification and react to it emotionally—and that keeps you engaged. On the other hand, if you aren’t aware of the concept, it helps give you a gentler introduction to prepare you for the more in-depth description later on.

What we need from you: If you feel like something is oversimplified, don’t just dismiss it, and definitely don’t assume that we missed a major idea or that we glossed over or forgot an important point. Chances are, you’ll find the point that you’re looking for later on in the book. If it helps, think of a simplified introduction of a difficult concept as a sort of “Hello, World!” program for your brain—it gives readers who aren’t familiar with the concept a feeling of encouragement so that they know they’re on the right track, and it sets the stage for a deeper understanding later.

Conversational/casual tone

We keep a casual tone throughout this book in order to keep the material as engaging as possible. We use humor and occasional cultural references, and will sometimes speak directly to you or refer to ourselves using pronouns like “us” and “you.” There’s actually science behind this—cognitive research¹ that shows that your brain remembers more when you feel like you’re in a conversation.

What we need from you: While most people have no problem with a casual tone, some people really dislike it. For example, some readers bristle every time they see a contraction. For others, a casual tone makes them feel like the book isn’t authoritative enough. We understand that. Believe it or not, you’ll actually get used to it faster than you might think.

Key Points

Denoted by the icon. Throughout each chapter we’ll summarize key points that were covered recently. This helps you make sure that you “got” everything, and that you didn’t miss an important concept. It also gives your brain a quick break from learning.

What we need from you: Don’t just skip over the Key Points sections. Take a minute and look through them. Do you remember each of those points? If not, don’t be afraid to flip back a few pages and refresh your memory.

Frequently Asked Questions

Denoted by the icon. We spend most of our time actually working on software teams building real software for real users, but we’ve also spent years giving talks and presentations about agile, and talking to many, many people. And over all of that discussion, there are some questions that people kept asking over and over again.

What we need from you: Read the Frequently Asked Questions at the end of each chapter. Was this a question that you had? If so, do you like the answer? You may not always like the answer, but try to find the truth in it. If it wasn’t a question that you had, try to figure out why someone might ask it—that can help you see the material from a different perspective (and you’ll learn in Chapter 2 why that is important for a team).

What You Can Do Today

Denoted by the icon. The most effective way to learn something is to do it! At the end of each chapter, we include a short section that gives you a few things that you can do today, right now, either alone or with your team.

What we need from you: Obviously, the best thing that you can do is actually try those things! But the reality is that not every team or company is open to this—and one of the most important things you’ll learn throughout the book is that trying to put a practice in place on a team with an incompatible mindset can end badly. So before you try these things, think about how your team will respond. That can be as effective a learning tool as actually doing it.

Where You Can Learn More

Denoted by the icon. Isaac Newton once said, “If I have seen further it is by standing on the shoulders of giants.” We’re lucky to be writing this at a time when there have been so many groundbreaking books written about agile software development. After each chapter, we’ll give you a few places where you can learn more about what we just taught.

What we need from you: Keep learning! This book is a thorough overview of Scrum, XP, Lean, and Kanban, but we can’t cover every detail of each of these ideas. We didn’t come up with most of the ideas in this book; luckily, you can learn from the people who did.

Coaching Tips

Denoted by the icon. An agile coach is someone who helps teams learn agile. This book is written for someone who is learning agile, but it can also be used as a guide to help an experienced agile coach introduce these ideas to her team. If you’re an agile coach, look for the coaching tips at the end of each chapter. They’ll help you take the ideas and the approach that we use and adapt them to your own team.

What we need from you: Even if you’re not a coach, you should still read the coaching tips. That’s because one effective way to learn is to put yourself in the shoes of someone who is teaching others. If you’re learning these concepts for the first time, imagine how you might use these coaching tips to help your team learn more about agile.

How This Book Is Structured

This book is structured to help you understand agile by teaching the values and principles of an effective software team, the schools of thought that embody those values, and the practices that make them up.

The next two chapters will help you understand the values and principles that will help you to adopt an agile mindset. They will give you the tools to figure out if your team and your company are ready to adopt agile, which parts of agile will resonate with your team, and which might be more difficult to implement:

• Chapter 2, Understanding Agile Values, describes the core agile values. We will show you an example of a team struggling with a software project, and help you recognize that a main source of the struggle is a “fractured perspective.” We’ll explain the agile values, and use a metaphor to help you see how those values bring the team’s perspective together.

• Chapter 3, The Agile Principles, describes the principles that agile teams use to make decisions about how to run their projects. We’ll show you the purpose and idea behind each of the principles, illustrating them with a practical example from a software project.

The following six chapters will teach you about the most popular agile schools of thought: Scrum, XP, Lean, and Kanban. You’ll learn their basic application in a way that you can put in place on your team today:

• Chapter 4, Scrum and Self-Organizing Teams, uses Scrum, a popular agile methodology, to teach you how self-organizing teams work. We’ll give you advice for adopting Scrum on your own projects, and tools to help your team learn to self-organize.

• Chapter 5, Scrum Planning and Collective Commitment, shows you specific practices that Scrum teams use to plan their projects, and how those practices help your team commit as a whole to delivering valuable software. We’ll show you how real-life adoption of Scrum depends on how well the Scrum values match the culture of your team and your company, and what to do if they don’t.

• Chapter 6, XP and Embracing Change, teaches you about the primary practices of Extreme Programming, and the XP values and principles. You’ll learn how they help get each team member into the right mindset to build better code: instead of hating change, every person on the team learns to embrace it.

• Chapter 7, XP, Simplicity, and Incremental Design, teaches you about the final three primary practices of XP, and how they help you avoid serious code and design problems. You’ll learn how all of the XP practices form an ecosystem that leads to better, more maintainable, flexible, and changeable code.

• Chapter 8, Lean, Eliminating Waste, and Seeing the Whole, teaches you about Lean, and the values that help you get into the lean thinking mindset. And we show you how the Lean thinking tools can help your team identify waste and eliminate it, and see the whole system that you use to build software.

• Chapter 9, Kanban, Flow, and Constantly Improving, teaches you about Kanban, its principles and how they relate to Lean, and its practices. You’ll learn how its emphasis on flow and queuing theory can help your team put lean thinking into practice. And you’ll learn about how Kanban can help your team to create a culture of continuous improvement.

The world of agile includes more than mindsets, methodologies, and schools of thought. Companies are increasingly relying on agile coaches to help their teams adopt agile. This is why we included the final chapter in the book:

• Chapter 10, The Agile Coach, teaches you about agile coaching: how teams learn, how an agile coach can help a team change their mindset so that they can more easily adopt an agile methodology, and how that coach can help you and your team become more agile.

Figure 1-4.
Live graphic recording of Andrew Stellman’s talk at the STRETCH 2013 conference in Budapest, Hungary. The talk was based on the material in this chapter.

Graphic recording: Kata Máthé and Márti Frigyik
www.remarker.eu

¹ If you’re interested in learning more about how conversational tone helps you learn, have a look at E-Learning and the Science of Instruction by Ruth C. Clark and Richard E. Mayer (Wiley, 2011).