Always Agile

Building Continuous Delivery into an organisation requires radical change

While Continuous Delivery has a well-defined value proposition and a seminal book on how to implement a deployment pipeline, there is a dearth of information on how to transform an organisation for Continuous Delivery. Despite its culture-focussed principles and an adoption process described by Jez Humble as ”organisational-architecture-process not tools-code-infrastructure“, many Continuous Delivery initiatives fail to emphasise an organisational model in which software is always releasable. This contravenes Lean Thinking and the Deming 95/5 Rule – that 95% of problems are attributable to system faults, while only 5% are due to special causes of variation. Building an automated deployment pipeline can eliminate the 5% of special causes of variation in our value stream (e.g. release failures), but it cannot address the remaining 95% of problems caused by our organisation structure (e.g. wait times between silos). From this we can infer that:

Continuous Delivery = 95% organisation, 5% automation

Establishing a Continuous Delivery culture requires a change management programme more challenging, time-consuming, and valuable than any technology-based efforts. Donella Meadows recommended that to effect change we “arrange the structures and conditions to reduce the probability of destructive behaviours and to encourage the possibility of beneficial ones“, and we can achieve this by using the change patterns of Linda Rising and Mary Lynn Adams within the change management supermodel of Jurgen Appelo:

• Dance with the System
• Mind the People
• Stimulate the Network
• Change the Environment

To dance with the system, we propose a made to order Continuous Delivery programme, with a Tailor Made business case that emphasises reduced transaction costs and/or increased customer value according to the needs of our organisation. We must identify a Local Sponsor to support our efforts and a Corporate Angel to increase awareness, and we should communicate successful case studies to our stakeholders as External Validation.

To mind the people, we construct a collaborative, bottom-up change programme that encourages participation. We need to Involve Everyone from the outset, and apply a Personal Touch with each individual stakeholder to pitch Continuous Delivery in terms of their incentives. We should use Corridor Politics to promote our change initiative, Just Say Thanks to our contributors, and highlight value stream waste without dispute - as Morgan Wootten said “a lighthouse doesn’t blow a horn, it shines a light“.

To stimulate the network, we emulate the Diffusion of Innovations theory of Everett Rogers and exploit the social network that comprises our organisation. We must encourage Innovators to spark an interest in our change initiative, and then form a group of Early Adopters to offer us early feedback. We need to Ask For Help from Connectors to evangelise to their peers on our behalf, and by Staying In Touch with our supporters we can work towards an Early Majority invested in Continuous Delivery.

To change the environment, we focus upon changing our organisation structure and processes to instil a culture of Continuous Delivery. We need to radiate our value stream In Your Space to raise awareness of cycle time, lead times, and wait times using Just Enough repackaged Lean terminology (e.g. “average time to market” instead of cycle time). We must work as Bridge Builders between different siloed teams to reduce our communications burden, and we should develop our pipeline Step By Step to encourage the good practices and discourage the bad (e.g. enforcing decouple deployment from release in a user interface).

Building Continuous Delivery into an organisation can be achieved by automating a deployment pipeline and implementing a change management programme, but we should remember Jurgen Appelo’s advice that changing people “is hard to do without an expensive operating table“. Our change programme must be tailored to business requirements, personalised for each stakeholder, and focussed upon improving the environment – and we should always remember:

Building a Continuous Delivery pipeline is easy. Building a Continuous Delivery organisation is hard

Continuous Delivery and DevOps are interdependent, not equivalent

Since the publication of Dave Farley and Jez Humble’s seminal book on Continuous Delivery in 2010, its rise within the IT industry has been paralleled by the growth of the DevOps movement. While Continuous Delivery has an explicit goal of optimising for cycle time and an established set of principles and practices, DevOps is a more organic philosophy that is defined as “aligning development and operations roles and processes in the context of shared business objectives“, and gradually codifying into principles and practices. Continuous Delivery and DevOps possess a shared background in agile methods and Lean Thinking, and a shared desire to eliminate Waterscrumfall silos – but what is the nature of their relationship?

In Continuous Delivery, practitioners such as Jez Humble have warned that organisations require “a culture that enables collaboration and understanding between the functional groups that deliver IT services“, which refers to the culture-centric principles – Continuous Improvement, Done Means Released, and Everybody Is Responsible – that reduce handover delays between siloed teams. DevOps provides an implementation strategy for these principles – its emphasis upon “the integration of Agile principles with Operations practices” aligns Development and Operations working practices and encourages cooperation. However, these principles can be also implemented independently of DevOps – for example, an organisation might forego a QA team in favour of mandatory Development support for production releases, as at Facebook.

