The foolproof way to speed up the development cycle
Software development is hard. It takes time, concentration, and discussion to clarify needs and check the results. It's also impossible to predict in advance exactly how long something will take. In general, efforts at estimating the size of a piece of work are imprecise and subject to a high degree of uncertainty. Development is a fundamentally creative process. When you're operating in a complicated or complex domain, prediction is nearly impossible. New understanding and challenges emerge as the system grows.
In spite of this, end users always want things faster.
Often the pressure to speed up the development cycle is coming from outside: from impatient users, urgent bug fixes, and demanding executives. Increasing the speed of the development process is one of the few things that everyone in the organization can get behind. We’ve all become addicted to fast results in this hyper-speed era.
So what's the key to helping development teams to move faster?
This is a big topic, and I confess that the title is clickbait. As it’s said, “every time you build a foolproof process, someone builds a bigger fool”. Nevertheless, we can appreciate that a faster development lifecycle benefits everyone, especially developers and end users, because it reduces the gap between the creative work of developers and the feedback they need from users to know they're building the right thing. Any sophisticated endeavor requires feedback. The longer the development lifecycle, the slower the feedback loop. This reduces developers’ sense of meaning and purpose, and makes them less likely to deliver what people need. Not to mention the frustrating delay that users experience waiting for a feature.
Continuous delivery (CD) is the art of reducing lead time for changes. It's at the very heart of DevOps. The essence of CD is to see the delivery pipeline as a key part of the system that the team is building. The team is not just building an application, they are building the ability to change that system on demand. A good delivery pipeline is the core of that.
A delivery pipeline is the sequence of environments and processes required to take a change from development through testing into production. The foundational elements of a delivery pipeline are of course version control, automated testing, and automated deployments. But there are some other more foundational elements as well.
It is critical that all of the environments for development and testing be kept in sync. If you're building a custom application that's relatively easy, you can use containers to ensure a consistent environment every time. If you're building on SaaS platforms like Salesforce, it's more common to have long-lived sandboxes as part of the process. Therefore teams need rigorous processes to keep those sandboxes in sync. Another foundational element is having clear tracking of every change. The ALM or user story planning tool needs to be well-integrated with version control and deployment automation so that it's clear when work has been moved between environments, or is blocked by an issue. The status of a user story should change automatically in the planning tool as work progresses.
Those are some technical foundations for the practice of continuous delivery, but there are also cultural foundations. Teams need to be creatively engaged in the process of improving their own software delivery. This is an area where there is no substitute for human curiosity and playfulness: the wish of teams to improve their own tooling. The strongest teams are those that enjoy their work; where the work is gamified and they enjoy the experience of improving the speed, reliability, and visibility of the process.
To engage in those creative acts requires an environment of psychological safety, where all of the participants in the team feel comfortable experimenting with new changes without fear of repercussions if a problem emerges.
This atmosphere of psychological safety is invisible, and so its importance has long been overlooked. But almost every aspect of the software development process is invisible unless we develop eyes to see it. Security vulnerabilities, technical debt, and poor usability all require a trained eye to see them. The same is true for the cultural atmosphere on teams. Where there is psychological safety, there can be joy, learning, and experimentation. In its absence, teams may check all the boxes to complete their daily tasks, but are not likely to communicate openly and honestly about the challenges they’re facing, and may be afraid to invest time in improvements to workflow that could benefit the whole team.
In short, the key to speeding up the development cycle can be summarized as “improving the work is the work.” In other words, a team’s most important job is to optimize for the flow of change: both the flow of digital changes to a production system, as well as the flow of mental change through learning, communication, and experimentation. The foolish way to approach development is to go about our work with an uncaring attitude. The wise show respect for the work of every member of the team, and constantly strive to make work smoother for everyone.
