“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 yet 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 Ian Mitchell 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 to and worse than delegation, since the expectation of a managed and co-ordinated 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.
Fail #11. Trying to change agile practice instead of changing the organization
When an agile transformation initiative is announced in a company, employees can see a need to either reconcile or choose between two quite opposing forces. In the one corner we have lean-agile practice and its flyweight techniques for value delivery. In the other we have the super-heavyweight enterprise and its established way of doing things. It hardly seems a fair match to begin with. Moreover the existing system already applies to the organization in its own context. In comparison, an agile coach only seems to offer generalizations about certain practices which have been applied elsewhere. Who will listen to a dreamer like that in the ring? "Things are different here", it is very often claimed. "Vanilla agile won't work!" There is a perceived credibility gap to be bridged. Anything from introducing Sprint Goals to having a release-quality Definition of Done might be dismissed as being "too vanilla" or "too generic", if it doesn't quite square with the current set-up. The agile coach is at a clear disadvantage when the old guard of middle managers exercise a right of veto. If anything must change, they are likely to say, then it must be the agile practices you have in mind. An industrious coach is expected to provide something which has been "customized" or "configured" to align with the existing deal. The arc of the agile transformation is brought down by organizational gravity. "Bring us an agile way-of-working that matches what we already do", is the obvious yet unspoken implication. Anything less than that is seen as a failure to be practical. For many coaches it is tempting to acquiesce, collect the money, and live a quiet life until the rubes get wise about the scam they've bought into and it's time to move on.
Every executive must therefore understand and accept that "agile transformation" means changing the organization, and not changing agile practice. That is after all the purpose of the exercise if any benefits from change are to accrue. They must also be aware that a lucrative industry has emerged to satisfy the popular demand for half-baked transformation attempts which do not yield a satisfactory outcome.
Fail #12. Misunderstanding value and flow
Senior managers tend to think of agility in terms of executing projects more quickly and more cheaply. That's the secret sauce they often hope for. In truth though, agile practice is really about gaining empirical process control in a complex and uncertain environment. Those iterative and incremental techniques are geared towards experimentation, and at times the achievement of profit can seem almost incidental to that concern. Agile practice helps an organization to learn about the business context in which it truly operates. Agility isn't about running projects faster and cheaper. It's about learning to build the right thing at the right time.
Executives can be suckered into assuming a "faster-and-cheaper" prescript because they misunderstand the significance of value and flow. They may suspect both are important in achieving lean efficiencies. However, they might easily ignore the importance of visualizing the flow of value so business operations can be better understood. Most critically, they can fail to challenge the received wisdom of what "value" amounts to in the first place. Ask a manager what "value" is, and there's a good chance that "doing projects faster and cheaper" will be the depth of their reasoning. Middle managers, under pressure to complete projects under constraints of time and budget, are most likely to be nonplussed by a pursued line of inquiry. "Of course projects must be done faster and cheaper", they will think. "That's always the pain-point. What more to value can there be?"
Senior executives must be aware of how this thinking shapes organizational culture. They should be very careful to avoid framing agile discussions in "faster and cheaper" terms lest this mislead others or confirm their prejudices. Rather, they should clearly highlight the need for validated learning, the pull for small and incremental experiments, transparency over queue and batch sizes, value prioritization techniques, and team self-organization around clearly defined workflows.
Fail #13. Not thinking about what "Done" means
The degree to which a product is complete, and fit for purpose, is a common source of misunderstanding between stakeholders. For example if a product increment has been developed - but not tested under user conditions - then those working in an engineering department might still think of the fruits of their labor as being "complete". For them at least, it is finished. An end customer however might have different ideas. They could reasonably expect that user testing has indeed been carried out. They might additionally expect that documentation is in place and that training courses are available along with product support. So when is work truly finished?
Clearly there are implications here for quality control and for business reputation. Imagine what would happen if cars trundled off an assembly line without seat upholstery or headlight bulbs in place. In truth though, manufacturing industries generally have a robust understanding of what "done" means for their outputs to be production-ready. The IT industry is perhaps not so mature or circumspect in defining and assuring its quality standards. A "Definition of Done" therefore ought to be of critical importance to senior executives, because they ultimately carry the can for corporate risk and reputation. They need to be sure that the definition being subscribed to by development teams is appropriate for enterprise purposes and that it would not put the business in jeopardy. Managers should realize that the most effective way to check work for compliance is to use skilled inspectors at the time and place of work being carried out, and not as a separate stage or phase. Frequent and timely inspection stops waste from accumulating and reduces any rework needed. Automated checks reduce the time spent on inspection and the chances of error.
This also means ensuring that teams do in fact have all of the skills needed to create a truly "Done" increment, including all testing, documentation, and handover or support capabilities which might be needed. Being able to provide increments of work that are demonstrably complete, early and often, is instrumental in assuring transparency over progress, controlling risk, and minimizing the accrual of technical debt. Senior executive sponsorship may be required if any dependencies upon external resources, skills, or authorizations are to be eliminated and brought within a team.
Fail #14. Not reconsidering metrics
In traditional organizations, managers often depend upon reports to give them an idea of what is going on and the decisions they ought to make. Charts and numbers provide them with essential information, and they interpret these sources using the indicators and measurements they think best reveal the underlying truth. Their view of the world is filtered and shaped by such metrics.
Unfortunately however, even transformational progress will often be gauged using these existing indicators. The time left until the supposed completion of the initiative can be thought most important for example, instead of the value which is being delivered now, and what might be learned from it. Executives should realize that the way success is measured is also something that has to change. More appropriate and empirical means of assessment can include a focus on innovation accounting and the elicitation of actionable rather than vanity metrics. Even measures of employee performance could have to be revised, so that better teamwork might be rewarded. Whatever techniques are chosen, executives need to accept that agile transformation cannot be sponsored or assured using old anachronistic measures and terms of reference.
Fail #15. Not applying empirical process control to enterprise change
It would be foolish to try and conduct an agile transformation as if it were just another program of work. However, it would be equally foolish not to set about change in a managed way. Unfortunately though, a lack of control is apparent in many agile transformation attempts. Empiricism is typically lacking. Instead, a mixed slush of agile techniques will be thrown against the wall, in the hope that some of it might stick. It's a recipe for people to become adept at "doing" agile rather than "being" agile. They'll go through at least some of the forms and motions, for a while, but the empirical evidence provided by agile delivery is unlikely to be forthcoming. Organizational gravity is more likely to assert itself, and to bend change to the institution's current will and shape.
Empirical process control is inherent to any true agile way-of-working and that must include a transformation attempt. Hence senior executives must look for empirical evidence of improvement, and not reports or other promissory notes, to be assured that an agile change initiative is indeed "on course". For example, they might reasonably expect transformational effort to be visualized and managed as one or more change backlogs. Each should capture the good agile practices which are expected to "move the needle" and help achieve empirical improvement in team-based value delivery. At least one transformation group may be needed who can interpret the effect of agile coaching in this way, and inspect and adapt those transformation backlogs, until agile practice is normed across the enterprise and self-organizing teams are in place.
Managing a cultural shift of this nature is not something which can be delegated. There will be many things that need doing, and which will transcend any one program of work. They are likely to cut across the whole organizational structure. Even getting just one team to successfully deliver a release-quality increment after just one iteration can require deep and pervasive change across the enterprise. There will be many unforeseen dependencies which will have to be recognized, challenged and removed. New agile teams will have to be brought together with the ability to self-organize. There will be new value streams to be identified and old ones which will need to be improved. Teams will have to acquire new skills, to learn based on evidence, to sort out their dependencies with others, and to identify and remove waste.
If you were to get to the heart of what enterprise agility really means, you could say that it demonstrates the empirical mastery of innovation at scale. Since most organizations are conservative rather than innovative, executives must recognize the barriers which are likely to be presented to any associated agile change attempt. The organization is likely to harbor some quite reactionary forces, including middle-managers who genuinely believe that resisting change, and preserving established and "proven" norms, is the right thing to do. Very often, empiricism is something only resorted to in an emergency, and abandoned when the danger recedes. Senior executives must sponsor transformation across all of the parts of an enterprise, and advocate the empirical process control which always underpins agile practice.
Fail #16. Not encouraging a product focus
Pick a large organization, any one. Go to the head office and take a good look. What business are they in?
Well, chances are you could be forgiven for thinking they're in the business of running projects. That's the main thrust of what they might seem to be doing anyhow...irrespective of whatever products or services they might provide or the industry sector they are in. They are likely to be drafting project initialization documents, seeking and approving mandates, scoping requirements sets, establishing project plans at various levels of detail, concocting RAID logs and RACI matrices, leveling resources, securing funding and putting together work packages. Everywhere, documents are passed around which are promissory notes for some value as yet unevidenced and undelivered. In a perverse expression of managerial self-aggrandizement, these documents may even be referred to as "products". Risk is transferred from one party to another until judgment day when the actual product is scheduled to materialize.
Projects are by definition temporary endeavors. Much effort is expended in setting them up, monitoring their supposed progress in the absence of regular useful deliverables, and in tearing them down afterwards. They are known to be a poor vehicle for sustaining the flow of value, and for retaining the institutional knowledge and team skills which allow value to be optimized.
Encouraging executives to rethink the enterprise not in terms of projects, but rather in terms of the genuine products which allow value to be released and empirical lessons to be learned, has proven to be a long and slow battle. Then again, developing a product focus might be criticized on the grounds that it doesn't necessarily emphasize value and flow. We could still have products which are ill-conceived and poorly represented in terms of ownership, and perhaps end up with limited visibility over services. Nevertheless, establishing a product-focused organization is undoubtedly a step forward to understanding value streams of any type, and it is a significant improvement on project-execution mode. Senior executives should therefore take care to ensure that products rather than "projects" are being sustained, and that they are clearly owned and represented at all levels.
Fail #17. Not rethinking roles
Agile change is determined not just by the work that people do, but by how they begin to see themselves in relation to it. Any of an organization's present roles, perhaps even all of them, could need to change if value delivery is to be maximized. Senior executives themselves may need to rethink how they fit in to an enterprise value stream, and the value they should be adding. Is it really appropriate to expect "reports" from others, given that this can subject essential data to filtering and delay? How about building transparency, and even more importantly, making use of it? Furthermore, shouldn't responsibility for inspection and adaptation be devolved upon those who actually perform the work? Establishing transparency over the various things that are done, and the way people go about them, is essential to agile development.
In Scrum there are a mere three roles and Scaled Professional Scrum adds to this just one more. They are optimized to deliver work of release quality at least once every month. In comparison to this, large organizations can have scores or even hundreds of job descriptions. Each of them will be geared towards the scheduling of work according to the availability of the associated "resource", such as analysts and designers, programmers and testers. Work will be passed from one person, or pseudo-team with similarly constrained skills, to another.
Executives must understand that in agile practice work is not scheduled by resource availability, or by the passing of work between silos and through stage gates. Instead, people ought to go to where the work is, so that a so-called "resource" and the role they fill becomes orthogonal to the workflow. That's the intent behind a self-organizing team, and the teamwork they should exhibit. People should be able to organize themselves around the work that needs doing, when it needs doing, and ensure that it is done to a satisfactory level of quality.
Fail #18. Overlooking the strategic, operational or tactical aspects of change
I've often found that when I'm hired as an agile coach, little thought is given to the type of coaching I will need to do, or how it is likely to impact the organization and its stakeholders. Sometimes it's just assumed that I will ensure an initiative is somehow accomplished "faster and cheaper". The classic error of executing agile change as a project or program, or on the back of another one, is rarely far away. More remote unfortunately is any consideration of empirical process control or of what it means to have a learning organization. The agile coach is simply thought of as another manager, albeit one who brings that “agile secret sauce"...the magic ingredient of project success. What executives fail to realize is that agile coaching impacts the whole organization, and hence it must be considered at tactical, operational, and strategic levels.
Tactical coaching is most often team-facing and innately unpredictable. There are always retrospectives or other events which need facilitating, or during which a Scrum Master could need to be mentored. There might be on-the-spot advice which is asked for or which ought to be given, estimation or other agile techniques which must be taught, and outreach sessions to other parts of the enterprise which need to be arranged. Tactical coaching is usually ad-hoc, and isn't something that an agile coach ever really escapes from, or should wish to. It's about helping people to understand and master agile practice in the field.
Operational coaching is comparatively focused, and aligned towards the specific agile roles people need to fulfil. Product Owners, Scrum Masters, and Development Team members can need formal or semi-formal training so they at least broadly understand the part they have to play, and the collaborative relationship they will need to have with others. Scrum courses which articulate to some type of accreditation can provide a certain degree of grounding. Also, there are people in existing roles, such as business analysts, testers, or project managers, who can feel uncertain or threatened by the prospect of what agile change will mean for them. Sometimes workshops can help people to move into new roles for which they are qualified. Business analysts, for example, may benefit from group sessions in which user story writing or backlog refinement are explained. In short, people may need to be coached to perform their agile roles at an operational level.
Strategic coaching is aimed at executives. The assistance given can be structured or unstructured, depending upon when it occurs in the engagement and which management functions are addressed. There might be a formal workshop or training course to begin with during which essential terms of reference are established. Later on, there might be more tightly-focused sessions during which many questions will need to be answered and risks clearly highlighted. Some of the issues and pitfalls covered here might be explored, for example. It's also vitally important to ensure that a strategic vision for enterprise agile transformation is elicited, and that adequate sponsorship for it is in place.
Fail #19. Thinking they’re above it all
Sponsorship for agile change, unfortunately, very often proves to be the Achilles' heel of a transformation scheme. Part of the problem lies in a delegation culture and in assuming that the challenge is essentially a technical one. From this executives can compound their error by failing to consider the agile coach as an enterprise change agent who is deserving of their time. Rather, the coach is seen as a junior manager or technician, someone who works with developers and other technical-types so the agile gubbins is plugged in. There's little chance of being invited to the top floor, or the board-room, to discuss over coffee the various organizational impediments which you see building up. There's even less chance of executives coming down to where the work is done, and taking a proper look for themselves. The CEO's presence is reserved for management consultants on ten times your day rate, or real "celebrity coaches" with their kumbaya games and mood-music. You meanwhile are someone to be kept below stairs, under the control of the delegated subordinates who hired you for their project or program.
This is the most critical executive fail, since it drives many of the others we have explored here. It enforces a disjuncture between the vision of an agile enterprise, and the pro-active sponsorship which is needed to achieve it.
Fail #20. Not changing themselves
If we were to look for a key take-away from this score of executive agile fails, it would have to be this. It's the reluctance of senior managers to change themselves. If you are one, try asking yourself these questions. Are you prepared to leave your desk, to wean yourself off reports, and to see for yourself what is really happening in your company? Are you willing to make agile transformation your top priority? Do you really want enterprise change, and not some sort of bolt-on capability which you think delegates ought to handle? Are you willing to challenge, and be challenged on, the very idea of what value means to the organization? Do you see the importance of flow, and the futility of making projections without empirical evidence?
Now think of it this way. There are many human behaviors we can wish were altered so our lives would be improved. However there is only one person whose conduct we can ever really change, and the agile transformation in your organization quite simply has to start there. I'm not going to spell out who that person is. And remember: agile transformation is a harsh mirror. If you don't want to know how ugly you are, don't look in.