Over a million developers have joined DZone.

How Agility Changes Consulting

DZone 's Guide to

How Agility Changes Consulting

Agile consultants use the same basic rules as other consultants, but being agile requires a different way of following them.

· Agile Zone ·
Free Resource

Consulting is both simple and complex. The 5-step process used by consultants, whether doctor, lawyer, or architect, has been the same for centuries:

  1. Understand the current state
  2. Define the desired state
  3. Analyze the gap
  4. Recommend a plan of action to address the gap
  5. 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 5-step approach outlined above, 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-up-front-plan approach to project management and software development, we see that it also has to go in the agile consulting world.  To be agile consultants, we’re contracting to undertake an experimental, experiential quest with our client to discover together how far towards agility their collective awareness, desire, and will can take them. We only learn their agile limit by trial and error.

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 TQM and 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 above, 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 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 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 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 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 twelve 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.

consulting ,agile coaching ,agile management ,agile organization

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}