Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Twenty Top Fails in Executive Agile Leadership [Part 2]

DZone's Guide to

Twenty Top Fails in Executive Agile Leadership [Part 2]

Second verse, same as the first. Check out the second section of this two-part with more mistakes executives make when involved in an agile transformation.

· Agile Zone ·
Free Resource

Download this white paper to learn about the ways to make a Scrum Team great, brought to you in partnership with Scrum.org

The first part of this article appeared yesterday and can be read here.

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.

Learn more about the myths about Scrum and DevOps. Download the whitepaper now brought to you in partnership with Scrum.org.

Topics:
agile ,digital transformation ,agile coach ,executive leadership ,executive sponsorship ,value ,flow ,agile transformation

Opinions expressed by DZone contributors are their own.

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

{{ parent.tldr }}

{{ parent.urlSource.name }}