AoAD2 Practice: Trust

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, 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.


Product Managers, Whole Team

We work with our stakeholders effectively and without fear.

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 programmers working long hours with their heads down and UML diagrams papering the walls. 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 whiteboards.

Like it or not, our teams don’t exist in a vacuuum. Agile can seem strange and different at first. “Are they really working?” outsiders wonder. “It’s noisy and confusing. I don’t want to work that way. If it succeeds, will they force me to do it, too?”

Ironically, the more successful Agile is, the more these worries grow. Alistair Cockburn calls them organizational antibodies. (He credits Ron Holiday with the term.) If left unchecked, organizational antibodies will overcome and dismantle an otherwise successful Agile team.

No matter how effective you are, you’re in trouble without the goodwill of your stakeholders.

No matter how effective you are at delivering software, you’re in trouble without the goodwill of your stakeholders and sponsor. Yes, meeting schedules and technical expectations helps, but the interpersonal skills—soft skills—your team exhibits may be just as important to building trust in your team.

Does this sound unfair or illogical? Surely your ability to deliver high-quality software is all that really matters!

It is unfair. It is illogical. It’s also the way people think. If your stakeholders don’t trust you, they won’t collaborate with your team, which hurts your ability to deliver valuable software. They might even campaign against you.

Don’t wait for your stakeholders to realize how your work can help them. Show them.

Show Some Hustle

Things may come to those who wait, but only the things left by those who hustle.1

1Thanks to George Dinwiddie for this quote.

Abraham Lincoln

Many years ago, I hired a small local moving company to move my belongings from one apartment to another. When the movers arrived, I was impressed to see them hustle—they moved as quickly as possible from the van to the apartment and back. This was particularly unexpected because I was paying them by the hour. There was no advantage for them to move so quickly.

Those movers impressed me. I felt that they were dedicated to meeting my needs and respecting my pocketbook. If I still lived in that city and needed to move again, I would hire them in an instant. They earned my goodwill—and my trust.

Energized Work
Informative Workspace
Stakeholder Demos

In the case of a software team, hustle is energetic, productive work. It’s the sense that the team is putting in a fair day’s work for a fair day’s pay. Energized work, an informative workspace, stakeholder demos, and appropriate roadmaps all help convey this feeling of productivity. Perhaps most important, though, is attitude: during work hours, treat work as a welcome priority that deserves your full attention, not a burden to be avoided.

Show Some Empathy

Development teams often have contentious relationships with key business stakeholders. From the perspective of developers, it takes the form unfair demands and bureaucracy, particularly in the form of imposed deadlines and schedule pressure.

So it might be a surprise to learn that, for many of those stakeholders, developers are the ones holding all the cards. Stakeholders are in a scary situation, especially in companies that aren’t in the business of selling software. Take a moment to think about what it might be like:

  • Sponsors, product managers, and key stakeholders’ careers are often on the line. Developers’ often aren’t.

  • Developers often earn more than stakeholders, apparently without the hard work and toeing of lines that stakeholders have to put in.

  • Developers often come to work much later than stakeholders. They may leave later, too, but stakeholders don’t see that.

  • To outsiders, developers often don’t seem particularly invested in success. They seem to be more interested in things like learning new technologies, preparing for their next job hop, work/life balance, and office perks like ping-pong tables and free snacks.

  • Experienced stakeholders have a long history of developers failing to deliver what they needed at the time that they needed it.

  • Stakeholders are used to developers responding to questions about progress, estimates, and commitments with everything from condescending arrogance to well-meaning but unhelpful technobabble.

  • For many stakeholders, they can see that big tech companies deliver software well, but their company rarely does, and they don’t know why.

Think about what success and failure mean to your stakeholders.

I’m not saying developers are bad, or that these perceptions are necessarily true. I’m asking you to think about what success and failure mean to your stakeholders, and to consider whether, from the outside, your team appears to treat success with the respect it deserves.

Deliver on Commitments

If your stakeholders have worked with software teams before, they probably have plenty of war wounds from slipped schedules, unfixed defects, and wasted money. But at the same time, they probably don’t have software development skills themselves. That puts them in the uncomfortable position of relying on your work, having had poor results before, and being unable to tell if your work is any better.

