Over the years, software teams have had to learn how to evolve with their changing industry, not only with emerging architectures, technologies, and frameworks, but with newer approaches to development altogether, like Continuous Deployment. In this agile movement that we find ourselves in, the ultimate goal is to minimize the time between the moment we take on a task and the time we release it into the production environment. Continuous Deployment allows teams to release each feature when ready as opposed to grouping them together for a final release, creating a more efficient development process. However, for teams that use Scrum – like Scalable Path – continuous deployment throws some fundamental Scrum concepts (like sprints and retrospectives) into question. It also puts into question whether there are other – more suitable – project management frameworks to use in this context. In this article, we’ll look at whether Continuous Deployment impacts the Scrum process and consider how an alternative project management tool like Kanban may offer solutions to Scrum’s shortcomings.
Continuous Deployment is becoming a popular development approach. Today, it represents an important competitive advantage for companies and there are three key reasons why it is a valuable practice to adopt:
- It allows you to focus on your product.
- It integrates teams and processes in a unified pipeline.
- It improves productivity by automating and reducing repetitive tasks.
The Continuous Paradigm
Let’s refresh ourselves on the functions of Continuous Deployment. From the outside looking in, CD might appear to be a simple process, however, the capabilities that need to be in place in order to maintain and develop it are nothing but simple. It requires organization, quality, planning, and an excellent technical and cultural foundation in the entire organization. Let’s define some concepts and dive into the important questions that come with them.
- Continuous Integration: Code committed by developers is merged into the main branch as often as possible. Tests are triggered automatically to validate the changes, raising an alarm if an issue is detected. This practice helps detect problems early and reduce merge conflicts when compared to a more traditional build-release cycle.
- Continuous Delivery: Changes that have successfully passed through the CI phase are automatically verified and packaged to be made available for deployment to production, be it a manual release at the push of a button, or automatically via CD (below).
- Continuous Deployment: Deployment to production happens automatically, conditional on the successful completion of the previous steps. Features and bug fixes go live to users as soon as they’re ready, without manual intervention.
Achieving this process of integration through to deployment involves certain costs and skills, but even more, it implies maturity of the project and the team. The following checklist will help determine if your team and project are ready for Continuous Deployment:
- You have a modular application that is highly testable
- Your team is practicing test-driven development (TDD) and is able to provide sufficient test coverage such that manual testing isn’t generally required
- You have the necessary experience and resources to commit to automating your development processes for CI/CD, with a sustained overhead to keep it running and respond promptly to issues in the system as they crop up
- A plan for rolling back changes and deployments if required, and the ability to trace back problems to their origin
- Time and willingness to commit to documenting your CI/CD regime and related processes
- Enough confidence in your tools and processes to trust the outputs at your targeted level of automation
If you answered yes to all or most of the above questions, your project likely has the green light for compatibility with CD. These questions can also bring light to the best project management framework to use and, in turn, you will get the most out of the development process.
The Challenges of Being Agile in a Continuous Deployment Context
If you are familiar with Scrum, chances are you understand what it means to be agile. But how often do you look into other agile frameworks for a project? If your answer is “not that often,” it may be the case because Scrum comes with the assumption that this methodology is agile enough. Is it possible to be even more efficient when it comes to Continuous Deployment? And if so, what are the limitations that we may find when using Scrum in this context?
Before I contrast Scrum and Kanban in the context of CD, I’d like you to keep the following questions in mind, with regard to the core aspects of Scrum:
- Predefined goals, estimates, and time-boxing:
- Is the act of estimating tasks (as time or story points) before slotting them into a fixed-duration sprint in line with the iterative nature of CD? Or do these features simply act to facilitate the Scrum ideology?
- Ceremonies, artifacts, and roles:
- Is the reactive potential of CD lost when decision-making is scheduled instead of on-demand?
- Are the roles and practices associated with Scrum suitable for those participating in a CI/CD pipeline?
Now let’s dive in and consider Kanban as an alternative management framework. I’ll show that Kanban’s strengths allow it to act more harmoniously with Continuous Deployment when compared to the more rigid nature of Scrum.
Scrum vs Kanban for Continuous Deployment?
Goals vs Just-in-Time (JIT)
The nature of Scrum is such that goals are planned and agreed upon when preparing a sprint which, while active, typically remains unchanged. During a sprint developers focus on completing their quota of work in time for the end of the sprint, and then this process is repeated. Although CD can be used in tandem with Scrum, Scrum’s methodology puts developers into a mindset of locked-in priorities and timelines. This rigidity means that the potential benefits of priority switching and rapid deployment via CD are lost.
Alternatively, Kanban’s methodology allows the team to prioritize unforeseen events that need to be resolved and released immediately during the development process. While Scrum makes a list of items to resolve and then waits to complete the sprint, Kanban manages them immediately according to priority. Theoretically, Kanban responds better to the continuous deployment scheme because it is an implementation of the just-in-time method, where the key aspects are:
- Self-organized teams
- The Pull System to keep things going
- Zero error policy on completed tasks
So far Kanban seems like a better alternative, right?
Overhead vs Agile Manifesto
Scrum’s process and jargon-heavy methodology give it a notable learning curve and overhead to practice. The demands of its roles and ceremonies, but more significantly from the maintenance of its artifacts (categorized items and associated metrics) mean that a lot of time is spent “doing Scrum” instead of being served by the process.
Comparatively, Kanban is based on a more intuitive board of cards and is robust enough to cover the same pillars of transparency and adaptability that Scrum professes. The difference between them is that while Scrum pursues the good use and application of the methodology, Kanban seeks the automation of the processes (the same goal as CD). In Kanban, the goal is to make the workflow in the most efficient way possible to produce complete features and add the highest value that a team can deliver. It is a matter of focus. If you combine Kanban’s cardboard with CD, you will likely end up having pretty good metrics over the development process. The reason for this is that the team improves over one single category that is always visible to every member of the team, which ensures productivity limits and communicates results and team velocity openly. As I mentioned, this works towards the automation of the development process where CD also takes place in the automation of the release cycles, so we can see how they combine better.
Roles and Teams
Have you ever noticed that in the Kanban methodology, there is no facilitator or Scrum Master?
Instead, there are two key roles: the Service Request Manager and the Service Delivery Manager. The Service Request Manager understands the needs and expectations of the client and is capable of ordering tasks, similar to the Product Owner role in Scrum. The Service Delivery Manager is responsible for the delivery process to customers. Having a specific role that takes care of the delivery process is likely to be more suitable for the context of continuous deployment in which deployment can happen several times a day and aspects such as version control, traceability of changes, rollback, risk management, and monitor activities are essential. Comparatively, Scrum doesn’t have a specific role for this; it might exist as a member of the development team but not as its own role. In this case, often, what happens is the developer that is in charge of the delivery process likely has other tasks assigned, so there is no room to focus specifically on that part of the process. That is why I believe that Kanban’s roles maximize team capacity and simplify the process.
In Scrum, teams are usually multifunctional and self-managed, and during meetings like Scrum Planning or Daily Scrums, the work is assigned within the same team. Therefore, each member of the team, which is often composed of developers with different strengths and seniority levels, will proactively pick tasks to commit to that they can likely complete skillfully. Kanban works a little differently since tasks can be considered “mini” projects that have their own lifecycle and are not divided. And so, when using Kanban, it is important first to analyze how versatile the team is to decide whether or not every team member can perform any task at hand. Ideally, it is best to have a team of generalists using Kanban as it implies that everyone can take on any task regardless of its complexity, making the development process highly efficient.
Estimates vs. Development Driven By Priority
Scrum estimates are made either through the use of Story Points or by using a conversion to hours. It is a Scrum exercise that weighs items from a sprint backlog with other items of the same backlog to determine the development effort involved. On the contrary, in Kanban, tasks are addressed by priority, and there is a tendency toward non-estimation. Kanban maintains a constant workflow contained within clear limits of the work in progress, but unlike in Scrum, timeboxing doesn’t exist, and there is no such thing as “the end of the sprint.” The fact that Kanban has limits goes hand in hand with its ability to detect and prevent bottlenecks, not only because of the visibility of progress but also because of the commitment to deliberate results in an agile way without having to estimate them in advance. Overall, this reduces overhead in the planning process and adds efficiency to the development process. In contrast to Scrum, because it does have estimates and timeboxing, Kanban allows CD to work with an endless workflow, which works better in a continuous paradigm.
When it comes to supporting Continuous Deployment, it would appear that Kanban’s nature has an edge over Scrum in several regards. Primarily, its freedom from the timeboxing of sprints means that priorities can be shifted quickly to meet business needs. A necessary fix or newly-conceived improvement can flow through from its inception to being in-progress, and then through to automatic deployment at a rapid pace. Beyond that, Kanban’s roles for Service Request and Delivery managers appear more in-line with the flow of CD in comparison to Scrum’s more process-focused roles.
In an era where being first to market (not just for a new product, but also continued innovation) is critical, the advantages that arise from the combination of Kanban and CD are noteworthy. The tools and processes used by an organization should be empowering and work together harmoniously. Although Scrum’s structured framework has many strengths, some of its principles appear to conflict with that of CD, warranting a second look for its practitioners.
Given that there are many advantages to using Kanban for the context of CD, you may take an interest in adopting it, but being ready to make the switch involves other factors that are important to pay attention to. When choosing a new methodology, it’s important to understand how it works and the viability of being able to work with it. It may be the case that your current system is serving you well, or that a switch to Kanban (or even a hybrid approach like Scrumban) could benefit your organization. Ultimately, you must evaluate the options with your team and client in mind and determine what framework to adopt for the best results.
Are you looking for help with your next software project?
You’ve come to the right place, every Scalable Path developer has been carefully hand picked by our technical recruitment team. Contact us and we’ll have your team up and running in no time.