Making Delivery Faster

Problem

Being able to deliver faster is an unconditional imperative for software development. Businesses that can deliver their software faster will have a critical advantage over their competitors. A few years ago, while I was working in the real estate domain, our release cycles were two weeks with occasional one-week deliveries. While that seemed to be acceptable to our users, our business stakeholders wanted us to be able to deliver faster. To deliver faster, we had to improve some of our engineering practices.

Actions taken

For starters, I sat with my team and tried to understand where our process bottlenecks were. We tried to define what should be the ultimate goal we should meet and which would enable us to deliver faster. We started to inspect some blocking tickets and bugs that took significantly longer to fix to figure that out. By digging deeper, we tried to understand why those have been delayed for such a long time.

We realized that, in most cases, it was our dependencies with third parties, teams, and partners that were slowing us down. There were things we could control and some completely outside of our control. What we could control was how we ran our daily processes. We were agile on Scrum teams, but we could move some of our back-end and API pods to Kanban. So, we kept a few of our pods on Scrum and moved our back-end and API pods to Kanban. It wasn’t a massive process change, but it allowed us to get some of our releases faster.

We also established regular check-in meetings with the team to investigate why some tickets were blocked for a longer period of time. We named those investigations “blocking analysis,” during which we would analyze problems without pointing fingers. We would alleviate those blocked tickets on a regular basis, thus improving the overall processes within Engineering.

The thing we had less control over but still were able to exercise our influence had to do with our work with third parties, partners, and teams in other business units. We made sure that Engineering representative is participating in business meetings, and we created a feedback loop that allowed us to provide feedback and address those dependencies much faster than before.

After a couple of months, we were able to fine-tune our release processes and started release on a daily basis. That removed a lot of pressure that was put on the team but also appeased the business. We continued to improvise with our DevOps processes, ensuring that we could also release multiple times a day. The final result was pleasing to everyone: we were able to deliver faster, and by removing blockers, we also removed frustration our engineers got to experience.

Lessons learned

• There will always be dependencies, either inside or outside the team, inside or outside the company. In those situations being able to deliver or solicit feedback early on is critical. If you are waiting for someone or something to happen, raise your concerns as soon as possible and have other people understand the importance of it. Communication is often overlooked, but it is a central piece of any collaborative effort, and therefore, crucial for Engineering.
• As with any change, initially, there was some resistance to go with daily releases. However, in a short while, even those people who thought it would add to our processes and were skeptical were soon persuaded by the benefits daily releases were bringing to everyone. In fact, we didn’t add but remove some of the processes making the whole journey more lightweight.