What Is Your Mindset?


Whenever I start coaching a new team and promoting an Agile and DevOps approach to software delivery, it is common for some teams to procrastinate or even resist an automated delivery pipeline. Some teams feel it is better to get features manually deployed into production as soon as possible and that the time to develop an automated pipeline will minimize the number of features that can be delivered. 

Of course, this is true. Time is a limited resource, and the time to develop automated release pipelines takes away from delivering “true” features.

Some teams do not think this way. They see the value in investing the time in automation with the belief that it pays off in the long run.

I conclude that a team’s position on this depends on what a team mindset is and what they consider value to be.

Linear Mindset

Some teams view the delivery process as linier manner. Here we manually create our Dev, QA and Production environments. 


We use version control and develop our product in the Dev Environment. When we are ready to test, we deploy the codebase to the QA Environment where the QA Team formally tests the product features. When a release has passed our testing, it is deployed to the Production Environment. 

Automation is not necessarily ignored, but the value comes from getting features into production as fast as possible. Time spent on automation takes away from delivering features into production. 

Teams who follow this emphasize the value of deploying features into production and minimizing that of automation. Their mindset causes them to have this perspective.

Cyclical Mindset


In reality, delivery is not linear—it is cyclical. We want to move through the development and test cycle and into production as fast and as easily as we can. The way to do this is to follow DevOps principles and automate everything if possible. Things that are not automated should be carefully documented. 

A full discussion on DevOps is beyond the scope of this article; however, some general points are highlighted below:

  • Infrastructure as Code – We can define each of our environments in code and store it in version control. This makes it easy to manage changes and deployments. 
  • Continuous Integration – As code is committed to version control, it is then compiled and undergoes unit tests. An artifact is then created for deployment to our other environments.
  • Continuous Deployment – The artifact created by Continuous Integration is deployed to other environments for testing. Integration Tests and Automated QA Tests are executed at this time. Manual testing is also performed.
  • Production Deployment – The same artifact we have been using is deployed to production. If zero down time is needed, we use Blue/Green deployment techniques.

If we expand this over the life of our product, the process looks like the diagram below. This allows us to deliver our product to our customer quickly and with high quality.


It is very hard to do all this automation, and it does take time and money. If you have read this and still think it is not a fit for your situation, consider the following points:

  • It is a very competitive world. If you cannot deliver software to your customer quickly, your competition will.
  • You do not know what your customer needs until it is in production and used. If you cannot deliver software quickly to your customer, you cannot respond to your customer’s feedback on time.
  • When defects are found, you need to fix it fast without affecting the process development.

Teams who have accepted this balance the value of deploying features into production and the value we get by automation. They understand the investment in automation has high value.

Learn More

Some links to more information on DevOps is included below: