Continuous Delivery – Part 4

Share

Still not convinced that your organization can move to continuous delivery? In our fourth and final post on continuous delivery, we’ll summarize the previous three posts and look at one final ingredient.

Remember that continuous delivery is one of the guiding principles that underpin the Agile Manifesto. That principle reads as follows:

Our highest priority is to satisfy the customer
through early and continuous delivery
of valuable software.

There are three key enablers of continuous delivery as defined by Jez Humble – automation, patterns and practices, and collaboration. Having the right tools in place enables automation. Patterns and practices are established through well-defined processes. These processes can possibly take advantage of whatever tools you put in place to enable automation. Ultimately, the members of the team, the customers, and the stakeholders must work together to remove any impediments to continuous delivery.

In support of these key enablers, we next talked about three secret ingredients. Those were continuous integration, configuration management, and automated testing. Continuous integration ensures that changes are applied across all necessary environments when completed so that coding is done from the known baseline and that any testing activities take place against approved code. Configuration management has to do with the processing environment, coding standards, issue and defect tracking, and version control. Automated testing ensures that the same test cases are applied consistently for each and every time a particular scenario is tested. It also removes the overhead and human error commonly associated with manual testing, and allows a large number of test cases to be executed against the code.

In our last post we talked about addressing the risk of high-frequency release cycles. Concepts such as incremental releases reduce risk because entire blocks of code aren’t being released at once. Using techniques like feature toggles and blue-green deployment allow a release to be quickly turned on or off. Dark launching and canary releases get new features out either unannounced or to a limited set of users so that impact is minimized. One final concept we looked at is having a healthy Sprint Review meeting and an engaged Product Owner to ensure that the team is working on what the customer wants.

The last concept being introduced in today’s post has to do with governance and the involved teams. Adherence to such principles as SOX, HIPAA, and ITIL can slow down delivery cycles. Audit, compliance, segregation of duties and change management cycles can further derail a team’s efforts towards continuous delivery. But these can be overcome through involvement of the entire team from the outset. Roles and responsibilities should be clarified and communication channels established early. An ongoing dialog and an up-to-date status should be maintained on the Scrum board. Finally, even if things seem to be going well, continue the Sprint Retrospective to see what can be done better. Continuous improvement goes hand-in-hand with a high quality continuous delivery program.

Our series on Continuous Delivery has been inspired by Jez Humble’s presentation at Agile Alliance 2012. You can find the complete presentation by clicking here.

So what steps does your organization need to take to enable continuous delivery? Do you need assistance in the tools, the processes, the interaction and collaboration? Let Braintrust address those concerns and objections. With our experienced team of Scrum coaches, Braintrust can not only address these concerns but get your team up to speed on Agile methodologies quickly and efficiently. Click on the Contact page to hear from one of our product specialists. Or, head over to the Services tab to find out more about our offerings.