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 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.

Machine Bureauracy Compared with the Organic Model of Organization

[2]

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 21^st 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.

[2] https://www.forbes.com/sites/forbescoachescouncil/2022/03/16/12-reasons-your-digital-transformation-will-fail/?sh=5122b2351f1e

[3] https://www.mckinsey.com/capabilities/transformation/our-insights/why-do-most-transformations-fail-a-conversation-with-harry-robinson

[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

Agile Orthodoxy: Taking a “processes and tools over individuals and interactions” Approach to Agile

There are editorialists in the Agile community who are eager to dismiss practices and frameworks they believe do not align with some orthodox interpretation of the Agile Manifesto. I can appreciate where many of these editorials are coming from because it is no secret that agile transformations fail and fail frequently [1]. The argument is the adoption of fake Agile practices and frameworks that are blatantly unaligned with the Agile Manifesto contributed to the failure. I have to disagree. Poor planning, lack of appreciation for the economic importance of how people work together, and the misuse of practices and frameworks contribute to the failure, and not the practice or framework itself.

It is an ironic paradox these kinds of tribal conversations are even taking place, considering the first value of the agile manifesto is “individual and interactions over processes and tools.” Declaring practices as agile or not is taking a “processes and tools over individuals and interactions” approach to agility. It highlights a belief there is such a thing as an “agile practice” or framework. Let’s be clear: there is no such thing as an “agile” practice or framework. There are recommended ways of working and collaborating that are known to help teams and enterprises start on their agile journey, but you cannot identify a practice or framework as agile or not. If that were the case, then every cargo cult team would be an exemplary agile team.

Let’s be very clear about what agility is: it is the ability to sense and respond faster than the rate of change. In business, it is a time-based strategy for gaining a competitive advantage for economic success. Kent Beck captured the essence of Agile in the title of his XP book “Embrace Change.” A little research quickly reveals agility has long been known as a competitive strategy that existed well before the term was appropriated for the Agility Manifesto [2,3,4,5]. Even 1950s coal miners applied what we would instantly recognize as an agile mindset to dramatically improve output[6]. Our beloved frameworks, Scrum, XP, LeSS, Scrum @ Scale, and SAFe, are proven means for starting a team on their agile journey. But they are not the goal or the only way an enterprise can start on its agile journey.

Case in point: back in 2001, I was collaborating on a book with Alistair Cockburn when, one afternoon, he suddenly phoned me and excitedly told me all about the Snowbird meeting. I just shrugged my shoulders because I have had the good fortune that many of the companies I had worked at had an agile mindset. Our 1980s and 90s software development practices would not be recognizable as Scrum or XP. However, our organizational culture gave us a major competitive advantage and enabled us to operate at a faster tempo than our competitors. In some cases, our fast tempo not only enabled us to respond faster than our competitors to market changes but also enabled us to drive the market changes that frustrated our competitors.

The Agile Manifesto made agility accessible to software developers and inspired many to think about better alternatives to software development than the so-called “Big-M” methodologies that dominated the enterprise landscape. While the Agile Manifesto appropriated the term Agile, it highlighted values that enabled fast sense and respond capabilities for a software team. It was a breath of fresh air.

The problem with using the Manifesto as some scripture to bless a practice or framework as agile or demonize it as not, is that it stifles innovation and improvement. Change is the very essence of agile. A “processes and tools” approach to agile makes the goal of agile to be compliance with a specific set of practices rather than fast learning cycles for improving outcomes. As an agile coach, my job is to help my client exploit agility as a strategy for economic success. My job is not to create a textbook example of Scrum, SAFe, DA, or any other framework. Just because a team can write textbook-quality user stories does not make them agile. What I really want to know is, can they predictably get something demonstrable and valuable accomplished within a timebox? What did they learn about both the product and the process? What would it take to shorten the lead time for that learning? Can they quickly learn if they are building the right thing? Can they improve outcomes by experimenting with and changing practices? Now that is Agile as individuals and interactions. I’ve seen too many processes and tools cargo cult organizations where teams go through the framework motions without any real understanding or choice about the practices they pretend to follow.

Agile is about learning and using that learning to improve both our product and process. Principled conversations, questioning, and challenging beliefs and practices are good because that is how we learn and advance our profession. After all, a few individuals questioned if our traditional big-M methodologies were the best future for software development and encouraged the emergence of the agile community. However, the puritanical dismissal of practices and frameworks that do not align with an editorialist’s orthodox interpretation of the Agile Manifesto diminishes the Agile community to a collection of competing tribes protecting their territory. Curiosity, learning, and advancement are stifled. Worse, these strong puritanical views are not just pedantic academic arguments. They have led to serious economic consequences for enterprises.

Scrum, LeSS, DA, SAFe, Scrum @ Scale, etc. – We all want the same thing: to help clients deliver value to customers, make improvements along the way, and, of course, make some money by helping them. After all, I have a mortgage to pay and a kid to send to school. I am not a charity. We just have different ways of doing it, but the end goal is the same regardless of the practices or framework chosen. Thus, we have common ground. The reality is our frameworks are sets of integrated practices that start an enterprise on its lean and agile journey. They are not an end to themselves. Dictating which practices “are agile” and which are not takes our attention away from managing outcomes and puts our attention on demanding compliance with a set of blessed practices. And that is not agile.

[1] Davenport, T. H., & Westerman, G. (2018). Why so many high-profile digital transformations fail. Harvard Business Review, 9(4), 15.

[2] Stalk Jr, G., & Hout, T. M. (1990). Competing against time. Research-Technology Management, 33(2), 19-24

[3] Richards, C. (2004). Certain to win: The strategy of John Boyd applied to business. Xlibris Corporation

[4] Freeman, C. (1969). T. Burns and GM Stalker. The Management of Innovation.

[5] Lawrence, P., & Lorsch, J. W. (1967). Organization and Environment: Managing Differentiation and Integration. Boston: Harvard University.

[6] Trist, E. L. (1963). Organizational choice; capabilities of groups at the coal face under changing technologies: the loss, rediscovery and transformation of a work tradition. London: Tavistock

Where the < bleep > is my car? An Overlooked Lesson from Toyota

We in the SAFe community love to tell the story of Toyota and how its development and implementation of Lean concepts manifested by the Toyota Production System gave Toyota a massive manufacturing advantage. We love presenting the House of Lean and wowing our clients with words like Kanban, Kaizen, Muda, and Gemba. We love coaching organizing around the value stream and delivering a flow of value. We love this because we see the real benefit Lean and Agile thinking brings to an enterprise. However, there is another valuable but lesser known Toyota story we should tell and and that is the harsh economic consequences of a “broken” value stream

A value stream represents the series of steps for how we go from some trigger event to the delivery of value, or as we often like to say, “concept to cash”. Value stream thinking encourages us to take a systems view and optimize for delivery of outcomes rather than taking a more siloed view and optimizing for perceived local “efficiency”.

Mapping the value stream helped Toyota engineers learn where there were wasteful delays resulting and remove them. Taiichi Ohno’s dream was to minimize the time from when a customer ordered a car until when it was delivered.

A broken value stream is when the flow of value is interrupted and delayed because organizational silos or practices artificially segment the value stream. Up until the mid 1980s Toyota was hampered by a broken value stream. In a situation we often find ourselves in, the cause of their value stream breakage was their artificial distinction between “business” and “technology”.

In their book “Competing Against Time” and also in an HBR article [Time- The Next Source of Competitive Advantage, HBR July 1988], George Stalk and Thomas Hout tell the story of Toyota’s “broken value stream” and how it effectively squandered their manufacturing gains. Until the 1980s Toyota was organized as the Toyota Motor Manufacturing Company which built cars and the Toyota Motor Sales Company which sold and distributed cars – technology and business. In the late 1970s the Toyota Motor Manufacturing company could manufacture a car is less than two days. However, the Toyota Motor Sales company’s entrenched bureaucratic organization squandered this gain taking nearly a month to process a sales order and deliver a vehicle. According to Stalk and Hout:

“Twenty to thirty percent of the cost of the car – more than it cost to actually manufacture the car – and more than 90% of the time the customer had to wait was consumed by the sales and distribution function” [Stalk and Hout, Competing against Time, pg. 68].

We can imagine the frustration this created for Taiichi Ohno where the whole point of the Toyota Product Systems was to “…reduce the time line from when the customer gives us an order to the point we can collect the cash”.

In 1982 the frustration boiled over and two companies were merged. The executives and directors of Toyota Motor Sales were replaced by executives and directors who trained in Lean thinking. New processes and management information systems supporting those processes were developed. By 1987 the sales cycle was reduced from a month to 6 days from order to delivery of the vehicle. The benefit of this time compression was far more than just a cost saving exercise. The ability to compress time in this manner gave Toyota a massive competitive advantage because they were able to go from “selling whatever was on the lot”, to “selling what the customer wanted”. The benefit of this is huge because the short cycle times meant Toyota was able to exploit fast learning cycles and discover what cars customers wanted. By reducing their timelines and embracing change they not only were able to turn over units more quickly, they could also command higher margins on their sales.

What is the lesson we should take from this lesser known Toyota story? Far too many digital transformations follow the pattern of Toyota’s broken value stream with the same results. While our clients obtain some economic gain from the ability of their technology teams to predictably create economic value we may not have really made a significant difference in our client’s ability to deliver value to their customer. Technology is only one part of the value stream just like Toyota Motor Manufacturing was only one part of Toyota’s vehicle delivery value stream. To deliver customer value Toyota had to receive an order for a car, manufacturing the car, and then deliver the car. Just manufacturing a car creates little value.

A common example of a “broken value stream” in software development is the hybrid agile implementation , often referred to as “agi-fall”, or waterscrumming used by many organizations. Even in organizations adopting SAFe to inform their way of working we see this pattern. The technology teams eagerly organize around the flow of value, but only within their silo.

Broken Value Stream resulting from a hybrid agile implementation

While in this model we may be able to predictably create software in a very short period of time what have we gained if it takes a year or more to ideate, review, analyse, and fund a project before it is even seen by the technology organization? What have we gained if it takes several months to release software after its done?

In the Age of Software and Digital, just like Toyota, we risk squandering the gains of Lean-Agile adoption when our focus is only the technology side of the value stream or just a short segment of our value stream. To compete in the Agile of Software and Digital we need to learn Toyota’s lesson and not squander our technology gains. We need to remember Lean and Agile are not just IT or engineering science experiments. Rather as Toyota learned they are strategies for successfully competing in the time compressed era of the digital business.

It’s not ALL about costs. It’s about ALL costs.

Good cost discipline is a core capability of any successful enterprise and every manager knows the consequences of runaway costs. If not outright risking the viability of the business, broken careers, and loss of trust are often result of blown budgets. Software development gets a lot of attention because it is frequently one of the biggest – if the not the biggest – costs for many organizations. It is therefore not unreasonable for organizations to seek ways to reduce their software development costs.

Agile methodologies and practices are often offered as an approach for not only reigning in but also reducing development costs. I have been at many clients where the primary motivation for adopting agile or going through a “digital transformation” was to reduce IT costs by some significant percentage, often 30 to 40% within two years. This is mis-guided. First, this turns the agile coaches into the hatchet people because everyone knows staff are the biggest component of software development costs. A 30 to 40% cost reduction means reducing head count by 30 to 40%. This is not going to inspire a lot of trust, cooperation and enthusiasm for adopting agile practices.

Second, focusing almost exclusively on development costs reduction risks increasing costs in terms of delays, inventory, over-processing and movement – the wastes of lean. While development costs is accounted for and visible, these wastes of lean are invisible and unaccounted for. Yet their impact can be more devastating than the development costs that appear as line items on the corporate ledger.

To illustrate this, let’s examine a past client to demonstrate how a sharp focus on development costs creates waste. At this client management was judged on their development cost performance and there were six teams working on a variety of different projects. Well the term team may be a bit of an aggrandization, because these were not dedicated agile teams. Rather these were project specific work groups with a Scrum Master and Product Owner. Each “team” had responsibility for one project. People were frequently allocated to multiple “teams” to ensure their skills were efficiently utilized.

This multi-tasking across multiple projects increased the organizations work-in-progress, a source of waste. Most developers were on at least 2 teams and often had other operational responsibilities. The result was at any one time there were a large number of incomplete projects with incomplete features in progress. There was a lot of activity taking place but very little value delivered. This is a classic example of the lean waste of inventory. Where is the line item for inventory? At least in manufacturing they do account for work in progress and manage their inventory levels. Why don’t we do this in software? The cost this inflicts is very real, yet we ignore it.

Worse, it is well known that such multi-tasking introduces a context swap tax – the time it takes an individual to switch from one task and get into the flow on another. Some studies place this tax at approximately 20%, while others suggest this may even be higher – up to 40% (Psychological Review, 104, 749-791, Multi-tasking: Switching Costs. Retrieved July 17, 2012, from http://www.apa.org/research/action/multitask.aspx]). The implication of this is that to “efficiently utilize our staff” by keeping them close to 100% busy, we are effectively reducing their effective work week by at least one day, and perhaps even 2. In lean terms this is the waste of unnecessary motion, moving the machine or staff more than necessary. Where is the line item for this in our cost accounting?

Another cost saving was supposedly achieved by outsourcing testing to an overseas company some 12 time zones way. I’m assuming part of the pitch for outsourcing testing was not only were the overseas testers a quarter the cost of the domestic staff, but development work could take place around the clock. While it may be enticing to believe in a 24 hour development cycle story, it is certainly hard to achieve. Outsourcing of testing introduced the classic lean waste of transport where work is regularly shipped from one organizational silo to another. This created significant coordination delays between developers and testers. Clarifications, explanations, and rework cycles were significantly slowed by the time zone delay and this was exacerbated by the lack of a shared clear understanding of the system between development and test. These coordination delays along with other bottlenecks in the testing pipeline meant that test often ran two, and even sometimes three sprints behind the development teams, further increasing the work in progress. Of course there was no line item for capturing cost incurred for “transportation”

In an attempt to reduce these coordination delays, the organization unbeknownst to themselves, added in the waste of over-processing – doing more work than necessary to create value – to their invisible waste ledger. The business analyst wrote highly precise specifications that approached pseudo-code in their formality and it was not unusual to see 6 page user stories. The assumption was of course writing precise user stories would compensate for the lack of a shared clear understanding between development and test and therefore reduce coordination delays. This approach completely defeats the intention of a user story. User stories are not requirements that are thrown over the fence to an unsuspecting team. Rather, user stories facilitate development speed because they encourage a conversation between the team and the stake holders. These conversations quickly align the team and stake holders and reduce the coordination delays. Ironically writing detailed user stories didn’t have the intended effect because they just tended to confuse the test team even more. Where is the line item for the cost of over-processing?

So how could we start making these costs – the wastes of lean – visible? There are several tools we can use. First the use of a Kanban board can make “inventory” or work in progress immediately visible. Second, a cumulative flow diagram can show the relationship between work-in-progress and cycle time and help us answer questions like, how long does it take for us to get something done and what this the relationship between WIP and cycle time (getting something done).

Finally, show the true cost in dollar terms of all that “unfinished product” – that is value we cannot realize because the work is not done. Al Shalloway suggests “any waste in the system will show up as a delay” and this gives us a powerful tool to put a dollar figure to cost of this waste. All the wastes I described above, motion, inventory, transportation and over-processing will manifest themselves as delays in delivering value. Let’s see if we can express in dollar terms the cost of these wastes by calculating the delay these wastes imposed on the initiative.

The goal of the initiative was to reduce call center costs and increase customer satisfaction by creating a self service portal for customers. We had a team of 11 people, and our “aggressive” plan forecast it would take at least 12 months to deliver the system. From my point of view, this just did not seem like a 132 staff month effort. It was mostly get some data from the data base, update it, put it back – bread and butter IT work. I asked the team, what would happen if we appropriated the conference room we were in, set up our workstations around the table and focused exclusively on this one system? The consensus was about 2 months, 3 months at the outside. So, call it 33 staff months.

It was estimated the self service portal would save about $45,000 per month for the organization. That means every month the self service portal was not in service, the organization gave up $45,000 of benefit. The invisible waste resulting from the near exclusive focus on development costs meant the company was delaying the release of the portal by 9 months and giving up $405,000 of benefit. Where is the line item for that? Of course the problem is this line item does not show up on the IT ledger, it is not IT giving up $405,000. Rather, it is some other siloed department in the organization. It’s not IT’s problem.

Not only were these costs another department’s problem, these delays were silently built into the project plan. Developers are asked for timeline estimates and gave those estimates based on their existing development practices, and then project management developed schedules, resource plans and business cases for these initiatives based on those estimates and resource allocations. Now multiply that waste across multiple initiatives and you have a loss of value situation that should have impolite words coming out of the c-suite.

As a solution we proposed a simple backlog of initiatives, with true teams – not work groups with an Scrum Master and Product Owner – “pulling initiatives” when they were ready to swarm on it. In essence we proposed a simple form of lean portfolio management. When we proposed this alternative to our patron it was declined because it would mean risking the mandate to reduce per team cost. Our patron’s mandate was to get the cost of a “scrum team” down to 50K per month and he was now looking at completely outsourcing coding and testing. That was the line item on his IT ledger and not the loss of value the wastes created. His mandate was not maximizing throughput and delivered value.

Further, there were the political realities of the organization. Few project sponsors would accept their project being delayed so development teams could focus exclusively on getting another sponsor’s project done before starting theirs. Despite the fact they would get their project sooner, the thought of a “rival” manager getting their system earlier was so distasteful that they preferred to incur massive waste for the organization as a whole. Everyone acknowledged the cost of this waste, but there was no benefit to them for reducing that waste and in fact, there was a greater likelihood they would be sanctioned for not meeting their cost reduction targets if they tried.

While in my opinion this was not a successful agile organization, they were of the opinion their new operating approach was better than their previous classical waterfall approach. Their delivery was more predictable than what they had experienced in past. I suppose we can call that a success despite knowing how amazingly better the organization could be. The dark horse on the horizon is of course a competitor who does see how amazingly better they could be. A competitor who realizes it not all about costs, it is about all costs.

Is Face to Face Still Ideal? Thoughts on Agile 2019

Note: I wrote this blog last year just after the Agile 2019 conference in August 2019. While interest in virtual consulting and training was finally moving from the fringes and into the mainstream, I thought it would be still at least 3 to 5 years before widespread adoption of virtual training and consulting. What a difference 9 months make. Now virtual could be the main service delivery mechanism as virtual work becomes the new normal. Tobias Lutke, CEO of the Canadian tech superstar Shopify said it simply, “…this is the end of office centricity”

The Agile Alliance “Agile” conference is arguably the premier agile conference. Each year some 2500 people gather together to learn, to see and be seen, to share ideas, and even share a few ideas over a few drinks. The “Agile” conferences are great places to catch the pulse of the industry. Of course, business agility is the hot topic these days, but one undercurrent that really caught my attention this year at Agile 2019 in Washington DC, was the rising interest in online or virtual consulting and training. For the first time that I was aware of, there was a real buzz about delivering agile training and consulting services online. Not as a cheap substitute for development teams in far off lands, or those who do not apparently warrant “the luxury of in-person delivery” but rather as a legitimate and perhaps superior way of delivering services.

I was at agile to deliver an experience report which told the story of how we leveraged online assets to give everyone on a large globally distributed SAFe solution train an equal voice in the SAFe problem solving workshop. If you are interested in our experience report, you can find it at the agile alliance website “The Sun Never Sets on the Problem Solving Workshop”. https://www.agilealliance.org/resources/experience-reports/. Our experience report was followed immediately by Joe Fecarotta of Accenture/SolutionsIQ who explained how he is successfully training and coaching Accenture staff online. Later Shane Hastie of IC-Agile (icagile.com) lead a session on Training from the Back of the Room (TFTBR) online. For those not familiar with TFTBR, these are practices which move the instructor away from the classic “talking head, death by power point” model of course delivery to a more participative learning model. Take a look at Sharon Bowman’s website https://bowperson.com/training-from-the-back-of-the-room/; if this interests you, and it should if you are doing any kind of training. Shane’s session was about developing practices for developing online participative models that are consistent with the TFTBR principles. Looking around the well-attended session I noticed many agile coaches whom I consider thought leaders in our industry. Simply, virtual training is moving from the fringes to the mainstream.

I am convinced the time for virtual training and consulting has come for many reasons. First simply the collaboration technology has gotten way better. We have always believed that face to face is conversations are best, and in absolute terms this is true. However, online is beginning to offer a fair approximation of a face to face conversation. When the manifesto was written in 2001, the Internet and online collaboration technology were in their infancy. In 2001 I had dial up for access. Now I have 300Mbits/sec coming into my house. It’s not just speed, it’s also the resolution of the HTML5 standards wars which means there are now amazing online collaborative tools. Second product development and especially software development is a global industry, and regular in person face to face meetings are often impractical. Third the millennials – sorry guys, I know you hate us old boomers referring to you this way – are moving into leadership roles and with them there is a major organizational change in attitude towards online collaboration. These are people who grew up in an online environment and are totally comfortable working there. I often like to joke if educated and experienced engineers could do what my daughter does in Minecraft I would be out of a job – seriously, if you have kids watch them playing Minecraft. Fourth is cost, easily 20 to 25% of the cost of a consulting engagement is expenses. Either my customer would like to save that 20-25% or I would like to have that 20 to 25% go into my pocket rather than Air Canada’s and Marriott’s. But it’s not just monetary cost. It is also the physical and social costs on the people who have to regularly travel to deliver those services. There are fewer and fewer people who are willing to travel.

Given all this we have to ask, is it really necessary to have a coach or trainer onsite day after day, week after week? Recently a family issue prevented me from traveling to a coaching engagement, so I executed the engagement for the week using a variety of collaboration tools like Slack. In our opinions, I was just as effective working from home as if I had been onsite. Of course, I had already established a strong personal relationship with my client because I had previously been onsite. However, this was a clear indicator that I did not need to be physically onsite every week. Furthermore, I am currently working a completely online engagement with a client where we are successfully launching a number of Scrum teams. We have delivered the all the training and coaching online. Of course, as per Shane Hastie’s Agile 2019 session, we had to re-design our course delivery style to leverage the online capabilities, but we were still able to deliver an interactive and engaging experience. Trainers and coaches do not need to be onsite week after week after week to successfully deliver services.

Finally, and most importantly there is an environmental reason for moving more of our work online and that is the carbon footprint for air travel. While air travel only contributes between 2 to 3 % of green house gasses, it is the small cadre of frequent flyers like myself who make up the bulk of airline passenger. For me it’s a bit of a personal paradox because I try to live a low carbon lifestyle. I don’t own a car, I mostly use transit or ride a bicycle. Then every week I fly across the North American continent expelling the equivalent of a year’s worth of driving in green house gasses. It is not hard to notice there is already a backlash starting against excessive air travel. Some academics in Scandinavian countries now have to justify their carbon budget if they choose to travel to a conference. It would not surprise me that if in 5 years frequent flyers like myself will be frowned upon much in the same way as smokers were.

I want to leave something behind for my children, and if I can reduce my carbon footprint, reduce costs to my client, be in my own bed at night, and deliver as good or better experience then I am all for it. It’s time to follow our children’s leadership and join them online.

Apollo’s Legacy: A personal reflection 50 years after the first Lunar Landing

Apollo 11 astronaut Buzz Aldrin stepping off the LEM onto the lunar surface

July 21^st marked the fiftieth anniversary of Neil Armstrong setting foot on the moon culminating one of the greatest human engineering achievements in history. I remember watching that first step on a friend’s black and white 25 inch console television set. My first thought after recalling that moment at the 50^th anniversary was “am I really that old?” But after that shock wore off my thoughts turned to value of the Apollo program. Was it worth it? After all the cost of that first step was the equivalent of hundreds of billions of dollars in today’s money.

Most people argue the benefits of the Apollo program in terms of the technological spin-offs. It is often suggested the modern semi-conductor industry would not exist today at least in its present form if not for the Apollo program. That may be, but I think the greatest legacy of the Apollo program was how it inspired whole generations to become excited about engineering as a career. How millions of young men and women were inspired, became engineers and worked to make people’s lives better.

Many people remember the late 60s as a time of social upheaval but many of today’s engineers remember it as the time that inspired them to become engineers. Not only the moon landing, but also TV programs and movies like Star Trek and of course Stanley Kubrick’s classic space ballet – 2001. Both painted a picture of a future we not only wanted to live in, but to also create. I wanted to design and fly amazing space craft. I wanted to be one of the pilots of the Orion space shuttle or one of the engineers who designed and built the Clavius lunar base. Or the creator of HAL – the amazing and psychotic Artificial Intelligence controlling the Discovery. I was going to create and live in the world of 2001.

The world I thought I would help engineer

Of course it was not to be. The reality was that in 2001 I wasn’t designing cool space craft or lunar bases. Rather I was sitting in a rather ordinary conference room on Earth in yet another project status meeting during the development of a new cellular telephone system. Somehow my career placed me in a cube farm designing telephone switches, and railway signalling systems. I can’t recall a cube farm in Star Trek, or 2001. Nor do I recall project status meetings. Worse, later in my career I became a candidate passenger for the Golgafrincham “B” ark, and became a management consultant. It’s really, really hard to be stuck on Earth when your imagination is in the stars. Or is it?

For those not familiar with Douglas Adam’s “Hitchhiker’s Guide to the Galaxy, the “B” Ark was an attempt by the Golgafrinchams to remove all the “useless” people from their society such as account executives, public relations experts, and of course management consultants by telling them the planet was doomed. The Golgafrinchams gave them the “privilege” of being the first to leave Golgafrincham aboard a giant space ship called “B” Ark.

Where Project Managers and Management Consultants may end up

Even though I didn’t get to design moon bases and space craft, much of the work I did created value for a lot of people. The work I did with thousands of others designing digital exchanges and cellular telephone systems dramatically improved the communications services available to millions of people around the world. Railway signalling enabled cities to increase the capacity of their transit systems. Maybe not as cool as a lunar base, but we made a difference in peoples’ lives. More than that I got to work with many amazing people and I even had fun doing it – maybe with the exception of the project status meetings.

While the technological spin-offs of the Apollo program are always cited as its lasting economic legacy, I think it was how the program inspired so many of us to become engineers. We didn’t get to build space stations or lunar based or psychotic AIs, but we created wealth and comfort for many. Every day people make phone calls, take a train to work, watch television, drive their car, turn on an electric light and get a drink of water without any thought does of the extraordinary efforts made to create this world. For me this is what it means to be an engineer, we make people’s lives better, and no one has to give a second thought about it.

So, what will be the next great engineering achievement that will inspire the upcoming generations of younger engineers. While I would like to think of an Apollo repeat, that is a Mars landing, I don’t see that has having the same impact as the original moon landing. We have done our job well and space exploration is just yet another interesting domain, one among many. What, I see in the so called “millennials” and generation “z” is an overpowering desire to make the world a better place. David Pink argues that people are purpose driven and the current generations of children and young engineers are inspired by making the world a better place more than ever. Coping with climate change, developing new energy sources and distribution systems, ensuring there is enough food, clean water, and proper shelter for a future with 8 billion people. Building the systems and creating the wealth that allow all those 8 billion people to live in comfort and dignity while realizing their aspirations will be our greatest engineering achievement.

Is “Business Agility” the Future of Agile? – Thoughts from XP2019

I just got back from a week inMontreal where I had the opportunity to actively participate in XP2019, the Agile Alliance’s 20th International Conference on Agile Software Development (http://www.xp2019.org), co-chairing the experience report track with Rebecca Wirfs-Brock and filling in as the Leadership symposium chair. XP2019 describes itself as a forum where Agile researchers, practitioners, thought leaders, coaches, and trainers get together to present and discuss their most recent innovations, research results, experiences, concerns, and challenges, and debate the latest trends. It’s a small and intimate conference where both practitioners and researchers are able to look beyond “the edge”. In keeping with this billing, and with it being nearly 20 years since the fabled Snowbird meeting, the theme for this conference was “Agile – The Next 20 years”.

With the growing awareness of “business agility”, one question raised was “is business agility the future of the agile movement?” There is no shortage of pundits now pitching “business agility” and, in this age of disruption, only the agile will survive – so clearly it’s time for agility to move beyond the data center to across the enterprise. I was able to “officially” contribute my point of view as a panelist on the Business Agility panel. From my perspective, the thought that somehow the agile software community is leading business to a bright “business agility” future is somewhat strange because, in my humble opinion, agility was a well known business competition strategy long before the famed skiing vacation at Snowbird.

We in the agile software development community can be a little myopic, only seeing the world through the lens of the Agile Manifesto. Agility as a business strategy is an old concept – perhaps a century old, perhaps even older. One only has to do a little research to find many writers and business thought leaders, such as Stalk and Thomas – Competing Against Time , Verne Harnish’s Rockefeller Habits, Chet Richard’s Certain to Win, and of course Jim Collin’s Good to Great all describing agility as a business success strategy in the mid 80s and even earlier. My favourite definition of agility comes from Colonel John Boyd who, in the 1950s, developed the so called Observe-Orient-Decide-Act (OODA) model [https://en.wikipedia.org/wiki/OODA_loop]. To paraphrase Colonel Boyd, agility is “learning faster than your competitors and/or the rate of change”. Lovely, simple, succinct. It does not take a manifesto of software development, or much imagination, to know what happens if you are learning slower than your competitors or slower than the rate of change. This definition moves agility from an inward software-centric focus of “…better ways of developing software…” to a focus on business outcomes – business success. The corporate landscape is littered with marquee companies who learned more slowly than the rate of change or their competitors. I am willing to wager some of those failed companies even had agile software teams – anyone remember Nokia? In the age of digital disruption it would seem that business agility is certainly a concept whose time has come.

However, I am ambivalent about the term “business agility”. For better or worse, we in the software community appropriated the term “agile” without fully acknowledging agile history. There is much we can learn from others and from history. Optimistically, I hope the term “business agility” will be the solvent that finally dissolves the artificial barrier between “the business” and “IT” because, the last time I looked, IT is part of the business and not some bag on the side. This artificial barrier not only delays the ability for the business to bring new products and services to market – think a bank wanting to offer a new kind of bank account or loan service – but also delays validating the business hypothesis of that product or service. We only learn if the product or service is valuable when it finally goes into service. This artificial barrier slows the build-measure-learn cycle. I am excited by the possibility of large enterprises becoming more nimble and able to respond faster to their customers needs and changing market dynamics. Business agility could create powerful teams that can exploit all of an organisation’s capabilities to quickly learn and validate a new business hypothesis. IT is no longer a cost center, but rather a strategic part of the business.

My greatest concern is that “business agility” will become a sales mantra to bring a myopic manifesto to the business. “Business agility” will be used to sell certification courses beyond the software teams, such as Scrum for HR, Product Owner training for marketing, “agile” accounting for CAs and CPAs. People will be able to add additional two and three letter designations to their e-mail signatures. Retiring project managers will have a second career as certified agile business coaches. Organizations will prefix their operations with “agile” and someone will claim to have a magic recipe that turns a company into a fast moving agile business. We’ve seen this movie before and it does not end well.

Two underlying themes emerged at XP2019… Has agile been commodified and gone off the rails? Is there a future for agile as we currently know it? These are juicy topics for future posts. For now, we need to focus on taking a pragmatic approach and recognizing that “agile” has a rich history and encompasses a wide range of ideas, and is continuing to evolve. There is no “one size fits all” solution. We need to help companies identify what they need to learn and understand in order to grow into more profitable and sustainable enterprises. Our pursuit of “business agility” is just beginning and there is a lot for us learn.

So Welcome Back

View from the Balcony of the San Francisco War Memorial Opera House

Mea Culpa…..I guess I deserved it. I ignored my website for a year and it “disappeared”. One of the advantages of being in “lockdown” is I have a lot of time to start working on side projects again. This website is my vehicle for sharing ideas and resources.

My first order of business is to quickly repost earlier blogs and start blogging on something that approximates a regular basis. My last blog post was from Agile 2019 where I observed a strong interest in remote training and consulting developing. Seems almost prescient with the pandemic. After I repost my earlier blogs I will start with a blog for what I think training and consulting may be like in this brave new world, or what Shopify CEO Tobias Lutke called ” the end of office centricity”.

Welcome back.