Chapter 10: Champion your team
10.5 How do I get stakeholders and managers on my side?
If your organization is new to Agile, team members feel the transition’s effect the most. The change also affects the rest of the project community, but to a lesser extent. This oft-sizable group includes several layers of management above the teams, who need to adjust their expectations and behavior. It also includes professionals in other departments, downstream or upstream from the core team, whose work depends on effectively interfacing with the team.
As your team’s champion, build inroads to those people, effectively becoming the glue of the community. Doing so will secure the collaboration — or at least cooperation — needed for effective development, and will prevent them from sabotaging the team’s performance (intentionally or otherwise).
Start by providing basic education. Unlike your team, the stakeholders and managers just need to understand the principles and motivation of Agile, as well as the few practices that apply to them. Never assume that they’ll read the books, show up to your team’s training, or try to understand the finer details. Senior managers are the least likely to have time for this education, but having an audience with them even for one hour is often enough. When you meet them, don’t describe process mechanics or show slides. Instead, ask about the business effects and results that matter to them, explain how Agile would help achieve them, and discuss their involvement.
Invite the entire community to the iteration demo. Nominally, it’s an opportunity for feedback and course correction, but it’s also an opportunity for community building and the demonstration of commitments kept. I like to invite the same people also to the daily standup; they are allowed to share updates and ask for clarifications, but they are not allowed to meddle. (I never, ever, allow anyone to use the words chickens and pigs in this context.) Invite them to visit the team space, observe the valuable artifacts and information radiators on the walls, and socialize with the team. Be around to answer the questions that might arise about Agile. If the team is new to Agile, not all members might be able to explain some of the contentious points adequately.
In my experience, most senior managers in a company transitioning to Agile underestimate the time it takes to reach good productivity (see 6.8). To make matters worse, they are told that teams produce potentially shippable increments every couple of weeks. This appeals nicely to managers who wanted Agile for its promise of cheaper, better, faster. They apply subtle pressure on the teams to perform, and get quite frustrated and anxious when things turn out differently (see 10.6). You must manage their expectations regarding the team’s performance, so they take things in proportion. Teach them the Satir Change Curve (11.1). Explain the continuous improvement mechanisms you have in place. Keep them focused on winning the war instead of each battle; a charter comes in handy here, as it deflects attention from small-scale deliverables.
Understand what other managers care about, and tailor your responses to their model of the world. Most senior managers care about the project’s schedule (and making it shorter); customer experience (which goes directly to customer attraction and retention); and revenue and costs. You probably live in lower-level details, such as user stories and velocity, which are less useful to them. When they ask you for information, seek to understand their purpose.
For example, suppose they ask for daily detailed progress. Using techniques from chapter 8 you learn that they want visibility. Visibility affords them control, which would reduce their concerns about the project’s schedule. Now you can speak their language: Show them how your methods respect and possibly compress the schedule, and back up your words with data.
One thing that worries people downstream or upstream from the Agile team is, “How is this going to make my life harder?” As you have conversations with the various stakeholders — in particular, managers of non-Agile projects — listen and take note of their particular fears. Common fears include:
- “The team’s choice of Agile will compromise my meeting of my objectives.” The stakeholders still need to follow the company’s processes and manage dependencies. Seek to understand their objectives, expectations, and obligations. Collaborate with them to produce backlog items that address their needs.
- “They are asking for more time than I can spare.” Handle this by playing their involvement down. Since you don’t truly know how much they’ll need to be involved, don’t try to secure guarantees you may not need. Explain that the team is autonomous. Emphasize that the team will do whatever they can without encumbering others or treading on their turf. And demonstrate a genuine intent to minimize the impact on the stakeholders’ workload and schedule, working out their involvement as time goes on.
- “They’ll probably want me to change my process.” That fear is actually true to some extent, but again its details are not known a-priori. Explain that you’ll work out the details as you go along, because you frequently inspect and adapt.
- “I’m losing control.” Having a measure of predictability and a perception of control gives a good deal of comfort. Agile provides excellent control while giving off the impression that it doesn’t. Explain the control mechanisms that they still have.
To this day, more people are misinformed and confused about Agile than those who know what it is. Even those who’ve read a book on Agile might be confused by your team’s particular adaptation. Executives still tell me, “What’s the big deal? It’s only a process!” failing to realize the magnitude and ramifications of Agility. Any moment you’re not out there setting records straight, they are forming their own impressions and telling themselves stories that may not be in your favor. Keep the lines of communication open. It’s sometimes the people you don’t see every day that you need to communicate a lot with.
Remember that all project community members have needs, wants, and obligations, which they meet within the organizational power structure. Become familiar with that structure so you can be pragmatic about possibilities and expectations. You might need to make concessions, such as translating release and iteration plans into standardized project reports. Sometimes you’ll want to have certain item higher up in the backlog in order to get an influential person on your side. Other times you’ll encounter resistance, such as the HR manager saying “We can’t include auditions in the hiring process,” or the Operations team lead saying “We can’t deploy more than once weekly.” Look for common ground and ask, “Here’s what I want to do, what is it that we can do given the constraints of your job?”