Beat the Odds of Transformation Failure Using the Vegas! Principle

Use the Las Vegas Convention and Visitors Authority’s advertising slogan, “What happens in Vegas, stays in Vegas,” to unleash people’s creative skills and beat the odds of transformation failure!

Second in a series…

Processes and Tools over Individuals and Interactions?

In a previous blog post [-], I argued many agile transformations take a “…process and tools over individuals and interactions” approach to their agile transformation. Such transformations introduce new frameworks, practices, and roles, all enforced by new tools. These transformations focus on the technical system and expect the social system to adapt. The reality of this style of transformation is we are often just replacing one machine bureaucracy with another.

Machine bureaucracies seek to control behaviour and are appealing because they’re efficient. With their standard operating procedures, well defined tasks, job roles, and reporting channels, there is little need to expend effort on discovery, experimentation, feedback loops, and coordination. Everyone does the same thing the same way. By controlling the behaviour of individuals and teams, we have consistent, predictable, and repeatable responses to known situations. The problem is that agile is about embracing change, and machines are notoriously poor at adapting to changes in their environment.

Long before the software community appropriated the term agile, Agility was a well-known strategy for economic success by innovating and adapting faster than the rate of change or our competitors. An agile transformation is far more than changing a few software practices. An agile transformation aims to enable an enterprise to succeed economically by embracing change rather than succumbing to change. The key is machines do not innovate; people do. In short, our agile transformation needs to unleash the creativity of our people, not control or stifle it.

An Organic Model of Organization

Instead of a bureaucratic machine-like structure, what if we model our enterprise as a system that readily adapts to survive in an ever-changing ecosystem? A system that naturally adapts to change and evolves. What if we view an enterprise through an organic rather than a mechanical lens? In this model, rather than viewing the enterprise as a machine bureaucracy controlling the behaviour of people, we view the enterprise as an ecosystem of organisms exchanging resources. In 1961, Tom Burns and G. M. Stalker were two British researchers who established the distinctions between the mechanistic and organic models of organization[1]:

 Mechanical (Efficiency)Organic (Survival)
Nature of EnvironmentRelative stable, protectedHighly unpredictable with boundless market opportunities  
Nature of task facing the firmEfficient production of a standard productExploitation of rapid change and exploration of new market situations  
Organization of WorkClearly defined jobs in a hierarchical pattern  Completely free and informal. The communication process was unending and central to the organization concept.  
Nature of AuthorityClear, defined, and vested in formal positions.Self organization. Jobs are defined by the individuals concerned through interactions with others.  
Communications SystemsAccording to patterns specified in various rules and regulations. Mostly vertical.  Completely free and informal. The process of communication was unending and central to the concept of the organization.  
Nature of Employee CommitmentPatterns of authority are informal and constantly changing as roles become redefined.  Full commitment to the central tasks facing the concern as a whole and an ability to deal with considerable stress and uncertainty.  
Machine Bureauracy Compared with the Organic Model of Organization


Vegas Becomes Organic (or maybe object-oriented)

While Las Vegas is the antithesis of a natural ecosystem, the slogan “what happens in Vegas, stays in Vegas” is certainly pithy and catchy. It gives us a fun metaphor as an organizing principle for creating a more organic, adaptive, and competitive enterprise. Applied to our world, this principle becomes “what happens in the team stays in the team.” With this principle, the team is the master of its way of working and is responsible for its behaviour. How a team behaves internally is of little concern so long as that team can effectively exchange work products and information and coordinate with other teams in the ecosystem.

Rather than creating consistency by forcing individuals and teams to comply with standard practices and ways of working, which can shatter team norms, we create practice guardrails that enable teams to coordinate and exchange resources with minimal prescription on specific team practices. Programmers reading this post may recognize this as an object-oriented approach where teams present a public interface, but their internals are private. This organizing principle encourages teams to own their way of working, freeing them to experiment, innovate, and learn independently if their interactions with the broader ecosystem remain productive and harmonious.

A SAFe Example

So, what does this look like in practice? We have applied this principle in several transformations that were adopting the Scaled Agile Framework (SAFe) to inform our way of working. We used SAFe to provide the necessary guard rails for facilitating resource exchange between teams and teams of teams (aka ARTs). SAFe provided a common taxonomy for the content hierarchy and a synchronized cadence for coordination. It also defined roles responsible for inter-team coordination. Finally, SAFe defines mechanisms for relentless improvement of the team’s way of working.

