Agile Management Required

The exclusive focus on rules, ceremonies, and rituals applied by many coaches is actually counterproductive. Adopting agile practices can result in such rapid local progress (in the software development function) that the enterprise doesn’t believe it needs to push further. What’s the missing piece that would enable these initial, local successes to permeate the enterprise? To answer this question, let’s go back to lean fundamentals. David Mann,⁶ describes the missing element this way:

Why is it that so many attempts to convert to lean end in retreat and disappointment? It is a paradox: So many lean implementations fail because lean is too easy! It’s too easy to implement the physical trappings of lean while failing completely to notice the need for a parallel implementation of lean management.

The basic practices of agile are simple to learn and implement. New scrum teams can often absorb these techniques, and begin to profit from them, in a few sprints. These teams are successful in implementing rudimentary visual controls, in uncovering wasteful practices and processes in their retrospectives, and in developing long lists of blockages, detours, and wait-states that are impeding their momentum. They remove the obstacles within their teams, and start to exhibit stable, or even increasing, velocity, as their collaboration and problem-solving skills mature. After a number of sprints or releases, however, they plateau; the systemic problems, entrenched dysfunctions, and flawed processes that are not easily solved within the team become increasingly intractable, and the obstacles, detours, and defects pile up on lists but are never addressed or repaired. As the challenges ripple through the enterprise, they bump up against vested interests and legacy procedures that reach into the management and executive level. Their complexity and tenacity become unmanageable. Every process we touch affects dozens of others, with unpredictable results. Without the ability to improve the enterprise value chain, legacy processes, hierarchical organization structure, or the predictive, sequential mind-set of leaders, agile efforts lose their momentum, and gravity prevails.

In agile theory, as noted in the idealized example mentioned previously, scrummasters and agile coaches would guide teams to uncovering the obstacles and challenges that impede agility, leaders would use the big, visible controls and improvement backlogs to prioritize and enable change, and kaizen action would be taken every day to remove roadblocks and empower teams. Much of the agile literature recommends that these things happen but doesn’t delve into the details of creating an agile leadership structure to ensure that they do. Again, from David Mann:

Without alean management systemin place to support the new arrangements, people are left to rely on their old tricks for fooling the system, using familiar workarounds to get themselves out of trouble. It’s a path that leads swiftly away from a successful conversion. The promising lean system becomes one more sad entry in the roster of failed change projects. ⁷

This is where the role of agile consultant becomes arduous. It’s often great fun to work with teams on a grassroots agile adoption, as they learn new, powerful techniques and gain enthusiasm and confidence. As the visual controls and agile practices start to reveal difficult, politically charged obstructions, and the team looks to the scrummaster and agile advisor to help them clear their path, engagements swiftly shift from fun to funk. Complex structures, systems, and tools; intransigent and self-focused leaders; habits of evasion, avoidance, and blame—agile consultants must now bang their heads against all of these, and find a path through. If we expect to evolve the enterprise to agility, we’ll need to guide the organization through the fractious, controversial, and unyielding dysfunctions they’ve been avoiding for years. We’ll have to leave in our wake a robust agile leadership culture, not just a set of practices and charts.

This leads us to another paradox. The Agile Manifesto reminds us to value “individuals and interactions over processes and tools,” yet lean theory tells us that process focus is the pillar of lean management. To square that circle, remember that the lean processes referenced are those very practices that we’ve been instilling in our agile teams , namely, visual controls, accountability meetings, and kaizen reflection and action on obstacles, wait-states, and other forms of waste. These processes are miles away from the multistep, impersonal swim-lane processes that have evolved over time in many organizations, based on the theory that if you document every possible step of a process even an unskilled worker with minimal oversight can walk through the steps and produce a result. This is called the “so simple a monkey can do it” theory of process management, and, of course, it produces the result intended: unthinking, uncritical and mind-numbingly repetitive activities suited for monkeys but not for creative, intelligent humans. Managers in these sort of process-driven organizations “manage by exception,” meaning that every error or missed expectation results in a reprimand to the team or individual, a heaping on of additional controls, or a public shaming for the team and manager that “missed their numbers.”

