AoAD2 Part II: Focusing on Value (Introduction)

Book cover for “The Art of Agile Development, Second Edition.”

Second Edition cover

This is a pre-release excerpt of The Art of Agile Development, Second Edition, to be published by O’Reilly in 2021. Visit the Second Edition home page for information about the open development process, additional excerpts, and more.

Your feedback is appreciated! To share your thoughts, join the AoAD2 open review mailing list.

This excerpt is copyright 2007, 2020 by James Shore and Shane Warden. Although you are welcome to share this link, do not distribute or republish the content without James Shore’s express written permission.

Focusing on Value

You walk into work on a crisp October morning. After the Covid-19 pandemic, your team was eager to return to in-person work. Other teams chose to stick with remote work. Agile feels much the same either way, you muse to yourself, despite differences in the details.

Your team is a fluent Focusing team. As a team, you’re very good at understanding customer needs, defining useful features, and focusing your work on the most valuable thing you can do. There’s room for improvement, particularly around defects and deployment, and people have been talking about investing in Delivering zone fluency to solve those problems, but management is very happy with your output. Some people on the team really want your team to take full ownership as an Optimizing team, but, for now, your team’s priorities are determined by Hanna, a product manager in the marketing department. She’s pretty busy and her boss isn’t willing to assign her to your team full-time.

Speaking of product direction, today is demo day. Every week, your team releases a new version of its software, then makes a plan for the next week of development. Once per month, you gather together your major stakeholders, show what you’ve done, and get their feedback. You used to do it more often, but stakeholders couldn’t be bothered to show up that frequently. So now you have less frequent but chunkier demos, and people are excited to see what’s new. When you want faster feedback, you give private demos to interested individuals.

Before the demo, though, you have your weekly team retrospective. It’s an opportunity for your team to look at your practices, team dynamics, and organizational roadblocks to see what you can improve. You rotate who facilitates every week. This week, it’s Shayna’s turn. You’re looking forward to it. She always comes up with creative exercises to liven up the retrospective, and she’s good about making sure that the team follows through with an experiment to try.

After the retrospective, you all meet with Hanna, your product manager, for the stakeholder demo. Hanna takes the lead, as usual. She originally wanted team members to run the demo, but you found that having Hanna in charge of the demo meant she paid more attention to what you were building. (That was the result of a retrospective experiment, in fact.) It led to better feedback and better results. Plus, she’s much better at speaking stakeholders’ language.

Stakeholders seem happy with your progress this month. There’s a lot of interest in the whitelabel feature you’re working on, and the usual smattering of suggestions. Hanna makes note of them.

After a break, it’s time for your weekly planning session. Hanna pulls over your release planning board. It’s a large whiteboard with a bunch of index cards stuck to it with magnets. The cards form clusters, and each cluster has a name like “resellers,” “actuaries,” or “accountants.” They represent your customer groups. There’s another large group of cards marked “whitelabel.”

“We had some good ideas in the demo,” Hanna says, “but I want to stay focused on the whitelabel feature for resellers.” Everybody nods. You’ve been working on this for a few weeks, so it’s no surprise. “We’re getting close to being done with the whitelabeling itself, so the next feature is the administrator screens. Before that, I’d like to set up a trial run with one of our major resellers. I’ll send an email with the details.”

Hanna nods to Colton, the team’s UX designer, and he speaks up. “Hanna and I are going to be going over the trial run and whitelabel administration features later today. You’re welcome to join. After, I’m going to mock up a few designs and then I’d like to have a story break-down session later this week. I’ll let you know when I’m ready to schedule it.”

Hanna grabs a handful of blue story cards from the “whitelabel” section of the release board. “We still have enough in our backlog to get us through this week. Our capacity is still 12 points, right?“ Nods all around. “Great. Here’s three... six... eight, 11, 12. These should get us pretty close to being able to trial with real customers.” She holds up the first card, which says “whitelabel color scheme.” “Okay, for this one, we need to be able to change the site color scheme to match each reseller’s colors.” She briefly explains the remaining cards. There are a few clarifying questions, but you’ve all seen these before, so it goes quickly.

“Okay, that’s the plan!” Hanna concludes. “Colton should be able to answer any questions about the details. I’ve got some emails to take care of, but I’ll be over here”—she points to a corner—“until you’re done with planning. Let me know if you need me to clarify anything.”

Hanna sits down and Shayna takes the lead. You decided a while ago—it was another retrospective experiment—that the person who led the retrospective would facilitate all team meetings for the week. You haven’t heard of any other teams working this way, but for your team, having a predefined facilitator helps you stay on track, especially now that your coach has moved to a different team.

Shayna spins the planning board around. On the back is your weekly plan. “Okay, you know the drill,” she says. She points at the five story cards Hanna chose. “Go ahead and spread those out and start brainstorming tasks onto yellow cards. I’ll prep the board.”

