Agile Exposes Obstacles

Agile methods are simple to learn but difficult to instill and sustain. Not only do the practices of daily stand-ups, iteration reviews, and retrospectives uncover dysfunctional practices within the team, they also expose weaknesses at every connection point. If the development team is working toward an iteration goal, but information technology (IT) operations is uncooperative or offering limited “sandbox” and deployment services, we’ll uncover that as soon as we try to develop, test, or promote a package. If the Project Management Office (PMO) is talking agile but still expects a task-oriented, Gantt-style project plan , we’ll have to deal with that obstacle soonest. If management is calling itself agile but refusing to let the team “waste time” on retrospectives, we risk losing the kaizen benefits of the agile feedback loop. If the project manager is now called a product owner but has none of the customer intimacy or business knowledge required to play that role, then we are engaging in agile theatrics, with little chance for positive change. If our client enterprise is trying to force-fit agile development into a waterfall toolset, we’ll need to engage with the entire software selection, implementation, and support chain to encourage adoption of appropriate technology. All of these impediments are outside the team, but even the most eager and capable team can’t benefit from agility until we address these external obstacles.

For the agile consultant, observation is active, not passive. Even as we’re in the thick of daily coaching and consulting, we must be cataloging the obstructions thrown up by the enterprise environment. Daily stand-ups will quickly reveal impediments to the current iteration, but, more important for agile consultants, they’ll also tell us where we need to concentrate our advisory efforts. Scrummasters look for, and strive to solve, immediate impediments to the commitments of the current iteration . The wise agile consultant is building an improvement backlog that extends far beyond the team, and incorporates the cultural, historical, and technical issues that impede evolution. Addressing these externalities, rather than simply focusing on today’s deliverables, differentiates the agile consultant from the adoption-focused coach.

We’ve reviewed many organizational change frameworks, from Kotter’s accelerators to Cohn’s ADAPT (Awareness, Desire, Ability, Promotion, Transfer) structure . I’m a fan of the ADKAR approach, from which Cohn built his ADAPT techniques. ADKAR, which is an acronym for Awareness, Desire, Knowledge, Ability, and Reinforcement , is a helpful way of thinking about agile evolution, at both the team and the enterprise level. It’s incumbent on the consultant, once she’s begun to observe obstacles like the ones outlined previously, to consider solving them by applying an ADKAR mind-set. For each interface, from management to IT operations, the consultant should walk through the ADKAR framework mentally and ask herself where the problem lies.

ADKAR serves as a simple root cause analysis technique which allows the consultant to consider the people, processes, and systems in question and develop a solution approach that is connected to the real issue. If, for instance, the PMO is not aware that agility requires it to abandon the traditional Gantt chart, the consultant’s challenge is to raise awareness. This may be accomplished through conversation, education, or examples of previous projects that were planned to the most granular task level, yet still failed. If the PMO team is aware of the global migration to agile, and understands that agile is succeeding elsewhere, but lacks the desire to change, consultants must move from education to persuasion, by focusing on our compelling Agile Opportunity, by celebrating every win at the team level, and by motivating the PMO team with a team vision that addresses its fears and concerns, both organizational and personal. Lack of knowledge is clearly a significant handicap, as it breeds rumor, mythology, and uncertainty. Consultants must engage in continuous education, from the executive to the individual level, both in formal training settings and in every one-to-one conversation. I find that I can do more to educate reluctant executives or managers with a “chalk talk” on a whiteboard than in a crowded classroom. Face to face in front of a whiteboard, I can explain how agility affects their specific role, and help them understand the general advantages of agility to the enterprise.

Mature consultants address the ability challenge, not only through coaching and mentoring on agile practices but by observing how each individual affected is rising to the challenge of transition. Many developers, for example, have technical ability to spare, but have personal concerns with practices like pair programming or daily stand-ups. Managers may have outstanding leadership skills but are reluctant to surrender their control over teams or their need for predictive plans and estimates. When we address ability challenges, we need to look beyond the questions of technical or management capabilities and examine, with patience and compassion, the personal ability to share responsibility and to abandon false beliefs in prescience and predictability. Too many coaches operate solely at the practice-adoption level, and lack the consultative skills to guide individuals and teams through the thickets of pride, ego, power, and insecurity. While a clear and compelling Agile Opportunity statement is helpful, it takes delicacy, empathy, and individualized attention to guide each human being through the adjustments required for agility to take root. Coaches and consultants who preach the fiction that “just doing the practices will propagate change” are discounting the decades of research that illustrate the deep complexity of transitioning both organizations and individuals. Even teams that are following every letter and concept of agile practice will quickly find that team-based agility is not enough, if the enterprise that surrounds them lacks the attributes of ADKAR .

