This is an excerpt from The Art of Agile Development, Second Edition. Visit the Second Edition home page for additional excerpts and more!
This excerpt is copyright 2007, 2021 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.
October has rolled around again. Last year, your team achieved Delivering fluency (see Part III). At the time, some team members wanted to push for Optimizing fluency, too, but management was skeptical. You couldn’t get the support you needed.
Since you’ve achieved Delivering fluency, though, your team has been firing on all cylinders. Productivity went way up; defects, way down. Hanna, your product manager, was having trouble keeping up. She delegated more and more responsibilities to the team, which rose to the challenge.
It got noticed. Hanna was singing your praises to the marketing director, and your boss was talking you up to the engineering director. The time was right to push for Optimizing fluency again. This time, it worked. Hanna was assigned to join your team full time. Not only that, she got permission to try “the Agile experiment.”
“The Agile experiment” is what they’re calling the way Hanna works with your team. Instead of having to go through a yearly planning exercise like the rest of Marketing, she got permission to own your team’s financials. She meets with her boss regularly to share statistics such as revenue and customer retention, and she’s constantly trying out new ideas and experiments. (Her colleagues are jealous. They still have to go through six weeks of budget and target-setting hell every year.)
It’s not just Hanna. The whole team is getting in on the action. Although Hanna is first among equals when it comes to product marketing expertise, other members of the team have developed their own areas of expertise. Shayna, in particular, loves visiting customer sites to see how people work.
Shayna’s just asked for the team’s attention. “I just finished a remote session with Magda,” she says. “You all remember Magda, right?” Nods all around. Magda is a developer who works for one of your new customers. Her company’s bigger than your normal customers, so they’ve been pretty demanding.
“Magda’s company has been dealing with an increasingly complex tax situation,” Shayna continues. “They have remote employees in more and more countries all over the world, and dealing with the various taxes and employment law is overwhelming. Magda’s heading up a team to automate some of that work, and she wanted to know how to integrate with our API.”
“But it got me thinking,” Shayna’s voice raises in excitement. “That isn’t too far off from what we do already. What if we sold an add-on module for international employment? It’s a lot of work, but we could start one country at a time. And Bo, you have some experience in this area, right?” Bo nods thoughtfully.
Hanna purses her lips. “It’s a big bet,” she says. “But it could have a huge pay-off. This could crack open the market for more companies like Magda’s. It would definitely widen our moat. None of our direct competitors have anything like that, and the big players charge two arms, a leg, and half your torso in professional services fees. Plus, we’re a lot more user-friendly.” She grins. It has a lot of teeth. “We’d only need to charge an arm and a leg. What do the rest of you think?”
Your team engages in a rapid-fire discussion of the idea. As you come to the consensus that it’s worth pursuing, Hanna nods sharply. “I love it. We’ll need to validate the market and figure out how to break it down into smaller bets. I’ll put a story on next week’s plan to come up with Build-Measure-Learn experiments. We can start on them after we release our current increment. In the meantime, I’ll do some research and run it by the boss. If the experiments work out, we’ll need her to approve more funding and a change to our mission.”
“Thanks, Shayna,” she finishes. “This is why I love being part of this team.”
Welcome to the Optimizing Zone
The Optimizing zone is for teams who want to create more value.
The Optimizing zone is for teams who want to create more value. They take ownership of their product plans and budget so they can experiment, iterate, and learn. This allows them to produce software that leads their market. Specifically, teams who are fluent at Optimizing:1
1These lists are derived from [Shore2018b].
Deliver products that meet business objectives and market needs. (Teams fluent in the other zones deliver what they’re asked to deliver, which isn’t necessarily the same.)
Include broad-based expertise that promotes optimal cost/value decisions.
Understand where their products stand in the market and how they’ll improve their position.
Coordinate with leadership to cancel or pivot low-value products early.
Learn from market feedback to anticipate customer needs and create new business opportunities.
Make business decisions quickly and effectively.
To achieve these benefits, teams need to develop the following skills. Doing so requires the investments described in the “Invest in Agility” chapter.
The team responds to business needs:
The team describes its plans and progress in terms of business metric outcomes jointly identified with management.
The team collaborates with internal and external stakeholders to determine when and how roadmaps will provide the best return on investment.
The team works as a trusted, autonomous team:
The team coordinates with management to understand and refine its role in achieving the organization’s overall business strategy.
Team members jointly take responsibility, and accept accountability, for achieving the business outcomes they identify.
Management gives the team the resources and authority it needs to autonomously achieve its business outcomes.
Management ensures that the team includes dedicated team members who have all the day-to-day skills the team needs to understand the market and achieve its business outcomes.
The team pursues product greatness:
The team engages with its customers and market to understand product needs and opportunities.
The team creates hypotheses about business opportunities and conducts experiments to test them.
The team plans and develops its work in a way that allows it to completely change plans, without waste, given less than a month’s notice.
Achieving Optimizing Fluency
The investments needed for Optimizing fluency challenge the preconceptions and established order of most companies. It requires giving up a lot of control and putting a lot of trust in the team. There’s oversight, but it can still be scary.
As a result, you’ll usually need to demonstrate success with Focusing and Delivering fluency for a few years before your company will give you the authority and autonomy needed for Optimizing fluency. Early stage startups tend to be an exception, but everyone else will have some trust-building to do.
By the time you’re ready for Optimizing, your team is likely to have mastered the rest of the practices in this book. You won’t need a how-to guide any more. You’ll have mastered the art.
So the chapters in this part are short and sweet. They’ll help you get started, and provide clues about what to try next. It’s up to you to take what you’ve learned about Agile development, combine it with these ideas, and create something great of your own.
These chapters will help you get started:
The “Autonomy” chapter discusses the nature of autonomous teams.
The “Discovery” chapter discusses ways your team can learn.
The “Into the Future” chapter wraps up with a look at what comes next.