How Can We Go Faster?

Across previous pieces I broke down delivery into various stages from a commercial strategy to a user's perceived experience. Ideally every stage is executed perfectly, and the flow is linear. If that actually happened I wouldn't have a lot to talk about. In short, changes at the beginning of the process can have serious consequences for everything that happens downstream. A change in commercial strategy can mean that you decide to build a completely different unit of software. Many kinds of changes to the idealised digital product affect the projected timeline and what the ideal digital factory looks like.

Bearing all of this in mind, we are often looking for ways to do two things: expedite the delivery loop, and reduce the number of iterations to reach an acceptable jumping off point. Both of these are working toward the same goal: how do we make this go faster? There are two approaches to this - to consider what is slowing you down in the present, and what can change for the future in order to increase your velocity.

Confidence is significant here. Confidence in individuals, in the broader team, the project, the digital factory, the digital product, particular technology choices, the business and the market. In a crisis of confidence, there is a shift from action to reaction and in a good case scenario, reaction translates to one or more of delays, meetings and additional work. In other scenarios it can be highly destructive.

This is not to say that we want to have high confidence when it is not warranted - we need rules and frameworks to protect both our time and our velocity that enable us to automate alignment and decision-making where possible. Ideally there is a shared understanding of what a dealbreaker is and what the priorities of the moment are.

Ambiguous priorities enable a situation where non-essential tasks can be addressed before essential tasks, and a similar dynamic applies for dealbreakers. It is fairly straightforward that in the lead-up to a release that a candidate exhibits abrupt session stops that this usually constitutes a dealbreaker. The more that we can enumerate the dealbreakers ahead of time the more efficient we can make the process of delivery from end-to-end. We may have a 'definition of done' for particular items planned for a release and yet in practice some criteria may not actually be dealbreakers.

Automated integration test infrastructure comes at a price but if you are interested in reliability at scale, that is the path. In the real world there are thousands on thousands of permutations of devices in the market, and they can't be trusted to behave equally. On balance avoiding issues before they happen turns out to be much cheaper than the alternative.

Sometimes issues appear in production. Again it pays dividends to know what your priorities are and it also pays to understand the general conceit of digital factories - that delivery of the digital product is achieved through emergence between interoperating systems, only some of which tend to be within the control of the business. For instance, when Apple releases a new version of iOS there is some potential for handshake agreements to be violated for software running on iPhones. The app doesn’t need to change in order to exhibit a failure mode, it is sufficient for the world to change around it. Without this understanding teams run the risk of a crisis of confidence.

If you have guardrails, you are in a much stronger position to throw (perhaps significant) pieces of work in the bin and replace them with new pieces that have a different set of trade-offs. The factory model of software is particularly helpful in communicating the dynamic that practitioners manage as effectively as they can. As we keep more promises, we tend to find that keeping all of them simultaneously becomes increasingly difficult.

Which brings me to the integration of concerns at other layers of delivery in a more broad sense, where the same principle applies. The independent game developer has no one but themselves to consult about the management of their own intellectual property, a contractor making a game for IP owned by Disney will have a markedly different experience. The smaller the pool of concerns and stakeholders, the greater the achievable velocity.

Appropriate technology choices can certainly help accelerate delivery. In previous posts I outlined what the work of a software developer looks like in terms of the investigation of issues and the formation of the plan. It stands to reason then that great technology choices should help practitioners perform this work effectively, and this broadly aligns with what we see in markets aimed toward developers and development companies. There’s a lot to be said about the evolution of technologies over time but I’ll try to be brief here - technologies like C++ and JavaScript (and their ecosystems) have been widely used for various purposes, and continue to be used today for good reasons. They were also originally built for a very different world and over time have like many other concepts I’ve written about, effectively become large and complex fields to master.

New entrants to the market of primitives (more specifically libraries, languages, frameworks) attempt to take what has been built in the past and refine it in some way. They face many of the same market-related challenges that consumer-facing software faces in terms of establishing confidence, building an audience and so on. Software practitioners weigh-up the intangible against the tangible. I’ll leave it as an exercise to the reader to determine which usually wins.

At an individual level one of the ways that developers have historically moved faster in delivering software is by selecting a handful of reliable primitives that they can be productive with and increase their depth of familiarity over time, a phenomenon reflected plainly in job descriptions for software developers. Today there is an expectation that developers go faster by depending on software to write code on their behalf, a technique made more feasible by articulating in human language the priorities and dealbreakers, an interdisciplinary act involving concerns of design, the product and the factory.

There is a lot said about developing an excellent instinct for what customers, actually want, and you can certainly go faster by understanding them sooner if the intention is to meet them where they are. A complementary way to go faster is to build a great team, and keep it together for as long as you can - a conversation that started in delegation and outsourcing.

When you are able to keep a good band together, you lose less time to crises of confidence, and members form an integrated understanding of the market, the business, the project, the factory and the product. They can leverage these understandings to both predict future decisions and make more effective decisions themselves. They internalise The Plan more deeply and therefore can reason about it more efficiently. I personally see this as the greatest missed opportunity in software today.

The world's largest technology companies have reached an understanding that you can go faster by owning as much of the supply chain as possible. This is not only a story about vertical integration and increased margins, it is also a practical requirement that emerges from many of the considerations we've been exploring.

Until next time.