Making 'Agile' Business as Usual

“Agile” approaches to organizational life are in vogue.

Despite its very focused roots in Project Management in the Tech Sector, more companies are moving with great speed to integrate “Agile” methodologies into everyday ways of working. In mid-2017, Shane Elliott, the CEO of one of Australia’s biggest banks, ANZ, announced that the entire company was “going agile.” That’s right, all 50,000 ANZ employees were going to migrate to “agile” ways of working. ANZ is one of many organizations trying to capture the fairy dust of Silicon Valley. While the concept of “agility” is sexy in theory—offering customer centricity, less command-and-control, and fewer layers of hierarchy—its execution is much more problematic.

It is well documented that Agile approaches work for technology projects. Where organizations struggle is translating Agile approaches to Business-as-usual activities. Recently a government department received a high-profile project request from the Australian House of Representatives with tight timelines and skinny budgets. Government departments aren’t the least agile organizations in the world, but the stereotypes around Government bureaucracy exist for a reason. This department decided to try something different. They used Agile methodologies on the project with great success; exceeding customer expectation and generating a 15% cost savings to the already tight budget. But after the project, everyone returned to their normal teams and resorted to their standard, slow and bureaucratic, ways of working. Everyone on the project team agreed that many of the Agile principles could be used in their areas, but they were not being adopted.

Making “Agile” approaches a part of business-as-usual is tough. While “Agile” can reshape how we approach work across industry sectors, its integration into the rich web of day-to-day practices and existing policies presents the distinct possibility of destroying significant value and introducing massive risk to organizations. Understanding the common failures, and successful approaches to enabling behavioral change and embedment in everyday work, are critical to enabling Agile in business-as-usual activities.

Where We Get Embedding Agile Wrong

There is more to Agility than putting lipstick on a pig. Organizations that attempt to migrate to Agile approaches need to take accountability for their “inner pig.” Any sector can espouse Agile practices, such as SCRUMS, Sprints, and Stand-ups. That is the easy part. The challenge that most organizations face is that they layer Agile approaches on top of their existing social system, without addressing the intricate web of local practices and tribalism that have developed over time.

At their core, organizations are social systems, and they have ingrained ways of working that people are domesticated to. While organizations may have published operating models, crisply written work processes, and the like, the way work is done is very local and tribal. Work is social, and teams define realities and ways of working much more than any mandate or communications campaign from the head office. Changing these social systems, and the local ‘domestication’ that goes along with them, is a challenging proposition.

Simply adopting Agile events like stand up meetings may not make sense in the ways local teams work. “Stand-ups” are a familiar Agile event; they are 15 minute meetings in which teams actually stand and quickly tackle core work priorities. But, with an existing team that has 163.04 Todd M. Warner & Dr. Byron Hanson Making ‘Agile’ Business as Usual established ways of working, this purpose can be lost. One mining engineer working for a mining company that was becoming Agile related: “I attended a ‘stand up’ meeting, where we all stood around the chairs in a board room for 45 minutes (the meeting was supposed to be 15 minutes long), doing exactly what we’d done in previous meetings, but more uncomfortably.” Layering new Agile events on teams does little for any organization, besides creating discomfort.

“Agile” approaches frequently go wrong as organizations fail to take stock of how people are domesticated to certain ways of working in their local teams. Most traditional organizations have decades of local practices built up that inhibit the migration to anything new, including Agile. “Generations” of employees are brought in, and trained by those around them, and the local teams tend to police what really happens in any organization. These local working teams develop their own patterns for work, and their own forms of domestication. When any new-fangled approach from “head office” shows up, there is scepticism, and people circle their wagons to protect the status quo. Rather than building a new approach from the bottom up, Agile approaches are frequently layered on top of existing practices, work teams, and organizational processes, like leaves falling on top of a river. Anyone who has ever watched leaves fall on a river knows how it turns out for the leaves—the river wins!

For Agile approaches to work, organizations need to focus on embedment. One way to do this is to look to at high performers that thrive in your social system. Every organization has agile leaders; you just don’t call them that. Organizations attempting to drive Agile need not push “stock and standard” Agile methodologies on everyone in their organization. Agile is a philosophy, after all. Identifying Agile “routines” that emerge from the local work practices of high performers is a much more productive place for most organizations to start. To make Agile work within an organization, you have to build from how local tribes have learned to work, and how people collaborate with one another to get things done.

