Chapter 2. Agile values and principles: Mindset meets method
There’s no “perfect” recipe for building great software.
Some teams have had a lot of success and seen big improvements after adopting agile practices, methods, and methodologies, while others have struggled. We’ve learned that the difference is the mindset that the people on the team have. So what do you do if you want to get those great agile results for your own team? How do you make sure your team has the right mindset? That’s where the Agile Manifesto comes in. When you and your team get your head around its values and principles, you start to think differently about the agile practices and how they work, and they start to become a lot more effective.
Something big happened in Snowbird
In the 1990s there was a growing movement throughout the software development world. Teams were growing tired of the traditional way of building software using a waterfall process, where the team first defines strict requirements, then draws up a complete design, and builds out all of the software architecture on paper before the code is written.
Note
People on waterfall teams weren’t always 100% clear on exactly why they didn’t like their process, but there was a lot of agreement that it was somehow too “heavyweight” and cumbersome.
By the end of the decade, there was a growing consensus that teams needed a more “lightweight” way to build software, and several methodologies—especially Scrum and XP—were gaining popularity as the way to accomplish that.
Leaders from across the industry got together to figure out if there was anything in common among the various and increasingly popular lightweight methods for building software.
Meeting of the minds
In 2001, a group of seventeen open-minded people got together at the Snowbird ski resort in the mountains outside of Salt Lake City, Utah. The group included thought leaders from all across the new “lightweight” world, including the creators of Scrum and XP. They weren’t sure exactly what would come out of the meeting, but there was a strong sense that these new lightweight methods for building software had something in common. They wanted to figure out if they were right, and maybe find a way to write it down.
The Agile Manifesto
It didn’t take long for the group to converge on four values that they all had in common. They wrote those values down in what would come to be known as the Agile Manifesto.
Note
The idea that there’s no “silver bullet” method for building software was first introduced in the 1980s by pioneering software engineer Fred Brooks, in an essay called “No Silver Bullet.”
They weren’t trying to come up with a “unified” methodology.
One of the fundamental ideas in modern software engineering is that there’s no single “best” way to build software. That’s an important idea that’s been around in software engineering for decades. The Agile Manifesto is effective because it lays out values that help teams get into an agile mindset. When everyone on the team genuinely incorporates these values into the way they think, it actually helps them build better software.
Adding practices in the real world can be a challenge
Teams are always looking for ways to improve. We’ve seen how practices can help. That’s especially true of the lightweight practices used by agile teams, which are designed to be simple, straightforward, and easy to adopt. But we’ve also seen that the team’s mindset or attitude can make it much more difficult to adopt them successfully—like when Kate found that the attitude that she, Mike, and the rest of the team had made a big difference when she tried to start holding a daily standup meeting.
The four values of the Agile Manifesto guide the team to a better, more effective mindset
The Agile Manifesto contains four X over Y lines that help us understand what agile teams value. Each of those lines tells us something specific about the values that drive an agile mindset. We can use them to help us understand what it means for a team to be agile.
Let’s take a closer look each of those four values →
Agile teams recognize that processes and tools are important. You’ve already learned about a few practices that agile teams use: daily standups, user stories, task boards, burndown charts, refactoring, and retrospectives. These are all valuable tools that can make a real difference to an agile team.
But agile teams value individuals and interactions even more than processes and tools, because teams always work best when you pay attention to the human element.
You’ve already seen an example of this—when Kate tried to introduce daily standups, and ended up getting into a conflict with Mike and his development team. That’s because a tool that works really well for one team can cause serious problems for another team if the people on the team aren’t getting anything out of it, and if it’s not directly helping them build software.
Good idea, Kate!
Processes and tools are important to getting the project done, and they can be really valuable. But the individual people on the team are even more important, and any tool that you introduce needs to improve their interactions with each other and with their users and stakeholders.
What does “working” software mean? How do you know if your software works? That’s actually a harder question to answer than you might think. A traditional waterfall team starts a project by building comprehensive requirements documents to determine what the team will build, reviews that documentation with the users and stakeholders, and then passes it on to the developers to build.
Most professional software developers have had that terrible meeting where the team proudly demonstrates the software they’ve been working on, only to have a user complain that it’s missing an important feature, or that it doesn’t work correctly. It often ends in an argument, like the one that Ben had with Mike after he gave a demo of a feature his team had been working on for a few months:
A lot of people try to fix this problem with comprehensive documentation, but that can actually make the situation worse. The problem with documentation is that two people can read the same page and come away with two very different interpretations.
That’s why agile teams value working software over comprehensive documentation—because it turns out that the most effective way for a user to gauge how well the software works is to actually use it.
No, this isn’t about consultants or procurement teams who have to deal with contracts!
When people on agile teams talk about contract negotiation, they often mean an attitude that people take toward their users, customers, or people on other teams. When people on a team have a “contract negotiation” mindset, they feel like they have to come to a strict agreement on what the team will build or do before any work can start. Many companies encourage this mindset, asking teams to provide explicit “agreements” (often documented in specifications, and enforced with strict change control procedures) about what it is they will deliver and when.
Note
Contract negotiation is necessary in cases where the customers are unwilling to collaborate. It’s very difficult to genuinely collaborate with someone who’s being unreasonable—like a customer who routinely changes the scope of the project, but refuses to give the team enough time to make those changes.
Agile teams value customer collaboration over contract negotiation. They recognize that projects change, and that people never have perfect information when starting a project. So instead of trying to nail down exactly what’s going to be built before they start, they collaborate with their users to try to get the best results.
Scrum teams are especially good at this because they have a product owner like Ben who is a true member of the team. He might not have been developing code, but he worked hard on the project by talking to users, understanding what they needed, and working with the rest of the team to help them understand those needs and build working software.
Some project managers have a saying: “Plan the work, work the plan.” And agile teams recognize that planning is important. But working a plan that has problems will cause the team to build a product with problems.
Traditional waterfall projects have ways of handling changes, but they usually involve strict and time-consuming change control procedures. This reflects a mindset in which changes are the exception, not the rule.
The problem with plans is that they’re built at the start of projects, and that’s when the team knows the least about the product they’re going to build. So agile teams expect that their plans will change.
That’s why they typically use methodologies that have tools to help them constantly look for changes and respond to them. You’ve already seen a tool like that: the daily standup.
It’s important to plan your project, but it’s even more important to recognize that those plans will change once the team starts working on the code.
Once Kate and Mike sorted out their differences, they both realized that the daily standup was a way for everyone to look at the plan every day, and work together to respond to any changes that were needed. When everyone on the team worked together to respond to change, they were able to update the plan that they all built together without introducing chaos into the project.
Manifesto Magnets
Oops! You had the Agile Manifesto re-created perfectly with refrigerator magnets! But someone slammed the door and they all fell off. Can you put the whole thing back together? See how much of it you can do without flipping back and looking for hints.
Don’t worry about the order of the values.
The four values in the Agile Manifesto are equally important, so there’s no particular order for them. Just make sure that each specific value (X over Y) is matched up.
Answers in “Manifesto Magnets Solution”
there are no Dumb Questions
Q: I’m still not clear on what “waterfall” means.
A: “Waterfall” is the name given to a specific way that software companies have traditionally built software. They divide their projects into phases, usually drawn in a diagram that looks like this:
It was given the name “waterfall” by a software engineering researcher in the 1970s who first described it as a less-than-effective way to build software. The team is often expected to come up with a near-perfect requirements document and design before they start building code, because it takes a lot of time and effort to go back and fix the requirements and design when the team finds problems with them.
The problem is that there’s often no way to know if the requirements and design are right until the team starts building code. It’s very common for a waterfall team to think they got everything right in the documentation, only to discover serious flaws when the developers start implementing the design.
Q: Then why would anyone ever use a waterfall process?
A: Because it works—or, at least, it can work. There have been plenty of teams that used a waterfall process and built great software. It’s certainly possible to create the requirements and design first so that there are relatively few changes.
More importantly, there are a lot of companies where the culture really lends itself to a waterfall process. For example, if you work for a boss who will severely punish you if he thinks you made a mistake, then having him personally approve fully fleshed-out requirements and design documents before any code is written can help you keep your job. But no matter how you do it, the effort it takes to figure out who’s accountable for each decision in the project takes away from effort that could be spent actually building your product.
Q: So is waterfall good or bad? And how is it less “lightweight” than an agile methodology, approach, or framework?
A: Waterfall isn’t “good” or “bad,” it’s just a certain way of doing things. Like any tool, it has its strengths and weaknesses.
However, many teams find a lot more success with agile methodologies like Scrum than they do with a waterfall process. One reason is that they find a waterfall process too “heavyweight” because it imposes a lot of restrictions on how they work: they’re required to go through complete requirements and design phases before any code is written. In the next chapter, you’ll learn how Scrum teams use their sprints and planning practices to start building the software quickly, which lets them get working software into the hands of their users. This feels a lot more “lightweight” to the team because everything they’re doing has an immediate effect on the code that gets built.
Q: Then exactly how should I run my projects? Should my team create documentation or not? Do we work from a complete specification? Should we throw out documentation altogether?
A: Documentation is important to agile teams—but mainly because it can be an effective way to build working software. Documentation is only useful if people read it, and the truth of the matter is that a lot of people just don’t read documentation.
When I write a specification requirements document and give it to you and your team to build, the document isn’t important. The important thing is that what’s in my head matches what’s in your head, and what’s in each of the team members’ heads. In some cases, like when there are complex calculations or workflows, a document can be a really effective way to the shared understanding that leads to great software.
Q: I’m just not sold on this idea that values are important. How do they help me and my team actually write code?
A: The values in the Agile Manifesto help you and your team get into a mindset that helps you build better software. And you’ve already learned that your mindset—the attitude that you have toward the practices that you use—can make a big difference.
Think about the example in the last chapter, where Kate and Mike were having trouble with the daily standup meeting. Kate only got mediocre results when she used it as a way to dictate her plan to the team and demand status from them. But when everyone had a more collaborative attitude, they got much better results. That’s how mindset can have a big effect on real-world results.
Question Clinic: The “which-is-BEST” question
A great way to prepare for the exam is to learn about the different kinds of questions, and then try writing your own. Each of these Question Clinics will look at a different type of question, and give you practice writing one yourself. Even if you’re not using this book to prepare for the PMI-ACP certification exam, give this a shot. It can still be a great way to help get these concepts into your brain!
Note
Take a little time out of the chapter for this Question Clinic. It’s here to let your brain have a break and think about something different.
They think they’ve got a hit ...
Mike’s been working with the development team for almost a year on the latest killer feature, and he’s really excited that they’re finally done.
... but it’s a flop!
Uh-oh. It looks like Mike and his team wasted a year working on a product that nobody wants. What happened?
Mike: What?! We’ve been working on this for a year. Are you telling me we just wasted our time?
Ben: I have no idea what you’ve been doing with your time. But I’m telling you right now, I don’t see any of our clients using this.
Mike: But what about that big presentation we gave at that conference last year? Every client we talked to said they would love to figure out exactly who their listeners are and start marketing directly to them.
Ben: Right. And nine months ago, three of those clients were named in a lawsuit for violating privacy laws. Now none of them would touch this.
Mike: But... but this is a huge innovation! You have no idea how many technical problems we had to solve. We even brought in a specialized AI consulting company to help us do advanced customer analysis!
Ben: Look, Mike, I don’t know what to tell you. Maybe you can repurpose the code for something else?
Mike: We’re going to have to salvage what we can. But I’ll tell you right now, whenever we tear out chunks of code, we always have bugs.
Note
This makes sense! A major source of bugs is rework, or taking code that was already built and modifying it for another purpose.
Ben: Ugh. I wish you’d talked to me about this sooner.
The principles behind the Agile Manifesto
The four values in the Agile Manifesto do a really good job of capturing the core of the agile mindset. But while those four values are great at giving you a high-level understanding of what it means to “think agile,” there are a lot of day-to-day decisions that every software team needs to make. So in addition to the four values, there are twelve principles behind the Agile Manifesto that are there to help you really understand the agile mindset.
The agile principles help you deliver your product
The first three principles are all about delivering software to your users. And the most effective way to deliver the best software possible is to make sure that it’s valuable. But what does “value” really mean? How do we make sure that we’ve got our users, stakeholders, and customers’ best interests in mind when we’re building software? These principles help us understand those things.
So what does that mean, exactly? It means that early delivery and continuous delivery add up to satisfied users:
Note
Early delivery
Getting the first version of the software into users’ hands as early as possible so you can get early feedback
Continuous delivery
Constantly getting updated versions to the users so they can help the team build software that solves their most important problems
Satisfied users
The users help the team stay on track by making sure that the most important features are added first
When the team delivers software early and often to the users, stakeholders, and customers, that gives everyone lots of chances to find changes early, when they’re much easier to make.
How does the team react when someone points out that they need to make a change that will affect a lot of the code? Every developer has been through this, and it can be a lot of (often difficult) work. So how does the team react? It’s natural to resist a big change. But if the team can find a way to not just accept but welcome that change, it means that they’re putting the users’ long-term needs ahead of their own short-term annoyance.
Note
“Requirements” just means what the software is supposed to do... but sometimes the users’ needs change, or the programmers misunderstand what’s needed, and that can lead to changing requirements.
When developers push back against changes, it’s not an irrational response: if they’ve spent many months working on a feature, changing that code can be a slow, painful, and error-prone process. One reason is that when teams do rework (that’s when they change existing code to do something new) it almost always leads to bugs, often ones that are really nasty and difficult to track down and fix.
So how does the team avoid rework? Deliver working software to the users frequently. If the team is building a feature that isn’t useful or does the wrong thing, the users will spot it early, and the team can make the change before too much code is written... and preventing rework prevents bugs.
Principles make the most sense in practice.
Most of us have been on teams that have struggled at one point or another, and the most common way to handle that situation is to adopt a new practice. But some practices that work really well for some teams only get marginal results with other teams—just like we saw with the daily standup in Chapter 1.
So what makes the difference between the team that only gets so-so results with a practice and the one that gets really great results? More often than not, it has a lot to do with the mindset of the team, and the attitude they bring to the practice. And that’s what these principles are about: helping teams find the best mindset that makes their practices as effective as possible.
You’ll see an example on the next page...
Fireside Chats
Tonight’s talk: Practice meets principle
| Principle: | Practice: |
| I’ve been looking forward to this debate for a while. | |
| I’m not sure there’s going to be much of a debate, if you want to know the truth. | |
| This again? There he goes, back on his “nothing gets done without practices” kick. | |
| Well, you have to admit, it’s a pretty good point. After all, where would an approach like Scrum be without me? Take away the sprints, backlogs, retrospectives, sprint reviews, Daily Scrum meetings, and sprint planning sessions, and what are you left with? Chaos! | |
| Yeah? OK. Let’s talk about those practices for a minute. Like the Daily Scrum, for example— | |
| Hold it right there. I already know what you’re going to say next. It’s that whole thing about the Daily Scrum getting “mediocre” results if the team doesn’t “get” the principles. | |
| Yep! And it’s not just the Daily Scrum. Let’s talk about iteration. | |
| A fantastic practice, thank you very much. | |
| Indeed. But what happens if the people on the team don’t really, genuinely believe in the principle of delivering working software frequently? | |
| There will still be iterations! And you know what? It’ll be better than it was before they added the practice. | |
| Yes. But will they really deliver working software? Or will they cut corners just to push something out the door before the iteration ends? Will they really delay a feature until the next iteration because it won’t fit? Or will adding iteration to the project make everyone on the team feel like they’re just “going through the motions”? | |
| Well, at least they’ll have something to show for their effort. Even if they only get a marginal improvement, it’s better than nothing! |
Note
Have you been on a team that tried to go agile but ended up with mediocre results? If so, this might remind you of your own experience.
Note
This is true! Even when the team doesn’t really understand the principles, adding iterations is still usually an improvement... not much of one, but enough to justify doing it.
there are no Dumb Questions
Q: Does each principle match up with exactly one practice? Is there a one-to-one correspondence?
A: Not at all. The first three principles behind the Agile Manifesto emphasize early and continuous delivery of software, welcoming changing requirements, and delivering working software frequently. And we used two practices (iteration and backlog) to help you understand the principles on a deeper level. But that doesn’t mean there’s a one-to-one relationship between the practices and the principles.
In fact, the opposite is true. You can have principles without practices, and you can have practices without principles.
Q: I’m not sure how that works. What exactly do you mean by “practices without principles”?
A: Here’s an example of what it looks like when a team puts a practice in place without really understanding or internalizing the agile principles. Scrum teams hold a retrospective at the end of each sprint so that they can talk about what went well and what can be improved.
But take another look at the last principle in the list:
What if the team hasn’t really taken this idea to heart? They’ll still have the retrospective meeting because the Scrum rules tell them to do it. And they’ll probably talk about some of the problems that they had, which can certainly lead to some marginal improvements.
The problem is that while the new meeting did something, it feels like it’s somewhat “empty” or superfluous. The people on the team feel like they’re taking time away from their “real” jobs to do it. Eventually, they’ll start talking about replacing it with something more “efficient,” like using an email discussion list or wiki page. A lot of teams have that experience when they add practices without principles.
Q: OK, I think I see how you can have practices without really believing in the principles. But how can you have principles without practices?
A: A lot of people have a little trouble with this idea when they first come in contact with the idea of an “agile mindset” driven by principles.
So what does it look like if the team takes very seriously the agile principle of reflecting on how to become more effective, but doesn’t have a specific practice for doing that reflection? That’s actually pretty common on very effective agile teams. Everyone is in the mindset of reflecting often, so when someone feels like it’s time to review how the project has progressed and make necessary corrections, that person usually grabs a few other team members and has an informal retrospective. If something good comes out of it, they talk it over, and make the necessary correction. For a team accustomed to a framework with well-specified rules, such as Scrum, that feels disorganized, chaotic, or “loosey-goosey.” That’s one reason teams like to standardize on a set of practices—so that everyone has common ground rules.
Q: Why did you capitalize “Product Owner” on the bottom of ????
A: Because while many people have the job title “product owner,” spelling Product Owner with capital letters refers to a specific role with responsibilities specified by the Scrum rules. You’ll learn more about that in the next chapter.
When the team adopts practices without the right principle-driven mindset, it often feels “empty” or superfluous, like they’re just going through the motions, and they’ll start looking for alternatives that take less effort.
Ben: And just as I was feeling good about how things were going. I wish you didn’t have to be so negative. What’s the bad news now?
Kate: I’m not trying to be negative. I’m really happy about the progress we’ve made just by starting to use iteration.
Ben: Right! I went back to the users with early builds, and they found all sorts of changes that we could fix early without a lot of rework.
Kate: Yeah, and that’s great. But we still have problems.
Ben: Such as...?
Kate: Well, like that meeting we had last Wednesday. We spent all afternoon arguing about documentation.
Ben: Why do you want to bring that up again? You and Mike keep asking for specifications with every tiny detail about what to build.
Kate: Yes, because then I can help the team plan out the project, and Mike and the team know exactly what to build.
Ben: But it’s not that simple! These specs are really hard to write. And even when we write a spec for one iteration, it still gets really long.
Kate: Look, if you’ve got a better idea about how to get the team to build the right software, I’d love to hear it.
The agile principles help your team communicate and work together
Modern software is built by teams, and while individual people are really important to any team, teams work best when everyone works together—which means developers not just working with each other, but with the users, customers, and stakeholders, too. That’s what these next principles are all about.
It’s really common for developers to dread or resent meeting with users, because those meetings often uncover changes, which leads to rework that can often be difficult and frustrating. But when the team has a better, more agile mindset, they know that meeting with users more often keeps them in sync, and actually prevents those changes.
Teams do their best work when the people on them are motivated. Unfortunately, most of us have had bosses or coworkers who seemed determined to drain all of that great motivation. When people feel like they aren’t allowed to make mistakes without serious consequences, are pressured to work extremely long hours, and generally feel like they aren’t trusted to do their jobs, the quantity and quality of their work plummets. Teams with a more agile mindset know that when everyone is trusted and given a good working environment, they flourish.
Waterfall teams typically build a requirements specification first, and then design the software based on those requirements. The problem is that three people can read the same spec and come away with three very different ideas about what the team is supposed to build. This can be a little surprising—shouldn’t specifications be precise enough to give everyone the same idea?
There are two problems with that in the real world: writing technical material is hard, and reading it is even harder. Even if the person writing the spec does a perfect job describing what needs to be built (which rarely happens), the people reading it will very often interpret it differently. So how do you get around this problem?
The answer is surprisingly simple: face-to-face conversation. When the team gets together and talks about what they need to build, it really is the most efficient and effective way to communicate exactly what needs to be built... and also status, ideas, and any other information.
there are no Dumb Questions
Q: Are you saying that when people are demotivated, they do bad work on purpose?
A: No, not on purpose. But it’s very difficult to innovate, create, or do the mentally taxing tasks required to work on a software team when you’re in a demotivating environment. And it’s surprisingly easy to demotivate a team: your motivation gets drained when you’re not trusted to do your job, harshly punished or publicly embarrassed if you make a mistake (everyone makes mistakes!), or held to unreasonable deadlines that you have no input into or control over. Those are all things that have been shown repeatedly to drag down software teams and make them a lot less productive.
Q: Wait, go back to what you were saying about mistakes. We’ve been talking about welcoming changes. But if you’re making a change, doesn’t that mean someone made a mistake earlier that has to be changed now?
A: It’s dangerous to think of changes as mistakes, especially when you’re using iteration. A lot of times, everyone on the team and the users and stakeholders all agree that the software should be built to do something, but when the users get their hands on the working software at the end of the iteration, they realize that it needs to change—not because they made a mistake earlier, but because they now have information they didn’t have at the start of the iteration. That’s actually a really effective way to build software. But it only works if people feel comfortable making changes, and if they don’t call it a mistake or “blame” anyone for finding the change.
Q: Don’t we need specifications for more than just communication? What if you need to refer back to the spec in the future? Or if it needs to be distributed to a lot of people?
A: Sure, and those are good reasons to write things down. And that’s why agile teams value comprehensive documentation—they just value working software more.
One thing to keep in mind, though, is that if you’re writing documentation to refer back to, or to distribute to a wide audience beyond the software team, then a software specification may not be the right kind of document for the job. Documentation is a tool to get a job done, and you always want to use the right tool for the job. The information that teams need in order to build software is usually different than the information a user or manager might need after the software is built, so trying to create a document that serves both purposes might do neither particularly well.
Q: Hey, it looks like the chapter is almost over, and you haven’t covered all twelve principles! Why not?
A: Because the agile principles aren’t just an isolated topic that teams learn once and then move on from. They’re important because they help you understand how agile teams think about the way they work together to build software. That’s why the values and principles of the Agile Manifesto are important.
We’re not going to stop talking about the agile mindset, values, or principles, even though we’re moving on to methodologies in the next chapter. We’ll keep coming back to them, because they help you understand the methodologies (for example, Scrum teams are self-organizing, and XP teams value simplicity).
The new product is a hit!
Kate and Mike delivered a great product, and it’s been extremely successful.
In fact, it’s gone so well that Ben has some fantastic news that everyone will want to hear. Nice work, team!
Exam Questions
Note
These practice exam questions will help you review the material in this chapter. You should still try answering them even if you’re not using this book to prepare for the PMI-ACP certification. It’s a great way to figure out what you do and don’t know, which helps get the material into your brain more quickly.
You’re a project manager on a team building network firmware for embedded systems. You’ve called a meeting to give a demo of the latest version of code the team has been working on for a control panel interface to a very technical group of business users and customers. This is the fifth time that you’ve called a meeting to do a demo like this. And for the fifth time, the users and customers asked for specific changes. The team will now go back and work on a sixth version, and you’ll repeat the process again.
Which of the following BEST describes this situation?
The team does not understand the requirements
The users and customers don’t know what they want
The project needs better change control and requirements management practices
The team is delivering value early and continuously
Which of the following is NOT a Scrum role?
Scrum Master
Team Member
Project Manager
Product Owner
Joaquin is a developer, and his software team is in the process of adopting agile. One of the project’s users wrote a brief specification that describes exactly what she wants for a new feature, and Joaquin’s manager assigned him to work on that feature. What should Joaquin do next?
Demand a meeting with the user, because agile teams recognize that face-to-face conversation is the most efficient and effective method of conveying information
Read the specification
Ignore the specification, because agile teams value customer collaboration over comprehensive documentation
Start writing code immediately, because the team’s highest priority is to satisfy the customer through early delivery of valuable software
Which of the following is TRUE about working software?
It does what the users need it to do
It meets the requirements in its specification
Both A and B
Neither A nor B
Which of the following statements BEST describes the Agile Manifesto?
It outlines the most effective way to build software
It contains practices that many agile teams use
It contains values that establish an agile mindset
It defines rules for building software
Scrum projects are divided into:
Phases
Sprints
Milestones
Rolling wave planning
You are a developer at a social media company working on a project to build a new feature to create a private site for a corporate client. You need to work with your company’s network engineers to determine a hosting strategy, and come up with a set of services and tools that the engineers will use to manage the site. The network engineers want to host all of the services internally on your network, but you and your teammates disagree and feel that the services should be hosted on the client’s network. Work on the project has come to a halt while everyone tries to come to an agreement. Which agile value BEST applies to this situation?
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
Donald is a project manager on a team that follows separate phases for each project, starting with a requirements phase followed by a design phase. Some work can begin on the code before the requirements and design are finished, but the team typically doesn’t consider any work to be complete until those phases are finished. Which term BEST describes Donald’s projects?
Iterative
Rolling wave planning
Waterfall
Scrum
Keith is the manager of a software team. He’s made it clear that mistakes are not to be tolerated. A developer spent several hours building “proof of concept” code to test a possible approach to a complex problem. When he eventually discovered from the experiment that the approach wouldn’t work, Keith yelled at him in front of the whole team and threatened to fire him if he did it again.
Which agile principle BEST applies to this situation?
The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
Continuous attention to technical excellence and good design enhances agility.
What’s the highest priority of an agile team?
Maximizing the work not done
Satisfying the customer by delivering valuable software early and often
Welcoming changing requirements, even late in development
Using iteration to effectively plan the project
Which of the following statements is NOT true about the daily standup?
The length is kept short by having everyone stand for the duration of the meeting
It’s the same thing as a status meeting
It is most effective when everyone listens to each other.
It’s an opportunity for every team member to get involved in planning the project.
Which of the following BEST describes the agile mindset with respect to simplicity?
Maximizing the work not done
Satisfying the customer by delivering valuable software early and often
Welcoming changing requirements, even late in development
Using iteration to effectively plan the project
A’ja is a project manager on a team that is just starting their agile adoption. The first change they made to the way they work was to start holding daily standup meetings. Several team members have approached her to say that they don’t like attending. And despite the fact that she’s getting some valuable information from the team at each standup, A’ja is concerned that the extra lines of communication might not be worth damaging the team cohesion.
What is the BEST thing for A’ja to do?
Stop holding the daily standup and find another way to adopt agile.
Make and enforce a rule that every attendee must put away his or her phone and pay attention.
Follow up with people individually after the meeting to get more detailed status.
Work with the team on changing their mindset.
You’re a developer on a software team. A user has approached your team about building a new feature, and has provided requirements for it in the form of a specification. She is very certain of exactly how the feature will work, and promises there will be no changes. Which agile value BEST applies to this situation?
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
Which of the following is NOT a benefit of welcoming changing requirements?
It gives the team a way to explain a missed deadline
The team builds more valuable software when customers aren’t pressured not to change their minds
There’s more time and less pressure so the team can make better decisions
Less code is written before changes happen, which minimizes unnecessary rework
Which of the following is NOT part of an agile team’s mindset toward working software?
It contains the final version of all features
It is the primary measure of progress
It is delivered frequently
It is an effective way to get feedback
Which of the following is NOT true about iteration?
The team must finish all planned work by the end of an iteration
Iterations have a fixed deadline
The scope of work performed during an iteration may change by the time it ends
Projects typically have multiple sequential iterations
Exam Answers
Note
Here are the answers to this chapter’s practice exam questions. How many did you get right? If you got one wrong, that’s OK—it’s worth taking the time to flip back and re-read the relevant part of the chapter so that you understand what’s going on.
Answer: D
Did this situation sound negative, like something was going drastically wrong? If it did, you may want to think about your own mindset! This was actually a pretty accurate description of a very successful agile project that uses an iterative methodology. It only sounds like the project is running into problems if you approach it with a mindset that considers change and iteration to be a mistake rather than a healthy activity. If you see the project this way, then you’ll be tempted to “blame” the team for not understanding the requirements, or the users for not knowing what they want, or the process for not having adequate controls to prevent and manage changes. Agile teams don’t think about things like that. They know that the best way to figure out what the users need is to deliver working software early and frequently.
Answer: C
Project managers are very important, but there’s no specific role in Scrum called “project manager.” Scrum has three roles: Scrum Master, Product Owner, and Team Member. The project manager will fill one of those roles on a project that uses Scrum, but will often still have the “Project Manager” job title.
Note
When your team follows an agile methodology that has specific roles, the role that you fill doesn’t always match the title on your business card, especially when your team is just starting to adopt the methodology.
Answer: B
It’s true that agile teams value customer collaboration, believe face-to-face conversation is the most effective method of conveying information, and place the highest priority on delivering software. However, the user took the time to write the specification, and the information in it could be very helpful in either writing code or having a face-to-face conversation.
Note
When someone takes the time to write down information they think is important, it’s very UN-collaborative to ignore it.
Answer: D
When agile teams talk about working software, they mean software that they consider “done” and ready to demonstrate to the users. But there’s no guarantee that it fulfills the users’ needs or that it meets the specific requirements in a specification. In fact, the most effective way to build software that genuinely helps users is to deliver working software frequently. The reason is because the early versions of working software typically don’t fully meet the users’ needs, and the only way for everyone to figure that out is to get it into the hands of the users so they can give feedback about it.
Note
This is why agile teams value early and continuous delivery of working software.
Answer: C
The Agile Manifesto contains the core values shared by effective agile teams. It doesn’t define a “best” way to build software or a set of rules that all teams should follow, because people on agile teams know that there’s no “one-size-fits-all” approach that works for all teams.
Answer: B
Scrum teams work in sprints, typically (but not always) 30 days long. They plan the next 30 days of work (assuming the length is 30 days) at the start of the sprint. At the end of the sprint, they demonstrate working software to the users, and also hold a retrospective to review what went well and find ways to improve.
Answer: C
The project is suffering because the team is having trouble collaborating with their customer. In this case, the network engineers are the customer, because they’re the ones who will be using the software. This is a situation where it would be easy to take a contract negotiation approach, laying out specific terms and documents to describe what will be built so that software development work can begin. But it’s more effective to genuinely collaborate with them and work together to discover the best technical solution.
Answer: C
A waterfall project is divided into phases, typically starting with requirements and design phases. Many waterfall teams will begin “pre-work” on code once the requirements and design have reached a stable point, even if they’re not yet complete. However, this is definitely not the same thing as iteration, because the team doesn’t change the plan based on what they learned building and demonstrating working software.
Answer: B
Agile projects are built around motivated team members. Keith is taking actions that undermine the whole team’s motivation by undercutting a team member who’s taking a good risk and genuinely trying to make the project better.
Answer: B
Flip back and reread the first principle of agile: “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.” The reason this is the highest priority is because agile teams are focused first and foremost on delivering software that’s valuable. All of the other things we do on projects—planning, design, testing, meetings, discussion, documentation—are really, really important, but it’s all in service of delivering that valuable software to our customers.
Answer: B
While some teams treat the Daily Standup as a status meeting where each team member gives an update to a boss or project manager, that’s not really its purpose. It works best when everyone listens to each other, and uses it to plan the project together as a team.
Answer: A
Agile teams value simplicity, because simple designs and code are much easier to work with, maintain, and change than complex ones. Simplicity is often called “the art of maximizing the work not done” because—and this is especially true of software—the most effective way to keep something simple is often to simply do less.
Answer: D
The reason that the team isn’t paying attention during the daily standup is because they don’t really care about it or buy into it as an effective tool, and mainly want it to end as quickly as possible so they can get back to their “real” jobs. When teams have this mindset, it’s likely that they will eventually stop attending the meeting altogether, and the agile adoption is much less likely to be successful. The daily standup practice will be more effective if the team understands how it helps each of them, both individually and as a team. That mindset shift can only be accomplished through open and honest discussion about what’s working and what isn’t. That’s why working with the team on changing their mindset is the best approach to this situation.
Answer: B
It certainly makes sense to read and understand the specification. But the most effective way to truly ascertain whether or not the team really understands what she intended is to deliver working software to her, so that she can see how the requirements she documented were interpreted and work with the team to determine what works well and what needs to change.
Answer: A
There are a lot of great reasons that agile teams welcome changing requirements. When customers are encouraged to change their minds (rather than discouraged from it), they give better information to the team, and that leads to better software. And even when people keep their mouths shut about changes, they almost always eventually get exposed in the end, so when the team gets them early it gives them more time to respond—and the earlier the changes arise, the less code has to be reworked.
However, changes are never an excuse for poor planning or missed deadlines. Effective agile teams generally have an agreement with their users: the teams welcome changing requirements from users, customers, and managers, and in return they aren’t blamed for the time it takes to respond to those changes, because everyone recognizes it’s still the fastest and most effective way to build software. So nobody really sees welcoming changing requirements as giving the team a way to explain a missed deadline, because the deadlines should already be adjusted to account for the changes.
Answer: A
Working software is delivered frequently so that the team can get frequent feedback and make changes early. That’s why working software should never be assumed to contain the final version of any requirement. That’s why it’s “working” software, not “finished” software.
Answer: A
Iterations are timeboxed, which means that the deadline is fixed and the scope varies to fit it. The team starts each iteration with a planning meeting to decide what work will be accomplished. But if it turns out that they didn’t get the plan right and work takes longer than expected, then any work that didn’t get done is returned to the backlog and reprioritized (and often ends up in the next iteration).
Manifesto Magnets Solution
