In Chapter 1 we looked at existing transformation frameworks, like ADKAR (Awareness, Desire, Knowledge, Ability, Reinforcement), ADAPT (Awareness, Desire, Ability, Promotion, Transfer) , and Kotter’s “accelerators.” Each of these frameworks has a lot to recommend it. So why do I feel the need to develop a completely new framework, rather than just advising you to learn and use one of these existing change models?
As mentioned, there are gaps in these frameworks for an agile consultant. Cohn’s ADAPT framework gives a consultant a basic overview of the necessary conditions for an agile evolution. Cohn expands it beautifully in his book Succeeding with Agile, the essential work on the techniques of agile adoption. The elements of the ADAPT framework are not, however, addressed to the needs of a consultant, who must structure a commercial agreement that suits the client and sets up for a successful engagement. To evolve the enterprise, consultants must be sure they’ve set reasonable expectations in the client’s mind. We must know what the client is envisioning. We’ve got to explore the current state, and do a bit of due diligence, before we even engage. Is this a client you want to partner with on this complex and delicate transition, in a culture with which you can successfully engage? Can you do it yourself or do you need partners? What result are you responsible for, and to what is the client committing? What constitutes success?
This framework is certainly no original creation. I’ve shamelessly stolen those ideas that fit the consulting context from Cohn, Kotter, and others. We’ll discuss situations where, armed with Cohn’s book, I learned in practice what works and how to frame it. From consulting on large-scale acquisitions and organizational designs during my Big 5 days, and on agile projects now, I’ve encountered the persistence of history, legacy, and personality that makes change so challenging. I’ve incorporated elements from everything I’ve learned about organizational dynamics and change leadership, and brazenly arranged the concepts to fit my preordained EVOLVE acronym. My original contribution, if there is one, is to use these borrowed ideas fairly and wisely, from an agile mind-set, to incorporate my pragmatic experience, and to try to shift the conversation from team-focused practice adoption to enterprise-focused agile evolution.
We apply a framework because the complexity and sensitivity of agile evolution necessitates consulting discipline. Enterprise clients must know that we can engage strategically as well as tactically. They want to see an approach that indicates that the consultant has pondered their unique qualities, and thought through a tailored roadmap to their agility. Even if the move to agility is vigorously encouraged by senior management, sponsors of agile evolution projects want to know they’re partnering with a consulting professional who can negotiate, plan, and carry out a successful engagement. A framework is a marketing tool as well as a consulting tool. It illustrates that you’re credible, you’re experienced, and you know what works.
I want to make one important disclaimer: this is not by any means a “big, upfront plan” for “going agile.” As I hope I’ve clarified, engaging on this road with a client is an odyssey that will evolve and mutate as we’re experiencing it. There isn’t, and can’t be, a static plan for a dynamic engagement. This framework doesn’t predict anything, and it doesn’t promise any outcome but kaizen, the eternal search for perfection.
We’ll walk through the key ideas within each step of the EVOLVE framework (see Figure 3-1), and then I’ll expand on each concept in its own chapter. Of course, in the spirit of agile, I invite you to inspect and adapt. EVOLVE is just a convenient way for me to structure my ideas and experiences, and perhaps a way to encourage a bit of consulting discipline in the emerging field of enterprise agility.
Figure 3-1. The EVOLVE framework
What drives a sponsor, whether executive or information technology (IT) manager, to engage an agile change agent? The IT manager is experiencing pressure to deliver more innovation, more throughput, and more functionality, for more platforms. His teams are clamoring to try, or to expand, agile. The executive is in fear of, or already experiencing, digital disruption from innovative competitors. The business press is extolling the wonders of agility. In Kotter’s XLR8 1 and Denning’s Radical Management, 2 the agile ethic is applied to the enterprise. Their arguments, and the experiences they chronicle, are persuasive. In short, the belief is spreading that agility just might be a way to retain or advance their competitive advantage, customer responsiveness, and innovation. Whether focused on market position and financial metrics only, or sincerely striving toward a more humane, frictionless, adaptive workplace, executives understand that the impetus behind enterprise agility is growing and will soon be overwhelming .
When a client decides to engage an outside advisor, she’s already made a few admissions that may not be flattering. She’s accepted that she doesn’t have the inside resources to solve her problem, or that her leadership team can’t come to consensus on an approach. She may feel uneducated about agility and seeks an expert who can help her visualize an outcome. She may have concluded that her teams just can’t manage the change without a professional change agent, or she may just want the opinion of an objective outsider. Whatever the case, or combination thereof, an agile consultant must consider the situation and adapt the approach accordingly. An autocratic, hierarchical executive in a Control culture will have sharply differing concerns and expectations than the leader who has created a Collaborative culture, encouraging participation and valuing each individual. Those differing concerns and expectations will lead to a completely unique engagement and outcome for each.
Explore and Engage
This Explore and Engagestep in the EVOLVE framework prompts us to consider the personality of the sponsor and the organization. It reminds us that not all clients are good clients, and not all cultures are places we’d choose to work. It reminds us also of three fundamental rules of consulting:
Every client and engagement is unique.
Explore before you engage.
Engage judiciously.
Even when, early in the sales cycle, the client invites us in for an initial chat, we’re exploring all the elements: business context, enterprise and individual personality, culture, and atmosphere. As we’re advising the client on how to proceed, we’re incrementally observing every clue that might inform us of the best way to plan and execute this particular engagement. If the physician’s Hippocratic Oath is “First, do no harm,” then the consultant’s oath should be “Don’t prescribe before diagnosing.” Before we start to propose and negotiate an agile roadmap, we need to understand what we’re stepping into, and where the boundaries, taboos, and pitfalls might lay. As I’ve said, in an experimental, experiential engagement, we’d better consider the landscape we’re treading, and negotiate and engage with understanding and with clear expectations all around.
Visualize Success
Long before the debates on the definition of “done,” the skilled consultant learned that client expectations can be ambiguous, and that helping the client create a vision of a successful outcome is an essential practice. Experienced consultants know that organizational gravity is powerful, and that people have an emotional investment in their rank, their role, and their work. They’re invested in their culture, as they’re part of the community that built and sustains it. People and teams define themselves by their place in the enterprise, the enterprise provides them stability and solvency and reflects the common values and history that took them here. In short, enterprises have a powerful, organic inertia.
When we Visualize Success with the client, we’re preparing for agility in a number of ways. We’re clarifying what success looks like, and ensuring that consultant and client are anticipating the same process and outcome. We’re also helping the client develop a communication scheme that can be used to create momentum around agile evolution. Momentum is the opposite of inertia, and its only cure. The wise agile consultant will validate the client’s vision of agility, what it means, and its perceived benefits. For enterprise-level evolution, the prudent consultant begins to test the edges as early as possible, to determine how far on this journey he expects to go. He educates clients about the possible challenges and learnings they’ll encounter along the way. He helps the client craft a vision of agility that resonates with the enterprise strategy and culture.
Part of the consultant’s art is the ability to help the client communicate, educate, and reassure the enterprise community. I intend for Visualization to be an agile exercise, cascading through the organization, with sponsors initially participating to set the vision, and then opening participation to widening circles. I’ve called this Visualization step out separately because I believe it to be a critical predictor of success. If we can come to a common understanding of agility’s potential strategic impact, its iterative, exploratory nature, and the roles, commitments, and success criteria for all players, we’ve prepared for the agile transition. We’ve helped the client envision our agility roadmap, we’ve reassured the client that we can do this, and we've started the process of articulating an agile vision across the enterprise.
Observe and Plan
In our initial exploration, we’ve started to get a glimpse under the covers of our sponsor’s enterprise, but it’s only a glimpse. In order to plan the effort required to migrate an entire organization toward agility, it’s prudent for agile consultants to know as much as they can about the client’s business, culture, and challenges. We often start our engagements at the “grassroots” level, allowing us the chance to see these factors from the team’s perspective. These initial encounters are very revealing; in an iteration or two, we can start to expose the challenges inside the team, and the external obstacles of weak process, hierarchical management, and unhealthy culture.
Agile consultants have a complicated mix of responsibilities: training, coaching, mentoring, persuading, and executing. They have a complex mix of teams that they’re doing it with; from gung-ho coders to reluctant server teams within IT, radiating out to resistant accountants and busy executives. There may be teams of scrummasters already in-house who’ve developed practices that need refinement (to be polite). There may be a Project Management Office (PMO) that’s emotionally married to a complex systems development life cycle (SDLC) that it has developed over the years.
If we look back at Kotter’s accelerators , we see that once we’ve created a sense of urgency behind a “Big Opportunity,” which we should have started in our Visualization exercise, Kotter recommends we create a guiding coalition, and enlist a volunteer army. The observation and planning I recommend includes guiding the organization to empower a Product Owner as its key representative during the agile evolution. It includes determining what the role of any guiding coalition is: does it have veto power and decision rights, or is it a “cheering committee” of enthusiastic sponsors, or both? We’ll be orchestrating teams that are set up in a traditional project management PMO “resource pool,” or as a function-centered technology team, as they dissolve and reform to become agile teams. If we’re bringing in partners, or engaging with incumbents, we’ll need to figure out a mode of working that suits all parties .
The keys to observation and planning, in my experience, are transparency and discipline. Transparency is, of course, a central agile value, but I see it as a central consulting value as well. One of the reasons we were invited into the client’s house is because we’re objective. We’re not driving toward an agenda, as internal advisors might. As agile change agents, we’re enthusiastic and committed to agile ideas, but our role is not to implant our own vision. It’s, instead, to objectively advise and guide clients through the delivery of their vision, within their competence and will. That leads us to be transparent; to be honest, open, and truthful about triumphs, obstacles, successes, and failures. Transparency builds the trust that underlies any agile transition. When trust develops, the boundaries among teams start to evaporate and new forms can emerge.
Discipline is also key. As democratic and egalitarian as agile is, groups need leadership. If you’re lucky as an agile consultant, 95% of the leadership toward enterprise agility is coming from committed managers and volunteers. If you’re like the rest of us, you have to prod, goad, and then end up leading the communication program, the training program, and the hands-on coaching of teams across the enterprise. I’m disappointed to report that I’ve worked with agile change agents who fluttered from one training course to another planning poker session, with no overarching plan or program. This misinterprets agility; we’re not making it up as we go along. In my vision of agile consulting, we’re trying some stuff that we’ve seen work, such as good scrum practices, and adapting our techniques and expectations every day, as the enterprise stutters toward agility. The orchestration of forces to deliver agility requires trust, adaptability, and discipline.
Lead Teams to Agility
In 1993, Jon Katzenbach and Douglas Smith wrote the classic book on teamwork in business.3 Based on years of experience as a McKinsey consultant, Katzenbach, with his partner Smith, presented a set of six “team basics”:
Small number
Complementary skills
Common purpose
Common set of specific performance goals
Commonly agreed upon working approach
Mutual accountability
Katzenbach and Smith called teams that exhibited these characteristics “real teams.” Over 20 years later, I call them agile teams . The characteristics clearly coincide.
The small number theory has become the “two pizzas” idea popularized by Mike Cohn, or the “7 + / - 2” theory all agilists know, but the underlying concept remains. The communication and consensus overhead of large teams inhibits innovation and throughput. Complementary skills are aligned with cross-disciplinary teams and integration of Dev and Ops. Common purpose is now a vision statement, performance goals are now roadmaps, iterations, and valuable features. Scrum (or whatever practice you’ve chosen) is the common working approach. Mutual accountability is manifested in the big visible charts by which we measure ourselves and the kaizen manner in which we approach reflection and adaptation.
The performance indicators revealed in this classic text demonstrate that the team concepts within agile didn’t come out of nowhere, and that empirical observation proves these fundamentals are valid. At the team level, there are some well-known success factors that have been shown to improve results. The success of the agile movement has finally made these ideas, which seem the opposite of real life in the typical big company, accepted as “best practice.”
The results of teaming successfully and adaptively, from Katzenbach’s time to ours, are so strongly validated and so compelling that enterprises can’t resist. They also can’t do it alone, at least not yet. As agility migrates across levels, helping managers and executives understand, accept, and support these team concepts is an agile consultant’s big challenge. The team approach isn’t trivial in a single team of like-minded and like-dispositioned coders, but as we ascend the organizational ladder, motives become less transparent, and interests come to the fore. Guiding Dev and Ops to a continuous delivery cycle is tough enough. Getting sales and marketing to collaborate, or siloed division heads to team up cross-functionally, is a whole ‘nother thing. From agile organizational design, to team, tribe, and squad theories of teaming, the agile consultant will need to adaptively apply multiple, various team formations as she engages across the enterprise. Agile consultants at the enterprise level are engaged in multiple interdependent layers of disruption and change. The composition, objectives, styles, and expectations of development teams, operations teams, marketing teams, finance teams, risk-management teams, and executive teams will differ sharply, and the iterative process of advising, inspecting, and adapting these teams is demanding. We’ll outline the experience and knowledge required to successfully advise teams at every level.
Visible Results Now
It’s an axiom of change management that visible results encourage enthusiasm, engagement, and optimism. From Cohn’s ADAPT model to Kotter’s accelerators , the promotion of successes, large and small, is a key element of the transition process. Even without a sophisticated change model, most people know intuitively that “low-hanging fruit” is a metaphor for selecting some immediately achievable goals and demonstrating that we can actually produce results with a different approach. Any experienced consultant has bumped against the outer limits of culture, protocol, personality, and structure. As I gained experience as a consultant, I learned from painful experience that the generation of momentum is the primary sustaining element of change. Gravity, inertia, culture, or bureaucracy, whatever you call it, all advisors experience it, and all change agents must navigate it in pursuit of their goal. Their complexity expands exponentially with the size of the enterprise.
Luckily for agile consultants , our iterative, incremental approach to agile evolution is a great fit with the promotional concept. Based on our roots in IT, we typically start with development teams. When that atomic unit is working effectively, and producing observable results, we use all the venues at hand, from web sites to “lunch & learns” to posters and celebrations, to make those successes visible enterprise-wide. We augment that with leadership, putting those improvements in strategic context and underlining their business significance. We generate momentum by producing “potentially shippable code” (whatever the product) and collaborating with the entire enterprise to optimize the value of that product. I visualize a set of concentric circles, starting at the team level and radiating progressively outward, in which, at least within some individuals, we can plant a spark that encourages them to seek out agility and join the volunteers. This is the vision that inspires me to keep using the phrase agile evolutionrather than the popular transition or transformation. By succeeding at the team level, and evangelizing our success, we incrementally and organically evolve to our maximum agility. The momentum created by visible success is one of the emotional levers that energizes change.
I have a pet peeve in consulting; I hate “drive-by engagements.” A drive-by engagement occurs when a salesperson makes unreasonable promises, drops the project in a consultant’s lap, and drives away to the next victim. Drive-by engagements are often perpetrated by consultants themselves. I often see this in the “consultants” that are actually dedicated product implementers for a software provider. They come into the enterprise, configure a working instance of the software, train an administrator and a couple of users, and are gone. In consultant-led change programs , beginning the change effort is often relatively easy. The organization has already acknowledged a problem that it can’t fix itself, just by hiring you. Especially with agile, there’s usually a bottom-up groundswell of desire to participate. There are always volunteers so motivated by their contempt for the current circumstance that they’ll join the revolution. In agile, I’ve usually experienced more enthusiasm than resistance at the grassroots level. It’s in evolution and sustainment that the real heavy lifting emerges for the agile consultant.
I’ve mentioned earlier the tendency of “program of the month” efforts to succeed for a minute, based on leadership’s enthusiasm and staff’s compliance, and then to get dragged back by the infinite gravity of culture. But what actually occurs when programs fail? As a former (or reformed) Big 5 consultant, I’ve observed problems across the change spectrum from the initial idea, to the strategic meaning, through planning, implementation, and sustenance. Programs get initiated by a software salesman or a golf-course conversation. No connection is made to the strategic outcome. Plans are unrealistic, with big, upfront predictions and arbitrary schedules. Communication is weak. Implementation is sloppy and “drive-by.” These are all clear failure patterns.
But the most significant failure pattern in change initiatives, in my experience, is the failure to sustain. That’s why I hate drive-by consulting so much; it leaves clients unable to unlock the value they thought they were buying. By not implementing a sustainment program, they’ve doomed their product to grudging acceptance at best, or shelfware at worst. It’s our responsibility to ensure that the client understands the pull of inertia, and considers the long-term implications of sustaining disruptive change.
When the first agile team is successful, visible, and practicing kaizen, we’ve planted the first tiny seed. That seed sprouts when agility spreads to other teams. As agility propagates across the enterprise, experienced agile consultants can help the client foresee the elements of gravity that might pull the new practices into the black hole. By collaborating with the client to understand the unique circumstances within their enterprise, we can craft strategies that enable the organization to become self-sustaining and continuously improving. By inspiring agile ideals for quality, standards, craftsmanship, and value, we can aspire to guiding whole enterprises not just to gain agility but to keep it.
Summary
While there are many organizational change frameworks, none of them fits precisely the unique needs of a consultant guiding an enterprise to agility. We’ve looked at Kotter’s accelerators and Cohn’s ADAPT frameworks, and then walked through the EVOLVE framework that I’m proposing specifically for agile advisors. The evolution to agility is too complex and fraught to simply feel our way through; we need to apply a structured framework, based on mature consulting practices mingled with the principles of agile. We’ve taken a brief tour of the elements of the EVOLVE framework, as a roadmap of the topics we’ll address in subsequent chapters. The emphasis is on an adaptable, lean, and agile approach to agile consulting engagements, and on the idea that each engagement will be different and each enterprise requires a unique approach.
Footnotes
1 John P. Kotter, XLR8 (Accelerate!) (Boston: Harvard Business Review Press, 2014).
2 Stephen Denning, The Leader’s Guide to Radical Management: Reinventing the Workplace for the 21st Century (San Francisco: Jossey-Bass, 2010).
3 Jon R. Katzenbach and Douglas E. Smith, The Wisdom of Teams (Boston: Harvard Business School Press, 1993).