More on this book
Community
Kindle Notes & Highlights
We agreed that clearly named variables and short methods were important. We agreed to use assertions to make our code fail fast, not to optimize without measurements, and never to pass null references between objects. We agreed on how we should and shouldn’t handle exceptions, what to do about debugging code, and when and where to log events. These standards helped us far more than a consistent formatting style would have. Each had a concrete benefit. Perhaps that’s why we were able to agree on them when we couldn’t agree on formatting.
People make mistakes. Assume your colleagues are professional and well-meaning. If someone isn’t following an agreement, assume there’s a good reason, despite evidence to the contrary. Your challenge is to find that reason and address it. This approach shows respect for others and will improve their respect for you.
For example, if I’m coaching a team that has agreed to try pair programming, but they’re not doing it, I won’t say, “You need to be pairing.” Instead, I’ll say, “I notice that people aren’t following the pair programming working agreement. Why do you think that is?” Then I can follow up by asking if the agreement is still appropriate and whether it should be changed.
Energized work is about recognizing that although professionals can do good work under difficult circumstances, they do their best, most productive work when they’re energized and motivated.
Pair programming is another way to encourage energized work. It encourages focus like no other practice I know. After a full day of pairing, you’ll be tired and satisfied. It’s particularly useful when you’re not at your best: pairing with someone who’s alert can help you stay focused. Mob programming isn’t as good at ensuring focus—it’s easy to tune out—but it is good for preventing the errors that occur when you’re tired.
Finally, “norming” teams (see “Norming: We’re #1”) have a lot of energy. They’re a lot of fun, too. You can recognize such a team by how much its members enjoy spending time together. They go to lunch together, share in-jokes, and may even socialize outside of work. You develop a “norming” team by paying attention to team dynamics.
“Stories” helps your team plan its work in small, customer-centric pieces. “Adaptive Planning” balances adaptability with predictability to focus your team’s plans on value. “Visual Planning” creates plans that communicate context and options. “The Planning Game” creates a detailed plan for guiding your team’s next steps. “Real Customer Involvement” allows your team to include customers’ perspectives in their plans. “Incremental Requirements” determines requirements details just before they’re needed.
Because stories are just a reminder to have a conversation, they don’t need to be detailed. In fact, detailed stories are a sign that people are missing the point. You’re supposed to have a whole team, a team room, and talk together regularly. The story is the reminder. A way of sparking conversations about the details.
Stories represent customer value and are described in customers’ terminology. They describe work that customers recognize and value, not implementation details. This allows your on-site customers to make informed prioritization trade-offs. Stories have clear completion criteria. It doesn’t have to be written on the card, but on-site customers need to understand what it means for a story to be “done” and be able to describe it when asked.
Stories need to be customer-centric. Write them from customers’ point of view, and make sure they provide something that benefits customers, users, or business stakeholders. On-site customers are in charge of priorities, so if they don’t think a story has value, they won’t include it in the plan.
Developers often struggle with making stories customer-centric. Keep practicing! Without customer-centric stories, on-site customers have trouble making good prioritization decisions, and ruthless prioritization is the secret to releasing sooner.
Splitting stories is more difficult, because they need to remain customer-centric. The trick is to find the essence of the story, not the individual steps it involves.
Often, that value comes in the form of reduced risk. For example, a story to add distributed tracing could be described as, “Make it easier to find source of performance problems during performance emergencies (distributed tracing).”
Sometimes, developers won’t be able to size a story because they don’t know enough about the technology required to implement the story. When this happens, create a spike story to research that technology. The purpose of a spike story is to size the other story, not to design the solution or research every nook and cranny. For example, “figure out if ‘send HTML email’ story should be split.” Or, more concisely, “spike ‘send HTML email.’” They’re called spike stories because you’ll often use a spike solution to do the research. But you don’t have to.
When you use stories well: On-site customers understand all the work they approve and schedule. It’s easy to explain to stakeholders what the team is working on and why it matters. Your team works on small, manageable pieces and makes customer-valued progress multiple times per week. Stories are cheap to create and easy to discard.
Stories are a simple idea, but they’re also connected to a perennial software development problem: deciding what to build. Simple idea plus important problem means everybody has their own spin on stories. You can find any amount of templates and story writing advice online. All will claim to solve this problem or that so the team can build better software.
These experiments tend to miss the point. Stories are about the conversation, not the card. Any change that puts more focus on writing than talking—a template, more detail, a taxonomy of stories—is going in the wrong direction.
Jeff Patton says stories are like a vacation photo: they remind you what happened.
Similarly, a valuable increment is “released” only when you can achieve its value. Teams using continuous deployment will deploy their software multiple times per day, but it isn’t released until a configuration switch is flipped and the increment is available to its intended audience.
The more frequently you release, the more you get, as Scenario C shows. It’s the same as Scenario B, except that the team has figured out how to slice each of their increments in half. Instead of releasing a $4 increment in two months, they release a $2 increment in one month. After seven months, they’ve earned $42.
The smaller your increments, the more frequently you can adapt your plans, and the more agile you can be. In a perfect world, your increments should be broken down to the smallest fundamental pieces that can still have releasable value.
Second, WIP makes changes more costly. When you change your plans, any work that isn’t done has to be set aside. As time goes on, the decisions that went into that work become outdated and have to be redone. Code for incomplete increments is particularly expensive: either it increases the size and cost of maintaining your production codebase, or it’s stored in a separate branch where it becomes increasingly difficult to merge back into production. Metaphorically, WIP rusts away. It either has to be maintained, reworked, or thrown away, and that’s wasteful. Keep it to a minimum.
On the other hand, a decision to delay an increment, either by bundling it into a one-off release or using a release train, is a decision to delay value. Organizations also tend to use release trains to paper over technical and organizational deficiencies that prevent more frequent releases. When you think about your release strategy, trade off the benefits of bundling increments into releases with the cost of delaying their value, and be honest with yourself about your reasons for delaying.
An MVP isn’t necessarily a release, or even a product, in the traditional sense. It’s an experiment, and you can have more than one. As such, true MVPs are most often used by Optimizing teams.
To reduce waste and make planning easier, use rolling-wave planning to plan at the last responsible moment. In rolling-wave planning, detail is added gradually, just before it’s needed.
The distance each level of detail looks into the future is called its planning horizon. An Agile plan has multiple planning horizons,
Balancing Adaptability and Predictability Each level of detail in your plan has an associated planning horizon. For example, Figure 8-2 shows that tasks are planned for the next week; stories are planned for the next month; small increments are planned for the next three months; and possible increments are planned for the next six months.
Rolling-wave planning requires a clear purpose and regular updates to the plan. Use it when you can reliably revisit the plan at least once per week. Be sure your team includes people who have the skills to update and revise the plan.
Even if developers don’t attend, they still need to understand the plan and provide feedback. Be sure to set aside time to discuss the plan with developers. The planning game might be a good time to do so.
Estimating is just one technique for making predictions, and not even the most important one. The real secret to predicting well is to understand uncertainty and risk. That’s why I call it forecasting instead.
The secret to being ready on a predefined release date is to slice your work into the smallest valuable increments you can. Focus on getting to a releasable state as quickly as possible. To do so, set aside every story that isn’t strictly necessary to release.
In a perfect world, you want every story to be something that can be released on its own, without having to wait for any additional stories.
number of weeks remaining = number of stories (or estimate total) remaining ÷ weekly throughput × risk adjustment
number of stories (or estimate total) done = number of weeks remaining × weekly throughput ÷ risk adjustment
More importantly, make sure you really need a forecast. Too many companies ask for forecasts out of habit. Forecasting takes time away from development. Not just the time required to make the forecast itself, but the time required to manage the many emotional responses that surround forecasts, both from team members and stakeholders. It also adds resistance to adapting your plans.
An alternative is to use Monte Carlo simulations to amplify small amounts of data. Troy Magennis’s “Throughput Forecaster” spreadsheet at https://www.focusedobjective.com/w/support is a popular example.
Before you experiment with alternative date and scope forecasts, remember that the best way to forecast is to pick a predefined release date and steer your plans to meet that date exactly.
When you discuss how to break down tasks, talk about your design. Write tasks in terms of how your design will change: “Add endpoint to UserReportController.” “Update ContactRecord.” “Add columns to GdprConsent database table.”
In an ideal world, your team will swarm each story: everyone will choose tasks for the same story and focus on getting the story “done done” before moving on to the next. This minimizes work in progress (see “MINIMIZE WORK IN PROGRESS”) and exposes risks early.
On the other hand, collective ownership also means you don’t have to be perfect. If your code works and you’re not sure how to make it better, don’t hesitate to let it go. Someone else will improve it later, if and when the code needs it.
Conversely, when you’re working in “someone else’s” code (but it’s not someone else’s—it’s yours!), avoid the temptation to make personal judgments about them based on their code. But do always leave the code a little better than you found it. If you see an opportunity for improvement, don’t be shy. You don’t need to ask permission. Do it!
At first, collective code ownership is an opportunity for conflict. All the little annoyances about your colleagues’ work styles are double-underlined with a bright purple highlighter. This is a good thing—really!—because it gives you a chance to align your style. But it can be frustrating at first.
To help the process go more smoothly, decide on important coding, design, and architectural standards as part of your alignment chartering session. When you first adopt collective code ownership, try mob programming for a week or two so you can hash out important differences. Bring up areas of disagreement in your retrospectives and come up with plans for resolving them. Pay attention to team dynamics.
Agile requires that your organization recognize and value team contributions more than individual heroics. If that’s not true for your organization, collective code ownership might not be a good fit.
Simple design and its focus on code clarity make it easier to understand unfamiliar code.
Different programmers on our team are responsible for different products. Should the team collectively own all these products? If you’ve combined programmers onto a single team, then yes, the whole team should take responsibility for all of their code. If you have multiple teams, then they may or may not share ownership across teams, depending on how you approach scaling.
Safety is critical. If team members don’t feel safe expressing and receiving criticism, or if they fear being attacked when they raise ideas or concerns, they won’t be able to share ownership of code. Instead, little fiefdoms will pop up. “Don’t change that code yet. You should talk to Antony first to make sure he’s okay with it.”
When you pair, one person is the driver. Their job is to code. The other person is the navigator. Their job is to think. As navigator, sometimes you think about what the driver is typing. (Don’t rush to point out missing semicolons, though. That’s annoying.) Sometimes you think about what comes next. Sometimes you think about how your work best fits into the overall design.
Take a moment to check in with your partner about each other’s preferences, too. When driving, do you want your navigator to give you time to think things through on your own? Or would you rather that they keep on top of things so you never have to stop and think? When navigating, do you want your driver to verbalize what they’re thinking, so you understand where they’re going? Or do you want to be able to concentrate on what’s next? Do you want strict separation of driver and navigator roles? Or a casual, informal approach?