We’ll talk about the Reinforcement element of ADKAR in later chapters when we address the challenges of sustaining agility. Suffice it to say here that many successful adoptions have “snapped back” to cultural norms swiftly once the consultant is gone, and that the sustainability of agile evolution is dependent on the actions we take at the outset of our engagement to ensure that acceptance, desire, and ability are real and internally motivated, and not just a temporary response to external pressures and mandates.

Planning the Roadmap to Agility

The roadmap to agility is one of the consultant’s most important tools. Not only does it position us to set expectations and begin to outline time boxes, it also sets big, visible goals for our teams. When the outcome expected is team adoption, the roadmap reminds the team of its commitments, time boxes, and the enterprise’s expectations. At the team level, a typical roadmap, as illustrated in Figure 6-2, will present an iterative approach to adoption, proposing, for instance, that we’ll guide three teams to consistent quality, delivery, and agility within the first six months, and that we’ll propagate those learnings to four other teams over the following six months. This simple roadmap is honest but incomplete. A more definitive roadmap will include some of the connection points mentioned above, and remind the sponsor that guiding teams to successful adoption includes moving the enterprise, at least at the critical junctions, to understand, accept, and encourage agile methods. The epics that might issue forth from such a roadmap will, of course, include training, coaching, and measuring the team’s progress, but also might include epics such as “As an agile developer, I need an isolated development environment so I can develop and test my product without risk of interrupting production systems.” Roadmaps that don’t include any mention of enterprise obstacles create a false narrative, set the wrong expectations, and ignore the focus areas that will have the most impact on agile success. Of course, we can’t know every obstacle upfront, and so roadmaps and epics will necessarily evolve as we observe and experience. That’s a core concept of agility. We can, however, anticipate some of the more obvious impediments, such as reluctant PMOs and siloed functional teams, and ensure that we’re thoughtfully observing all the intersections so we can foresee some of the traffic jams we’re likely to encounter. Clients hire agile consultants because they assume we can, through our experience, anticipate and address some of the ubiquitous challenges they’re likely to face. Failing to advise clients about the challenges and disruptions ahead is, put simply, malpractice, as it would be if a doctor tells his patient that a heart transplant will be painless and risk-free.

Figure 6-2. Project roadmap

At the enterprise level, developing a roadmap to agility is exponentially more challenging. The impediments at the management level are ingrained, historical, and cultural. The agile consultant engaged at this level must have the depth of business experience to grasp the client’s business model, its strategic advantages, its processes and personalities. She must be able to follow the value stream, understand the legacy cultural remnants and artifacts that impede agility, and observe organizational disconnects, with neutrality and sensitivity. She must have the diplomatic skills required to tell senior executives that “they’re doing it wrong” without upsetting egos or losing support. Most important, she must be able to highlight dysfunctions and inhibitors at the management level in a persuasive manner, motivating leaders to listen and heed rather than to escort her out of the building.

Constructing an enterprise agility roadmap is an extension of the Agile Opportunity visualization exercise we examined earlier. The examples of enterprise visions that we reviewed in Chapter 5 are aspirational, inspirational, and, frankly, ambiguous. They describe the attributes of an agile future, and some of the capabilities the enterprise hopes to gain but don’t present any details on how we’ll get there. The enterprise-level consultant who has assembled a guiding coalition, helped the enterprise develop an agile vision , and helped communicate a consistent and persuasive message now has the responsibility to take that vision a step further and encourage the leadership team to build a roadmap of the features, time boxes, and investments associated with its agile journey.

Opportunity visions and roadmaps have very different purposes, and skilled consultants should help leaders turn their vision statements into epics that describe the outcomes and expenditures they envision. A vision statement may inform the enterprise that “BIG Corporation will be agile and responsive to user needs, based on feedback obtained from our markets and social media relationships,” but it gives no hint of how we’ll accomplish that. Agility epics, on the other hand, can state that “As a marketing manager, I want to see a summary of all social media interactions every morning so I can plan for market and customer responsiveness.” Part of the complexity of enterprise-level migrations is that each department, silo, and function will have its own agile epics to tell and may need significant help to tell them.

