Chapter 1. What is agile?: Principles and practices
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. Agile teams use simple, straightforward practices that have been proven to work on real-life projects. But wait a minute...if agile is so great, why isn’t everyone doing it? It turns out that in the real world, a practice that works really well for one team causes serious problems for another team, and the difference is the team mindset. So get ready to change the way you think about your projects!
The new features sound great...
Meet Kate. She’s a project manager at a successful Silicon Valley startup. Her company builds software that’s used by video and music streaming services and internet radio stations to analyze audiences in real time and choose programming suggestions that make their viewers or listeners happy. And now Kate’s team has an opportunity to deliver something that will really help the company.
...but things don’t always go as expected
Kate’s discussion with the project team didn’t go nearly as well as she’d hoped. What’s she going to tell Ben?
Kate: So if we can get those new advanced audience analytics features into the next release, we’ll all get a big bonus.
Mike: Well, that sounds like it would be great.
Kate: Fantastic! So we can count on you guys?
Mike: Hold on! Not so fast. I said it sounds like it would be great. But there’s no way it’s happening.
Kate: Wait, what?! Don’t mess with me, Mike.
Mike: Look, if we’d known about this change four months ago when we were designing the audience data analysis service, this would be easy. But now we’d have to rip out a huge chunk of code and replace it with... well, I don’t want to get into technical details.
Kate: Good. I don’t want to hear them.
Mike: So... are we done here? Because my team’s got a lot of work to do.
Agile to the rescue!
Kate’s been reading about agile, and she thinks it might help her get those features into the next release. Agile’s gotten really popular with software teams because the ones that have “gone agile” often talk about the great results they get. The software they build is better, which makes a big difference to them and their users. Not only that, but when agile teams are effective, they have a much better time at work! Things are more relaxed, and the working environment is a lot more enjoyable.
So why has agile gotten so popular? Lots of reasons:
When teams go agile, they find that it’s a lot easier to meet their deadlines.
They also find that they can really cut down on bugs in their software.
Their code is a lot easier to maintain—adding, extending, or changing their codebase is no longer a headache.
The users are a lot happier, which always makes everyone’s lives easier.
And best of all, when agile teams are effective, the team members’ lives are better, because they can go home at a reasonable hour and rarely have to work weekends (which, for a lot of developers, is a first!).
A daily standup is a good starting point
One of the most common agile practices that teams adopt is called the daily standup, a meeting that happens every day, 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. Adding a daily standup to their projects has brought success to a lot of teams, and it’s often the first step in going agile.
Kate tries to hold a daily standup
To Kate’s surprise, not everyone on Mike’s team shares her excitement for this new practice. In fact, one of his developers is angry that she’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.
Different team members have different attitudes
Kate ran into problems adopting agile almost as soon as she started—and she’s not alone.
The truth is that a lot of teams simply haven’t had as much success with agile as they’d hoped they would. Did you know that well over half of companies that build software have experimented with agile? Despite the success stories—and there are many of them!—a lot of teams try agile, but end up with results that they’re not particularly happy with. In fact, they feel a little ripped off! It seemed like agile came with a promise of big changes, but trying to get agile working on their own projects never seemed to work out.
And that’s what’s happening to Kate. She created a plan all on her own, and now she wants to get status updates from her team. So she’s started dragging a reluctant team to her daily standup meeting. She’s able to get them in the room. But will it really make a difference? She’s worried about how people are deviating from her plan, so she’ll concentrate on getting a status update from each person. Mike and his developers, on the other hand, want the meeting to end as quickly as possible so they can get back to “real” work.
No! The right mindset makes practices more effective.
Let’s be clear: the way Kate is running her standups 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. Kate will find out about problems with her plan, and Mike’s team will benefit in the long run because those problems that do affect them can be taken care of sooner rather than later. The whole thing doesn’t take much time every day, and that makes it worth doing.
But there’s a big difference between an agile team that goes through the motions and one that gets great results. The key to that difference is the mindset the team brings to each project. Believe it or not, the attitude that each person takes toward a practice can make it much more effective!
Note
The attitude that each team member brings to a practice like the daily standup makes a huge difference in how effective it is. But even when everyone tunes out, the meeting is still effective enough to make it worth doing, even if it’s boring.
A better mindset makes the practice work better
What would happen if Kate and Mike 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 Kate felt like everyone on the team worked together to plan the project? Then she would genuinely listen to every single developer. If Kate changes her attitude toward the standup, she’ll stop trying to figure out how they’ve deviated from her plan so that she can correct them. The focus of the meeting changes for her: now it’s about understanding the plan that everyone on the team worked together to create, and her job is about helping the whole team do their work more effectivly.
That’s a very different way of thinking about planning, one that Kate was never taught in any of her project management training courses. She was always taught that it was her job to come up with a project plan and basically dictate it to the team. She had tools that let her measure how well the team followed her plan, and strict processes that she would enforce to make changes to it.
Now things are totally different for her. She realized that the only way she could make the daily standup work is if she puts effort into working with the team so that everyone on the team can work together to figure out the best approach to the project. Then the daily standup turns into a way for the whole team to work together to make sure everyone is making solid decisions, and that the project is on track.
Note
Kate used to get really frustrated when she discovered changes to her project plan, because it was usually too late for the team to effectively change course.
Note
Now that the daily standup is in place, the whole team works with her every day to find those changes, so they can make them much earlier. That’s a lot more effective!
And what if Mike felt like this meeting wasn’t just about giving status updates, 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 Mike knows that in the long run that will make his job of coding more rewarding for his team, 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.
Things work best when Mike (and the rest of the team) figure out that the daily standup helps them plan the next day’s worth of work—and every single person on the team is part of the planning process.
So what is agile, anyway?
Agile is a set of methods and methodologies that are optimized to help with specific problems that software teams run into, and kept simple so they’re relatively straightforward to implement.
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.
Mindset versus methodology
Agile is also a mindset, and that’s a new idea for a lot of people who haven’t worked with agile before. It turns out that each team member’s attitude toward the practices they use can make a huge difference in how effective those practices are. The agile mindset is focused on helping people share information with each other, which makes it much easier for them to make important project decisions (rather than just relying on a boss or project manager to make those decisions). It’s about opening up planning, design, and process improvement to the entire team. To help everyone get into an effective mindset, each agile methodology has its own set of values that team members can use as a guide.
Scrum is the most common approach to agile
There are many ways that teams can be agile, and there’s a long list of methods and methodologies that agile teams use. But there have been many surveys done over the years that have found that the most common approach to agile is Scrum, a software development framework focused on project management and product development.
When a team uses Scrum, every project follows the same basic pattern. There are three main roles on a Scrum project: the Product Owner (like Ben) works with the team to maintain a Product Backlog; the Scrum Master helps guide the team past roadblocks; and the Development Team members (everyone else on the team). The project is divided into sprints, or cycles of equal length (often two weeks or 30 days) that follow the Scrum pattern. At the start of a sprint, the team does sprint planning to determine which features from the Product Backlog they’ll build during the sprint. This is called the Sprint Backlog, and the team works throughout the sprint to build all of the features in it. Every day the team holds a short meeting called the Daily Scrum. At the end of the sprint, working software is demonstrated to the product owner and stakeholders in the sprint review, and the team holds a retrospective to figure out lessons they’ve learned.
We’ll cover Scrum in depth in Chapter 3 and Chapter 4, and we’ll not only teach you how it helps teams build better software and run more successful projects, but we’ll also use it to explore important concepts and ideas shared by all agile teams.
XP and Lean/Kanban
While Scrum is the most popular agile methodology, many teams take other approaches. The next most popular methodology is XP, a methodology focused on software development and programming that’s often used in combination with Scrum. Other teams approach agile with Lean and Kanban, a mindset that gives you tools to understand the way you build software today and a method that helps you evolve to a better state tomorrow. You’ll learn about XP and Lean/Kanban in Chapter 5 and Chapter 6.
there are no Dumb Questions
Q: It sounds like Scrum, XP, and Lean/Kanban are very different from each other. How can they all be agile?
A: Scrum, XP, and Lean/Kanban focus on very different areas. Scrum is mainly focused on project management: what work is getting done, and making sure that it’s in line with what the users and stakeholders need. XP is focused on software development: building high-quality code that’s well-designed and easy to maintain. Lean/Kanban is a combination of the Lean mindset and the Kanban method, and teams use it to focus on continually improving the way that they build software.
In other words, Scrum, XP, and Lean/Kanban are focused on three different areas of software engineering: project management, design and architecture, and process improvement. So it makes sense that they would have different practices—that’s how they differ.
In the next chapter you’ll learn about what they have in common: shared values and principles that help teams adopt an agile mindset.
Q: Isn’t this all just stuff I know already, only with a new name? Like, Scrum sprints are really just milestones and project phases, right?
A: When you come across an agile methodology like Scrum for the first time, it’s really common to look for the parts of it that are similar to things you already know—and that’s a good thing! If you’ve been working on teams for a while, then a lot of agile should feel familiar. Your team builds something, and you and your teammates are almost certainly doing a lot of things well that you don’t want to change (yet!).
However, it’s very easy to fall into the trap of thinking that a familiar-seeming part of agile is exactly the same thing as something you already know. For example, Scrum sprints are not the same thing as project phases. There are many differences between phases or milestones in traditional project management and sprints in Scrum.
For example, in a typical project plan, all of the project phases are planned at the beginning of the project; in Scrum, only the next sprint is planned in detail. This difference can feel very strange to a team accustomed to traditional project management.
You’ll learn a lot more about how Scrum planning works, and how it may be different from what you’re used to. In the meantime, keep an open mind—and try to catch yourself when you have the thought, “This is just like something I already know!”
Kate: This project’s gone so much better than ones in the past. And all because of one little meeting every day!
Mike: Well, I wouldn’t say that.
Kate: Come on, Mike! Don’t be such a pessimist.
Mike: No, seriously. Look, you didn’t really think you’re the first person to try to solve our project problems by adding meetings, did you?
Kate: Well, I... um...
Mike: We got some really good results, so I’ll be honest with you here. When you started holding those daily standups, almost everyone on the team was unhappy.
Kate: Really?
Mike: Yeah. Don’t you remember how for the first week and a half, most of us just stared at our phones the whole time?
Kate: Well, sure. I guess that wasn’t particularly useful. If I’m honest with myself, I was actually thinking about calling the whole thing off.
Mike: But then one of my coders brought up that serious architecture issue. Everyone listened because she’s really good, and they all respect her opinion.
Kate: Right. We had to make a major change, and I cut two of the features out of the release to make room for it.
Mike: Yes! That was really important. Normally when we run into a problem like that, we have to work late nights to deal with the aftermath. Like when we found out that the listener feedback analysis algorithm had a serious flaw in it.
Kate: Ugh, that was awful. I usually find out about problems like that after we’ve all promised things we couldn’t deliver. This time we caught the problem early, and I could work with Ben to manage our users’ expectations and get you guys the time you needed to come up with a new approach.
Mike: We’ll definitely bring up problems like that every time they come up.
Note
Looks like Kate discovered that software projects are a lot less clean and simple in real life than they are on paper. Before, she could just build her plan and then force the team to work it...and when things went wrong, it was their fault, not hers.
Note
On the other hand, this project went a lot better than her last ones. She had to work a lot harder to deal with problems, but she got better results!
Kate: Wait—what? That kind of problem happens a lot?!
Mike: Are you kidding? I’ve never had a project that didn’t run into at least one nasty surprise like that once we started coding. That’s how software projects work in the real world, Kate.
The PMI-ACP certification can help you be more agile
The Agile Certified Practitioner (PMI-ACP)® certification was created by the Project Management Institute to meet the needs of project managers who have increasingly found themselves working with agile methods, methodologies, practices, and techniques. And just like with the PMP certification, PMI has constructed an exam based on realworld tasks, tools, and practices used by agile teams every day.
Note
The PMI-ACP certification is for anyone who works on agile teams, or in an organization that’s moving toward adopting agile.
The exam is focused on real-world agile knowledge.
The PMI-ACP exam is designed to reflect the way teams work in the real world. It covers the most common methods and methodologies, including Scrum, XP, and Lean/Kanban. The exam questions are based on knowledge and real-world tasks that teams use every day.
That’s why this book is, first and foremost, built to teach you agile: because understanding agile methods, methodologies, practices, values, and ideas is the most effective way to prepare for the PMI-ACP certification.
Note
Part 1 of this book has just a little bit of material specific to the PMI-ACP®, because focusing on learning about agile is the most effective way to prepare for the exam.
In addition to teaching you all about agile, we will also spend some time focusing specifically on exam material. This book has 100% coverage of the PMI-ACP exam content, and includes many practice questions, test-taking tips, and exam preparation exercises, including a complete, full-length practice exam that mimics the real thing.
Chapter 2 through Chapter 7 each end with a set of practice questions. They also include “Question Clinic” sections that break down different types of questions that you’ll run across on the exam.
Learning to recognize different kinds of questions that you’ll see on the exam is really useful because when you see something familiar it helps your brain relax, which can help the answer come more quickly. We call this one the “Just the facts, ma’am” question. It looks like it’s just asking for some basic information, but read all of the answers carefully! There’s often a misleading answer that looks like it might be right, but isn’t.
Get Head First Agile now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.
