Twenty Top Fails in Executive Agile Leadership [Part 1]

“Most executives, many scientists, and almost all business school graduates believe that if you analyze data, this will give you new ideas. Unfortunately, this belief is totally wrong. The mind can only see what it is prepared to see.” - Edward de Bono

If you are ever hired as an agile coach, it's quite likely that the importance of the engagement will be impressed upon you from the outset. That's certainly been my experience, anyway. I've never been recruited for a gig which was described to me as being trivial. Why is this the case, though? Are chief executives looking at their charts and numbers and saying "There's only one thing for it, we'll have to bring $$anonymous$$ in"? Am I a high-rolling celebrity coach who only gets top-level contracts? It would be nice to imagine so. However, my accountant, at least, I am sure, has reason to suspect that this might not be true.

Rather, it's much more likely that when an organization is stressed, the pressures end up being applied to an external locus—namely the coach being hired to provide remedy. As a new and perhaps unknown quantity, all sorts of characteristics can be imagined onto a coach's blank dial before he or she arrives. Some may see you as a force to be channelled and directed against their cankered enemies, given that a powerful and mysterious magic will be heralded by your dawn. Get a good agile coach on board, it is often assumed, and new wonders will begin. Things will become faster and cheaper. The agile coach will bring change and make others see reason. Just watch!

Of course things don't quite pan out that way. Unless you have your own issues, you’ll recognize that no transformative magic can ever be radiated by your mere presence. You'll know that people have to want change, to realize that it affects them, and that sponsorship for engagement with a coach must be communicated and reinforced from the very top. Unfortunately, this can also present a significant problem. The difficulties may become apparent in the first meeting you have on a client site. To understand why, let's review the direction an initial rencontre avec eux might actually take.

“I hope you realize just how important this agile coaching initiative really is," you are informed with gravitas. "There's a lot riding on it. It's big, urgent, and critical to the future of the company.”

“Fine," you reply. "Let's get a meeting with the CEO into the diary. That’s who’ll have to sponsor the deep and pervasive organizational change which will be required.”

“Ah...um...well...”

You see, what often happens is that the supposed scale, importance and urgency of the challenge is passed onto the coach. The agile transformation initiative is handled like any other—through delegation. What isn't realized is that there's precious little an agile coach can do with exhortations such as this, no matter how gravely they are intoned. The coach does not have a hand-cranked transformation machine which can be turned any harder or faster. The constraints which inhibit change are much more likely to be found within the organization itself and across its serried departments, cultural assumptions, and established practices. That's why a good coach will value executive sponsorship and be keen to secure it. Anything less is likely to result in drift and delay, and the exposing of impediments which will stagnate unresolved. There may be local optimizations to scrabble for which can be worthwhile, and a window of transparency over critical issues and dependencies can certainly be put in place. At a strategic level though, the gains will be poor and it is unlikely that the high expectations will be met.

The simple fact is that responsibility for enterprise change cannot be delegated away to subordinates and hirelings. Senior executives are accountable for what happens, and they must be careful and keen to engage with any party who would help revise the model through which the organization delivers value. Yet so often they are conspicuous only by their absence, and by an unmet need for clear executive authority which only they can provide. It is their middle managers, and not coaches, who are served and who presently make decisions on what the disempowered should do. Ironically, these can be the people whose interests are most likely to be vested in the status quo. They've been there for years and know how to work the system and exploit its foibles. If a coach tries to make a connection with the senior higher-ups in order to explain and resolve an organizational impediment, mid-tier managers are likely to intervene and put a stop to the attempt or otherwise contain it. The organization’s officers act so that control of access-to-power is reasserted through the hierarchy. At times, hunting down a true executive sponsor for a supposed agile transformation can seem like an episode of the X-Files. As soon as a coach gets close to what might be the truth, the Men In Black appear, complete with smart suits, a threatening robotic manner, and dire warnings of how important it is to back off and take things no further.

The risks presented by weak executive sponsorship are great. A company does not typically stop in order to transform, and enterprise change must happen while an organization is in flight. Ultimately it is senior managers, and not the coach, who will be accountable for the success of the endeavor. So now let's examine some of the more common failure modes which executives demonstrate when abdicating their agile leadership responsibilities.

Fail #1. Not Recognizing the Immediate Significance of Organizational Culture