When agilists talk about creating a lean or agile leadership structure that focuses on process, we mean the exact opposite. Our practices, like the backlog, the stand-up, and the retrospective, are the catalyst for collaboration, analysis, and action, not blaming and shaming. The real-time focus on assessing the problems uncovered by agile methods, discussing them with openness and honesty, and solving them with courage, discipline, and urgency differentiates our style of process management. This kaizen process doesn’t violate the spirit of the Manifesto; it embodies it.

It also doesn’t happen automatically, and this is where many agile advisors lose the plot. In order to evolve to agility, the enterprise must embrace the challenge of discarding what’s broken and searching for new solutions. The development of an agile leadership culture that enforces improvement action, rather than mere list-shuffling, requires agile consultants to engage, and change behavior, across the enterprise. That takes many agile coaches and scrummasters out of their comfort zone, if not out of their level of competence. This is not a knock on anyone; engaging at the management and executive level requires a completely different skill set than guiding agile practices. Successful managers and executives have learned a set of beliefs and behaviors that have produced results and led them to their positions. The disruptive force of agility now requires them to modify, or even extinguish, the successful techniques of the past. This is a tough pill to swallow, and an even tougher one for the agile consultant to administer.

I don’t think anyone who has worked for a traditional corporate enterprise would argue that their enterprise’s management systems are lean or agile. Management decisions are made based on obscure reports, which often travel through multiple layers of the hierarchy before landing on the desk of the decision maker. These reports are often contradictory, as department managers massage their numbers to give the best impression. Meetings often devolve into either endless debates about which numbers are accurate or rote recitations of fictional outcomes that afford no questions or analysis. The rearview focus means that the problems addressed either have already been fixed by workarounds on the ground or have been repeatedly exposed in meetings spanning multiple years but have never inspired any action. Critically, from an agile perspective, these meetings are usually closed and exclusive, and both the results reported and the actions promised are often invisible to the rest of the organization.

One of the myths about agility is that it’s just a disguise for an undisciplined work environment, in which teams make it up as they go along, with no planning, tracking, or accountability, and then leave behind an unsupportable mess. While anyone who has worked in a well-functioning agile organization knows this is nonsense, we must also acknowledge that the potential for this outcome is there. Every agile coach has encountered teams that believe that agility is an excuse for shedding discipline and resorting to “cowboy coding.” We’ve all encountered managers in whom the report-driven, management-by-exception mind-set taught in their MBA programs are so familiar and comfortable that the idea of relying on visual controls scattered around the workplace, and on self-managed teams that make their own decisions, seems risky and unworkable. To delivery teams, discipline, even in an agile context, can feel like a brake on creativity. To managers, agile leadership looks like “the inmates running the asylum.” Our primary task, as we take on the evolution to agility, is to reorient both groups to the real meaning and methods of agility. Our second task is to help them evolve to both a disciplined production process (like scrum) to deliver the product and an adaptive leadership culture to ensure that delivery processes are optimized, monitored, improved, and, most important, responsive.

To be clear, I’m not recommending that we replace one hierarchical, top-down management structure with another, “more agile” one. Agility requires adaptive leadership, not top-down management. Teams are self-managed, with the daily allocation, prioritization, and production work of traditional line managers now entrusted to teams, their scrummasters, and product owners. My thesis is simple: kaizen-style continuous improvement doesn’t happen in a vacuum, and, at the enterprise level, simply leaving improvement to each individual team replaces hierarchical, process-bound management with a different type of dysfunction, that of suboptimization. Each team optimizes for its own specific needs, whether by project, function, product, or client, with no connecting thread between these local optimizations. Without some form of overarching agile leadership structure, the enterprise is at risk of atomizing into an agglomeration of independent units, each of whose optimizations contradict or even impede their colleagues’ ability to deliver. Suboptimization, or local “centers of excellence,” whose reforms are not guided by a vision for enterprise improvement, can be as disruptive to enterprise unity as the old, secretive, and hierarchical styles from which we’re trying to evolve.

Agile Scaling Frameworks

