More on this book
Kindle Notes & Highlights
over-attention to detail sometimes occurs when an estimator is reluctant to make estimates. It’s common among programmers who’ve had their estimates used against them in the past. They’ll try to make their estimates perfectly accurate, rather than aiming for consistency that’s “good enough.”
The most common capacity problem I see is poor internal quality: crufty code, slow and unreliable tests, poor automation, and flaky infrastructure. It’s also called technical debt.
Internal quality has a greater impact on team capacity than any other factor. Make it a priority and your capacity will improve dramatically. However, this isn’t a quick fix. Teams with internal quality problems often have months, or even years, of cleanup ahead of them.
Establish a habit of continuously improving everything you touch.
If your team doesn’t include on-site customers, or if they aren’t available to answer questions when developers need them, developers have to either wait or make guesses about the answers. Both of these reduce capacity.
capacity isn’t a measure of productivity. It’s a prediction tool. It’s influenced by productivity changes, sure, but it doesn’t measure them, and even then, the relationship is tenuous. In particular, capacity can’t be compared across teams.
If you’re a manager, don’t track, reward, or even talk about capacity, other than to encourage a stable capacity. And never, ever call it productivity.
Partially done stories don’t count. At the end of the iteration, if you have any partially done stories, create a new story for the work remaining and give it a new estimate, if you’re using estimates. (See “Incomplete Stories” for details.) The part done in this iteration doesn’t count toward your capacity, which means your capacity will go down.
and thinking in terms of ideal time and the most-qualified team member is the easiest way to be consistent.
the best use of slack is to increase your ability to deliver.
Don’t batch up your improvements. Make improvements every day, throughout the iteration:
Always leave your code and other systems a little bit better than you found them, no matter how much time you have. You’re not choosing between “sloppy” and “clean;” you’re choosing between “slightly cleaner” and “a lot cleaner.”
The risk of slack is that it can lead people to think that activities such as improving internal quality and developing customer skills aren’t important. They’re actually vital, and a team that doesn’t do them will slow down over time. They’re just not time-critical like your iteration commitment is.
Stand-ups interrupt the team’s work. This is a particular problem for morning stand-ups; because team members know the meeting will be an interruption, they sometimes just waste time waiting for the stand-up to start. You can reduce this problem by moving the stand-up to later in the day, such as just before lunch.
The stand-up starts with team members going through the stories on the task board one-by-one, starting with the story that’s closest to completion. For each story, the people who worked on that story describe what’s changed and what’s left to be done, as well as any new information the team needs to know.
After walking the board, take a moment to focus the team on what’s needed to complete their work, including blockers that aren’t getting resolved. Teams using iterations should take this opportunity to check on their iteration commitment.
Most days, the stand-up meeting should take only about 5 minutes, or 10 at most. If it consistently takes more than 10 minutes, something is wrong.
Partially finished stories increase your work in progress, and this increases your costs, as “MINIMIZE WORK IN PROGRESS” describes. Rather than pushing a button to release, you have to complete an unpredictable amount of work. This destabilizes your release plans and prevents you from making and meeting commitments.
Your team should finish 4–10 stories every week. Getting that many stories “done done” may seem like an impossibly large amount of work. Part of the trick is to work incrementally, as just described, rather than in phases. The real secret, though, is to create small stories.
I know somebody who worked in a company with two development teams. One was Agile, met its commitments, and delivered regularly. The team next door struggled: it fell behind schedule and didn’t have any working software to show. Yet when the company downsized, they let the Agile team go rather than the other team! Why? When management looked in on the struggling team, they saw formal diagrams papering the walls and programmers working long hours. When they looked in on the Agile team, they saw people talking, laughing, and going home at five with nothing but rough sketches and charts on the
...more
Don’t wait to bring up problems just because you don’t have a solution yet. Instead, explain the problem, what you’re doing to come up with mitigations, and when they can expect to hear more.
Beware of the temptation to work overtime or cut slack to make up for lost time. Although this can work for a week or two, it can’t solve systemic problems, and it will create problems of its own if allowed to continue.
One possibility is to create a “value book” that business stakeholders can share with their bosses. This is a document, updated regularly, where you write down the value you’ve brought to stakeholders. This helps remind stakeholders what you’ve done for them, and it helps them justify your work to the rest of the organization.
Borderline behavior includes glossing over known defects in a stakeholder demo, taking credit for stories that aren’t 100% complete, and extending an iteration deadline for a few days to finish everything in the iteration plan. Covering up the truth like this gives stakeholders the impression that you’ve done more than you actually have. They’ll expect you to complete your remaining stories just as quickly, when in fact you haven’t even finished the first set. You’ll build up a backlog of work that looks done, but isn’t. At some point, you’ll have to finish that backlog, and the resulting
...more
There’s an old programming joke: the first 90% of the work takes 90% of the time…and the last 10% of the work takes 90% of the time. Until the story is totally done, it’s impossible to say for certain what percentage has been done.
Don’t make commitments to stakeholders before you’ve proven your ability to make and meet commitments privately, within the team.
the real feedback provided by stakeholder comments is not the feedback itself, but how surprising that feedback is. If you’re surprised, you’ve learned that you need to work harder to understand your stakeholders.
It’s harder to fool yourself into thinking work is done when you can’t demo it to stakeholders.
Product managers often ask developers to lead the demo instead. I see this most often when the product manager doesn’t see themselves as part of the team, or doesn’t feel that they know the software well. Push back on this request. Developers aren’t building the software for the product manager; the whole team, including the product manager, is building the software for stakeholders. The product manager is the face of that effort, so they should lead the demo. Help the product manager be more involved and comfortable by reviewing stories with them as they’re built.
The prepared portion of the demo should be less than 10 minutes. You don’t need to show every detail.
Because the meeting is so short, it’s good to start on time, even if some attendees are late. This will send the message that you value attendees’ time.
Begin the presentation by briefly reminding attendees about the valuable increment the team is currently working on and why it’s the most important use of the team’s time. Set the stage and provide context for people who haven’t been paying full attention. Then provide an overview of the stories the team worked on since the last demo.
The real secret to predicting well is to understand uncertainty and risk.
If you tell people exactly what you’re going to do, you’ll have to change your forecast every time you change your plan. At best, this means the time and effort that went into the previous forecast was wasted. More often, people treat your forecasts as commitments and get upset when you change them.
your increments need to be small enough that you can easily finish at least one before your release date.
As you finish work, keep an eye on how much time is left and use it to decide what to do next. If there’s a lot of time, you can build a big new increment that takes the software in a new direction. If there isn’t much time left, focus on smaller increments that add polish and delight.
Ask the sponsor to describe the development goals, when work would start, who would be on the team, and the latest release date that would still be worth the cost. Then ask the product manager and programmers if they think it’s possible. Note that you aren’t asking how long it will take. That’s a harder question to answer.
number of weeks remaining = number of stories (or estimate total) remaining ÷ weekly throughput × risk adjustment
Risk adjustment: See Table 10-1.4 Use the “high-risk team” column unless your team has both Focusing and Delivering fluency.
Likelihood Low-risk team High-risk team 10% (almost impossible) 1 1 50% (coin toss) 1.4 2 90% (very likely) 1.8 4
if the release includes any spike stories, you’ll have to finish all of them before you can make a forecast. This is why spike stories are separate stories in your plan; sometimes it’s valuable to schedule them early so you can resolve risks and make forecasts.
Update your forecast at the end of every iteration,
Your rule-of-thumb risk adjustments are too large. Can we use a lower ratio? When your forecast gives you bad news, it’s tempting to play with the numbers until you feel happier. Speaking as somebody who’s been there and has the spreadsheets to prove it: this is a waste of time. It won’t change when your software actually releases.
the best way to forecast is to pick a predefined release date and steer your plans to meet that date exactly.
Most organizations use measurement-based management: gathering metrics, asking for reports, and designing rewards to incentivize the right behavior. It’s a time-honored approach to management that stretches back to the invention of the assembly line. There’s just one problem. It doesn’t work.
Value velocity is a measurement of productivity. It measures the output of the team over time. To calculate it, measure two numbers for each valuable increment the team releases: the impact, such as revenue; and the lead time, which is the number of weeks (or days) between when development started and when the increment was released. Then divide: impact ÷ time = value velocity.
To get the conversation started, ask “why” questions. Why is the chosen cluster most important to improve? Why isn’t the current situation good enough? Why are things done the way they are?
If nothing changes, the retrospective didn’t work. To help the team follow through, make the retrospective objective visible. If you decided to do something, add those tasks to your plan. If you’re changing your process, update your planning boards to visualize the change. If you want people to change their behavior, track it with a big visible chart. If you’re changing a working agreement, update your working agreements poster.
you don’t have enough slack in your schedule. When you have a completely full workload, nonessential tasks such as improving your work habits go undone. (The sad irony is that improving your work habits will give you more time.)
[A real team] is a small number of people with complementary skills who are committed to a common purpose, performance goals, and approach for which they hold themselves mutually accountable.