In DevOps, one of the four key areas described by Patrick Debois is Extend Delivery To Production. The intention is for the delivery mechanism to act as a focal point for collaboration between Development and Operations, resulting in improved speed/reliability of releases and a sense of shared responsibility for production systems. Continuous Delivery offers an implementation strategy for this key area – a deployment pipeline provides a shared one-button workflow, encourages the emergence of a shared codebase and toolchain, and facilitates a release cadence that minimises change sets and the risk of failure. However, it should be noted that Extend Delivery To Production could be accomplished without Continuous Delivery – for example, a push-based Continuous Deployment mechanism might underpin the value stream instead of a pull-based pipeline, as at IMVU.

From the above we can surmise that Continuous Delivery and DevOps are interdependent, but the inherent fuzziness of the DevOps philosophy allows different interpretations of the relationship. For example, Jeff Sussna recently contended that “delivering software as service makes operations an explicit part of the customer value proposition… customers view functionality and operability as inseparable aspects of service” and that by defining DevOps “not in terms of how IT structures itself, but rather in terms of what customers expect” we can say “DevOps IS Continuous Delivery“. While it is an interesting approach to couple DevOps to customer expectations, the commonly accepted definitions focus upon internal organisational change in order to meet business objectives, which may or may not include operability as a first-class concept. It is evident that SaaS customers will have explicit operability requirements, but for many organisations the reality is that customers explicitly expect functionality and timeliness while implicitly expecting operability. For example, Jeff uses a restaurant review metaphor to describe the combined value of functionality and operability (“the food was great but the service was terrible“), but restaurant customers cannot observe back-of-house operability and will likely only comment upon front-of-house operability if it impacts upon functionality and/or timeliness.

Jeff also makes a comparison of nomenclature, suggesting that for agile development and Continuous Delivery the name describes the value… in the case of DevOps, the name describes the implementation, not the desired outcome“. Surely the desired outcome of DevOps is expressed in the portmanteau – Development and Operations teams seamlessly working together to deliver value-adding features to the customer.

Optimise accessible cycle time constraints, radiate the inaccessible

The goal of Continuous Delivery is to optimise for cycle time, so that we can reduce lost opportunity costs and improve our time-to-market. However, how do we construct a cycle time strategy, and how might it be implemented without a comprehensive change mandate? A study of Continuous Delivery experience reports and Lean Thinking suggests some common impediments to optimising cycle time:

1. Excessive rework
2. Long lead times
3. Incongruent organisation structure

From the above we can therefore form an ideal cycle time strategy:

Optimise cycle time = optimise product integrity + optimise lead times + optimise organisation

Optimising product integrity is essential as rework has a pernicious influence upon delivery cadence, highlighted by David Anderson stating that “unplanned rework due to bugs lengthens lead times… and greatly reduces throughput“. By using practices such as Acceptance Test Driven Development and root cause analysis as well as applying Continuous Delivery principles such as Build Quality In and Repeatable Reliable Process, we can trim our defect waste and gradually remove rework from the value stream.

Optimising lead times encourages us to recognise that unreleased product increments are valueless inventory, and that we should accelerate our pathway to production until we obtain a First Mover Advantage over our competitors. By introducing Work In Progress limits to reduce batch sizes and employing the Continuous Delivery principles of Automate Almost Everything and Bring Pain Forward, we can curtail our inventory waste and deliver value-adding features to our customers faster.

Optimising an organisation offers both the greatest challenge and the greatest potential for cycle time optimisations, particularly in siloed organisations. Despite being described by Jez Humble as a ”response to the historical expense of computing resources and the high transaction cost of putting out a release [that results in] lower software quality, lower production stability, and less frequent releases“, it remains a prevalent model despite its inherent coordination costs. By restructuring our organisation into product-centric, cross-functional teams and instilling the Continuous Delivery principles of Everybody Is Responsible and Continuous Improvement, we can eliminate our wait waste and obtain a significant cycle time reduction.

At the outset of our Continuous Delivery programme, a value stream mapping and analysis of product defects will likely indicate our expected cycle time impediments, and we should present these findings to our stakeholders along with our ideal cycle time optimisation strategy. However, the ambitious scope of our strategy means that without executive sponsorship our change mandate is unlikely to extend to such radical notions as establishing cross-functional teams. In this situation we should use the confines of our mandate to derive an organisation-specific optimal cycle time strategy:

Optimise cycle time = optimise product integrity + optimise lead times + optimise organisation

Rather than being discouraged by the limitations of our mandate, we can use it to guide our optimisation efforts according to constraint accessibility. If we cannot optimise the organisation, we optimise lead times. If we cannot optimise lead times, we optimise product integrity. After each successful change is implemented, we communicate to our stakeholders both the net gain in cycle time and the larger, inaccessible potential improvements:

Optimise the accessible, radiate the inaccessible

In this manner we can gradually build confidence in our Continuous Delivery programme, until our change mandate is broadened to encompass the comprehensive change required to dramatically improve both our cycle time and our product revenues.