With all of this said, what are the practical, on-the-ground actions that agile consultants can take to guide the enterprise to their own optimized version of agility? In summary, we need to create agile teams and visual controls, as we’ve discussed previously, and to encourage an agile leadership culture that ensures that those controls translate into quick exposure of issues, rapid and collaborative analysis, and immediate action to eliminate root causes, not just work around roadblocks. In-sprint burndown charts, for example, enable teams to spot production problems during the actual delivery cycle, not afterward, when the faulty product or missed deadline has already occurred. Retrospectives enable us to immediately apply the learnings of the iteration just completed, while they are fresh and their pain is still apparent, rather than waiting for eons while reports are generated, massaged, reviewed, analyzed, and then, in too many cases, ignored.

The works of Cohn, Adkins, and many others have documented the roles and responsibilities of scrummasters and product owners. In short, the scrummaster is there to train, guide, and help the team to apply the agile processes properly, and to help them deal with roadblocks and impediments that might put their commitments at risk. The product owner represents the interests of the ultimate consumer of the product, with the authority to guide the delivery team in building and prioritizing the backlog, to respond to changes and communicate their implications to the client, and to help teams make decisions about the features and functions required to satisfy the client’s expectations. Here, we’ll address their place in an agile leadership culture, and emphasize why their actions, rather than merely their roles, define the ability to extend agility across the enterprise. We’ll see how the command-driven management style of the 20th century can evolve into an adaptive leadership style that suits agility and responsiveness.

As agility has progressed, the focus has shifted from team practices to enterprise scalability. When organizations first experimented with agility, scrum became the most popular agile framework. Similarly, Dean Leffingwell’s Scaled Agile Framework has become the de facto standard in enterprise-level agile scaling. As illustrated in Figure 9-1, SAFe offers a structured, disciplined approach to scaling agility that defines roles and processes for four levels of the enterprise: the portfolio, value stream, program, and team levels. The diagram looks complicated, but, when decomposed, it presents a clear mechanism for solving some of the problems of scaling, such as misaligned strategies and dependencies, unsynchronized schedules, and the coordination of multiple, independent backlogs. Firms like Lego, Intel, and Accenture have applied SAFe to their agile efforts with great success.⁸

Figure 9-1. Scaled Agile Framework 4.0

At the Portfolio level, SAFe describes a process that is triggered by the strategic decisions made by enterprise leadership. As in most organizations, strategic themes are then refined into a portfolio of programs designed to achieve the strategic objectives. Epic Owners and Enterprise Architects collaborate, based on their budgets and commitments, to create a portfolio backlog that then drives the program and team backlogs at the next levels. At the value stream level , firms organize their delivery of value into Agile Release Trains, to coordinate large sets of programs and deliverables into a synchronized and integrated stream of delivery. Enterprise roadmaps, metrics, release management, and DevOps are managed at this level. Program-level participants , like the release train engineer, the system architect, and product management, focus on the features of the product, the epic-level components of that feature, and the synchronization of the architecture and the release schedule, while the teams perform the familiar scrum activities of iterating through the sprints to actually develop, build, test, and integrate the products that realize the strategic objectives set forth at the portfolio level.

SAFe has a large community of proponents and practitioners, and has been endorsed by many of the leading agile tool companies, like Rally and VersionOne. It’s easy to see why this framework is so appealing. It shows enterprises how to take their successes in agile at the team level and scale them to fit the strategic goals and initiatives that executives care about. It presents a coordinated, synchronized, and disciplined approach that sets out clear roles, responsibilities, and time frames so that teams are not suboptimizing, improvising, or floundering. For executives who are accustomed to predictable, organized delivery, led by strategic decisions made at the leadership level, it offers an agile alternative that is comparable to existing portfolio-program-project hierarchies, and can correlate to the predictive models they’re used to.

