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 Environment | Relative stable, protected | Highly unpredictable with boundless market opportunities |
| Nature of task facing the firm | Efficient production of a standard product | Exploitation of rapid change and exploration of new market situations |
| Organization of Work | Clearly defined jobs in a hierarchical pattern | Completely free and informal. The communication process was unending and central to the organization concept. |
| Nature of Authority | Clear, defined, and vested in formal positions. | Self organization. Jobs are defined by the individuals concerned through interactions with others. |
| Communications Systems | According 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 Commitment | Patterns 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. |
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.
