- What Is Continuous Delivery?
- Implementing Continuous Delivery
- Managing Projects with Continuous Delivery
- How Can I Tell If I'm Really Doing Continuous Delivery?
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Managing Projects with Continuous Delivery
There is no doubt that for teams new to continuous delivery, the discipline required can come as a shock. Many of your internalized intuitions about how a project behaves, including the interactions between team members, will need to change. The most important thing when implementing continuous delivery is, as with all agile methodologies, for teams to constantly reflect on what they are doing through regular retrospectives, and make incremental changes to their process to improve it.
Recalibrate Your Intuitions
Every project has a natural rhythm and narrative arc. Traditional delivery processes tend to report a respectable level of progress towards the beginning and middle of the projects. However, at a certain point, the customer and management team usually make an unpleasant discovery: While much work is “dev complete,” the application doesn’t work well (or at all) in an integrated state in a production-like environment under realistic loads.
At this point, the project enters “crunch mode,” with people working long hours under stressful conditions to try and make things work. This is extremely unpleasant for everyone, and indeed in some industries, crunch mode has become the norm.
In projects that practice continuous delivery where building, testing and deployment are automated from the beginning and acceptance testing is performed against every good build in a production-like environment, progress can seem slow at first. This makes team members, especially managers who are new to it, uneasy. However this demonstrates that things are actually working. The effect of continuous delivery is to bring the pain forward, so that steady, realistic, measurable progress can be made.
What you're experiencing is that "dev complete" is not the same as "done." In reality, “done” means released to users, or at the very least showcased to them from a production-like environment following integration and rigorous acceptance and regression testing. Much of the work to get features done happens after they are dev complete: the part of the delivery process often known as the last mile (see Figure 1). So continuous delivery, by insisting that no work can be considered complete at this stage—and of course there is no "50 percent done"—makes progress appear slower.
)
However, what you gain through continuous delivery is substantial. Firstly, because continuous delivery means your software is always in a releasable state, you remove the entire testing and integration phase that normally takes place at the end of the project. This in itself constitutes a huge reduction in project risk. These phases often result in serious problems being found—even major architectural shortcomings—that take an unpredictable amount of time to fix. With continuous delivery, these problems are found much earlier in the delivery process when they are cheaper to fix.
Second, you can get much faster feedback from customers and users on the new features you are working on. By practicing incremental development and continuously releasing software to users, you can get feedback on the new features early on in their creation process, making course adjustments as you go. As a result, the software evolves and adapts much more rapidly to meet the needs of its users.
Managing Incremental Development
Incremental development on mainline also requires close collaboration between analysts, testers, and the development team in order to break down larger features into small, valuable, testable, independent stories. This discipline provides several additional benefits.
Perhaps most importantly, it allows teams to separate what is essential in a feature from what is not, which allows customers to make very fine-grained decisions about scope. Breaking a "must-have" feature up into many small, incremental stories is a really effective way to winnow out what is the core part of the functionality and what is more peripheral.
You can then push out the core part of the functionality to users—the initial, most straightforward implementation—and test it to find out what users want to be able to do next. This gives the customer data that lets them prioritize what additional work they want done on a feature, or indeed if they'd rather spend that time working on another feature instead. And if the customer decides (based on the feedback) that the feature wasn't actually that valuable, you can stop right there without putting any more effort into it.
Incremental development depends on everybody pushing to mainline at least once a day, so that the application is continuously integrated. This seems impossible for teams used to working on long-lived branches for developing new features or for serving multiple customers. The good news is that working off mainline works, even for very large teams. The bad news is that it requires a well-architected application with loosely-coupled components. It also requires the ability to make new features available through the UI via configuration options, so you can make functionality that is in flight unavailable until it is ready. This allows you to continuously release your software, even when the team is in the middle of working on new features.
However the benefits are great: the ability to continuously deliver functionality that you are sure is valuable to your customers, without wasting time on stuff that you are only guessing will be valuable. Releasing valuable new functionality frequently is the best way to improve your revenue.