These days pretty much every chief executive talks about becoming agile. For the most part, they would genuinely like to think of themselves and their people as being able to work in this way. However, the executive view of their organization is cast through the lens of their immediate reports, filters, and barriers to access. This is the domain where the "frozen middle" hold sway. Any assessment of cultural impediments to agile practice will therefore pass through and be shaped by the system itself. The information they receive about the organization will be inherently self-referential and objectively blurred and distorted. Yet through this intelligence executives hope to redefine value streams and portfolios and roles, and to discern a strategic agile policy. They wish for a telescope to see further and are handed a milk bottle to look at the moon.

Nevertheless, the failure belongs with them. Everyone must recognize the significance of culture in defining what is seen now and the way it is seen. Agile transformation is indeed deep and pervasive, and understanding that it somehow "involves" cultural change is not enough. It's also essential to realize that the information you receive, and the way you receive it, may no longer be fit for purpose. Hence the way executives personally interact with their organization must change, too.

Fail #2. Thinking That Agile Change Is Technical

We've all seen it: the roll-your-own "agile" model which draws a loop around the development stage in a waterfall process. We cannot feign surprise. Software, being inherently plastic, is the point of least resistance when it comes to organizational change. It's also where value is most clearly added to any products or services being built. Other enterprise processes and artifacts are further removed from the empiricism provided by demonstrable working code. These other parts of the value stream often move glacially, and are abstracted away into more rarefied administrative layers. Yet all of those requirements sets, design specifications, sign-offs and promissory notes effectively define the established way-of-working. They are consequently much harder to challenge, and harder again to genuinely change.

This can easily mislead stakeholders, including senior executives, into thinking that agile transformation is essentially a technical concern. The result of this bias will be weak pull for any deliverables which those "agile development teams" are expected to create. Also, any dependencies they may have upon other organizational elements, such as other teams, architectural authorities or change control boards, will remain unresolved. There may be local optimizations and improved transparency over old problems, but any significant change to the way business is actually conducted cannot be expected to happen. It's incumbent upon senior executives to realize that if the benefits of agile change are indeed to accrue, then change must be demanded from—and sponsored across—the whole enterprise.

Fail #3. Trying to Delegate Responsibility for Change

Most organizations, especially large ones, are hierarchical. The way in which value and decisions flow across the enterprise is shaped by this structure. Broad decisions are made at the top. The details are left to middle-management layers to sort out, oversee, and implement. Progress will be gauged not through empirical evidence, but through the reports and pro-forma mechanisms expected by those delegates, and which transfer accumulated risk from one party to another.

This can lead executives into assuming a hands-off posture when seeking enterprise change. A decision may be made to "go agile", and perhaps to even adopt a particular framework, but the execution of the plan will be delegated. This posture may be reinforced by the specious argument that employees ought to be self-organizing in this new agile world. The duplicity of this logic is quite clear: the people can't self-organize because the culture for doing so hasn't arisen yet. Moreover, by delegating risk through and across a hierarchy, empirical control of the change process will be lost. How can an executive know that a plan is correct, and correctly understood, and correctly acted upon? People may see a need for change, and genuinely want it, but they rarely want to change. The responsibility for implementing a transformation is then delegated ever-further downward. It must happen elsewhere. Eventually it may land at the feet of an agile coach...someone whom few can spare time for, but from whom great results are expected. Again, this is a top-level executive failure. Everyone must be involved in enterprise transformation, and the responsibility for managing its success cannot be passed on to someone else.

Fail #4. Not Appreciating the Effect of Organizational Gravity

Organizational gravity can be defined as the tendency of people to revert to traditional ways of working. This is often the case in an agile transformation initiative where traction is not gained. Employees may observe old procedures and protocols while emulating new agile practices as well. It can be seen as the state of doing agile without being agile. When a coach eventually leaves, not even lip-service to the new system might be paid any more. Organizational gravity can also cause people to behave defensively when faced with the expectation of genuine change on their turf. A company's "frozen middle" management layer can see it as their duty to stop a dangerous revolution from happening, while mollifying senior executives with carefully engineered optics that suggest change is indeed underway. The organizational antibodies can be expected to kick in when the status-quo is threatened. There can be a great reluctance to see existing roles undergo metamorphosis, or even just to hold previous reporting structures in abeyance.

