Principles of Continuous Confidence

Continuous Confidence is not a new idea. Over the years, I have spent many hours thinking about, and witnessing multiple development shops implement their own understanding of Continuous Integration. Time and time again they fail to completely succeed. There are moments when there is fresh air and people are happy, but then something comes along to spoil that zen moment. After looking at what was happening, I came to realize that there is much more to continuous integration than what is really out there.

People are funny creatures. When we have a problem, we try to find a solution. We will try anything and everything we can, that makes sense to us. If we don't understand it, then we shy away from it. If we are developers, we tend to judge the worthiness of a statement, and then if found lacking, we ridicule and mock it for not making sense. (Overstating the obvious for dramatic effect.) Here in is the key to understanding failure to implement Continuous Integration or Continuous Deployment in our shops: miscommunication.

At the very center of continuous integration and deployment, are the automated build and automated tests. We, as developers, invented this process. We said, Hey, let's build over and over again and test our code so that we know when something is broken or not. This was a great day when this happened. So we built the system and we started releasing code. But, there is a cultural break down that prevents the rest of our company from having the same trust we have in our tests and deployment mechanism. We say to the IT guys, hey, we are going to do this now. We tell sales and customer service, we have tests! And they don't believe us. They still don't trust us.

Here in lie the principals of Continuous Confidence.  We need to gain their confidence. So what do we do.

Communication

Communicate. Don't communicate in our terms, but in their terms. Ask them questions. Acknowledge that there is uneasiness. When someone asks a question like: are you sure nothing will break? Answer truthfully. No, I am not sure, but here is what we have done to guarantee it goes smoothly. Show what has been done, and help them gain that confidence in us.

Potential

Recognize all the people in our company as their full potential. Do we have people who have remedial tasks that feel they do little to nothing to help things move along? Do we have people that do limited tasks that don't directly influence the release of code? Recognize them for who they are and what they contribute. Recognize that they are untapped potential, and they need to be on board as well. 

Do we look at Quality Assurance as just testers? Do we view them as the final obstacle to releasing code? Do we focus on a them vs. us mentality? We need to stop this. Quality Assurance becomes a linchpin in the Continuous Confidence model. They become a key part to translating successfully the product requirements and making sure things are being proven they are done correctly.

Respect

This is finally, the most important principle of Continuous Confidence. Respect. We need to respect each other. Respect our strengths. Respect our weaknesses. Respect all people in the company and understand that we all want success. Be humble and listen to all people and encourage each other to participate in releasing. Shouldn't all people involved know when something gets out to production? Shouldn't all departments have confidence that we are doing things the right way? When we all respect each other to trust each other, then the customer ultimately will trust us as well. That is continuous confidence.