Meanwhile, your team consumes tens of thousands of dollars every month in salary and support. How do stakeholders know whether you’re spending their money wisely? How do they know that the team is even competent?

Stakeholders may not know how to evaluate your process, but they can evaluate results. Two kinds of results speak particularly clearly to them: working software and delivering on commitments. For some people, that’s what accountability means: you did what you said you would.

Task Planning
Stakeholder Demos

Fortunately, Agile teams can deliver both of those results every week. You can use iteration-based task plans to make a commitment every week, and you can demonstrate that you’ve met that commitment, exactly one week later, with a stakeholder demo. You can also use release trains to create a similar cadence for releases, and steer your plans so you always release precisely on time, as described in the “How to Steer Your Plans” section.

This week-in, week-out delivery builds stakeholder trust like nothing I’ve ever seen. It’s extremely powerful. All you have to do is create a plan that you can achieve... and then achieve it. Again and again and again.

Manage Problems

Did I say, “All you have to do?” Silly me. It’s not that easy.

First, you need to plan and execute well (see the “Planning” chapter and the “Ownership” chapter). Second, as the poet said, “The best laid schemes o’ mice an’ men / Gang aft a-gley.”2

2“To a Mouse,” by renowned Scottish poet Robert Burns. The poem starts, “Wee, sleekit, cow’rin, tim’rous beastie, / O, what a panic’s in thy breastie!” Reminds me of how I felt when asked to integrate a year-old feature branch.

In other words, some releases don’t sail smoothly into port on the last day. What do you do when your best laid plans gang a-gley?

Actually, that’s your chance to shine. Anyone can look good when life goes according to plan. Your true character shows when you deal with unexpected problems.

The first thing to do is to limit your exposure to problems. Work on your hardest, most uncertain stories early in the release. You’ll find problems sooner, and you’ll have more time to fix them.

Stand-Up Meetings
Task Planning

When you encounter a problem, start by letting the whole team know about it. Bring it up in the next stand-up meeting at the very latest. This gives the entire team a chance to help solve the problem.

Iterations are also a good way to notice when things aren’t going to plan. Check your progress at every stand-up. If the setback is relatively small, you might be able to absorb it by using some of your iteration slack. Otherwise, you’ll need to revise your plans, as described in the “Making and Meeting Iteration Commitments” section.

The bigger the problem, the sooner you should disclose it.

When you identify a problem you can’t absorb, let key stakeholders know about it. They’ll appreciate your professionalism even if they don’t like the problem. I usually wait until the stakeholder demo to explain problems that we solved on our own, but bring bigger problems to stakeholders’ attention right away. Team members with political savvy should decide who to talk to and when.

The sooner your stakeholders know about a problem (and believe me, they’ll find out eventually), the more time they have to work around it. In my experience, it’s not the existence of problems that makes stakeholders most upset—it’s being blindsided by them.

When you bring a problem to stakeholders’ attention, bring mitigations too. It’s good to explain the problem, and it’s better to explain what you’re planning to do about it. It can take a lot of courage to have this discussion—but addressing a problem successfully can do wonders for building trust.

Beware of the temptation to work overtime or cut slack in order 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.

Respect Customers’ Goals

Team Development

When Agile teams first form, it usually takes individual team members a while to think of themselves as part of a single team. In the beginning, developers and customers often see themselves as separate groups.

New on-site customers tend to be particularly skittish. Being part of a development team feels awkward; they’d rather work in their normal offices with their normal colleagues. Not only that, if on-site customers are unhappy, those colleagues—who are often have a direct line to the team’s key stakeholders—will be the first to hear about it.

When forming a new Agile team, make an effort to welcome on-site customers. One particularly effective way to do so is to treat customer goals with respect. This may even mean suppressing, for a time, cynical developer jokes about schedules and suits.

(Being respectful goes both ways, of course, and customers should also suppress their natural tendencies to complain about schedules and argue with estimates. I’m emphasizing customers’ needs here because they play such a big part in stakeholder perceptions.)

Another way for developers to take customer goals seriously is to come up with creative alternatives for meeting those goals. If customers want something that may take a long time or that involves tremendous technical risks, suggest alternate approaches to reach the same underlying goal for less cost. Similarly, if there’s a more impressive way of meeting a goal that customers haven’t considered, bring it up, especially if it’s not too hard.

