For many non-technical people, agile development sounds like programmers playing fast and loose with the rules and releasing software willy nilly. It sounds risky, since new ideas don’t go through a long vetting and planning phase before they’re implemented. However, as organizations have transitioned to agile over the past five years, we’ve seen that early and frequent software releases actually decreases business risk. As a result, organizations are starting to adopt continuous integration and deployment. As features as complete, they get released.

This transition from waterfall planned releases to agile continuous deployment can be difficult to explain to clients and executives. It feels like new features and updates are unpredictable, largely because they are. But that unpredictability allows us to evaluate what’s working in the current code, change priorities when something needs to be fixed, and add new features based on user requests. Quick, small releases help us respond to problems, add functionality, and maintain code quality.

Clients, Here’s Why We Don’t Have “Notification Chains”

I’ve been at companies that have notification chains or approval sign-offs before every release. Developers don’t like working for these types of companies because simple updates can get tied up in hours’ worth of meetings or days waiting for approval. I have always found it frustrating working at companies that have notification or approval chains to release software. It’s inefficient and a pain for everyone involved and drastically slows down development.

The project manager has to spend their time concerned about who has and hasn’t signed off or received information. Anytime there’s a change to the release plan due to tests not passing, the PM would have to notify everyone all over again. It's extra stress and generally doesn't make developers feel good. Development isn't easy, and tests frequently don’t pass for many reasons. I don't want developers feeling as though the entire management team knows when they make a mistake.

Instead, our weekly standup meeting is designed to get everyone on the same page about new releases and features. I’ve built agile development teams because I believe agile is the best way to build software.

We Take Code Releases Seriously

Just because we’ve done away with notification and approval chains doesn’t mean we’ll release any code at any time. When we complete a feature, it doesn’t immediately get released. There’s still a release process that follows industry standards for agile software deployment.

Our Agile Code Review and Release Process

1. Engineer Code Review - This is the first level of review. Another experienced engineer on the development team looks for mistakes or vulnerabilities in the new feature’s code.
2. Manager Code Review - Once the Senior Engineer is satisfied, a manager reviews the code to double check.
3. Technical Sign Off - The Developer, Senior Engineer, Manager, and Technical Executive (CTO, Director of IT) all sign off on a final version of the code.
4. Release Implications - We create a rollback strategy, analyze potential risks, and prepare for contingencies in the release.

This process is solid and follows industry best practices. As you can see, it doesn’t involve anyone non-technical in the release process as it would significantly delay the release cycle. Non-technical parties can express their preferences, priorities, and concerns at our weekly standup meetings, where they’ll also learn about new releases a week before they go live.

Why Frequent Releases Mean Less Risk

There are many reasons not to complicate or slow the release process. Releasing quickly means each release is smaller, making the changes isolated and less impactful. If something goes wrong, our quick release schedule means we can roll back or fix the problems without much impact to the organization as a whole. The small nature of each release also forces us to prioritize our business objectives and determine which changes are most important and urgent.

These small releases also make quality assurance and auditing much easier. We can automate much of the QA process. Since we’re not working on long deadlines, there’s less pressure to “make the release” in the first place, meaning developers aren’t pulling all nighters and introducing errors into the code. A great side effect of frequent release is developers don’t get burnt out with big deadlines, and the development team will get better at continuous releasing over time.

Continuous deployment using an agile approach has many advantages. It mitigates risk, speeds up the development process, and leads to happier development teams. The shortest release cycle you can manage is often the best.