For critics, that’s the rub. Many agile experts, including signatories of the Agile Manifesto , like Ron Jeffries⁹ and Ken Schwaber,¹⁰ have published critical reviews of the method. Most of the criticism revolves around a few ideas; that SAFe is not really agile because it imposes a top-down line-of-command structure, that its very structure and discipline make it less adaptable and agile, and that it assumes that big, portfolio-level programs should be tackled at all, versus breaking them down further and allowing teams to self-manage their division of work. I won’t try to adjudicate these questions here; I recommend especially Ron Jeffries article, as it presents a fair-minded appraisal of the good and bad elements of SAFe from his perspective. For a laugh, check out Mike Cohn’s lampoon of agile scaling frameworks, The LAFABLE (Large Agile Framework Appropriate for Big, Lumbering Enterprises) process .¹¹ As we’ve noted, this book is not intended as a tutorial to agile techniques, so I’ll refer you to the deep training material on the SAFe site,¹² or, if you’re so inclined, to the certification opportunities available there as well.

DAD ¹³ is another structured enterprise-scale framework. Intentionally IT focused, and promoted as more of a “process decision framework,” DAD is less prescriptive and hierarchical than SAFe, and is agnostic about the team-level practices applied. Billing itself as a hybrid model, DAD advocates using different methods, from scrum to kanban, and from Lean Software Development to XP, to create the perfect mix for the situation. Scott Ambler, the force behind DAD, describes it as risk-focused, goal-driven and enterprise aware. DAD has gained some traction in the agile community, but has not achieved the acceptance of SAFe.

Craig Larman and Bas Vodde¹⁴ have made the most explicit connection between agility and lean concepts. Focusing on the lean concepts introduced at Toyota, and the lean manufacturing ideas that sparked Japan’s rise as a quality leader, they bring us back to first principles in our agile thinking. They remind us that lean and agile are about different ways of thinking, not just different practices and behaviors. By reminding agilists that lean techniques are really intended to encourage us to apply systems thinking to the problems we encounter, and to learn a new, lean mind-set, they’ve developed a process for scaling agility that remains true to lean principles and doesn’t support predictive, framework-focused recipes for agility. The ideas they express in the book have been compiled into a scaling process they call LeSS . Larman and Vodde emphasize that LeSS is a scaled-up version of regular, one-team scrum, and doesn’t require lots of new processes or structures. Rather, LeSS recommends that all teams in an enterprise are working in a common sprint to deliver a common shippable product. LeSS adds a few more ceremonies—for example, breaking sprint planning into an enterprise-level “big room” session in which teams self-organize the entire product backlog—and a separate sprint planning session for each team. More than practices, LeSS concentrates on applying the principles of lean mind-set, such as systems thinking, transparency, continuous improvement, and a whole-product focus. For those agilists who frown on the highly structured and somewhat hierarchical concepts behind SAFe and DAD, Larman and Vodde’s ideas are closer to the “Scrum of Scrums” concepts promoted by Cohn and Schwaber.

The Spotify scaling example,¹⁵ the result of a long-term, experimental journey at the company, has become a model for scaling without an overarching framework, based instead on clear definitions of principles, roles, and alignment strategies. By defining a unique set of roles and principles, Spotify has created an agile culture that addresses many of the difficulties of enterprise-level agility. Spotify has created new definitions of teams and their collaborative roles, and defined the interaction between leadership and those team structures in thoughtful and imaginative ways. Organizationally, Spotify has modified the typical scrum team and instead created agile squads, with the ability to select their own methods and practices rather than mandating all-scrum or all-kanban, for example. Squads, once they’ve demonstrated that they’ve grasped the agile mind-set and can self-organize, can adopt or reject any of the typical ceremonies of scrum or XP. For example, some do daily stand-ups, some don’t. They focus on principles rather than practices: autonomy, alignment with company mission, high motivation, and community trust building are some guiding ideas. Each squad is focused on a particular feature or function of the Spotify platform, like search or playlists, and so can build expertise in their area.

The next unit of collaboration at Spotify is the tribe, a collection of squads with a similar mission. Tribes periodically gather to discuss and minimize dependencies, and to ensure that all squads are working toward the same mission. Most collaboration sessions are impromptu and situational, rather than enforced on a specific schedule.