Senior managers must understand the withering effect of organizational gravity, which tugs and tears at a transformation attempt until everything becomes molded to the organization's current shape. They must be particularly wary of agile vocabulary being co-opted, where new words are merely used to describe unchanged roles, artifacts, or events. They must be equally wary of that new vocabulary being modified to fit in with an organization's existing values and prejudices. The result would be a debasement of agile practice and a loss of inertia for achieving the new ways of working that are expected. Executives owe it to themselves and their company to be properly informed about the difficulty of change, and what the words describing change really mean.

Fail #5. Not Sponsoring Change Robustly

Not all senior executives are bluff and headstrong captains of industry. Some are weak and easily blown by the prevailing winds, or are too detached from the enterprise and its work to be truly bothered about a change initiative. They may have given the nod to an agile transformation attempt when pressured by certain factions, but they will leave any handling to their direct reports to sort out. This is different from and worse than delegation, since the expectation of a managed and coordinated result isn't even there.

The consequence of weak executive sponsorship is a piecemeal approach to change. Some change may occur in isolated pockets for brief periods, but the critical mass for enterprise transformation will never be gained. The strength of agile sponsorship is a critically important factor in overcoming the organisational gravity which holds change back.

Fail #6. Not Communicating the Requisite Sense of Urgency

John Kotter's "8-Step Process to Leading Change" ought to be instrumental in guiding executives through a transformation attempt. Usually, however, it is not. Even the very first step—creating a sense of urgency for change—is rarely followed through in practice.

A well-communicated sense of urgency is arguably the purest expression of good agile sponsorship. Imagine the possibilities were it to be asserted at board-level that not only must change happen, it must happen now. Conversely a failure to transmit this imperative across the enterprise, and to set expectations accordingly, will stop critical momentum from building up. Change will be put off or delegated until the scale and immediacy of the challenge recedes from view or can be deposited at a new coach's feet. Senior managers must take care to ensure that agile transformation is given top priority, and that adopting and improving agile practice is not an afterthought but instead must anchor everyone's working day.

Fail #7. Executing an Agile Change Initiative as If It Were Just Another Program

The modus operandi of an enterprise defines not only the way in which it delivers value, but its very method for implementing change. The processes it follows describe how change is allowed to happen, whether it be the construction of a new product to be added to a portfolio, or a new system to replace an old one through which institutional data is manipulated and retained. The processes themselves are generally assumed to be immutable until they are challenged by transformative agile thinking. They can appear to be the only conceivable way of doing things...an inherited bias which corrupts the art of the possible. Its strictures can even masquerade within the organization as common sense.

The ramifications of a transformation attempt are clouded by this thinking, which lingers as a sort of original sin. It pollutes rationalization and militates against an objective understanding of its forces. Senior executives, following established doctrine, may therefore try to delegate an agile transformation initiative as if it were just another program of work. It will be budgeted for in the traditional manner, given a standard mandate, and its success measured using old-style metrics in an old-time way. In effect the agile coach is transmogrified into a known quantity whose remit is already circumscribed by establishment orthodoxy: a program manager. The ability to apply empiricism, and therefore to prove value, will also be lost. Obviously the success of a change attempt will be severely impacted by this, and most likely from the very beginning. Executives must appreciate that an agile transformation will fundamentally change the organization itself. The whole enterprise is likely to be affected even if one team is to succeed, and hence the initiative cannot be subject to established program constraints.

Fail #8. Trying to Ride an Agile Change Initiative on the Back of Another Program

A further degeneration of the spirit of change is regrettably common. Instead of being framed as a true enterprise initiative, it might be applied as a salve to another program of work, and perhaps one which would otherwise be dismissed as being hopelessly over-ambitious. Examples of this are the so-called "digital transformation" schemes which have become fashionable across government and the larger corporates. The scope of such a scheme can be one of large-scale migration and technical uplift, often with a view towards abandoning troubled legacy estate and a necropolis of technical debt. However, any "agile" part of the initiative is rarely thought through. A mystery to those concerned, agility is conjectured to be the secret sauce which will align time, scope, and budget.