At the so-called “team level,” teams plan and coordinate their work using whatever way of working they decided was best for them, so long as on the outside of the team, they looked like a SAFe Agile Team. They have a Scrum Master (now called a team coach), a Product Owner, and a dedicated team. The team plans on the same synchronized cadence as all other teams, and if the team is part of an ART, then the Scrum Master and Product owner participate in ART coordination ceremonies. But what happens in the team stays in the team. Within the guardrails provided by SAFe, the team owns their way of working. They are truly a self managing team.

The same principle applies to ARTs (team of teams). On the outside, an ART must look and operate like a SAFe ART with an RTE, Product Management, and System Architect. The ART plans, demos, and retrospects on a cadence. However, how the ART is internally organized is at the discretion of the ART. In one case, we had an ART in a Solution Train follow a modified waterfall (sometimes called the Sashimi Model). Despite their early insistence that a waterfall approach was the only rational approach for them, they could still effectively work with and coordinate with the more flow based ARTs.

Outcomes of the Vegas Principle

I do not have hard quantitative data to support my argument about the benefits of using the Vegas! But these are my qualitative observations:

  • The transformation was viewed as less of something being done to the team and more as something they could participate in defining.
  • There was less resistance to the transformation overall.
  • Teams were more likely to take ownership and use the new ways of working rather than trying to just “feed the beast” and find workarounds.
  • Teams were more likely to use their retrospectives and experiments effectively to improve their way of working.
  • Teams readily shared their learning with their peers and leveraged learning from other teams.

One final observation was how, through experiments and learning, the different team’s ways of working tended to converge toward similar practices. One extreme example was the aforementioned “waterfall ART” that, within six months, began to move towards a more flow-based delivery model.

How our tools get in the way of the Vegas! Principle

The biggest challenge is that most agile lifecycle management tools are designed to facilitate enterprise reporting requirements and do not accommodate different ways of working or workflows. Tools are often used to enforce standard behaviours on teams. This becomes especially problematic when the enterprise rolls up and aggregates team data. Some teams work around this impediment by maintaining shadow workflows, often in Excel. This can result in misleading reports and missing leading indications of problems.

The Cost of the Vegas! Principle

Simply, it’s not efficient – at least from a machine perspective. The Vegas! Principle encourages ecological diversity, and any biologist will tell you that diversity is a key trait of a healthy ecosystem. However, that diversity requires significantly more energy to manage our way of working than using the machine model as our organizing principle.  I am sure everyone has heard teams and individuals complain about agile coordination mechanisms.

Machine models are efficient because they do not require teams to pay much attention or put much effort into their way of working. There is no need to spend energy scanning and re-evaluating the environment (e.g. double loop learning). However, machine models do not do well in a Volatile, Uncertain, Complex, and ambiguous (VUCA )world. The overhead of the ecological diversity created by the Vegas! is only worth it if we believe that to survive and succeed economically, we need to embrace change. Consider this: most farms only grow a single crop because of the complexity of managing multiple crops. Monocultures are efficient industrial farming. Of course, this lack of diversity exposes a farm to environmental changes (e.g., pests, weather) or the market.

Beating the Odds

Beating the odds of transformation failure using the Vegas! Principle means understanding your ecosystem by asking yourself a few questions:

  • What is the nature of the environment we operate in? Is it stable and protected or changing?
  • Do we succeed economically by being the most efficient producer or a faster innovator?

If our success depends on being a fast innovator, then the Vegas! Principle enables innovation and adaptation by unleashing the creative talents of our people.

[1]This is an abridged version of Burns and Stalker’s and only captures the extreme endpoints from their patterns of organization. The original table provides a continuum from purely mechanical to organic organization models.

[2] Derived from Burns, T., & Stalker, G. M. (1961). Mechanistic and organic systems. Classics of organizational theory, 209-214.

What can we learn from 1950s Coal Miners to reduce the 70+% Transformation Failure Rate?

Or did 1950s British Coal Miners Know More about Agile Transformations than 21st Century Agilists? First in a series…

Transformations Often Fail

It is an unfortunate, open, dirty secret in our industry that most agile transformations fail. Depending on how you define an agile transformation, nearly 70% (or even more) of these transformations fail to achieve their advertised goals[1][2] [3]. Why?

