How we integrate Continuous Deployment into our Scrum Teams
When the Engineering department at Crunch began using Continuous Deployment on the Lead Generation family of Products, valid concerns were raised about how this fitted in with the teams that used Scrum.
Since Scrum prescribes that at the end of each sprint a potentially shippable increment was delivered to the Product Owner, who was then under their own jurisdiction to release, it was felt that Continuous Deployment would be problematic.
However, in practice it has worked differently. Each product backlog item that is worked on as part of a sprint, now strives to be a potentially shippable increment in itself, which the Product Owner can choose when to release. This has increased the importance of refinement sessions, where the team breaks down larger items into a series of features that can be individually delivered, whilst trying to continuously deliver value to the user. This means the user typically gets value sooner than if a more traditional release process was followed.
Towards the end of the sprint, when teams would typically spend time preparing code for deployment, our teams can continue working on delivering value to our users, since deploying code simply involves merging to the master branch.
Introducing Continuous Deployment has also encouraged the teams to collaborate more. Since we are striving to deliver value to the users early, the developers, designers and testers are working more closely than ever to increase the throughput of value to the user. This also means that there is greater overlap between disciplines and ensures that we aren’t practicing “Scrummerfall” (a waterfall process disguised within a sprint).
At first, since the item was often live days before the end of the sprint, the benefit of the Sprint Review seemed diminished since stakeholders often had an opportunity to review the work and provide feedback early in the sprint. However, the time is now focused even more towards providing feedback on the work completed, looking at what is upcoming, and ensuring that priorities are aligned. This frees up the Product Owner’s time during the sprint to work closer with the team. This also aids in increasing the levels of transparency between people and departments, so they are more aware of what the teams have been working on.
Our teams are constantly using inspect and adapt to improve our processes, which Scrum promotes. We will continue to make changes to our processes where we see fit and using Scrum and CD in tandem is a great framework to keep building upon.
Written by Samuel Catt, Scrum Master at Crunch. In his spare time Samuel is a competitive English Pool player taking part in a number of competitions.
Find out more about the Technology team at Crunch and our current opportunities here.