AUG 16, 2019
By Jadwiga Osikowicz

How We Develop a Culture of
Continuous Improvement in ECConnect

In a perfect world, every time we rolled out code at the end of a sprint, it would work perfectly in production. There would never be any bugs or delays, and there would never be any issues that forced us to roll back code that has already been deployed.

Of course, we don’t live in a perfect world. That’s why over the years we have focused on constant improvement of the process of software development lifecycle, and have brought together methodologies and ideas from many frameworks to make processes individually suited to ECConnect.

Our goal of making the processes as streamlined as possible also made our team’s jobs easier (or more pleasant). Saving time and money, but also to get far better value out of our efforts and operations.

While keeping this article brief, I will explain ECConnect’s continuous improvement strategy within our team, how it was implemented, and how it relates specifically to the process of software development.

How it was before

We can’t improve something without understanding what it is, and how and where it is broken. The first step in improving our release management was to form a detailed picture of the current process and tools from many years of operation. We began with a number of brainstorming sessions with all the team involved in the development and release process.

We agreed that our deployment strategy was very old and manual due to several reasons:

• Time: The release process took long times to be pushed to production, there was software still waiting for a number of weeks after being completed. And we knew that delays in software releases have a negative impact on our customer satisfaction and could damage our ability to ship reliably.

• Risk: Of course, we don’t live in a perfect world. No matter how good our testing and QA is, some bugs only surface when the affected code is running in production. Over the years, we experienced many outages caused by releases. The bigger the release is, the more risk it contains with unforeseen impacts and especially if it needs to be rolled back.

• Stress: Our releases generally involved all of the team to be sitting in front of their computers at 1:30 PM, drinking lots of coffee (glad we have good coffee - thanks to Joanna :) , looking at server logs and incident reports and pointing and shouting and trying to get the big release working so our customers can start using the shiny just updated new software. Stress, stress, stress… We wanted to enjoy our work, not be stressed about it.

Overall, we agreed that our process became time consuming, risky and stressful.

What we decided to do

No big-bang Release Day anymore! We took pressure off the team so our Developers now can focus on building software, and see their work go live sooner after they've finished working on it. We started off at the pace of 2 releases each month, and gradually found our way to the pace of more than 2-3 releases per week on average. Sometimes pushing to prod seamlessly 2-3 times during the same day!

After a couple of months of intensive use, the team now knows the process by heart so now we are pushing to production features shortly after the development, testing and UAT is finished. This methodology also perfectly suits to company mission: Get The Job Done.

The process is still followed but we know that it does not need to be a formal process anymore. We are happy to say that the team has informalized the process.

We don't write anymore the kind of documentation that endangers rain forests and puts its readers to sleep. We provide documentation that people (technical and otherwise) can read and act on. We successfully adjusted the process to suit our needs and the needs of our clients.

The outcome

The complexity of deploying software has been taken away. We don’t have to spend days preparing for a release anymore. We release more often, thus accelerating the feedback loop with our customers. There is much less pressure on decisions for small changes, hence encouraging iterating faster.As we deploy small batches of changes, releases are less risky and easier to fix in case of problems. Our customers see a continuous stream of improvements, and quality increases every day, instead of every month, quarter or year. Is it that cool?

What next?

Our process is the best? We are happy what we have achieved over these recent couple of years, but is still in constant improvement. That journey continues today and we don’t see an end to it. We do not follow processes blindly anymore, we rather take the time to analyze what your goals are and are prepared to adjust the process as we go along.

Have you implemented or plan to implement continuous improvement in your organization? Comment below, let us know what you have been doing and if is working for you.


Jadwiga Osikowicz
Software Quality Assurance