On March 2018, Ian Mitchell published a depth and detailed post about top failures when executives do not assume their leadership responsibilities in the context of an Agile transformation.
For people who would find it TL;TR, here are some extracts to get the main insights.
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.
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.[Consider this real case situation:]
=> 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.
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
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
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.
Fail #3. Trying to delegate responsibility for change
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.
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.
Fail #5. Not sponsoring change robustly
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
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.
Fail #7. Executing an agile change initiative as if it were just another program
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. 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.
Fail #8. Trying to ride an agile change initiative on the back of another program
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 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.
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”
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. 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
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.
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.
In comparison, an agile coach only seems to offer generalizations about certain practices which have been applied elsewhere. “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. 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.
Fail #12. Misunderstanding value and flow
Senior managers tend to think of agility in terms of executing projects more quickly and more cheaply.
In truth though, agile practice is really about gaining empirical process control in a complex and uncertain environment. 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.
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?
Ensure 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. 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.
Fail #14. Not reconsidering metrics
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.
Fail #15. Not applying empirical process control to enterprise change
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.
Fail #16. Not encouraging a product focus
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.
Fail #17. Not rethinking roles
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.
Fail #18. Overlooking the strategic, operational or tactical aspects of change
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. 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.
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.
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.: