Sooner Safer Happier: Antipatterns and Patterns for Business Agility

by Jonathan Smart

In this new age, every company is an information technology company, whether they know it yet or not.

The organizations that are thriving are the ones that are leveraging information technology and treating software not as a cost center but rather as central to generating new business value.

in the Digital Age, you don’t write the same software thousands of times. Software is written once, rewritten a few times to improve it, and then runs thousands of times. Every software binary coming off the virtual assembly line is unique. People don’t know what they want and you don’t know how you’re going to write the software until you’ve written it. Only once it’s in the hands of people do they know what they don’t want and do you realize how you should have written the code. Rather than the domain of work being repetitive, knowable, and deterministic with known-unknowns (you know how to fix it if something goes wrong), unique product development is unknowable and emergent with unknown-unknowns instead. For something that has not been done before, you don’t know what you don’t know until you do something and get feedback.

Project management and Gantt charts come from two technological revolutions ago, optimized for the primary context at the time, which was repetitive, knowable, deterministic, and generally physical activity. The evolution in ways of working, with time studies, reinforced the notion of managers versus workers, with a command-and-control, order-giver, order-taker, behavioral norm. Productivity improved, however, at a human cost, with workers treated as cogs in a machine.

Where work is emergent there is no such thing as best practice. There is no one size fits all. Your context is unique.

Better is quality. Quality is built in rather than inspected in later. With smaller slices of value and multidisciplinary teams, changes are within a team’s cognitive load (that is, complexity that fits in your head) and there is a limited “impact radius.” There are fewer incidents and outages. There is less rework, less failure demand. More time is spent proactively rather than reactively.

Value is unique; it’s why you are doing what you are doing. It is of value to someone. It could be financial; it could be maintaining public safety; it could be charitable.

Sooner is time to market, time to learning, to pivoting, to de-risking, to avoiding a "sunk cost fallacy," to locking in ...

Safer is Governance, Risk, and Compliance (GRC), information security, data privacy, regulatory compliance and resilience in chaos, be that a cyber-attack or a global pandemic. It is customers trusting your organization. It is agile rather than fragile. It is speed and control, not one or the other. It is cultural...

Happier covers customers, colleagues, citizens, and climate, as it is not about “more for less” at any human or climatic cost. It is high levels of customer advocacy and colleague engagement with a positive impact to society and ...

A key theme in this book that is worth highlighting is “Go Slower to Go Faster.”

There will be quick wins, and it is a fallacy to try to do too much too soon. People have a limited velocity to unlearn and relearn.

We’ve implemented many mandatory, regulatory initiatives with a fixed scope and fixed date, with a need to cease business activities if not implemented in time, all implemented with agile and lean principles, all early and all successful. In these situations, a waterfall approach would have been too risky, with late learning and back-loaded risk. Due to agility and fast time to learning, having got early learning on the least understood and the riskiest bit of these activities, we were able to go back to the UK regulator and suggest that for the benefit of global competitiveness, they might want to update the legislation, which they did. Even regulation isn’t always immutable if you’re learning fast enough.

It is a huge pivot, how people work together, a mindset shift with a focus on outcomes over output, with finance, HR, compliance, internal audit, and real estate implications. This is a once-in-a-lifetime pivot in how human endeavor is organized. Therefore, building on all the bodies of knowledge to date, it is still a nascent topic and there is still much to learn. My intent is that this book will be updated in the future as we all continue to learn.

I would advise caution and not use this as a rationale to knowingly adopt an antipattern with a command-and-control, deterministic mindset. I would suggest starting with the patterns and experiment with fast feedback.

The successful pattern is to identify the top ten or so principles that you feel are most important to encourage across your organization, communicate them relentlessly, and recognize behaviors in line with them. They are positive behavioral guardrails.

Both of these initiatives tried to force a deterministic-way-of-working peg into an emergent-domain-of-work hole, but that does not make it magically work.

The premise of the Man Record Chart was to watch over workers and follow up on perceived idleness—a continuation of the command-and-control culture of Taylorism, with managers telling workers exactly what to do. While the result was greater efficiency, it also drove a strong “us and them, managers versus workers” culture

Work has moved away from hand-making the same thing repeatedly—effort that’s deterministic and has known-unknowns—to unique, knowledge-based work that is emergent and full of unknown-unknowns.

Are you optimizing for the fast flow of safe value with high levels of customer advocacy and colleague engagement? Or for role-based silos, where work is passed over the wall to the next role-based silo with little notion of end-to-end ownership?

Are you optimizing for value and time to value, or for pushing a “promise for a future solution” through endless gates and committees for years? Are you optimizing for fast learning and pivoting in order to maximize outcomes in the shortest possible time and with the least effort and least risk? Or for following a predetermined project plan with learning and risks back-loaded to the end with a large impact radius, big-bang implementation?

Are you optimizing for everyone using their brains to run safe-to-learn experiments to continuously im...

These organizations, in the context of new product development, had small, empowered, multidisciplinary teams working in small iterations and with a clear North Star outcome. They were empowered as to how to achieve the mission, within guardrails, and with a high degree of experimentation.

As Barry O’Reilly, author of Unlearn, has subsequently put it, “Think Big, Start Small, Learn Fast.”17