To keep team members connected with their discipline, a capability that is often compromised when functional silos are replaced by cross-functional teams, Spotify introduced chapters and guilds. Chapters are cross-team groups of those within the same discipline, such as coders or testers, who meet regularly and ensure that all are up to date on the latest techniques, that learnings are shared, and that nobody is reinventing solutions that already exist. A guild is a less formal and more inclusive group. A testing guild, for example, may include a wide collection of testers, but might also include coders who want to better understand testing or contribute to guild knowledge.

This is, of course, a brief fly-by of the concepts developed at Spotify . To dig more deeply into this model, access the resources cited.¹⁶ The cited references go much deeper into the challenges of autonomy versus authority and the technical elements of this model, than I can include here.

My personal preference is toward the less prescriptive, less hierarchical models, like the Spotify or “scrum-of-scrums” approach . The prescriptive models, most notably SAFe, are easier to sell to command-based organizations, as they offer the perception of predictability and control, and seem like a one-stop solution to the enterprise scaling problem. In exchange for that corporate comfort level, however, I believe enterprises sacrifice some of the core concepts of lean and agile. In high-structure models like SAFe, programs are defined at a high level and “roll downhill” to the teams, which start to resemble, in my view, an agile assembly line of developers working to spec, with less autonomy and ownership of the outcomes they produce. Tightly defined release trains can drive teams to imposed deadlines and arbitrary time boxes, and budgets created at the portfolio level resemble, to me, arbitrary estimates defined before the understanding of the requirements are known and understood. These models constrain the autonomy and creativity of the teams, and fail to acknowledge some of the hard-won lessons of agility, namely, that hierarchical and predictive program management doesn’t work, and that innovation occurs closest to the work.

In the Spotify model , principles, not practices, rule. Through the creative use of organizational structure, and enterprise acceptance and reinforcement of a few core principles, squads, tribes, chapters, and guilds retain their autonomy and collaborate to define their own methods of solving problems and delivering solutions. This model is necessarily evolutionary, as teams gain maturity in self-organization and collaboration. It’s also a more difficult sell to traditional hierarchical enterprises, as it requires executives to trust that teams will perform successfully and manage themselves to mission-based outcomes. The “high-autonomy, high-alignment” model at Spotify reflects the ideals of lean and agile most accurately, as it enables executives to set enterprise mission, goals, and objectives, and to focus on encouraging motivation and alignment, while allowing teams to organize, innovate, and manage themselves to come up with the best methods and practices to fit the mission and their team culture.

Opinions differ, of course, and I present all of these models so agile consultants can draw their own conclusions. Different organizations, depending on the existing culture, the maturity of teams, the architecture in place, and the company’s business niche, will benefit from different scaling approaches. It’s obviously easier for a disruptive, innovative startup to embrace a Spotify model than it would be for a large bank or insurance company with dozens of projects in flight at the same time and regulatory compliance issues that require traceability and audibility. The ability and experience to discern the client enterprise’s legacy, culture, and marketplace, and recommend the appropriate scaling approach, is a consulting, not a coaching, skill. The further up the ladder we move, and the more we need to change executive mind-set and management styles, the more critical mature consulting and advisory skills become.

Evolving to Agile Leadership

Whether we recommend that enterprises adopt the SAFe framework or the Spotify model, we’re making big assumptions about the organization’s ability to adapt. SAFe requires managers to embrace disciplined portfolio management, to adopt a kanban approach to that portfolio, to invest in changes in the technical architecture to enable agility, and to migrate to agile metrics and concepts. The Spotify model expects managers to step back from their traditional “how to do it” roles and apply a more hands-off, trust-based, mission-oriented management style, allowing autonomy at the producer level. Whatever enterprise scaling philosophy we apply, we aren’t just touching some isolated groups of technicians in a small agile pilot team. We’re evolving way beyond the “Agile 101” activities of guiding and coaching individual teams, and instead tackling the entire edifice of management style, philosophy, and organization. We’re advising the enterprise on its entire structure, and asking managers and executives to migrate from the ingrained styles they’ve applied to a completely new set of beliefs and practices. Every experienced agile coach or consultant has seen the challenges and gyrations many teams go through to adapt to agility. Project managers, client representatives, sales teams, operations teams, and developers, testers, and solution designers all initially struggle with their changing roles as agility evolves and they encounter unfamiliar territory. I’ve said before that agile practices, like scrum, can be taught in a day and start showing results in a few sprints, but that doesn’t mean that agile is easy. The deeper you go, the harder it gets, and the evolution to enterprise agility must go broad and deep to generate the results the enterprise expects.