Companies outside the tech sector need to see Agile not as a collection of meetings to adopt, but as a way to rewire local practices. This means not only adopting new ways of organising and delivering work, but—more importantly—letting go of entrenched and guarded practices that work against Agility. Fear, control, and the status quo are stock standard artefacts of every organization; they are not, typically, sponsored by head office, but their existence will work to unwind any efforts to enable Agility. These artefacts emerge from the social side of work, with local teams creating realities, and the practices that go with them. Most organizations, and the people in them, have a difficult time giving up local practices around these things, as they have had a defined purpose in the past, and have led to local success.

Finally, Agile requires people to act differently—more collaborative versus hierarchical, more autonomous versus approval driven, and more just-in-time versus bureaucratic. But how do you do that? Most organizations facing this challenge rely on a list of behaviors to communicate what people need to do differently. Generating lists of behaviors or competencies seems to make sense to most HR departments, not to people doing the work. To enable significant behavioral change to be more Agile, a more embedded approach to behavioral change is required.

An orientation to behavioral change that enables Agile, needs to be applied, not abstracted. We once asked a group of high performing leaders about their leadership competency framework— 163.04 Todd M. Warner & Dr. Byron Hanson Making ‘Agile’ Business as Usual namely what the “effective communication” competency looked like, and how they did that as leaders. The leader couldn’t answer this other than to repeat the competency definition that was on the piece of paper in front of them. However, when we asked them how they conducted a particular meeting we had identified as critical to enabling Agility and effective communication, they told us amazing stories of effective communication in practice. Leaders understand leadership as the moments that matter and not in the abstract behavior terminology of HR. So, if you want your leaders to be more Agile, you need to give context and focus on the routines that need to shift in very applied terms, while taking stock of the existing practices that have emerged in local teams. There are two key considerations that can help organizations more rapidly embed Agility to their ways of working.

Rewire the Plumbing

Organizational processes and systems train people more than any corporate handbook or leadership development program. David Thodey, the former CEO of Telstra, tells a great story about trying to drive accountability into that organization. The mantra espoused by Telstra was, “value local ownership and accountability.” As Thodey made his way around the organization, he would frequently hear murmurs that many of the day-to-day processes that people had to work through, and that inadvertently “trained” them, communicated something very different: Procurement processes required weeks of paper work and eight signatures to sign off, people managing hundred-million-dollar projects had to get approvals from their boss’s boss for a $200 flights, and the like. Without rewiring facets of this “plumbing”—particularly those that impede local teams—any effort to embed Agile or any new approach will fail. We call these core processes and systems “functional rhythms,” because organizations tend to create a cadence around these activities. Core functional rhythms need to be interrogated and matured, 163.04 Todd M. Warner & Dr. Byron Hanson Making ‘Agile’ Business as Usual not only to be consistent with Agile approaches, but to address the ways that they contribute to the “domestication” of local teams.

To enable Agile approaches in business as usual, functions need to audit, and be held to account for, their impact on operational teams. Functions in most organizations wield varying degrees of power. If the functional impact on local teams is not wound down, people on the ground will point to a litany of impediments that suggest the futility of local “agile” practices. Organizations need to ask themselves what are the appropriate levels of risk assurance, governance, and compliance that are really required within functional domains, while allowing Agility to grow. They must also have mechanisms in place to continually challenge the natural inclination of organizations to add and protect bureaucratic clutter rather than reduce it. Only when leaders and teams can see the systemic barriers that they do not control shift and change to support their Agile practices will they be able to see Agility stick in local teams.

Identifying the Routines of Agile

When organizations oversimplify Agile by focusing on abstracted behaviors, or scripted meetings, they miss the criticality of context. For organizations to become Agile, they need to find the unique routines that will embed Agile in their social context. To enable Agile, organizations need to recognize that all moments are not created equal. Successful companies identify and leverage deeply applied, local routines that enable Agile in their social context. While the routines are unique to any individual company and social system, they tend to fall into three broad clusters:

Work Delivery Routines: This is the easiest collection of Routines, as Agile approaches were designed to get work delivered more quickly. The irony is that every organization has pockets 163.04 Todd M. Warner & Dr. Byron Hanson Making ‘Agile’ Business as Usual of agile approaches, and exceptional work delivery routines, in their social system, today! We don’t call them that, but they exist. Organizations should not simply overlay Agile meetings on top of day-to-day work practices and ask teams to adopt them. Rather, they should be studying their highest performers at any hierarchical level. Bell curves of performance exist in every field—from Doctors to NBA players—but they don’t have to be as broad as they currently are. If organizations can get better at using local language and pockets of excellence to drive improvement instead of relying on new ideas and imposed solutions, embedment (and performance) will improve. People tend to want to do well, and the best performers in any system do a handful of things differently. Not only will these localized routines make sense to leaders and teams, they can be the critical activities where Agile behaviors can cluster and be practiced to achieve more collaboration, innovation, and impact.

