Why Visualize?

Our goal in Visualization is to build a consensus, at the highest level with which we’re engaged, on a vision of the future state, the capabilities that will be gained, and the challenges that will be addressed. If we’re engaged at the team level, we need a team-level vision built on participation and consensus. The same is true if we are engaged at the enterprise level. In either case, we’re encouraging ownership, buy-in, and enthusiasm. We’re trying to craft a concise, logical, positive, and persuasive message, aligned with the sponsor’s agile strategy and the participants’ agile expectations.

John Kotter calls this vision “The Big Opportunity,” and I prefer this to the common “burning platform” phrasing. Language matters, and I prefer a positive vision, not one that implies roasting to death. The threat of impending doom may be motivating, but it’s certainly not inspiring. It may be true that existential disruptions are on the horizon, and that current methods are broken; that’s an important part of the message. The enterprise agility vision , however, should emphasize the future capabilities and benefits awaiting the enterprise when it embraces agility, instead of focusing on fleeing the coming inferno. Part of our visualization work is to keep the enterprise focused on what it’s driving to, not what it’s running from. Many teams and enterprises are panicked enough about merely adopting basic agile practices. Ringing the fire alarm in the middle of that transition isn’t helpful.

During our exploration and engagement time, we’ve had some substantive conversations with sponsors about vision, expectations, and the problems they’re trying to solve. In the initial engagement cycle, however, we’ve only gone so far. Most clients aren’t prepared to reveal the depth of their dysfunction or poor performance, in fear of scaring you away. Most consultants can’t afford to spend many hours in initial discovery , especially in the sales cycle, before the meter is running; we need to bill hours. We’ve seen the outline, but we haven’t seen the Big Opportunity . And usually, neither has the client.

Acknowledging this reality, agile consultants must be prepared to guide the sponsor, and the enterprise , through some bare minimum elements of a Visualization exercise, including agreement on:

• A guiding agile vision or “Big Opportunity,”

• A definition of success,

• A compelling message, and

• A plan to communicate it.

I emphasize the word guide here; no consultant can build the vision for a sponsor. The client must own it, and, so should the teams. I differ here with Kotter; he still recommends that a leadership committee creates this vision. The committee may set the strategy, and have greater visibility into the enterprise portfolio, but I’m a proponent of a broad community participating in visualizing. That, in my view, is both consistent with the values of agility and likely to deliver a more persuasive message. This is a tightrope, as “vision by committee” can often mean long and impenetrable language, as the vision statement tries to address everyone’s input and interests. Agile consultants need to thread the needle between a “tablets from the mountaintop” vision, handed down from executives on high, and an endless cycle of word-by-word debate.

The Enterprise Agile Opportunity

As agile consultants , we are initially engaging with a sponsor, or a committee, and not the entire enterprise. Sometimes that’s someone in the executive suite, sometimes a functional manager focused on a particular silo. I’m not a fan of top-down vision building, but there are advantages to starting the conversation at the top. Agile consultants that have the endorsement, and the attention, of influential leaders should take advantage of their strategic and portfolio visibility , to get a business-minded view of the opportunities agility presents. We’re starting from the core of information we gathered during our exploration activities, but, now that we’re engaged, sponsors will begin to be more candid about the challenges they face and the flaws in the system.

When we engage at the executive level, one of most important imperatives is to help leaders evolve from their strategic language to plain talk. “Increasing market penetration by 11% in Asia” is an example of a strategic objective, but few coders or testers are going to be inspired by it. That’s why I stay focused on capabilities. In a vision of agility, I want the organization to articulate the capabilities it hopes to achieve, not the strategic objectives it wants to apply them to. As an agile consultant, I can guide the enterprise toward faster delivery cycles, a more intimate relationship with the business, and a more collaborative environment. I can’t help the enterprise achieve market penetration in Asia, except indirectly.