The most important work on agile leadership comes, unsurprisingly, from Jim Highsmith at Thoughtworks. Highsmith’s paper on Adaptive Leadership ,¹⁷ and his associated talk on this topic,¹⁸ are the most sophisticated representations of the challenges facing the executive and management layer of the enterprise as it transitions to agility. With a hat tip to Mr. Highsmith, I’ll outline and interpret some of his key ideas, and then apply the unique perspective of the agile consultant to guide our advisory path at enterprise level.

Let’s start at the strategic level . What strategic questions should enterprise leadership contemplate in our increasingly turbulent and disruptive business environment? In the contest between efficiency, the holy grail of 20th-century business, and responsiveness, the mantra of the 21st, where should we focus our strategic intent? Efficiency and low cost are, of course, constant drivers of competitive advantage, but, for many firms, from Google to Amazon and from Gap to Ford, responding to the concerns and desires of the marketplace has become the key differentiator. Those retail stores, from Gap to Uniqlo, that can respond quickly to the trends on the street and keep pace with rapidly changing customer demand, use responsiveness as the key attribute of success. Internet-based businesses respond daily with new features, and quickly dispose of the ones that don’t work. Responsiveness is the key, and simply creating a few agile teams in IT can’t achieve that; only enterprise agility can.

Every business leader should be considering the benefits that responsiveness can bestow in his particular marketplace. When organizations, from Salesforce¹⁹ to Capital One,²⁰ recognize and exploit the idea of agility as a business strategy, not just a software process improvement technique, and disrupt entire industries by achieving enterprise agility, competitors and other businesses must take note. As difficult as enterprise transition may be, the benefits of applying an agile mind-set to the entire business are manifest. The difference between doing agile, following the practices in isolated product development teams, and being agile, enabling the entire organization to respond continuously to changes in market needs and trends, is the foundational idea of enterprise agility. As Highsmith reminds us,

Adaptive leadershipis the work of energizing, empowering and enabling teams to rapidly and reliably deliver business value by engaging customers and continuously learning and adapting to a continually changing environment.

Focus on value, rather than on tasks or activities, is a core lean and agile philosophy. Executives and managers who aspire to agility must also make the transition from managing and monitoring activity to measuring, through customer feedback and collaboration, the value delivered. The Triple Constraint, or Iron Triangle, taught in traditional project management programs, consisting of scope, time, and budget, is still important in agile work, but it is viewed as a set of constraints and boundaries, not as the marker of success. All experienced project managers know that projects can deliver on scope, cost, and schedule and still deliver zero value to the customer, especially in these turbulent times. It’s a central part of the agile consultant’s role to help leaders understand this concept, guide them through the change in mind-set, and persuade them that it’s value, not activity, that requires measurement and oversight. Agile consultants often encounter managers who continually refer back to the traditional management style, as in “agile doesn’t allow me to estimate like I’m used to” or “agile doesn’t fit into my traditional strategic plan process like traditional project management.” They are presenting current conditions as if they are ideal, and it’s the consultant’s job to remind them that these techniques are not working, so we’re not contending with a comparison between a perceived ideal and an unsure and unfamiliar future. We must remind them that studies consistently show that half of the features they deliver are not valued or used by customers. We have to educate them on the success rates of agility versus predictive methods, as illustrated by the Standish Group studies cited earlier. When sponsors compare every aspect of agility to their traditional practices, the obvious question is “How’s that working out for you?.”” Of course, experienced consultants will phrase it diplomatically and with sensitivity, but it’s important to remind them that these techniques, though familiar, are ineffective and uncompetitive.