As the team has these conversations, barriers will be broken and trust will develop. As stakeholders see that, their trust in the team will blossom as well.

You can also build trust directly with stakeholders. Consider this: the next time a stakeholder stops you in the hallway with a request, what would happen if you immediately and cheerfully listened to their request, wrote it down as a story on an index card, and then brought them both to the attention of a product manager for scheduling or further discussion?

This might be a ten-minute interruption for you, but imagine how the stakeholder would feel. You reponded to their concern, helped them express it, and took immediate steps to get it into the plan.

That’s worth infinitely more to them than firing an email into the black hole of your request tracking system.

Be Open

When your company is new to Agile, other people in the company are likely to be curious, and little wary, about your team’s strange new approach to software development. This curiosity can easily turn to resentment if your team seems insular or stuck up.

So be open about what you’re doing. One team posted pictures and charts on the outer wall of their team room that showed what they were working on and how it was progressing. Another invited anyone and everyone in the company to attend its stakeholder demos.

You can be open in many ways. Consider holding brown-bag lunch sessions describing your process, public code-fests in which you demonstrate your code and Delivering practices, or an “Agile open house day” in which you invite people to see what you’re doing and even participate for a little while. I’ve even heard of people wearing buttons or hats around the office that say “Ask me about Agile.”

Be Honest

In your enthusiasm to demonstrate progress, be careful not to step over the line. 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 in order to finish everything in the iteration plan.

These are minor frauds, yes. You may even think that “fraud” is too strong a word—but all of these behaviors give stakeholders the impression that you’ve done more than you actually have.

There’s a practical reason not to do these things, too. Stakeholders will expect you to complete the 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 delay will produce confusion, disappointment, and even anger.


Even scrupulously honest teams can run into this problem. In a desire to look good, teams sometimes sign up for more stories than they can implement well. They get the work done, but they take shortcuts and don’t do enough design and refactoring. The design suffers, defects creep in, and the team finds itself suddenly slowed while they struggle to improve internal quality.

Similarly, don’t yield to the tempatation to count partially-completed stories toward your capacity. If a story isn’t completely finished, it counts as zero. Don’t take partial credit. 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.


Why is it our responsibility to create trust? Shouldn’t stakeholders do their part?

You’re only in charge of yourselves. Ideally, stakeholders are working hard to make the relationship work, too, but that’s not under your control.

Isn’t it more important that we be good rather than look good?

Both are important. Do great work and make sure your organization knows it.

Why bring big problems to stakeholders’ attention before smaller, already-solved problems? That seems backward.

The sooner you disclose a problem, the more time you have to solve it.

Problems tend to grow over time. The sooner you disclose a problem, the more time you have to solve it. It reduces panic, too: early on, people are less stressed about deadlines and have more mental energy for problems.

You said developers should keep jokes about the schedule to themselves. Isn’t this just the same as telling developers to shut up and meet the schedule, no matter how ridiculous?

Certainly not. Everybody on the team should speak up and tell the truth when they see a problem. However, there’s a big difference between discussing a real problem and simply being cynical.

I’ve met many developers with cynical tendencies. That’s okay, but remember that customers’ careers are often on the line. They may not be able to tell the difference between a real joke and a complaint disguised as a joke. An inappropriate joke can set their adrenaline pumping just as easily as a real problem.


Commitments are a powerful tool for building trust, but only if you meet them. Don’t make commitments to stakeholders before you’ve proven your ability to make and meet commitments privately, within the team.


When your team establishes trust with your organization and stakeholders:

  • Stakeholders believe in your team’s ability to meet their needs.

  • You acknowledge mistakes, challenges, and problems rather than hiding them until they blow up.

  • Everyone involved seeks solutions rather than blame.

Alternatives and Experiments

Trust is vital. There are no alternatives.

There are, however, many ways of building trust. This is a topic with a long history, and the only thing truly new idea Agile brings to the table is the ability, using iterations, to make and meet commitments on a weekly basis. Other than that, feel free to take inspiration from the many existing resources on relationship building and trust.

Further Reading

The Trusted Advisor [Maister et al. 2000] is a good resource on generating trust.

The Power of a Positive No: How to Say No and Still Get to Yes [Ury 2007] describes how to say no while preserving important relationships. Diana Larsen describes this ability as “probably more important than any amount of negotiating skill in building trust.”

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.