One root cause for transformation failure is they take a “…process and tools” over “…individuals and interactions” approach to the transformation. Agile transformations often focus on the technical system, introducing new frameworks, practices, and roles, all enforced by new tools. The expectation is for the social systems, that is, individuals, attitudes, skills, and values, to adapt to – even comply with – the technical transformation. However, entrenched hierarchies (e.g., silos), individual belief systems, social relationships, and loyalties often impede the adaptation of the social system to the new technical practices. There is a reason why the first value of the Agile Manifesto is “individuals and interactions over processes and tools” and not the other way around. Perhaps we can learn why such technically focused agile transformations have such a high failure rate from 1950s coal miners.

The Haigh Moor Coal Mines and Social Technical Systems

In the 1950s, post-war Britain’s economy was expanding, and so was the demand for coal to fuel that expansion. Yet, the newly nationalized coal industry was not doing well despite heavy capital investment in mechanization – processes and tools. Worker morale was poor, and turnover was high, along with high absenteeism rates. Except for the Haigh Moor seam in South Yorkshire. There, production was increasing, worker morale was good, and turnover was low. Researchers were dispatched to the Haigh Moor to learn why. They soon discovered that it was not just the introduction of new technology that led to substantial improvements. Instead, the dramatic improvement resulted from both the deployment of new technology and the mine management’s authentic delegation of authority to the miners to manage their way of working. Together, these changes enabled the miners to socially re-organize themselves into self-managing teams.  

The researchers observed, “The improvements at the Haigh Moor mines are an example of a socio-technical system where an organization’s objectives are best met not by the optimization of the technical system and the adaptation of the social system to it, but by the joint optimization of the technical and social aspects, thus exploiting the adaptability and innovativeness of people in achieving goals instead of over determining the manner in which these goals should be achieved[4].”

As Agilists, the lesson we learn is the improvement in the work system’s outputs result from joint interactions between these two systems. Thus, any design or redesign of a work system must deal with both systems in an integrated form””[5]

But perhaps as you read this, you are thinking, “Well, duh.” We’re agile, and that is what we’re all about. We’re all about creating self-organizing, self-managing teams. Really? That is what we like to say and maybe even want to believe. But who really controls the team’s way of working? In classical Fredrick Taylor industrial era machine models, management owns the way of working with which workers have little to no control and must comply with. This is where agile transformations often start to fall short on individuals and interactions.

While we speak eloquently about retrospectives, learning, and continuous improvement, what authority over their way of working does the team doing the work actually have? What can they experiment with to learn, change, and improve? Can they change their story workflow? Can they change their meeting agendas and frequency? Can they change story formats? Can they change their definition of ready and done? Can they even delete a story from their backlog? Can they change their team dashboards? Can a team make these changes without drawing the wrath of their Agile coach or some centralized Agile consistency group? Can they go beyond pedantic agile and take ownership of their way of working? Or must they comply with a top-down imposition of their way of working?

Meet the New Boss, Same as the Old Boss[6]?

A “processes and tools over individuals and interactions” style transformation accomplishes nothing more than exchanging one Frederick Taylor-inspired machine organization model with another. If we believe an enterprise is a social-technical system, and if we are genuinely seeking transformation like that of Haigh Moor mines, then what does a holistic joint optimization of both the technical and social systems, a genuine “individuals and interactions over tools and processes” transformation look like? What can we learn from 1950s coal miners about agile?

In future blog posts, I will elaborate on how we can create a genuine “individuals and interactions over tools and processes” transformation. Those blog posts will explain how software development is primarily a social process and how social processes have the biggest influence on outcomes, often swamping all other cost drivers. Subsequent blogs will introduce five principles for a more biological perspective on transformation that creates consistency without improvement killing machine model compliance. You can preview some of this content by watching a recording of my Agile India presentation, “Don’t Bulldoze the Swamp for Agile.

[1] N. Ramesh and D. Delen, “Digital Transformation: How to Beat the 90% Failure Rate?,” in IEEE Engineering Management Review, vol. 49, no. 3, pp. 22-25, 1 third quarter, Sept. 2021, doi: 10.1109/EMR.2021.3070139.



[4] Cherns, A. (1976). The Principles of Sociotechnical Design. Human Relations 29(8), 783.

[5] Bostrom, R. P., & Heinen, J. S. (1977). MIS Problems and failures: a sociotechnical perspective part I: the cause. MIS Q., 1(3), 17-32.

[6] The Who, Won’t Get Fooled Again