Consulting matters. Our advice, good or bad, can affect the future of clients, their companies, their employees and customers. Some consultants, such as doctors and lawyers, can, by their advice, instigate reprieve or catastrophe. Mentors and managers are advisors, as are our peers and colleagues. Although we give and receive advice all day, the professional consultant has a unique responsibility. As a paid advisor, the consultant is ethically bound to focus on the client’s best interest. The best consultants have the domain expertise and creativity to add value, the temperament to advise gracefully, the relationship skills to collaborate and guide, and the tenacity to adapt to the client and accept their boundaries. Clients of consultants expect more than counsel; they want us to implement the ideas we’ve proposed, and to be accountable for the business results we promised.
When I envision an agile consultant, I see a consultant with the experience, mature skills, and agile domain expertise to guide a client’s evolution toward enterprise agility. He’s seen agile adoptions from the inside, and experienced the tensions inherent in the migration process. He’s run into some of the roadblocks of organizational culture and politics, and he’s made the transition from predictive thinking and embraced the values of adaptation and self-direction. He’s fallen into traps, from the team to the enterprise level, and has figured his way out of them. He’s aware of the evolving theories of agile, from SAFe to tribes, and is thoughtful but enthusiastic about applying promising new practices with his clients.
All of this agile experience and domain expertise, however, is essential but not sufficient. The participative, cross-functional, egalitarian instincts of agile require much more personal interaction than the old “expert from out of town” advisory style. At the team level, for example, modeling the right level of neutrality as a facilitator is critical to educating your team about collaborative behavior. At the management level, the ability to translate unfamiliar agile concepts into accessible, business-oriented language is more important than your mastery of story-point estimation. At the executive level, a strategic conversation about the competitive benefits of organizational agility will go farther than an explanation of the Agile Manifesto. The consultative skills that you can deploy in the face of conflict, resistance, failure, and reflection are more critical for success than is domain knowledge. Your ability to set the bar high, create a collaborative, performance-oriented team atmosphere with a sense of purpose and achievement, while keeping everyone’s eyes on the business prize, will determine your success as an agile advisor.
Agile consultants are engaged in the intimate daily flow of human relationships, biases, feuds, and triumphs. We uncover broken team and enterprise dynamics that have been swept under the rug forever. We raise expectations of achievement, and of the joy of work, for individuals, teams, and companies. Agile consultants are introducing methods designed to disturb the status quo. We’re not delivering a routine consulting project to “migrate the client to agile”; we’re unleashing a revolution in the client’s house. Then we must guide clients to accept, embrace, and finally capitalize on that revolution. As a kaizen1 practice, agile evolution has no end but the unattainable, perfection. The expectations we set, the skills and experiences we bring, the humility with which we approach the client’s culture and history, our empathy for those whose stability we’ve disrupted—these account for success. Agile domain expertise is expected. Mature consulting skills, the ability to guide an agile evolution that fits, and sticks, are rare and precious.
I’m also visualizing a consultant who applies an agile business model in her own consulting practice, building an iterative, experiential relationship with clients accustomed to “firm fixed price, scope, and schedule” contracts. As we’ll see, the traditional consulting model is unsuited for agile evolution, and may be obsolete for any type of consulting engagement. The forces of digital disruption and lean thinking have swept over every sector, and the consulting business is not immune.
Agile Changes Consulting
Agile is both simple and complex. It’s simple in that the basic practices of scrum or XP can be taught in a day. Simplicity is inherent in the agile principles. “Maximizing the amount of work not done” is one of the most elegant statements of lean philosophy I’ve encountered. It’s complex, however, because it’s designed to disrupt assumptions, processes, relationships, and hierarchies that are built to avoid disruption. Achieving the level of agility required to simplify our work is a complex endeavor.
Consulting is also both simple and complex. The five-step process used by consultants, whether doctor, lawyer, or architect, has been the same for centuries:
Understand the current state.
Define the desired state.
Analyze the gap.
Recommend a plan of action to address the gap.
Implement and monitor the plan.
This simple list of steps, however, contains multitudes. Understanding the current state can involve a quick walkthrough of a department, a month of interviews and surveys, or a year of due diligence. Defining the desired state is especially difficult when the aim is agility. The goal, as in all lean, kaizen exercises, is perfection through continuous reflection and improvement. It’s a goal, like speed-of-light travel, that becomes increasingly elusive the closer we approach. Gap analysis is also a challenge in an agile transition, when many of the gaps don’t become apparent until agile adoption begins and roadblocks start to emerge. Recommending a plan of action to proceed in an agile transition is also an emergent task. At each evolutionary stage in our agile expedition, the recommendations must change based on our experiences so far. We can perhaps overlay a map that points us to previously worn paths, but each voyage is distinct.
The traditional consulting engagement model , it seems, has been disrupted. The simple five-step approach outlined previously, used by Hippocrates with his first patient and by your doctor yesterday, is another victim of the “creative destruction” of the agile model. Once we abandon the predictive, big-upfront-plan approach to project management and software development, we see that it also has to go in the agile consulting world. As agile consultants, we are essentially contracting to undertake an experimental, experiential quest with our client to discover together how far toward agility their collective awareness, desire, and will can take them. We only learn their agile limit by trial and error. In agile evolution, when you push the boundary, the boundary pushes back.
The traditional consulting business model , at least at the top tier, isn’t designed for speed-to-value. It’s designed for lengthy, entrenched projects that intersperse a few veterans with legions of profitable rookies, and for which the firm then sells lucrative maintenance contracts, or extracts retainers, to sustain the changes they implemented. The fad-driven “program of the month” mentality, which now threatens agile, has demonstrated its bankruptcy, as the majority of Total Quality Management (TQM) and Business Process Reengineering (BPR) enterprises slide back into old cultural norms. The “scope extension” sales philosophy, in which every consultant is an inside spy, eavesdropping in the cafeteria seeking the next problem the firm can swoop in and solve, is deadly to trust in the consultative relationship.
If the sponsor is aware of both the potential for agile and the risks of his current circumstances, wants to change and understands the disruption involved, and has the will to adapt both himself and the culture around him, you’ve walked into the ideal scenario for a successful agile evolution. Good luck finding that guy. Even if you successfully discover this perfect, willing candidate, the evolution to enterprise agility is monumental. In the ideal scenario described earlier, with a willing client, the contracting phase alone can be daunting. Whether or not the CEO wants to “go agile,” the procurement agent wants a signed scope of work. Training your sponsors to support and enforce corporate acceptance of an iterative, pay-as-you-go engagement with an ambiguous outcome is often an obstacle before you even engage. In our humanistic, participative agile world, every element of agile transition is negotiable by anyone in the conversation. The most mature consultant, with superior facilitation, communication, influencing, and coaching skills, will have his hands full, even with this ideal sponsor.
Now consider the other end of the client spectrum. Our executive sponsor has read a Harvard Business Review article on agility, heard her chief information officer (CIO) mention it a few times, and thinks of it as a software process improvement project. She’s OK with trying it out in a “swat team” within the development group but still thinks the Project Management Office (PMO) should manage all projects, wants to see a project plan before she’ll approve any expenditures, and still wants her quarterly strategic plan and budget from information technology (IT). The culture is an extension of her personality, which values stability and predictability over innovation and change. She’s granted limited access to her best and brightest coders for this “pilot test” of agile adoption.
In each of these circumstances, the key success attribute of the agile consultant is adaptability. The boundaries will obviously differ vastly between the scenarios, and will require both the sensitivity to understand them and the tenacity to challenge them. The consultant, in either case, is called upon to learn a new culture, a new business scenario, and a new set of personalities. None of that should be new to any advisor. The understanding that each engagement is unique comes early to an alert consultant.
What’s different is that we now have to revamp the traditional engagement model entirely. The big-scope consulting project, with a defined beginning and end, finely negotiated deliverables, and a tightly managed change control process, necessarily must give way to an iterative, collaborative, time-bound and change-ready engagement (perhaps serially extended) that delivers value throughout. The agile consultant is committing to a series of time-boxed value deliveries, rather than a 12-month study that produces a report. The value we deliver in early iterations may be only the first sparks of enlightenment, but when we can demonstrate progress, the spread of agile principles will become self-reinforcing.
The cornerstone of an effective consultative relationship in the agile world is honesty, openness, and trust. The agile consulting model is less predictive, less prescriptive, and more evolutionary. The current state, future state, gaps, and plans are acknowledged as unknowable until the engagement is underway. These things were always obscure; just because we called it predictive planning doesn’t mean it actually predicted anything. Agile is reality-based, and we encounter and adapt to reality by living it. The incremental model of consulting, both for agile transition clients and for our traditional consulting clients, is the disruptive idea that must inevitably replace the traditional leveraged, predictive, eternal entrenchment model of the Big 5 (or 4, or 3, or however many are left).
The nature of the engagement does not have to change radically. It just becomes atomized. That big-bang, omnibus fixed-scope project now becomes a series of collaborative experiments, time-bound and targeted, in which you and the client will discover how agile ideas affect the enterprise. Many consultants are already familiar with the “discovery first” business model, in which the consultant charges a fee to perform some minimal due diligence, before committing to planning and delivery. Agile consultants are offering a series of discovery projects, typically expanding concentrically from the team to the team-of-teams, then incrementally through the enterprise. We’re promising to apply our skills and experience to guide teams to agility; how their existing competencies, attitudes, and practices will adapt is unknown. Successful agile consultants start their engagements with the explicit mutual understanding that they are guides, not project managers, and their role is advising and mentoring, not enforcing process compliance. The agile consultant’s key commercial challenge is ensuring that the client grasps the concept of variable scope. No coach or consultant can promise to “make you agile,” especially in one iteration or “pilot.” There are too many uncontrolled variables.
If we can’t promise “agility in a box,” what is our promise? We’re committing to the client that we actually have the agile domain experience and expertise we claim. We’re committing that we’re coming to the engagement “pure,” not trying to make ourselves indispensable and eternal but instead dedicated to using our domain knowledge and consultative skills to bring agility to their enterprise and make it self-sustainable. We’re committing that we’ll engage collaboratively, that we’ll meet them where they are and help them adapt from there. We’re committing that we’ll view their agile evolution strategically, and ensure that our pursuit of agility is tightly coupled with the pursuit of their competitive goals. Most important, we’re committing to embody the agile principles and to be a role model of the adaptable, humanistic, purposeful, and collaborative spirit that epitomizes the agile enterprise.
Agile Consulting Principles
When I wrote my first book2 back in 1999, the predictive planning model for project management and consulting engagements was still the norm. At that time, I formulated a list of five fundamental ideas that, I felt, were the necessary underpinnings of any consultative relationship. Going back to them now, I’m proud to report that I believe they are still applicable in the agile world; in, fact, I’ll make the argument that they are more pertinent than ever. Let me reveal those five fundamental ideas of consulting I put forth in 1999:
Focus on the relationship.
Clearly define your role.
Visualize success.
You advise, they decide.
Be oriented toward results.
These principles clearly did not address technical issues back then, and they don’t now. Instead they help define the consulting relationship you establish with your client, the clarity of expectations, the definition of “done,” the collaborative nature of the relationship, the client’s right to accept or reject your advice, and the orientation toward delivering value, not just white papers and migration plans.
I’ll walk through these ideas and describe why I believe that, unknowingly, I was articulating some agile principles in my recommended approach to the client.
Focus on the Relationship
The relationship element is critical in any advisory relationship, since trust is the first prerequisite for advising and being advised. In my Big 5 days, the key relationship was often with a solitary executive, who commissioned a report or program, with everyone else a spectator or, at best, a “stakeholder.” The intimate nature of agile consulting, on the other hand, broadens our scope of relationships to every team and individual we touch in the process of agile evolution. This makes relationship cultivation central to agile consulting. We’re not just interviewing and commenting on the behavior of teams, or making remote suggestions for improvement, like consultants of old. We’re in the daily working life of our teams, making independent relationships with team members, managers, customers, and executives. More to the point, we’re hands-on in helping change their behaviors, attitudes, and methods. The traits we typically display in a personal relationship, like empathy, patience, and respect, will be tested in an agile consulting relationship. Any consultant lacking the relationship focus and skills, the “emotional intelligence,” to develop collaborative and productive connections will struggle as an agile advisor.
Clearly Define your Role
The advisory relationship is always ambiguous. That’s why traditional consultants spend so much energy on writing pinpoint scope documents. The fear of implied expectations, role confusion, and scope creep made documenting the commitments of both client and consultant essential. Clients can imply all sorts of commitments and expectations. As I said in 1999, some clients believe that if you recommend a $99 accounting package, you’re bound for life to rectify any bugs, act as the go-between with the software publisher, and build any reports they need. The chain of implied expectations applies equally to agile, where the end state is ambiguous and roles are emergent. What do you mean, the team’s not ready for continuous integration . . . we’ve been at this agile thing for three months already !
In the collaborative atmosphere of agile consulting, where the participation of the client and the upholding of commitments is vital, the importance of role clarity is magnified. Agile evolution isn’t a project that a consultant can “go do”; it is by its nature a collaborative exercise that loses all meaning if the players don’t understand and commit to their roles. In fact, a large part of the agile consultant’s challenge is to help teams and individuals clarify and understand their new roles in a new world. This is not to say that we can determine these roles upfront. The true scrummaster in a rookie agile enterprise should arise spontaneously, not by a manager pointing to someone. At the least, as mentioned earlier, the consultant must ensure that the client understands we’re not peddling “agile in a box” but rather a mutual expedition of discovery toward their maximum agility.
Visualize Success
As I’ve watched agile theory evolve since the Agile Manifesto, I’ve seen the debate around “the definition of done” increase exponentially. I’ve witnessed arcane arguments about “done” versus “done, done” versus “done, done, done.” If we accept the premise that agile product development, software or otherwise, is not a project, in that it has no end that can be defined at the beginning, then clear agreement about what we call complete is mandatory. The debate about the definition of done may have become extreme, but the importance of defining it, especially in a paid consultant arrangement, is fundamental.
The visualization of success is, to me, a humanization of the quest for a definition of done. Rather than a big, upfront specification that defines success criteria, we now need to help the client visualize a high-level roadmap that illustrates, in business language, how the disparate efforts or workstreams come together in a cohesive scenario that supports the business strategy. The “vision box” exercise that Jim Highsmith recommends3 is great for the team that’s trying to define priorities and overall feature mix, but my experience is that managers prefer a roadmap conversation that concentrates on strategic alignment, timing, and budgeting, one that helps them plan marketing, sales, and fulfillment campaigns.
Visualization of potential outcomes through roadmap planning is a powerful tool in the agile arsenal, but, in the consulting relationship, it’s fraught with risk. The agile consultant’s challenge is to present a possible future scenario, based on what’s now known, and not have it turn into the dreaded “fixed firm scope” project executives naturally favor. Before the enterprise has embraced or internalized agile, the tendency toward predictability and artificial certainty will be powerfully ingrained. Agile consultants who help their sponsors understand the inevitable uncertainties and unknowns, and help them grasp the concept of emergent development, are more likely to succeed at visualization than those who confront a command-and-control culture with an ambiguous and variable roadmap.
Visualization is also about articulating the big idea that we’re evolving toward. In agile evolutions, where the creation of momentum and enthusiasm is a success factor, the clarity and persuasiveness of the driving vision are key. Our message must speak to the fears and concerns of the teams, as well as the glorious future that awaits. The time to begin thinking about the enterprise communication and promotion strategy is at the beginning. The vision, roadmap, and our evangelizing should all send a consistent message: change is hard, what we’re attempting is hard, we acknowledge that we’re disrupting time-honored practices, but others have succeeded, and we can do this together and unleash creative power within the enterprise, to work with less friction and achieve more than we ever believed possible.
You Advise, they Decide
Consultants learn early in their careers that client ownership of the proposed solution determines project success or failure. Every veteran has experienced the “your idea” syndrome, when the inevitable delays and unknowns impact the project, and the client intones those famous words. If you, as a consultant, are in the position of having the customer tell you that this was “your recommendation” and you therefore are responsible for its success and risks, you’re doing it wrong.
Even before the collaborative ethic that imbues agile was pervasive, client ownership of the solution and vision was critical. The advisor advises; the advised considers, then decides. The decision process can’t be outsourced, and client attempts to turn consultants into “blame agents” must be resisted. We can explore options, describe the implications of choosing one direction or another, and anecdotally advise the client, if it were me, I’d . . ., but once that’s done, the client, and the enterprise, must resolve to take a particular course and own that decision. As outside advisors, we bring many advantages; we can apply the experience of all the other clients we’ve worked with, cultures we’ve seen, and roadblocks and enablers we’ve encountered. From our vantage point, outside the prevailing culture and with “no dog in the fight,” we can unstick problems, often with simple solutions that are apparent to the unbiased eye. However, even if the solution is obvious to us, we need to take the client and her teams there, facilitating them to make the right decisions themselves, and to own them.
For agile consultants, in an emergent and evolving organization that we’re guiding through change and disruption, the client’s ownership of the decision process must be explicit. Both agile transitions and the projects that agile teams undertake must have a product owner, the keeper of the strategic flame, of the priorities, and of the decisions and trade-offs that accompany any effort. We are unambiguously coaches and advisors, working with the environment and competencies we find. As we incrementally expand the breadth of agile within the organization, we should also be expanding the ownership and enthusiasm. The natural scrummaster becomes a natural coach, who mentors more scrummasters who coach in turn. As Sun Tsu said in The Art of War, “A leader is best when people barely know he exists. When his work is done, his aim fulfilled, they will say: we did it ourselves.”
Be Oriented Toward Results
The connection between this principle and the value-driven nature of agile is obvious. The value ethic of agile requires us to stop measuring success based on documents produced, or steps followed, or tasks performed, or milestones reached. At each iteration, we commit to delivering a result that could potentially be released. It has working features that bring value. It can be both subjectively and objectively evaluated. While this may be a stretch when the project is an agile evolution, the ethic remains; agile consultants deliver value incrementally, and can demonstrate that value to their sponsors. Measuring progress in collaboration and purpose may be more difficult than in a software project , but as agilists ourselves, we maintain agile’s value focus when we expand the cycle of enhanced creativity, collaboration, adaptation, and enthusiasm that successful agile evolutions experience.
Agile Change Models
Michael Sahota, in his widely read Survival Guide,4 said
Let us consider the question of the skill level Agile change agents have in “helping organizations with Agile.. I make the assertion that the vast majority of Agile change agents are at the accidental [lowest skill] level. The key reasons are:
Failure to understand Agile as a system of culture and values
Failure to understand the disruptive power of Agile in general and Scrum in particular
Not understanding the difference between adoption and transformation
Often no explicit adoption or transformation framework
Weak or mis-alignment with management goals and objectives
As we’ve discussed, agile is a set of values, not a set of practices. It’s a culture, not a methodology. We’ve also emphasized the disruptive nature of agile, both practice and culture. Doing agile and being agile, as we’ve discussed, are two different things. And the clash of agile with current strategic planning methods, and indeed with big, upfront strategic plans themselves, should be obvious.
The lack of an adoption or transformation framework, however, is of real concern to the agile consultant. We may understand that we’re embarking on an iterative, experimental voyage with the client, but we still can benefit from some structure around the engagement. No client will, and no consultant should, embark on an agile engagement without some guiding framework, in my experience.
For instance, Mike Cohn, in his Succeeding with Agile, 5 recommends an adoption framework based on the acronym ADAPT :
Awareness that the current process is not delivering acceptable results.
Desire to adopt Scrum as a way to address current problems.
Ability to succeed with Scrum.
Promotion of Scrum through sharing experiences so that we remember and others can see our successes.
Transfer of the implications of using Scrum throughout the company.
Cohn’s framework, an adaptation of the ADKAR6 model , has great applicability in defining the elements that must be in place for agile adoption in a scrum-based environment. For consultants, it presents a stepwise series of symptoms that we can look for, or encourage, within the client organization. Based on extensive ADKAR research, this sort of framework has rich academic credentials as a barometer of change readiness, and as a set of goals to achieve for change to self-sustain.
Twenty years ago, Harvard Professor John Kotter performed a study of change in the enterprise. 7 Kotter proposed an eight-step model that, based on his team’s studies, was the most successfully path to sustained organizational change. His eight-step model 20 years ago was:
Establishing a Sense of Urgency.
Forming a powerful Guiding Coalition
Creating a Vision
Communicating the Vision
Empowering Others to Act on the Vision
Planning for and Creating Short-Term Wins
Consolidating Improvements and Producing Still More Change
Institutionalizing New Approaches
It goes without saying that each of these steps had significant detail behind it, which I’ll not try to expand upon here, as there are great references available online,8 or in Kotter’s book itself.
I’d prefer to concentrate on Kotter’s recently revised eight-step model , from his new book XLR8, 9 which is much more aligned with an agile viewpoint. The original model, for example, took a phase-gated approach—you could only move on to the next step once the current step was complete. The new model, in contrast, is concurrent; multiple steps are incrementally advanced as organizational readiness increases. Twenty years ago, Kotter’s model was focused on a core group of leaders selected from the hierarchy to drive change linearly; the new model focuses on a cross-functional network of enthusiastic volunteers, jumping on new opportunities and capitalizing on them quickly. For those agile consultants who begin their engagement at the strategic level, with a powerful sponsor who grasps the risks and benefits, and can mobilize the organization, Kotter’s new “accelerators” of change can be a powerful renewal engine. It’s demanding and radical, however, expecting much of the organization and its leadership. Agile consultants who, due to their assessment of the culture they’ve walked into, choose to take a more bottom-up, adoption-based approach won’t have much immediate use for a complex organizational model like Kotter’s. For those agile consultants who have the privilege of partnering with determined leaders pursuing a guiding vision of enterprise agility, however, Kotter’s accelerators are potent.
Kotter’s accelerators haven’t changed that much from 20 years ago, but their intent is completely different, thanks to the inroads of agile thinking.
Create a Sense of Urgency
Kotter emphasizes the development of a big, guiding idea that generates momentum and enthusiasm, which he terms the Big Opportunity. In our case, of course, the big opportunity is agility in the enterprise. Our challenge as consultants is to help the organization frame a compelling “burning platform” that creates the urgency required to counter organizational inertia. We’ll discuss in later chapters the disruptive challenges that are driving enterprises to seek agility.
Build a Guiding Coalition
In contrast to the hierarchical, executive-focused coalition that Kotter originally recommended, this new coalition is cross-discipline, cross-function, and cross-rank. All players are equal in this more participative, “swarm” consortium. This idea is congruent with one spread by Ken Schwaber10 about the creation of an Enterprise Transition Team, itself a scrum team that manages the enterprise transition iteratively.
Form a Strategic Vision and Initiatives
We commonly talk of the capital-v Vision statement in the agile community. Many of the original agile thinkers wrote extensively about different practices that teams could use to develop a guiding vision. While visualizing the glorious future state is essential, Kotter’s insistence on initiatives to move it forward differentiates it. It’s not just a vision we’re creating here, it’s a plan to achieve that vision through a specific portfolio of actions.
Enlist a Volunteer Army
In most development-centric organizations, finding a team of volunteers for agile adoption is not challenging. Those who have not transitioned usually want to, with a vengeance. Finding volunteers, however, among the concentric circles that surround the development team is the challenge. As agile practices in development teams create pressures in IT operations, which then roils outward toward marketing and fulfillment, our need to keep seeding the army of volunteers becomes more urgent, and more difficult. The ability of an agile consultant to work with the guiding coalition to keep the momentum going is a predictor of success.
Enable Action by Removing Barriers
Removing barriers, of course, is a lean and agile core principle. It’s also a phrase that simplifies an extraordinarily complex idea. Every process, every human being, every historical artifact and cultural norm within any enterprise can be an obstacle to progress. As we’ve said before, when you push the envelope in agile evolution, the envelope pushes back. Existing processes and behaviors that have grown over years don’t get obliterated in an instant. The removal of barriers is a key scrummaster competency. At that level, we’re often discussing tactical barriers, like I can’t finish this until she does that. At the enterprise level, removal of barriers is often a miracle of persuasion, desire, and will.
Generate Short-Term Wins
Again, this step is clearly in line with the agile principle of iterative value delivery. The celebration and visibility aspects are emphasized in Kotter’s method. The visibility of short-term wins also appears, as Promotion, in Mike Cohn’s ADAPT framework. The importance of visible progress in the creation of momentum is obvious. If the teams, and the entire enterprise, couldn’t see incremental success and progress, why would they continue?
Sustain Acceleration
Sustainment of change is the hardest part, as the many failed adopters of TQM , BPR , and Enterprise Resource Planning (ERP) can testify. A resourceful leader can often generate enthusiasm and momentum toward a goal, and a horde of eager volunteers can adopt it with vigor. As change begins to penetrate the further layers of the institutional onion, embedded processes and cultural norms produce added friction. Whether you prefer the rubber band metaphor, in which culture is a rubber band that pulls rogue elements back into compliance, or the gravity theory, which proposes that organizational inertia is a natural force that can’t be reversed, one thing is true: Culture eats strategy for breakfast. The agile consultant who can stretch his capabilities and guide clients to sustainable agility is truly having strategic impact.
Institute Change
The crowning step of the consultant’s art is the ability to institutionalize change so that it, in turn, becomes the new “personality of the organization.” Advising leaders on the mechanisms of communication, participative leadership, agile strategic planning, and operational dexterity is the summit of the agile consultant’s achievement, and will take the summit of his efforts. The ability to guide a client through the disruptive process of agile evolution, and to see that enterprise embrace new values, live new ideals, and inculcate those ideals in its rookies and veterans, is an achievement worth celebrating.
Both Cohn’s and Kotter’s change frameworks have much to teach agile consultants, whether we’re guiding the adoption of scrum practices within a team or driving an enterprise transition. Approaching a client engagement in a structured and orderly manner is a sign of professionalism. It reassures nervous clients that they’re in competent hands. Agile consultants don’t want to validate the negative view of agility, that it’s just an excuse to make it up as we go along. We, instead, want to demonstrate that even though agile is iterative and experimental, we can approach its adoption and evolution in a disciplined way.
I’m humbled by the insight and real-world experience that both Cohn and Kotter have built into their change frameworks. Humbled, but not satisfied. I’m not satisfied because, as an agile consultant, they both have flaws for me. Cohn’s ADAPT method , apart from its scrum specificity, seems to be addressed to inside change agents. It’s not the consultant’s Awareness that needs to be raised but the enterprise’s and its leaders’. Similarly, the other elements of Cohn’s approach are necessary conditions for agility, but not a prescription to take the client there. Kotter’s model, while a bit more amenable to the outside advisor, makes the assumption that change starts at the top, and not until multiple steps into the model do we engage the actual teams in our volunteer army. In addition, neither of these models takes any account of the engagement model that consultants must apply from a commercial perspective. The first step for us isn’t the awareness of the client or the creation of a sense of urgency, (although those things can be part of our sales strategy). First we must get engaged to do the work. We’re essentially contractors, and our framework needs to acknowledge that fact. Our risks and concerns are different from those of the inside coach or agile leader. We have to ensure that the client understands and accepts our proposed approach, that we’ve defined what “done” means, and agree on the terms of our relationship. In short, agile consultants need a different change model, one that suits our special circumstances.
As we progress, I’ll introduce my EVOLVE consulting framework , which, I believe, takes the core elements of the transition frameworks we’ve discussed and adapts them to the specific concerns of the agile consultant. Before we explore that framework, however, let’s examine some of the challenges of dealing with existing culture in agile evolutions.
Summary
The agile consultant requires a unique combination of skills. Expertise in the agile domain, is, of course, critical, but the consultative skills of facilitation, negotiation, and persuasion are also key. Agile consultants, unlike many agile coaches, engage at the enterprise level, and so they need the capability to understand the business and strategic context in which agility is being implemented. Agile consultants must be able to navigate conflict, resistance, and individual agendas to be effective.
Agility has changed many industries, and the consulting business has changed as well. The big, upfront plans of traditional project management are becoming obsolete, which means that the big, upfront consulting contracts, with their fixed fees, fixed scope, and fixed schedule, must be replaced by a more agile engagement model.
There are many similarities between the principles of good consulting and those of agile consulting. These principles, however, must be adapted to the agile world and mind-set. We’ve reviewed some attributes of mature consultative behavior and noted how they must be adapted to the agile environment.
Finally, we examined organizational change models, like Mike Cohn’s ADAPT framework and John Kotter’s XLR8 model , and seen how they can aid in evolving an organization, and some areas where they are insufficient for an agile consultant engaging to remake the enterprise. We mentioned the EVOLVE agile consulting framework, and we’ll dig into the components of that framework beginning in Chapter 3.
Footnotes
1 Gradual, continuous improvement.
2 Rick Freedman, The IT Consultant: A Commonsense Framework for Managing the Client Relationship (San Francisco; Jossey-Bass/Pfeiffer, 2000). Available at: www.amazon.com/Rick-Freedman/e/B000APKF5U/ref=dp_byline_cont_book_1.
3 Jim Highsmith, Agile Project Management: Creating Innovative Products, Second Edition (Addison-Wesley Professional; 2 edition (July 20, 2009)). Available at: www.amazon.com/Agile-Project-Management-Creating-Innovative/dp/0321658396/ref=sr_1_1?s=books&ie=UTF8&qid=1447619469&sr=1-1&keywords=agile+project+management+highsmith.
4 Michael Sahota, An Agile Adoption and Transformation Survival Guide: Working with Organizational Culture (InfoQ, 2012). Available at: https://www.infoq.com/minibooks/agile-adoption-transformation .
5 Mike Cohn, Succeeding with Agile: Software Development Using Scrum (Boston: Addison-Wesley, 2010).
6 Awareness, Desire, Knowledge, Ability, Reinforcement.
7 John P. Kotter, Leading Change (Boston: Harvard Business Review Press, 1996).
10 Ken Schwaber, The Enterprise and Scrum (Redmond, WA: Microsoft Press, 2007).