More on this book
Kindle Notes & Highlights
Agile is everywhere. And paradoxically, nowhere.
In the 20 years after the Agile freight train roared into software developers’ consciousness, the number of companies calling themselves “Agile” increased by orders of magnitude. The number of teams actually taking an agile approach to their work? Not so much.
Agile teams define success as delivering value, not conforming to a plan. In fact, truly Agile teams actively look for opportunities to increase value by changing their plans.
When a company fails to achieve the results they want from Agile, it’s usually because they didn’t make the required investments. Often, they don’t even realize what was needed.
The Focusing zone is about Agile fundamentals: focusing on business results; working as a team; taking ownership. Teams that are fluent in this zone focus development on their team’s core purpose, release their most valuable features first, and change direction in response to changing business needs. They’re constantly Focusing on their organization’s most valuable priority.
Pre-Agile organizations make plans in advance, ask teams for estimates, and expect reports about how work is progressing relative to those estimates. Focusing teams revise their plans frequently—at least every month—and demonstrate progress by showing what they’ve completed.
Pre-Agile organizations break their plans into tasks, assign those tasks to individuals on the team, and judge individuals based on how well they complete their tasks. Focusing teams do their own task breakdowns, decide for themselves who will work on each task, and expect to be judged on their ability to create value as a team.
If you are able to get buy-in, Focusing fluency will take each team about 2–6 months of dedicated effort to achieve.
Delivering teams prevent this problem through technical excellence. They design their code to respond to frequent changes. They keep code quality high, so they don’t waste time hunting bugs. They refine their production lifecycle so releases are painless and operations are manageable. They’re capable of Delivering reliable, low-defect software whenever it makes the most business sense.
Optimizing teams achieve this level of agility. They understand what their market wants, what your business needs, and how to bridge the two. Or, as in a startup environment, they know what they need to learn and how to go about learning it. They’re constantly Optimizing their product plans to achieve the most value possible.
Creating optimal plans requires constant attention by people with deep business and product expertise, and that means having product and market experts join development teams full-time.
Focusing: Main benefit: Focus on business priorities; visibility into teams’ work; ability to change direction Investments: Team structure; management; work environment Approximate timing: 1-4 month performance dip; 2-6 months until fluency
Delivering: Main benefit: Low defects and high productivity; technical longevity Investments: Development skills; integrating testing and operations Approximate timing: 2-6 month performance dip; 3-24 months until fluency
Optimizing: Main benefit: Higher-value releases and better product decisions Investments: Embedded product management; team ownership of budgets and plans Approximate timing: 1-...
This highlight has been truncated due to consecutive passage length restrictions.
Managers often micromanage when they don’t know what else to do, or when they fear that there won’t be a place for them in an Agile environment.
If the team’s under a lot of time pressure, team members will have trouble learning. They’ll default to what’s worked for them in the past rather than taking time to learn new ideas.
A related issue is managers who value only tangible output. On an Agile team, there are many ways to contribute to success, such as the person who doesn’t write a lot of code, but spends a lot of time reproducing bugs, or the person who works in the background to improve communication.
The stakeholders who are most likely to resist are your teams’ business partners: product management, marketing, and sales. Agile represents a major shift in how teams interact with these groups. They’re used to a predictive approach, with a focus on commitments and deadlines. Their interactions with development teams are typically focused on documents, progress reports, and sign-offs.
Agile teams focus on feedback, frequent delivery of value, and adapting their plans. They constantly ask their stakeholders for feedback, then change their plans based on what they learn. Because their plans are always changing, they don’t make detailed release commitments. Some teams do provide release forecasts, but even then, those forecasts aren’t commitments, and they change frequently.
the pilot teams get all the support they need: eager participants, organizational patience, outside help, and an assignment that’s good for learning. Then, thinking its employees now all understand Agile, the organization provides little support for the second wave of Agile teams. Managers force Agile on people who don’t want it, provide no outside help, and impose more schedule pressure.
If the software isn’t valuable enough to warrant the time of someone with good product management skills—someone who could mean the difference between success and failure—maybe it isn’t worth developing in the first place.
Your software’s user interface is the face of your product. For many users, the UI is the product.
Nobody on the team is in charge of anyone else. That doesn’t mean every decision is up for discussion; people have final say over their areas of expertise. For example, programmers can’t override customers’ opinions about product priorities, and customers can’t override programmers’ opinions about technical necessity. Similarly, you’ll still have senior team members who take the lead on important decisions.
If you’re stuck on a problem and somebody on the team knows the answer, ask them to help. There’s no sense in banging your head against a wall. To support this, many teams have a working agreement: “We always help when a team member asks.”
If you spend a lot of time answering questions, you might not be as productive. But Agile is about the team. Even if you end up spending more time than you save, the team will be more productive overall.
the Law of Mobility: “At any time, if you are neither learning nor contributing, move yourself to a place where you are.”
when planning, don’t have one person sit at a computer and type everything into an electronic planning tool. Instead, visualize the plan with index cards or their virtual equivalent. That way, multiple people can write new cards at the same time, and multiple people can change the plan—and discuss their changes—by moving cards around and pointing at them.
In dot voting, each person gets a certain number of votes. (I multiply the number of choices by three, then divide by the number of people.)
In a consent vote, somebody makes a proposal, then everybody votes “I agree” (thumbs up in person, “+1” in group chat), “I’ll go along with the group” (thumb sideways or “+0”), or “I disagree and want to explain why” (thumbs down or “–1”).
If nobody votes “I agree,” the proposal fails for lack of interest. Otherwise, if nobody disagrees, it passes. If someone does disagree, though, they explain their objection, and the group adjusts the proposal to address it. The proposal doesn’t pass until all objections are addressed.
Consent votes work for two reasons. First, they leave room for people to withhold support without stopping a proposal from going forward. Second, if someone does feel strongly enough to veto a proposal, they have to explain why, which gives the group an opportunity to address their concerns.
In 2012, Google launched Project Aristotle, an internal research effort intended to identify why some teams excelled and others did not. Google looked at a number of factors: team composition, socialization outside of work, educational background, extroversion versus introversion, colocation versus remote, seniority, team size, individual performance, and more. None of them made a significant difference to effectiveness. Not even seniority or individual performance. What mattered? Psychological safety.
When a person has spoken once in a meeting, it’s safer for them to speak again later. Be sure to give the option to pass, too. It shows that it’s also safe to not speak up.
Another option is to split large discussions into small groups of two to four people each. One person from each group shares the group’s conclusions with everyone else. This allows people who are uncomfortable speaking up in large settings to have a voice, without requiring them to speak to the larger group.
Some leaders make the mistake of emphasizing positivity on their teams. They say things like, “don’t be so negative,” or “be a team player”—by which they mean, “go along with the rest of the group.” This tells people they aren’t safe to express disagreement.
Every team has a purpose: a reason for its existence and expectations about its output. But, far too often, that purpose isn’t communicated to the team. Instead, team members are told a lot of details about what to do…but not why they’re going to do it, or how it helps the company achieve its goals.
Vision. Why is the team’s work valuable? Describe how the world—or, at least, your small part of it—will be different when the team is successful.
Mission. In the next three to six months, how will the team help achieve the vision? Describe what the team is expected to accomplish and what’s out of scope,
Indicators. How will team members know they’re on the right track? Describe up to five high-level success indicators. Be concrete and unambiguous. Avoid talking about specific features (such as “ship feature X on date Y”). Instead, talk about the business results stakeholders expect.
the indicators are not a contract. They’re a guide. A way of checking if the team is on track or not. If your team isn’t on track to meet the indicators, it means you need more help or lower expectations. If you’ve exceeded the indicators, it means you’re ready to raise your expectations and shoot higher.
For each indicator, make sure it can be used to check progress toward achieving the mission, that it has a clear “yes” or “no” answer, and that the team is able to make it happen.
Set a specific time to revisit and revise the purpose. Every three or six months is a good idea. When you do, create a new draft and conduct another chartering session. It’s likely to go more quickly than your first one. Typically, the vision won’t change much, the mission will need some revision, and the indicators will need to be updated or replaced.
During the context discussion, you’ll work with key stakeholders to consider three aspects of your team’s context: the skills available to your team, the team’s boundaries and interactions,
Having a chartering session in collaboration with your key stakeholders is great for creating connections and empathy in both directions. It’s much more visceral and memorable than a set of documents some people will never take the time to read.
Finish off by rephrasing the working agreements and transferring them to a cleaned-up list. Each working agreement should finish the sentence, “We work together best when…” Describe what to do instead of what not to do. In other words, rather than saying, “We don’t interrupt one another,” say, “We let people finish their thought before adding our own.”
For your first standard, decide what it means for work to be “done.”
Changing work habits is disruptive and can make people feel like they’ve lost control. Sometimes they react by picking small things that they refuse to change. An obstinate desire to stick with a particular standard or communication style, regardless of the wishes of the rest of the team, might be a symptom of this reaction.
I love my work. I enjoy solving problems, writing good code, watching tests pass, and I especially love removing code while refactoring. But if I’m on a team with unclear goals, little collective responsibility, and infighting, I’ll wake up dreading going into work. I’ll put in my hours at the office, but I’ll be tempted to spend my mornings reading email and my afternoons picking at code while surfing through marginally related websites.
To be compelling, the team’s purpose also needs to be achievable. Nothing destroys morale faster than behind held accountable for an unachievable goal. If the team is responsible for meeting specific date and scope targets, make sure the targets are realistic and based on the team’s forecasts
Stories may be the most misunderstood idea in all of Agile. They’re not requirements. They’re not use cases. They’re not even narratives. They’re much simpler than that. Stories are for planning. They’re the playing pieces of the planning game. That’s it!