Traditional PMO s may know that agility is in their future, and may accept that their predictive methods aren’t working. That doesn’t mean that they’ll be able to articulate the changes required to get there without the consultant’s guidance. It may be obvious to us, as experienced agilists, that the PMO may have an epic like “As a PMO leader, I need access to burndown charts and scrum boards so I can understand the team’s progress against commitments,” but agile rookies won’t come up with epics like this themselves. Functional departments, such as accounting or logistics, may be surprised to learn that changes to the software development function will affect them, and surely won’t know how to create epics illustrating that. The role of the consultant in guiding, mentoring, and coaching leaders in the development of an agile roadmap is essential, and we haven’t even mentioned the likely disputes or contradictions, in which one function’s aspirations directly collide with another’s.

Many consultants fall into the trap of concluding that the challenges, and the solutions, for every client will look like those of their previous clients. I’ve seen consultants “go on automatic,” or jump to solutions before they’ve thoroughly observed and analyzed the particular scenario in front of them. We can’t arbitrarily assume that the challenges we find in one organization will turn up in another. That’s why I named this chapter “Observe and Plan.” In agility transitions, as in all agile projects, planning is based on our experiences and learnings as we do the work. Consultants face a paradox; our clients expect us to bring the knowledge and experience we’ve gained in other engagements, yet to also honor their unique situation. They want us to have the foresight to help them avoid pitfalls, yet are rightfully touchy about “canned solutions.” Because we’re billable by the hour, clients often expect us to reach solutions quickly, but, especially in agile evolution projects, we can’t solve challenges we haven’t identified. Observation, and the ability to put those observations into context, is the agile advisor’s indispensable skill.

In the debate about “big bang” versus incremental agile evolution, I’m clearly in the incrementalist camp. Agile evolution is too complex, even at the team level, to expect the enterprise to migrate from a predictive mind-set, adopt a set of new practices, work through the initial bumps, and identify roadblocks and impediments in one fell swoop. Mike Cohn does a great job of outlining the pros and cons of each approach,¹ so I won’t recount them here. Many teams and organizations have already tried agile and failed, or have been through serial “change of the month” efforts, so, on top of the challenges I’ve laid out here, we often face a skeptical and weary atmosphere. Most clients want to see improvement on a very short time scale, and so part of our work is to instill patience in our sponsors and inform them of the realities of wading through the swamps of misperceptions and broken practices, which hamper the road to agility. Agile evolution is an iterative and incremental process, and is best run as an agile project itself, using the vision, roadmap, and backlog approach outlined above.

It’s no accident, in my view, that the lean practices that underlie agility were initially perfected in Japan. I see the agile journey as a Zen exercise , requiring us to shed the fictions of control and predictability and embrace daily adaptation to reality. This quality also applies to scrummasters and agile consultants; if we approach the agile evolution with a ticking clock in our heads, with frustration and irritation when the teams stumble over obstacles, or with a preconceived notion about the enterprise’s ultimate level of agility, we send the wrong messages to our teams, and we drive ourselves nuts. The proper attitude to agile guidance is patience, adaptability, receptiveness to reality, and empathy for our fellow voyagers. By observing the real conditions in the enterprise, adapting to them through our teaching and coaching, and mentoring our teams with composure and compassion, we model the qualities that will help teams evolve to a better version of themselves.

Summary

Observation and analysis are the core consulting skills. Mature consultants understand that every enterprise, culture, and personality is unique, and that an ounce of observation is worth a pound of premature diagnosis. Experienced consultants are always in observation mode, listening more than they speak and allowing the organization to devise its own solutions and get out of its own traps. Assuming that all engagements will be the same, and will be subject to the same sets of practices and methods, is a rookie mistake that does disservice to the client and the consultant.

Every enterprise’s unique characteristics and challenges must be analyzed with care, and the plans that come from this diligent observation must fit the circumstances. In short, inspect and adapt. Guiding teams and organizations to agility is a Zen exercise, in which restraint, compassion, and patience pay off ultimately, even when the customer wants to “get agile now!” The development of a broad overall roadmap to agility sets the proper expectations with the sponsor and, although it must change as we learn and adapt, serves as a guide to the agile journey and enables us to ensure that we’ve created a timeline that’s realistic and achievable based on the real conditions in the enterprise.