Another reason to focus on enhanced capabilities is that they’re less like to be controversial. “Increasing market penetration” can sound like a challenge to those responsible for achieving that goal, rather than a vision of future opportunities. It can cascade negatively across the organization, as every individual ponders the repercussions on his personal role, responsibility, and workload. “Achieve faster delivery cycles” can also be threatening, but, since it applies across the organization, it’s less likely to set off a reaction of dueling silos.

Most important, the agility guiding vision must be inclusive. The worst possible vision statement looks something like this:

From the Executive Suite, we command that you achieve these goals. You didn’t participate in setting them, you don’t understand how they align, and we’re not going to tell you how to achieve them, but we will hold you accountable at review time if you fail. Now go forth and do!

How do we help organizations migrate from a top-down, hierarchy based mandate to an inclusive, inspirational vision? First, we must acknowledge that, especially in enterprise-wide transitions, it’s difficult work. With all the strategic and technological variables, all the personal and cultural sensitivities, and all the individual agendas that arise, getting to a consensus, putting it into persuasive language , and communicating it effectively can be a marathon. We’re trying to craft a concise, logical, positive, and persuasive message that is aligned with the enterprise strategy. At enterprise scale, this is obviously an iterative, incremental exercise, as the chance we will craft a message with all these attributes the first time through is nil. If we do it right, we’re using the agile practices we apply in product development to craft the vision. We start with a business need (in this case agility), articulate it as best we can, run that message through a feedback loop, and refine it until we have a potentially shippable product. In this case, of course, the product we ship is an Enterprise Agile Opportunity that is clearly communicated and compelling.

Om the other hand, I’ve gone through successful visualization exercises with a single agile advocate over lunch. If the sponsor is a knowledgeable inside agile coach or advocate, it’s pretty easy to agree that “we want three teams, capable of applying the basic scrum practices consistently over three months of iterations, achieving stable velocity and quality.” It’s certainly not an enterprise vision, but it’s enough to work with if that’s the situation. The point is that, as with all agile projects, we can take a “barely sufficient” viewpoint on visualization; if there’s no wider team to inspire, and a core team that gets it and is eager to proceed, a short agreement on intent is all we need to get started. Let’s maximize the work not done; I’ll lay out a lot of practices here, but in many grassroots adoptions, a simple, tactical statement can define the effort.

The visualization process requires leadership . As Jim Highsmith notes,² “This is one area where effective leaders lead—they help cut through the ambiguity and confusion of creating an effective vision.” Whether we’re dealing with a single product owner trying to build a single scrum team or a leadership committee that is striving for full enterprise agility, we must have someone who owns the vision and brings the clarity required to avoid spiraling into an endless semantic debate. Leadership is also required to ensure that the teams participating in visualization do so in a productive manner, with an enterprise, strategic viewpoint, and avoid any parochial, siloed instincts that may have developed in their culture. We’ll look at an overview of the process I recommend, and then decompose it for a bit more detail.

Experience in building project visions , from the Project Charters of the waterfall days to the Enterprise Agility Vision statements I’ve developed with clients, has led me to a process that is both rapid and inclusive. To perform inclusive visualization, agile consultants should:

• Identify the Agile Opportunity product owner or committee.

• Craft a set of capability goals.

• Integrate feedback.

• Craft a Consensus Vision.

• Execute Their Communication Plan.

Identify the Agile Opportunity Product Owner or Committee

While agility is an egalitarian movement, there are moments in a company’s agile evolution that require leadership. Whether the aim is agility across the organization or agile adoption at the team level, leader sponsorship and enthusiasm build the momentum that kick-starts agility. When the conversation starts at the executive level, I’m a proponent of the Enterprise Transition Committee approach recommended by both Ken Schwaber³ and Mike Cohn.⁴ An executive committee of agile proponents willing to craft a vision and evangelize it is obviously an enormous boost. Just by helping our executive sponsor build a small, cross-functional transition team , the savvy consultant can learn a lot about who’s trusted, who advocates agile, and who the messengers of change would be. As in any agile project, we want a clearly designated product owner as the representative of the business through whom business decisions flow. The transition team owns the project, and must come to decisions and take actions depending on the product owner’s feedback. The agile consultant will often be called into transition committee sessions , both to facilitate and as a domain expert, but the designated product owner is accountable for driving business decisions and priorities.