The immediate consequence of this toxic exercise is to constrain sponsorship for change to the program concerned. Where teams have organizational dependencies outside of the host program, such as upon shared corporate resources or authorities, those impediments are not likely to be resolved. The remit for change will not extend into those areas, and there may be no obligation felt there to help agile teams meet their delivery responsibilities. Any work done will then fall short of the standard needed for it to be considered finished. The Definition of Done will soon be outweighed by the deficit for release once development starts. Work will be batched up, incomplete, until those who lie outside the program are in a position to deal with it.

Senior managers should recognize the danger of constraining agile change in such a way, and the folly of expecting program directors to provide organizational sponsorship beyond their narrow remit. No matter how sure it seems that all necessary resources lie under program control, as soon as a team starts sprinting unforeseen impediments and dependencies will surely emerge. Agile change is deep, pervasive, and must be expected to transcend all existing work and associated programs. There's nothing wrong in selecting a pilot scheme, but sponsorship for agile practice must reach beyond the narrow horizons which currently limit thought and action. It can only really come from the very top.

Fail #9. Trying to Hire “Method Installers”

I remember being on a large agile transformation attempt at a London bank, where I was one of many coaches. The bank insisted on having clear transformation backlogs in place for each would-be agile team, of which there were well over a hundred. Planning sessions, reviews, retrospectives, usage of artifacts, presence of roles and so on were enumerated in some detail.

Make no mistake about it, transformation backlogs can be a very useful thing. They can and should establish transparency over progress, so it can be inspected and adapted and correlated to improved value. Unfortunately, that's where the client's approach fell short. Change wasn't empirically measurable; it was something to be "coached out" to existing workgroups. Those groups had neither the authority to self-organize as proper agile teams, nor the time nor the remit to assay deep structural change. A coach had to work agile improvements into and around these busy people with their various silos, competing demands, and ongoing commitments within an otherwise stage-gated institution. There was no correlation between anything on a transformation backlog and any value which might be delivered in a timely way. The feedback loop was not likely to be closed for nearly two years. Worse, there were notional targets for attaining levels of supposed agile maturity during that dark period. Yet if there is no empirical evidence of improvement, how can maturity or progress be gauged at all? The bank thought they had their answer: they would conduct their agile transformation by checklist. If a coach, through some mystical means of divination, figured that a change had been coached satisfactorily then it was checked off. There were burn-downs showing how splendidly everything was going as each transformation backlog was whittled away.

You see, in reality we were not engaged as agile coaches at all. Rather, the bank had set us up as "method installers," and in so doing they had set their transformation up to fail. No business can hope to reduce a profound change in its culture to a check-box exercise. Amongst other things the validated learning loop must certainly be closed frequently, if an assessment of progress is to be grounded in anything other than fiction. The temptation to do otherwise can be considerable, since establishing empirical control within large organizations is hard. The path of least resistance can appear to be to set up false controls, with metrics and measures that are poorly vested in empiricism, but rich in convincing detail. Any assurances received will be fake. Senior executives must take care to ensure that an agile change initiative, including any work enumerated on transformation backlogs, is rooted in the empiricism agile practice brings to bear.

Fail #10. “Mapping” Instead of Changing

About twenty years ago, before agile practice had even become fashionable, other means of iterative-incremental delivery were nevertheless in the ascendant. I remember many companies spawning their own versions of the "Unified Process" and how I assisted in some truly monstrous births. It was thought that change could be eased into a hide-bound organization by "mapping" its stage-gated process onto a new iterative and incremental model. Improvements in the flow of value would be catalyzed by this exercise...or so it was hoped. In practice change very rarely happened at all. It never seemed to develop beyond the boxes, lines, and other squiggles which constituted the relevant process map.

The underlying issue is one which organizations still face today...people want change, but they don't want to change. The head of steam for improvement might build up no further than the creation of that theoretical mapping between an idealized agile state and the current reality. Institutional apathy can be especially irksome when a bimodal IT strategy is propagated. The ability to "drop out" of agile practice can be seized on, not when it makes best sense for value delivery, but when agile change simply proves too hard. Plus ça change, plus c'est la même chose.

Senior executives must therefore be genuine in their desire to bring about agile change. No benefits can possibly accrue from a paper-based exercise in which an agile "mapping" is thought to hold transformative power.

Stay tuned for the second part of this article, which will appear tomorrow!