Preface
Practical men, who believe themselves to be quite exempt from any intellectual influence, are usually the slaves of some defunct economist. John Maynard Keynes
Keynes was speaking long before Digital and long before there was a software industry, but his words still ring true. In the world of digital business too many people cling to the old model and assumptions of the pre-digital age, an age when information technology was simply a means of making a business more efficient.
As this still-young century continues, it has become clear that the business world is increasingly a digital world. The software companies of the last century are but the prototypes of the modern digital business.
Digitization forces companies to rethink the way they organize to do software development, technology operations and business alignment. Digitalization also means new management paradigms need to be embraced and some old ones let go.
Continuous is an alternative management model for digital businesses – a management model, a new way for managers to think about technology. This book sets out that model.
Many practical men and women are today slaves to the project model of software development. The project model condemns many digital initiatives, programmers and companies to failure. Continuous offers an alternative.
The project model has always been a problematic fit for software development, but things have become more difficult in the last few years. The Continuous model supersedes the project model. Projects by definition end, but successful business doesn’t end and successful software doesn’t end. Agile and continuous delivery provide the tools for successful digital business.
The business is technology, and technology is the business.
When the business is based on technology, ‘finishing’ the technology destroys the businesses. The mindset encouraged by the project model – that software can be created as an independent activity and ‘finished’ – is anathema to digital businesses, where building technology is business building.
The rise of agile software development has made the problems with the project model more apparent. The arrival of Continuous Delivery1 (CD) broke many of the principles on which the project model was based. Digital business demands a new way of thinking.
Digital
Few businesses have not felt the effects of increased digitization in the last decade. Modern business is digital. Fewer still are the number of high-growth businesses that are not dependent on software technology. If you want to be a high-growth business in the twenty-first century, you almost certainly need to build on top of a digital platform.
The digitization of business represents a force so powerful that few businesses are unaffected. Unleashing this force in your business creates massive opportunities: not unleashing the force creates massive threats. To some this will sound counterintuitive. Flexibility, according to this line of thinking, comes from being able to assemble a team when needed. Agile thinking postulates the opposite: flexibility comes by having a well-practiced team that is available when needed.
Information technology is no longer a side-show, something that happens off to the side of the real business. In the age of digital business, technology is the business, and the business is digital. Having a separate IT function is a luxury few growing companies can afford.
In the digital company technology development isn’t something that happens elsewhere, bounded within a ‘project’ that will one day be ‘finished’. The business has technology running all the way through it, like traditional English seaside rock. If this is not true in your company, then ask yourself and all those around you, if you foresee the business growing in the next decade?
Next ask yourself and your colleagues: “If a competitor wanted to disrupt our business, how would they do it?”. The answer is – Digital.
It follows that not only are businesses digital, but business lines within businesses are digital. If a business line is to succeed and grow, the business line must be tied to an information technology capability, and that capability must be ongoing. Structuring technology change as a series of stand-alone ‘projects’ no longer makes sense. Projects end, but who wants their business line to end? Who wants their company to end?
Agile and continuous delivery
Before agile many companies and teams considered a three-month release cycle as aggressive; an annual release was more common. Agile started to ask teams to make fortnightly releases, or at the very least be able to release every two weeks. Being releasable was more important than actual releasing, because staying at a releasable level forced teams to keep a high technical standard and thus gave options to business customers.
The best digital teams have now accelerated far beyond every two weeks. The Guardian newspaper in London commonly releases several thousand times a week and Amazon.com releases on average every 11 seconds.
A release every two weeks still looks like an impossible challenge to an average team – typically one working inside some large corporation. But for the best teams a two-week gap between releases looks like an eternity.
Regular releases well and truly break the link between project end date and software release. The parameters of date, scope and quality at the heart of the project model are managed completely differently.
Agile had already relaxed the idea of fixed – or at least predetermined – scope, such as requirements or work requests. In a continuous delivery environment teams build all sorts of feedback loops. When done well these feedback loops cause work to be added – that is, teams discover more valuable work – and other predetermined low-value work can be discarded.
Unlike some endeavors, the relationship between quality and time/cost is reversed in software development. Higher-quality (code) is delivered faster and at a lower cost than low-quality code that requires fixes and is hard to change.
Project managers are trained to see a tradeoff between higher quality and speed of delivery: reducing quality reduces time. But in software development the relationship is inverse – higher quality requires less time. Those schooled in the project model have been making things worse by advocating lower quality to reduce time.
The best agile teams were always multi-skilled and cross-functional. Rapid continuous delivery is simply not possible when organizational boundaries force teams to wait on others. As a consequence the idea of project teams working with specialist parts of the organization needs to change.
Such teams need to practice together, work together, adjust behavior and fine-tune their work. It no longer makes sense to create special, temporary teams for projects. Teams need far more continuity. Each piece of work is a rehearsal for the next piece of work.
To some this will sound counterintuitive. Flexibility comes not from being able to assemble a team when needed, but by having a well-practiced team available when needed.
The project model always had limitations when applied to software development. The project model set out an approach that did not accurately reflect what actually happened in software development. As a result traditional project managers spent much of their time patching the model to keep it relevant.
When one has an inaccurate model of the world it is hard to make good decisions and reliable predictions. Iterative agile presented an alternative model of the world within which it became easier to make reliable decisions.
Continuous Delivery makes the project model an even more inaccurate model of technology development. Once managers and teams have a mental model that correctly describes the work they do they can reason more effectively, become more effective and deliver greater value.
Products, not projects
One frequent riposte is the claim that there are two types of company: project-oriented companies and product-oriented companies. Project companies do something, finish it and move on, while product companies continue to build their products.
Imagine for a moment you are the Product Manager for Microsoft Office. One day you walk into Satya Nadella’s office and say “Good news, project Microsoft Office is done, we can lay off the team and save some money.” Think what that would mean.
Microsoft’s second biggest cash-cow is dead.
Microsoft is a product company: Office, Windows, X-Box and much more. Unfortunately many product companies have succumbed to the project model: they do one project on their product, then another project on their product, then another, until the end of time. Product companies applying the project model delude themselves and make their work more complicated.
Software product companies can be considered the prototypes of modern digital businesses. Like modern digital businesses, their success depended on their ability to build software technology. But being Digital is much more than being a software business as of old. Being Digital isn’t confined to the product: being Digital cuts across everything.
There is much digital companies can take from the product model and mindset, but they need to go further.
Once upon a time…
Most organizations are structured along pre-digital lines – functional divisions and cross-cutting projects. Such thinking, including the project model itself, dates from the 1960s. Software people call this model ‘waterfall’ and date it to a 1970 paper2. Let’s remember 1970 for a moment; I was still in nappies, but…
In 1970 the IBM 360 Model 195 was the cutting-edge mainframe of its time. This machine had 10 MIPS of CPU power, 4Mb of RAM and cost $250,000 a month to rent (about $1.75m in 2018 terms). Commercial programming was in Cobol against an IMS hierarchical database running on OS/360. It used green screen monitors and teleprinters for output.
By 2016 one could buy a Raspberry Pi computer for about $35. This has 4,744 MIPS, 1Gb of RAM (which is 1,024Mb, so 256 times more than the IBM), and runs an OpenSource Linux OS that can be programmed in languages such as Python, Scala, Ruby, C and even Cobol if you so wish. The results can be displayed graphically on your TV screen. Plus a Raspberry Pi can be connected to an Internet of several billions nodes. In 1970 there were less than a dozen Internet nodes.
When technology has changed so completely, is it not right to question the management practices and models that grew up at a time when CPU cycles were expensive?
In 1970 planning was cheap in relation to expensive CPU cycles. In 2018, with CPU cycles too cheap to measure, planning is extremely expensive.
And now for something completely different…
This book sets out to describe an alternative to the project model for developing software. Why do we need an alternative?
Because digital competition changes the way businesses need to operate.
Because the tools digital makes available allow different structures and new thinking.
Because the project model complicates reasoning about software development, and is holding back further improvements in software development in many organizations today.
Because digital companies need to rethink the traditional ways of managing and find new, effective, models to reason about their world. Management models developed in the 1950s and 1960s are not necessarily the best for leveraging modern technology.
Paradoxically, in the age of hyper-speed and rapid change the project model is too short-sighted. In the digital age acting fast, in ultra-short timescales, requires thinking and structuring for the longer term.
Adopting a Continuous model rather than a project model does not mean abandoning everything in the project model. As with so many models – agile in particular – it is necessary to look beyond the label and consider exactly what practices and processes the label refers to. Some of these practices and processes may be entirely appropriate in other models.
For example, some regard planning, objective-setting and governance as inherently part of the project model, but they are not. As this book will describe, planning, objectives and governance can be a meaningful part of the Continuous model.
Yet there is still much in the project model that needs rethinking for digital businesses to advance. Creating projects, assembling teams, waiting for the team to become productive and then dismantling the whole thing before starting again takes too long. Structures with longevity and devolved authority eliminate the start-up and shutdown phases that take so much time.
I will do my best in these pages to outline an alternative model, a model that I call Continuous. This model is a work in progress. There are examples of companies that work without projects, but that does not mean that your company can simply copy these as they stand.
The Continuous model is still evolving. It may never reach a point at which there is a fixed model – in fact I don’t want to reach such a point. I want practitioners, managers and my readers to think!
I do not have a guaranteed risk-free solution. I have pieces of a solution that you need to examine for yourself and apply in your context. For this I recommend thinking, reflection and discussion.
Being an early adopter of this model may not be risk-free, but the benefits are substantial. Remember the old maxim: profit is the return for risk. Early adopters may risk more, but they will benefit more.