In Lean Thinking, Daniel Jones and James Womack outline five lean principles:23 1.Value: specify value from the point of view of the customer. 2.Value Stream: identify the value stream and all the steps in it, from concept to cash. 3.Flow: limit work in progress; stabilize flow; focus on lead time, throughput, and flow efficiency; alleviate impediments to flow. 4.Pull: move from a push-based system of work to a pull-based system of work; go at the capacity of the system of work and don’t over-produce. 5.Perfection: the relentless pursuit of perfection.

Lean production (suited to knowable, repetitive work) seeks to minimize variability, striving for perfection, in some cases targeting Six Sigma levels of perfection. Agility (suited to unknowable unique work) actively seeks and benefits from variability with multiple minimally viable, safe-to-learn experiments in order to optimize for outcomes.

getting closer to “you build it, you run it,” sitting people together in multidisciplinary teams, automating testing and deployment, and having a focus on failure demand, supportability, resilience, and observability all lead to better outcomes. Having to support your own product is a strong motivator to maintain high quality and supportability. The primary tribal identity is aligned to the customer, the value stream, and the product(s), not the job role. The team succeeds and learns together.

In The Unicorn Project, Gene Kim defines five ideals of DevOps:24 1.Locality and Simplicity: alleviate dependencies between teams and components. 2.Focus, Flow, and Joy: the smooth flow of work that enables focus and joy. 3.Improvement of Daily Work: continuously improve and pay down technical debt. 4.Psychological Safety: a top predictor of team performance; enables improvement. 5.Customer Focus: optimize for customer value, not for a role-based silo.

Once the weakest link in the chain is no longer the weakest link, little value will come from continuing to strengthen it. Identify the next weakest link, which could be project-based funding for example and alleviate that, before repeating forever!

Learning is late, with a high-stakes, big-bang implementation and a large impact radius. Late learning delays the realization of value and reduces the likelihood of maximizing value.

People are stuck in role-based silos, with no feeling of or actual end-to-end accountability. People are promoted and incentivized within their role-based silos, leading to finger pointing. “It’s not my problem. I did my bit. The hole is on their side of the boat.” The problem with big-bang, waterfall failures has been described as “the application development crisis.”

Applying a waterfall approach in the context of unique change is a thinking error. It is miscategorizing emergent work (unknowable) as deterministic (knowable). It is taking an approach that came about in the context of manual labor shoveling iron ore or building dam number 57,001 (tasks that have been done sufficient times before to be knowable) and applying it to unique product development (which has never been done before and is unknowable).

When considering the optimal approach to the type of work, it’s not about agile or waterfall. It’s about agile (unknowable, unique) and lean (knowable, repetitive). Waterfall is “Think Big, Start Big, Learn Slow,” for which, in my opinion, there is no excuse. Why would you not optimize for early and often learning, continuous improvement, and the ability to pivot for unique change in order to de-risk and realize more value sooner and improve outcomes? Even construction has adopted agile and lean principles and practices.27

Complicated: Sweet Spot for Lean

Whereas the previous two domains are ordered, this domain is unordered. There is no such thing as best practice or even good practice because activity in this domain is emergent. The best approach here is to probe by running a safe-to-learn experiment to test a hypothesis, to sense the results, and then to respond by amplifying or dampening the experiment.

Organizations often comment that they are at their best in these situations, with people coming together, irrespective of job role or business unit, working as one multidisciplinary team to quickly address the issue. Most then go back to their previous ways of working. Techniques stumbled upon in Chaos can end up becoming a new good or best practice in the Complicated or Clear domains for business as usual.

Software benefits from both an agile and lean approach. The software binary is agile-created and the path to production is lean, as the build, test, deploy process should run repetitively and with a high degree of automation many times a day. Periodically there will be step-change agile experimentation in the path to production and then back into lean again. Software is an agile-created box on a lean conveyor belt.

Both software systems and human systems lose information over time. Left alone they become less efficient and less maintainable. Software becomes obsolete and people, with a charitable intent, introduce bureaucracy, often with unintended consequences. The weeds grow back. Instead, we need to be tending to the garden continuously, keeping it “evergreen,” nurturing culture, upgrading the plane while flying, and avoiding behavioral, process, and technical debt, which accumulates with compound interest. Change and continuous improvement should be a sustainable habit, a constant process of experimentation, feedback, learning, and pivoting to optimize for outcomes. After all, customers are not just buying a point-in-time product, they are buying ongoing innovation and an experience. And people want to work somewhere where the way of working is sustainable, engaging, and humane.

Agile, Lean, and DevOps are not the goal. An organization can score highly on a “How Agile Are We?” test (or worse, “How Much Are We Rigidly Complying to a Specific Agile Framework?” test, or “How Many Scrum Teams Do We Have?” test) without producing better business outcomes.

Flow efficiency is the percentage of time that work is actively being worked on during its elapsed end-to-end lead time, as opposed to waiting to be worked on.

The wait time is usually caused by impediments to flow, such as role-based or time-zone handoffs or multiple committee review steps, leading to work being queued. A high wait time is also caused by organizations attempting to do too much work in parallel. The more

Lead time is time to market, the time from starting work on an item of value to getting it into the hands of a customer. Reducing lead time enables faster feedback, quicker learning, reduced risk, earlier monetization, and the ability to pivot sooner to maximize outcomes.

Throughput is a count of items of value delivered into the hands of a customer in a given time period. As lead time comes down, throughput should go up. If it doesn’t, then flow has an upstream impediment.