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.
- 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 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 whiteboards.
Like it or not, your team doesn’t exist in a vacuum. 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, delivering software and meeting technical expectations helps, but the interpersonal 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
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 of unfair demands and bureaucracy, particularly in the form of imposed deadlines and schedule pressure.
So you might be surprised 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’ careers 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.
Does your team appear to treat stakeholders’ success with the respect it deserves?
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 stakeholders' 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
Furthermore, your commitments make it possible for stakeholders to make commitments to their stakeholders. If you have a track record of reliability, you reduce their anxiety. On the other hand, if you fail to meet a commitment and don’t give them advance warning, it’s easy for them to assume you deliberately left them out of the loop.
Fortunately, Agile teams can make reliable commitments. 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 “Predefined Release Dates” section.
Week-in, week-out delivery builds stakeholder trust like nothing I’ve ever seen.
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.
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.”1
1“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.
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.
It’s not the existence of problems that makes stakeholders most upset—it’s being blindsided by them.
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. Similarly, 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. 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, if you can. 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.
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.
Respect Customer Goals
- Team Dynamics
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 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 10-minute interruption for you, but imagine how the stakeholder would feel. You responded 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.
Make Stakeholders Look Good
Even if your immediate stakeholders love you, they need to convince their bosses to love you, too. What do your stakeholders need? Think about the situation they’re in, how they’re being evaluated, and what you can do to support them in return.
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. For example, “Release X processed 20,000 events in the first two months, reducing error rates by 8%.”
Although this may seem like a marketing exercise—and it is—it’s also a valuable way for the team to stay focused on value. Updating the value book forces team members to reflect on what they’ve done for stakeholders and customers. This helps prevent the team from thinking of itself as a mere factory for delivering stories.
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 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 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 temptation 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 people know it.
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.
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. See the “Making and Meeting Iteration Commitments” section for details.
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
Stakeholder 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 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.
Trust and Betrayal in the Workplace [Reina2015] is a thorough look at how to establish trust and what to do when it is broken.
'The Power of a Positive No: How to Say No and Still Get to Yes [Ury2007] 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.”