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.

Two people can see the same practice very differently. If they don’t both feel like they’re getting something out of it, it can make the practice much less effective.

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!

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.

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.

Brain Power

What happens if one team member checks out during the daily standup and doesn’t really listen to his or her teammates?

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.

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.

Relax

Getting a little overwhelmed with new vocabulary?

We’ll highlight new vocabulary words in boldface when we first introduce them. We did that a lot on this page—and if there are a few that you’re not familiar with, that’s OK! Seeing new ideas in context now will help them sink into your brain when you learn about them in detail later. That’s part of the Head First neuroscience that makes this lesson brain-friendly!

Watch it!

Don’t just dismiss the idea that mindset matters!

A lot of people—especially hardcore developers—tune out as soon as they start hearing words like mindset, values, and principles. That’s especially true of coders who have a habit of locking themselves in a room and never talking to anyone. If you’re starting to think this way, really try to give these ideas the benefit of the doubt. After all, a lot of great software has been built this way, so there has to be something to it... right?

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.

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 real-world tasks, tools, and practices used by agile teams every day.

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

In addition to teaching you all about agile, we will also spend some time focusing specifically on exam material. This lesson includes many practice questions, test-taking tips, and exam preparation exercises, including a complete, full-length practice exam that mimics the real thing.

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.