In engagements starting at the grassroots level, the product owner is usually a functional manager, of, say, software development or project management. Whether executive-led or team-focused, the product owner is the resource with whom we visualize the outcome, and is the owner of the Agile Opportunity message. Agile advisors can begin the conversation by walking the product owner through a roadmap discussion that helps them articulate their high-level expectations. The outcome of that conversation should be a graphic roadmap that then enables them to further articulate their more precise vision. The objective of the consultant’s initial conversations with the designated product owner is to agree on our capability objectives, our roadmap, and our roles.

When I begin any consulting engagement, I scrutinize and probe the enterprise’s structure, formal and informal, to see who should be included in the vision conversation. There are always technical specialists, business managers, and other domain experts who have a stake in the outcome of agile evolution. “Who else should I be talking to?” is one of the most useful questions for any consultant, and I ask it early and often. We must be judicious in how far we inquire, and how wide a circle we include, but representatives of key constituencies will add both insight and momentum to the agile vision.

For the consultant, the value of correctly identifying product owners on the sponsor side is incalculable. In traditional consulting, we often had to ask the question, “Who is the client?.” We were engaged with executives, managers, contributors, and users, each of whom had different interests, expectations, and decision rights. This is the problem that the “product owner ” concept tries to solve. By designating an individual, accountable representative of the business, we’ve now guided the organization to grant ownership to the product owner, who then is accountable for convening and caucusing the leadership team, for coming to group vision for agility and for communicating the vision to the enterprise. At enterprise or team level, it’s in the consultant’s interest to have a single product owner who has the explicit decision rights for the Agile Opportunity, and selecting the right representatives is decisive.

Craft a Set of Capability Goals

Why is the enterprise considering agility? Does it believe adopting agile will help it increase market penetration in Asia next year? Probably not. The enterprise is instead seeking enterprise or team-wide capability enhancements that will enable it to achieve its strategies. Agile, whether at the team or enterprise level, is about reducing waste, increasing responsiveness, and removing friction from the value stream. We strive to enhance the organization’s capability to execute efficiently.

Capability planning ⁵ is a facilitative method that helps the organization identify gaps in its performance. This process generates capability goals, quantified objectives that describe business execution capabilities. The capabilities they describe are cross-functional and hierarchical lines. Rather than strategic goals, like “Sales will increase our reach in the generics market by 22%,” the enterprise capability goals we seek look more like “The Enterprise will be capable of identifying new target markets, and establishing measurable progress within six months.” Other examples of capability goals are:

• The Enterprise will provide a friendly, positive response to any inquiry or complaint within 24 hours.

• IT Development will deliver a set of running, tested features for client review at the end of every iteration.

• Marketing will be capable of designing an initial campaign within 8 days of shippable product delivery.

Capability planning is the essential building block of agile visualization. We must know, at whatever engagement level, the business capabilities our sponsors expect to enhance. The previous examples illustrate that, whether it’s the entire enterprise or one eight-member development team, there is a clear, concise, and measurable capability that the team can identify.

In the process I apply, I begin capability planning with a process-mapping session , so we have a visible model on which we can plot barriers and broken connections. Team or enterprise, every entity has an input-process-output cycle that can be mapped and analyzed. Simple process mapping is a great way to coach teams in thinking about process efficiency, and to help them visualize obstructions. This practice can be simple or complex, of course, depending on the scale of your transition and the enterprise business model. I’ve been in mapping sessions that lasted a half hour, and sessions that took four days. I want just enough visibility so they can walk me through the flow of their value stream and point out obvious pain points. As we discussed earlier regarding value streams, it’s hard to target high-impact improvements if we don’t understand how the enterprise works.