The team gathers around the table and starts writing tasks on yellow cards. As they do, they call out their ideas, which in turn inspires more ideas. “Update the DB schema to include color scheme.” “Factor out CSS variables.” “Serve reseller-specific CSS file.” “Add reseller CSS file to top-level template.” Before long, there’s an orderly grid of cards showing everything that the team needs to do this week. Shayna helps transfer it to the whiteboard. You’ve heard that other teams visualize their plans differently, but your team likes this approach.

“Let’s do our stand-up,” Shayna says. You gather around the whiteboard and have a brief discussion about what to work on first, then everybody grabs a task card off the board. The tasks only take a few hours each, so as each one is finished, you'll mark it done and get a new card from the board. Every day, you’ll have another stand-up meeting around the board to review your progress and make sure the week is on track.

“I think that’s it,” says Shayna. The stand-up only took a few minutes, and the whole planning session has taken less than hour. With the retrospective and demo, it’s getting close to noon. “Who’s up for lunch?”

Welcome to the Focusing Zone

The Focusing zone of the Agile Fluency Model is for teams that want to focus their work on the things their company values most. They work closely with their business partners to understand priorities, provide visibility, and act on feedback. Specifically, teams that are fluent at Focusing:1

1These lists are derived from [Shore and Larsen 2018]. Used with permission.

  • Plan their work in terms of business value, not technical tasks, and align their work to their company’s business priorities.

  • Demonstrate progress at least once per month, and do so in terms of business value, not technical tasks.

  • Change direction to match changes in business priorities.

  • Provide visiblity into their progress, so management can intervene when the team is building the wrong thing or isn’t making progress.

  • Regularly improve their work habits, reducing costs and improving effectiveness.

  • Collaborate well within their team, reducing misunderstandings and hand-off delays within the team.

To achieve these benefits, organizations need to make the following investments (see the “Investing in Agility” chapter for details):

  • Create long-lived, cross-functional teams. Compose each team of people who work well together and have the skills and background needed to accomplish the team’s work. Allocate them 100% to their team.

  • Provide each team with a coach who can teach self-organization, team development, and the Focusing zone practices in this part of the book.

  • Create a productivity-focused workspace for each team, either physical or virtual.

  • Ensure each team has access to someone with business expertise who’s responsible for setting product direction and goals. They don’t need to be a team member, but they do need to participate in every planning session. (Some people call this person a “product owner” or a “product manager.” Generically, they’re the team’s business representative.)

  • Ensure that each team includes at least one person who’s able to determine the details of what the team’s software will do.

  • Remove, revise, or work around HR policies that impede effective teamwork, such as competitive ranking and individually-focused rewards.

  • Train managers how to create an environment that supports teamwork and how to manage the work system rather than individual contributions.

The Focusing zone involves the following skills. The team is proficient at the zone when the team exhibits all these skills. It’s fluent when it exhibits these skills with unconscious ease, even when under pressure.

The team responds to business needs:

  • The team works with a business representative who provides the team with organizational perspective and expectations.

  • Business stakeholders can rely on the team to work on whatever their business representative views to be their most valuable priority.

  • The team plans its work, and shows progress, in chunks that their business representative understands and values.

  • The team’s business representative sees, and can change, the team’s direction at least monthly.

  • Management enables the team to work at a pace that allows them to respond to business needs indefinitely.

The team works effectively as a team:

  • The team generates their own day-to-day tasks and plan, based on their business representative’s priorities.

  • Team members consider their plan to be the team’s work, not individuals’ work.

  • Team members share accountability for getting their plan done.

  • Management considers the plan to be the team’s work rather than assigning accountability to individuals.

The team pursues team greatness:

  • The team embraces, and continuously improves, a joint approach to their work.

  • The team is aware of how intra-team relationships affect their ability to succeed and proactively attempts to improve them.

  • The team is aware of how their work environment affects their ability to do work and proactively attempts to improve it.

The team doesn’t need everybody on the team to have these skills. Instead, they need the ability, as a whole team, to bring the right people to bear at the right times. There are several levels of maturity:

  1. Learning. The team is learning the skills.

  2. Proficient. The team is able to exhibit the skills when they concentrate on them.

  3. Fluent. The team exhibits the skills automatically, without conscious effort, so long as they have a coach as part of the team.

  4. Independently Fluent. The team exhibits the skills automatically, without needing a coach, so long as key team members are present.

  5. Resiliently Fluent. The team exhibits the skills automatically, regardless of who on the team is present.

The chapters in this part have practices that will help your team develop these skills.

  • The “Teamwork” chapter describes how to work effectively as a team.

  • The “Planning” chapter describes how to plan and prioritize work according to business value.

  • The “Accountability” chapter describes how to provide visibility into your work and gain stakeholders’ trust.

  • The “Ownership” chapter describes how to take ownership of your day-to-day process and plans.

  • The “Improvement” chapter describes how to improve your team’s work habits, relationships, and environment.

Share your feedback about this excerpt on the AoAD2 mailing list! Sign up here.

For more excerpts from the book, or to get a copy of the Early Release, see the Second Edition home page.

If you liked this entry, check out my best writing and presentations, and consider subscribing to updates by email or RSS.