What you will learn in this lesson#

• Understand how software management principles have shaped how we work with digital design

• Learn how we can get designers and developers to collaborate through a shared language

From waterfall to DevOps#

Let's look back a few decades. Most software was made within large organizations that could afford expensive computer hardware and the few knowledge workers (such as programmers) who could create functional software. The circumstances were essentially high cost and high risk, with a low number of skilled workers and organizations that were organized by department or specialization. Like a natural extension of the Taylorism and Fordism of the industrial age, the thinking went that work could be sliced into discrete, known units: more or less a kind of assembly-line production. By virtue of being understood and known, these units would be possible to plan, manage, and act on with a high degree of precision.

This led to the so-called Waterfall method of project management. While there are variants of this, the model prescribes that the initial phases–the design steps, as such–are to be done before executing on their implementation. Heavy up-front planning is assumed to be more efficient than taking risks dynamically while implementing the work package.

This was only further exacerbated by the later notions of "just-in-time-delivery" and economies of scale. Because markets were less volatile, the economy was less global, and services were physical or mechanical, planning cycles could practically afford to be longer; the world was more predictable. The events of the ongoing COVID-19 pandemic have shown that this planning fallacy lacks resilience and is unfit for highly variable environments.

Let's roll forward to the present day. For the last twenty years, the circumstances have dramatically changed with the extreme frequency of change, globalization of the economy, and move to a much higher degree of digitally-rendered services. Culturally, we also have very different expectations in our workplaces today. We tend to expect flat organizations, higher individual agency, and natural day-to-day relationships with cross-functional teams or colleagues.

The game-changer that—at least in many places—broke the rule of Waterfall was Agile, initially concocted by a group of software developers who concluded that traditionalist management techniques brought more problems than solutions to the context of software development. As you can read in the (very short) Manifesto for Agile Software Development, values became more important than any specifics of orthodoxy and methodology.

More recently, Agile, which was and still is really about principles and less about specifics of execution, has pollinated an extended range of more concrete approaches. The one that's had the biggest impact is arguably DevOps. DevOps is a philosophy and set of practices that aim to bridge development—often from the initial design and creation to operations and the long-term maintenance of a system. For a long time, the divide between these had created acrimony and inefficiencies. This bridging of the development process drastically cuts down on the cycle time from identifying a need to putting the work in the hands of customers. The Agile approach also takes a vertical responsibility of everything needed to conduct one's work—from idea to maintenance—rewarding teamwork and promoting a certain degree of generalization of skills, instead of the previous love of skills specialization.

A few of the major reasons the shift from Waterfall to Agile could happen with relative ease were:

• IT operations (including software overall) were able to be codified through developments like Infrastructure-as-Code

• Cultural mindset change, not least in organizations

• Successful start-ups having effectively challenged the industry and conventions of previous-era top performers

• Waterfall and Agile-ish frameworks (such as SAFe) were statistically proven to be less efficient (i.e., costs more for less value) than pure Agile

Common themes here are: code as a shared language, and that change is not a technical decision.