Your web browser is out of date. Update your browser for more security, speed and the best experience on this site.

Update your browser
CapTech Home Page

Blog | December 10, 2019

The Third Pillar in Digital Transformation? Delivering Iteratively.

yellow paper airplane that appears to have a shadow looking like a rocket ship
Brian Bischoff
Brian Bischoff

In previous posts, I have described how thinking iteratively and designing iteratively are critical components to digitally transforming an organization. You need to be able to rapidly and continuously generate new ideas, and your teams need to be cohesive across roles and departments. But what is the point of innovative ideas and intelligently designed systems if it takes six months to a year to get your solution in the hands of the people that matter?

That’s where delivering iteratively comes in as the final phase of digital transformation. In order to deliver iteratively (and thus quickly), you need to be able to support the following concepts:

  • Treat the quality of your product or service as importantly as its functionality
  • Enable continuous on-demand deployment

At first glance, these concepts may be less exciting than previous topics as they are more technical in nature; however, without focusing on these elements, engineering teams will have to spend more time on maintenance and troubleshooting, ultimately decreasing customer satisfaction and slowing the progress of new feature development.

Testing Equality

It may seem like a novel concept, but I am a big proponent of elevating the amount of time spent on the testing of new capabilities to equal that spent on new feature development. Note that I’m referring to automated testing – not manual. You might think that this amount of testing requires more time from the engineer, thus reducing overall throughput, but that is not the case.

There are few things more frustrating for an engineer than spending a sprint (or longer) developing a series of features only to find out weeks or months down the line that one of the features is no longer working. Allocating adequate time for engineers to create thorough unit testing helps prevent this scenario from happening. How? Unit tests, which are developed while creating new features and executed on every subsequent build, help verify that the change implemented has the desired effect and does not inadvertently break another part of the system.

In a Test-Driven Development (TDD) approach, teams write the unit tests first and then create the functionality. Once the features and unit tests are complete, before they can check in their code, the rest of the application’s unit tests must pass before integration with the whole. This allows the quality to remain consistent as new features are developed.

Automated testing isn't solely in the hands of the engineer. Business analysts and, at times, product owners can also create automated testing scenarios that can be run on demand, or as part of the build process, further adding to the quality of the overall product.

High quality process enables rapid delivery of new features. It can’t be ensured without rigorous testing.

Deploying Continuously

When I discuss deploying continuously, it is inclusive of both deploying the product to a live environment AND releasing it to users. While these concepts can be separated so that you can release to segments of users, this is an evolution of the ability to deploy continuously.

Deploying continuously doesn't mean you have to deploy every minute, hour, day, or even week. The idea of deploying continuously is having the ability to do so on demand, if desired. Increasingly faster deployment cycles are an evolution of the ability to deploy on demand.

To do so, you need to have your quality gates automated and the processes needed to deploy the software in place. Automation, once again, is key. Instilling DevOps processes to automate environment creation and software deployment is as important as the development of the features in the product. Without this consistency, your engineering team will spend significant time and effort on the deployment process and will need to repeat this effort for each and every deployment.


“Digital Transformation” can be an ambiguous phrase depending on your background and perspective. Leaders in many organizations may say that the phrase is no longer relevant since they have undergone at least some level of digital change. I think the term is still very much applicable but needs to be viewed through the lens of iterative transformation as I’ve written about throughout my blog series.

If you implement reusable processes and procedures to consistently generate new ideas, collaborate with cross-departmental internal teams to design and develop those ideas, and automatically and continuously test and deploy the solutions to your end users, you will be setting your company up to support your digital transformation needs now and into the future.