From executive teams to small contributor teams , my practice is to develop capability goals by convening a brief mapping session, getting the basic flow on a whiteboard, and then asking participants to point out blockers and enablers. With executives, the flow will typically be a high-level fly-by of their value stream. For developer teams , it might be “from software request to application acceptance.” With the basic map in front of us, we can start to probe. Where do we get stuck, and where might added capability solve a problem? I’ll then ask participants to propose solutions to the obstructions they’ve identified. If the problem is “Too many defects get through unit testing and blow up integration efforts,” the solution might be to “Enforce completed-test standards on all code passed to integration.” The move from solution to capability is natural. The capability goal in this case might be to “integrate successfully with no passed defects 85% of the time.”

Size capability planning to the scale of your agile engagement. Capability planning in a small team can be an informal exercise; team members know where they’re stuck. You can generate a set of capability goals in a beginning rookie scrum team in an hour or two. Just ask them what’s broken, and steer the conversation to a positive scenario rather than the current negative situation. Help the team articulate the solutions they envision for the broken places, and their capability goals will write themselves.

This list of capability objectives becomes our Agile Opportunity backlog, replacing vague goals like “be more agile in responding to customers” with explicit improvement expectations. Capability planning should be run like any agile planning session, building consensus on a backlog, prioritizing backlog items, and soliciting commitments from team members. The agile consultant facilitates the team through capability planning, helps them frame the language for positive impact, and assists in consolidation and prioritization. When capability planning is complete, the agility product owner or committee will have accepted a prioritized backlog of measurable enhancements, upon which the Agile Opportunity can be based.

Capability planning has a lot of advantages for the agile consultant . It develops consensus around the agile capabilities the sponsor expects. It subdues the inter-silo debate, and focuses instead on cross-functional process innovation. It enables the consultant to probe disconnects and dysfunctions, since each capability goal recognized is also a gap identified. It takes the focus off suboptimized, siloed improvement efforts and envisions enterprise capabilities that enhance results. Most important, it provides the raw material to be filtered down into a persuasive Agile Opportunity.

Integrate Feedback

Every lean and agile process has a feedback loop . Without feedback there is no kaizen. The creation of an Agile Opportunity vision must be inclusive if we want to avoid the dreaded executive proclamation. Leaders can shape the strategic direction of agile evolution, and be enthusiastic evangelists for the coming changes. What leaders can’t do is create ownership and commitment . That requires participation and a responsive feedback loop.

The feedback mechanism for an Agile Opportunity vision is obvious, because it is a straight application of agile practices. We iterate through drafts of the Agile Opportunity, solicit feedback from our target audience, and synthesize that feedback, all within a defined time box. The first iteration of draft and feedback is often the raw capability goals we built in our mapping session. At the enterprise scale, the transition committee has probably ironed out a lot of the disputes and created a set of capability goals that are not controversial. At the team level, team members often have already agreed that they want to adopt these practices and enhance their capabilities. Still, the feedback process is designed to surface disagreement and innovation. Capability goals should cycle a few times, especially in politically charged environments.

The target audience for our Agile Opportunity communications must be, well, targeted. I wouldn’t advocate an enterprise-wide communique at this point, before we’ve crafted a complete vision. An individual team can have an all-hands conversation and agree on the capabilities it is striving to achieve. At an enterprise level, a small, thoughtfully selected, and representative sample of informed, influential, and interested stakeholders is a wise strategy. We want to include enough diversity of opinion for a meaningful dialog, while avoiding a firestorm of confusion, resistance, and rumor in this initial stage of our agile journey. As we’ve emphasized, visualization of an agile outcome requires leadership, and, while the feedback loop is essential, it must also be prudent. Leadership still has a role to play in agility, and aligning the effort to strategic priorities is still leadership’s prerogative.