Collaboration Routines: In most large organizations, Agile is difficult because there are so many stakeholders to bring along on any journey. Organizations that are successful at implementing Agile approaches explicitly tackle the challenge of what collaboration needs to look like, and where it needs to happen. One local team in the financial sector developed a collaboration routine called the “Who” Routine, for responding to complex loan requests from institutional customers. Before the deal team progresses, they have to ask three questions: “Who” in the organization can help, “who” needs to know, and “who” needs to approve? They do this before they do anything else. This routine forces a collaboration mindset and stakeholder engagement at the right point of a deal: the beginning. Further, it creates discipline and speed in the team about who NOT to collaborate with. Because the practice emerged locally from some of the highest performing teams, the typical adoption barriers were avoided. Teams wanted to emulate what people in their system did differently to get results.

Organizations that are successful at enabling Agile approaches need to create intense discipline about where and when collaboration really helps. A focus on collaboration Routines clearly lays out accountabilities and minimizes the amount of work that people can design for others to do. Most people who work in organizations are well intentioned, but they frequently forget that their ideas and efforts are creating other work in the system. “Collaboration” as an overall organizational competency is misplaced; collaboration—like all routines—matters in particular moments, not universally, to enable Agile. Owning this work-creation, and focusing on the collaboration routines that enable critical interdependencies is vital to making Agile succeed in business as usual.

Feedback and Improvement Routines: Tech companies like Atlassian (an Australian “unicorn” software developer) use explicit routines that ritualise the practice of team building and improvement. Tools like Atlassian’s Team Playbook provide embedded routines where leaders and teams can provide feedback “health checks” and monitor team behaviors. Because the Atlassian Team Playbook was developed “by teams, for teams,” the adoption and use goes up. 163.04 Todd M. Warner & Dr. Byron Hanson Making ‘Agile’ Business as Usual Critical to Atlassian’s approach, however, is the obsession with feedback. Our research has found that your best leaders seek out feedback much more frequently than other leaders. Atlassian’s Team Playbook has some familiar “project” tools, but the bulk of approaches and tools are designed to build connection, empathy, and feedback as artefacts within the team.

Beyond individual and team feedback, a critical local routine for enabling Agility surrounds improvement. Agile approaches typically call for after-action-reviews, such as “Sprint Retrospectives.” The core of the “Retrospective” goes beyond challenging behaviors, but also challenges the system and processes that helped or hindered outcomes. In places where Retrospectives work, local teams own it, and their outputs have impact.

Examples of disrupting the status quo, and avoiding the calcification of business-as-usual, come from the Tech Sector, too. Spotify is one of the largest online music distributors, and they risk being lulled into self-preservation and complacency, but they have a specific credo that defines their organizational practices:

“Adaptive Over Prescriptive”: Does our enterprise invite disruption, or is the focus overwhelmingly more on policy and standards? Instead of asking “Why can’t it be done?” at Spotify we are empowered to seek answers to the question “How can it be done?”

Tech companies are terrified of the tyranny of the status quo that they see across other sectors. This has led Amazon to focus maniacally on the “Day One Problem”—getting all employees to think like it is “Day One” of the organization, and not allow clutter and complacency to emerge. Amazon has built their own local artefacts for innovation and improvement through their “work backwards” processes, which enables local teams to innovate and build customer-focused solutions for experimentation. Organizations seeking to embed Agile approaches need to create regular feedback and improvement routines, so that the teams own the approaches and integrate them—meaningfully—into their work.

Conclusion

To make Agile work as part of business-as-usual, leaders need to reorient to a different set of problems. Making Agile work in business-as-usual requires orienting to the nuances and peccadillos of social and organizational systems that their people have created. It is not merely a technical solution that is being solved for; merely imposing Agile events and methods on an existing system doesn’t work.

Work is done locally, in tribes. People in these tribes are internally referential—they care what one another thinks, and they protect their local practices. Added to this reality, over time, all organizations collect the clutter of bureaucracy, and become captive to a particular status quo. For Agile approaches to have any chance at surviving in business-as-usual, companies need to focus on rewiring their plumbing, by fixing and auditing functional process for their impact on teams, and focus on embedment through local routines.