How to be Agile in the deployment process
At the beginning of March, thanks to the effort and motivation from Voxel colleagues, we have organised the Software Development Summit, a national online event where we shared knowledge and learnings from the software development world.
Edu has wanted to participate showing us his vision about agility, focusing on technical aspects that allow inspection and adaptation frequently, rather than risks and cost during the deployment process.
Specifically, he speaks about small and safe steps to properly deploy to production continuously and assuring fast feedback. If we don’t have anything in production we are not giving value to the user and learning from that experience.
Safe Steps
How are we going to make safe steps in the development process? Edu introduces to us the Psychological Safety topic as an essential factor to create high performing teams, paying attention to diversity and inclusion. However, that safety must be complemented from a technical perspective.
He highlights the importance of adding Quality from the beginning and XP practices are a great example, for instance with the premise of adding tests even before starting to code. Techniques such as TDD or BDD are very common and popular.
He also adds that in a complex system the error is inevitable, but it’s essential that the final user can not notice that. Therefore, the optimization of recovering time and the impact of that error are really important. Some techniques related to this topic are Dark Launching, Canary Releasing or Feature Toggles.
Small Steps, product-wise and technology-wise
Once we know how to achieve safe steps, we must focus on small steps. Edu points up that this is not just a product owner responsibility, the whole team should be involved in the whole product development process.
He expects teams with enough context and product knowledge and a defined strategy without many details at the beginning. He also insists on building code as an expensive task, even more if you speak about maintenance, so it’s crucial to avoid implementing unnecessary code.
In this sense, he recommends Vertical Slicing. With this approach we assure doing small steps, just thinking forward about 2 or 3 more increments. This way the team must put in production the implemented code to obtain feedback and know which steps they can do next. This process helps to create an experimentation mindset and, at the same time, maximize all the undone work, since we can obtain user feedback earlier and then avoid implementing that unnecessary code.
Those increments should be from 1 to 3 days from the product perspective and having always in mind value and learning. The method that Edu prefers for Vertical Slicing is the Hamburger method by Gojko Adzic because it’s really visual and simple to implement by the team.
Not just it’s vital to make small steps from a product perspective, it’s also a must to make small steps from a technology perspective, what is called Technical Slicing.
To understand the concept, we must distinguish deployment and release. First one is just code in production, second one is code in production visible for the final user. In that sense, it’s important to put code in production without visibility for the final user. This way, from the one hand, we will be able to deploy changes fast, check and iterate. From the other hand, we will be able to obtain continuous feedback from the deploy system itself.
The main techniques for Technical Slicing are Dark Launching, Branch by Abstraction and Feature Flags.
The process is divided into 2 phases. The first one is related to change isolation and code implementation in parallel. The second one is related to change validation and duplicities removal.
Small Batches
Once we get those safe and small steps from a product and technology points of view, we must think about how many steps can go to production together.
Edu explains that the optimal quantity depends on two variables, the cost and the size of the batch to be deployed, so how much each deployed batch costs according to the increments inside this batch. If we have too many increments (steps) together, how many errors can go to production without realizing it? How many people can we need to solve them?
In the end, the key is making batches as small as possible, having in mind that the goal of continuous delivery is to assure that that batch’s deployment is cheap and safe. The reason for an ineffective deployment will be a high cost or a wrong slicing.
As a summary, Edu’s idea about the secret of Agility is based on:
- Safe steps.
- Small steps through Vertical and Technical Slicing.
- Deploy code as frequently as possible through small batches.
From my own experience working with development teams, I completely agree with Edu. It’s vital to reduce the increments to properly deploy as soon as possible. This way we can not just reduce the uncertainty through continuous feedback, but also the cost of rework coming from unnecessary code.
Watch the talk again:
About the author:
