A burndown chart is a line chart, updated daily, that tracks the amount of work left on the project, “burning” down to zero when the work is done.
Methodologies
Scrum
“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.”
The Agile Manifesto
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.
Individuals and interactions over processes and tools
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.
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
Customer collaboration over contract negotiation
“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.
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.
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.
Responding to change over following a plan
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.
That is, while there is value in the items on the right, we value the items on the left more.
Each of the four values in the Agile Manifesto contains two parts: something (on the righthand side) that agile teams value, and then something else (on the lefthand side) that agile teams value more. So when agile teams say they value responding to change over following a plan, that doesn’t mean that they don’t value planning—in fact, it means the opposite! They absolutely value following a plan. They just value responding to change more.
Principles Behind the Agile Manifesto
We follow these principles:
- Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
- Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
- Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
- Business people and developers must work together daily throughout the project.
- Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
- The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
- Working software is the primary measure of progress.
- Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
- Continuous attention to technical excellence and good design enhances agility.
- Simplicity—the art of maximizing the amount of work not done—is essential.
- The best architectures, requirements, and designs emerge from self-organizing teams.
- At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
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.
- Software is valuable when it does what the users, customers, or stakeholders need it to do.
- To ensure that software is valuable, teams should deliver an early version to the users, and keep delivering continuously.
- Agile teams welcome changing requirements, and finding those changes early helps prevent rework.
- The best way to find those changes early is to get working software to the users frequently.
- Documents are helpful, but the most effective way to convey information is face-to-face conversation.
- Developers on agile teams work with business people every day, including users and stakeholders.
- Iteration is a practice in which teams break the software down into frequent timeboxed deliveries.
- A backlog is a practice in which teams maintain a list of features that will be built in future iterations
Scrum
Events
The Sprint The Sprint Planning session The Daily Scrum The Sprint Review The Sprint Retrospective
Roles
Product Owner The Product Owner helps the team understand the users’ needs so they can build the most valuable product. The Product Owner works with the team every day to help them understand the features in the Product Backlog: what items are on it and why the users need them. This is a really important job because it helps the team build the most valuable software they can.
Scrum Master The Scrum Master helps the team understand and execute Scrum. Scrum may be simple to describe, but it’s not always easy to get right. That’s why there’s one person on the team, the Scrum Master, whose whole job is to help the Development Team, the Product Owner, and the rest of the company to do exactly that—get Scrum right. The Scrum Master is a leader (which is why the word “master” is right there in the name). But he or she demonstrates a very particular kind of leadership: the Scrum Master is a servant leader. This means that the person in this role spends all of his or her time helping (or “serving”) the Product Owner, the Development Team, and people throughout the organization:
- Helping the product owner find effective ways to manage the backlog
- Helping the Development Team understand the Scrum events, and facilitating them if needed
- Helping the rest of the organization to understand Scrum and work with the team
- Helping everyone do the best job they can to deliver the most valuable software possible