Many executives seek to migrate to agile due to a perception that “we’ll get stuff faster.” Speed-to-value is, of course, a desired effect of iterative, incremental refinement, but the perception of speedy delivery by the client is equally critical. Many leaders don’t realize that most customers would prefer a minimum viable product (MVP) that meets their core needs in 3 months, rather than an omnibus, all-in project that delivers their entire visualized scope in 12 months. They often assume that because the client delivered a 400-page Business Requirement Document (BRD), with field-by-field specifications and validations, they must deliver everything in the BRD exactly as specified. They don’t consider the possibility that clients don’t need, and frequently don’t even want, everything they’ve requested. Clients often throw everything they’ve ever dreamed of into the spec because they’ve been trained to believe that they have one chance only, and that, even if they don’t need specific features now, they better throw them in because there’s no “phase 2.” Agile consultants need to walk enterprise leadership through this chain of logic explicitly, so they grasp that it’s OK, in fact it’s required, that we have an MVP conversation with the ultimate customer and help the customer define the core problems the enterprise is hoping to solve, and the core features that will achieve that goal. Both the sponsoring executives and their customers require a transition to an agile mind-set, and only the agile consultant and her agile colleagues can guide them there.

In the evolution to agile, many consultants engage with teams that are running an endless race with commitments that exceed the capacity to deliver. Executives encourage sales teams to sell more and more, and then throw those commitments over the wall to already overloaded teams. This cycle of pressure inevitably leads to burnout and despair, which inevitably leads to poor quality, since something’s got to give. The agile terminology for this is technical debt, meaning we’ll hack though some parts of the product with less-than-craftsman-like code, with the false idea that we’ll come back around later to repair the damage, or, in agile language, to refactor the code to repay the technical debt. Of course, in these pressure environments, day 2 never comes and product quality starts to impact the customer, creating an endless cycle of support, revision, repair, and patch. The lack of connection between commitment and capacity is a common dysfunction in many enterprises, and is a large impediment for agile evolution. Quality declines, technical debt multiplies, and teams are detoured from their goals to support and maintain poor-quality products, leading to more pressure to deliver. As Highsmith notes , only management can solve this problem, and again it requires a mind-set change. One of the techniques I use for making this disconnection between commitment and capacity visible is Big Room Planning, in which every team exposes its portfolio of pending projects and available resources to the entire enterprise, including leadership. When leaders have to make the uncomfortable priority decisions themselves, and are confronted with a quantitative analysis of commitments versus capacity, they often begin to realize the conveyor belt of pain they are inflicting on their teams. Again, from Jim Highsmith:

Do less: cut out or cut down projects, cut out overhead that doesn’t deliver customer value, cut out or cut down features during release planning, cut out or cut down stories during iteration planning, cut down work-in-process to improve throughput. At the same time, focus on delighting the customer by frequent delivery of value.

Our goal as agile consultants is to ensure that the client understands the imperative for change, realizes that just because techniques are familiar and comfortable doesn’t mean they are adequate, and rises to the challenge of adopting an adaptive mind-set. It’s ultimately leadership and culture that will enable agile to stick, or to become unstuck. Agile consultants also need to help the leaders adapt, by assuring them that we’re not here to impose anything, that hybrid mixes of traditional, waterfall, scrum and other practices should be introduced if their environment calls for it, and that our goal is to help them inspect their current environment and challenges and adapt to the right mix of agility that addresses their unique situation.

Summary

There are many enterprise-scale agile frameworks available, from SAFe to LeSS, and each has features that can help organizations in their evolution. We’ve reviewed many of them, and addressed their benefits and drawbacks. Agile consultants must be familiar with these, as our work migrates from team-level coaching to enterprise-level consulting. Ultimately, at the executive level as well as at the team level, achieving agility is a human exercise, and it requires that agile advisors can address the fears, myths, and dislocations that agility brings, and can persuade leaders and teams that the evolution, even with some associated pain, is worth the journey. From Spotify to Thoughtworks, agile advisory shops are looking beyond the “Agile 101” practices and considering the strategic and organization requisites for turning agility into a competitive advantage. To evolve from practice-based coaches to strategic advisors, agile consultants must take the next step beyond scrum or kanban and devise a strategy for persuading and guiding leaders to the adaptive mind-set that truly embodies the agile ideal.