The time-boxed nature of the visualization effort is important, as a participative feedback cycle can be eternal, and agile enterprises can’t afford endless loops. Iterating through drafts, with a targeted feedback opportunity embedded in the cycle, can take us from capability goals to a broad, consolidated, and compelling Agile Opportunity statement rather quickly. The development of a set of capability goals, even in complex enterprises, can be done in a day. The dissemination of them, by e-mail or survey, with request for comment, can have a two-day time box. Another few days to integrate commentary and start to wordsmith and condense it into an Agile Opportunity, and another round or two of draft and feedback, and you’re on the way to an integrated synthesis of the enterprise’s agile expectations and hopes.

Of course, inspect and adapt this process ; some Enterprise Transition Committees can rocket through iterations and reach an Agile Opportunity statement quickly, and others are slow and deliberate. Some team-level sponsors are agile advocates with a deep understanding of where they're headed, and some have been assigned agile transition from on high, and need education and guidance. If the agility product owner , with the agile consultant’s guidance, articulates a set of concise cross-function capability objectives and puts them out for comment, we learn what is important to the enterprise community, what motivates them and what concerns them. Just as in a software development project, we allow the community to course-correct as we determine what agility means to the enterprise. What’s important to the agile consultant is that the Agile Opportunity vision we iterate toward is ultimately an elegant and urgent statement, and is owned by all the right participants.

Craft a Consensus Vision

Building consensus is a core consulting skill, and it requires delicacy, diplomacy, and resolve in equal measure. In the pursuit of an agile vision, we’ll frequently have to condense and modify language, prioritize objectives, and, in the process, strip out some group’s favorite phrases and descope someone’s urgent need. At the Visualization stage, the agile consultant hasn’t been around long enough to build much trust, and frequently applies collaborative, participative practices with which teams are unaccustomed. To evolve from capability goals to an Agile Opportunity statement will require us to refine a backlog of possible future outcomes into a crisp and compelling statement. Again, the consensus we seek at this point is not across the enterprise; it’s among the agility product owners and the selected domain representatives.

The dangers of “vision by committee” are obvious. Every team has its own language, its own pet phrases, and its own strategic priorities. Our first job as consultants is to keep the team’s eyes on the prize. Skilled consultants can facilitate a conversation that focuses on enterprise value rather than narrow interests. We can help the team move from the specific to the general. A capability goal that we mentioned earlier, to “integrate successfully with no passed defects 85% of the time,” may have great urgency for the application development team and be perfectly suitable if that’s the target. For impact across the wider enterprise, this might be better articulated as “Deliver running, tested applications, fit for use, within an agreed time box.”

Let’s recap. We’ve worked with the product owner of the agility initiative, whether executive committee member or team leader. We’ve done some preliminary process mapping or walked through the value stream, identified barriers, and derived a set of capabilities the business would like to improve. We’ve communicated these expected capabilities to a select group of domain representatives, and integrated their comments and ideas into revised versions of those objectives. We’ve gone through that cycle some number of times, and our product owners are ready to start crafting an Agile Opportunity statement. This statement will be the vision upon which we will build consensus and enthusiasm. It will be addressed to the enterprise at whatever level we are engaged, from the team to the entire organization.

The crafting of an Agile Opportunity may require us to broaden the circle of participation. Human resource experts, technical specialists, and additional domain representatives can often offer insights and help avoid landmines. Marketing specialists or technical writers can bring critical writing and persuasion skills. We still want to apply our “barely sufficient” discipline to team participation, but we need to be deliberate when developing a communique that broadcasts change and disruption.

The ideal team for crafting an Opportunity vision includes an executive sponsor or product owner, representatives of the critical teams within our engagement scope, and the writing and marketing talent to compose a compelling vision. The consultant plays a facilitation role, and often needs to reel the conversation back to the work at hand. My practice is to convene a single facilitated work session, with the right participants and a strict time box, in which the team commits to producing a final draft of an Agile Opportunity vision. Final, because we don’t have the luxury of eternal iteration, and draft, because we acknowledge that there will be feedback when we communicate, and attempt to evangelize, the vision.

To illustrate my view of compelling Agile Opportunity statements , here are three examples, from informal to enterprise scale:

• The RED user experience design team will pilot the application of agile methods. We’ll learn and apply scrum techniques in their pilot project, build a prioritized backlog, and iteratively present a valuable package of design functionality for customer review at each iteration. We’ll achieve scrum proficiency, including a steady and consistent velocity and the ability to manage a backlog, within the next three months. We’ll use the learnings from our pilot to migrate scrum to five additional teams this year.

• The GOLD software development team delivers quality software to our customers rapidly and responsively. We help customers articulate their needs and expectations, collaborate with them to ensure they can guide our development, and respond to their changing business needs. We present complete transparency of our progress through big visible indicators, and we work in cross-functional teams that focus on business value instead of activities. Our products add value across the enterprise, resulting in improved agility and responsiveness for our company. We apply continuous improvement to ensure we refine our practices with every iteration, and collaborate openly within our team and with our customers. We will achieve these capabilities by applying scrum practices with discipline and craftsmanship.

• The Blue Corporation has a long history of meeting customer needs in personal care products. We recognize that our customer’s needs evolve constantly, and that competitors are developing and marketing innovative products faster than us, and threatening our market share. We intend to protect and grow our market share by becoming a more agile and responsive organization. We’ll build a strong connection and feedback loop with our customers through social media. We’ll apply that feedback to developing innovative products within months instead of years. By applying agile methods, we will drive innovative new products through our R&D function at twice the current speed. We will create an agile software development community that can deliver quality applications on a regular cadence, with predictable and consistent speed. Our marketing team will be capable of developing a new campaign within two weeks, and our logistics chain will be prepared to put our products on shelves within a week of launch.

• By transitioning the enterprise to agile mind-set and methods, we’ll be capable of changing products quickly to meet evolving expectations, of marketing and delivering those products faster and better than our competitors, and developing the supporting software rapidly and accurately. We’ll build a collaborative, low-friction culture that empowers teams to make decisions and take ownership of their outcomes. By building agility and adaptability into our enterprise, we’ll have fun and dominate our market.

These are modified examples of agile visions I’ve worked with in the past. They reflect my style of writing and persuasion. I’m sure yours is better, because you are collaborating with your client and adapting to the client’s unique situation. As an agile advisor , you’ve led the client to reveal its hopes and flaws, develop its own solutions, and convert the client participant into concrete capability goals that will inform its agile vision. By facilitating the team or the enterprise through the creation of a compelling opportunity vision, it has told you what success looks like. You’ve prepared the team or enterprise for the heavy lifting of building enthusiasm and commitment.

Execute Your Communication Plan

Ineffective communication is the root of most business evils. In the worst cases, the strategic plan is impenetrable, objectives are unconnected, expectations are obscure, and direction is muddled. The culture is accustomed to long periods of silence, indecision, or controversy from leadership. The communications that randomly cascade from executives to managers, and from managers to staff, all seem like disconnected mandates rather than a coherent strategy. The response is more likely to be “here we go again” than it is to be enthusiasm, much less commitment.

An agile evolution program must begin with a clear and persuasive communication campaign. Organizational inertia is weighty, and won’t be moved by the issuance of an e-mail. If our Agile Opportunity is truly a Big Opportunity, it must stand out from the reams of corporate proclamations, and inspire teams to action. We’ll get a range of responses, from cynicism of “another fine program” to enthusiasm from agile advocates. The feedback is the point; it makes visible the fears, concerns, and hopes of the community , whether team or enterprise. In true agile form, it exposes the weak spots, so we know what to prioritize. The community transitioning to agility will tell you how to succeed through your interactive campaign of communication and persuasion.

Long before our Agile Opportunity vision is composed, we should be advising our clients to consider their communication and momentum program. Through what venues will we be communicating with our enterprise? Should we go beyond e-mails and surveys and create a Facebook page, a series of training videos, an executive presentation, or a “big room” work session? Are we asking for understanding, compliance, or feedback (or a bit of each)? Persuasive communication of an Agile Opportunity is our chance to demonstrate executive support, evangelize the benefits, acknowledge the challenges, and build some momentum.

As we’ve seen in the State of Agile Surveys, organizational inertia is the major factor in agile adoption obstacles. The management team isn’t ready for “servant-leadership,” the culture is change-weary and skeptical about another new program, and the “way we do things here” has encouraged and rewarded bad habits. Moving just one team to a new conception of work is a challenge. Moving the enterprise to a new mind-set is Herculean.

I use the word evangelizing, but bluntly, this is a marketing effort. As in all such, we must think about our target market, our appeal to their interests, and the behavior we hope to influence. While I believe the Agile Opportunity vision addresses the entire enterprise audience, framing it will differ in IT, where the pilot will take place, and in accounting, which won’t be immediately affected. IT wants to hear, probably from a technical manager, that it will be supported through adoption, that there’s benefit to the department, and that there’s nothing to fear. Accounting, like all other functional departments and all individuals, wants to know how this affects its members.

At the enterprise level, my recommendation would be to select a small team, with representation from human resources (HR) and marketing, to build the campaign. The individual team can have this conversation over lunch, but once we grow beyond, we need to be sophisticated in our approach. HR will guide us to appropriate language, and marketing expertise can add flash that makes this more than just another e-mail or program. We’ve already derived an Agile Opportunity message, but to complete it, we need to answer the questions I posed earlier. A broad set of communication channels, from the executive presentation to the social media campaign , and from video tutorials to scheduled training sessions, will reach different audiences with different interests and learning styles. Executive support, through team visits and all-hands presentations, can be a burst of jet fuel to momentum, especially if the message is positive, honest, and passionate.

The Big Opportunity is an opportunity lost if its communication is not compelling. Consultants have a large role to play in the framing of the message, due to our agile domain expertise. Sensitivity to agile theory, practice, and language will be critical. Starting to acclimate the enterprise to a new language and a new mind-set begins here. Consistency is also important, as inconsistent delivery of the agile vision will lead to rumor, speculation and negative interpretations. Inconsistent messaging often occurs when the message is cascaded verbally from top down, as in “tell your teams that we’re going agile and it’ll be great!.” We must also campaign honestly. While I talk about this as a marketing campaign, there’s a difference between manipulating and influencing. Agile is transparent, and our communication should be as well. Good agile vision messages emphasize the positives but acknowledge the challenges. We know this will be hard; we should tell them so. We also know that it works, and that teams and enterprises that adopt it are happier and more productive. If the agile consultant ensures that a compelling Agile Opportunity has been envisioned, articulated, and communicated, he’s done a service to the client. He’s also done himself a favor, having ferreted out the initial set of challenges, resisters, and advocates.

Some agile evolutions are team-focused, some are enterprise-wide. In either case, there is a natural progression from vision to roadmap to backlog. When the project is an agile evolution, the items that land in the backlog are improvement features, elements of the value chain that we intend to enhance with agile practices. The enterprise can’t get to an improvement backlog without a vision, whether accepted over lunch or cascaded through a marketing campaign. In Chapter 6 we’ll discuss the development of a roadmap, based on the vision we’ve just articulated and circulated. Without an overarching, vision, the roadmap is just a set of tasks. The Agile Opportunity vision opens the door for us to observe more directly, and to create a roadmap that reflects the client enterprise’s consensus on the capabilities they expect .

Summary

Every agile project begins with a vision that defines the guiding goals and objectives of the effort. The same must be true for an agile evolution project; the consultant and the sponsor must agree on the business reason for the effort, the results we’re expecting, and the path we choose to take. That path may be long and winding, and it may lead us to unexpected destinations, but the vision should be constant and consensual. Agile consultants help their clients understand the strategic meaning of the evolution, and help them craft and execute a communication plan to build understanding and commitment across the enterprise. Organizational inertia is strong. Only a persuasive vision and communication program can turn inertia into momentum. Agile consultants omit this key activity at their peril, and at the peril of the client’s agile expectations.