Shared continuous delivery toolchain, the silver bullet?

Introducing a continuous delivery tool(chain) is not a silver bullet…

We have all been there right? There is a problem with the current way of working, processes are too slow, the system is too slow, it is too complex to use, too many handovers, all that stuff. A lean consultant’s paradise if you will. Then someone comes up with a splendid idea: “Let’s install this new tool (chain) and all our problems will be solved!” As easy as this sounds, usually in the real world things turn out to be slightly more complex unfortunately.

The clients I work for have these kinds of problems more often than not. Technological change is actually the trigger for a broader view on change itself. Take for instance the deployment of a shared continuous delivery pipeline. The reasoning behind it might have been something like: “Infra resources deployment for application teams is slow, we need a tool (set) to speed things up in order to satisfy our partner’s increasing needs.”

This is a perfect opportunity for improvement and might be an interesting business case to start off with. Not only will this speed up deployment of code, it will also reduce the time required to manage these resources and incentivize users to use standard resources instead of requesting specials, which will reduce the load on the managing teams even further.

The Continuous Delivery tool chain on its own is not a silver bullet

But then what? You now have a tool chain which facilitates code specification, and takes care of storing in a repository, deployment to containerized VM’s, automated network resource deployment, testing and release. No small technical feat on its own. However, having this capability developed does not mean the organization can actually use it.

For this you need to have a clear view on the scope of the problem, and therewith the solution. Meaning that when you are developing a tool chain capability, which is to be used by an entire enterprise, the change will have enterprise-wide consequences.

An enterprise-wide change is required

So what else DO you need? Several things come to mind, which are explained in detail below:

Maintenance team
Without this team developing and maintaining the tool chain, there will not be much of a capability to speak of. Next to monitoring the performance and availability for users, they are the ones who will be designing and changing new tools in scope of the tool chain. Supporting the users is integral part of their job.

Production readiness
Once you have the tool chain technically ready, the move to production might make for some serious consequences if (non) functional requirements from the rest of the organization have not been taken up in the design and implementation. These might be security related, or they might for instance be about alignment with enterprise architecture standards (regarding tooling), not to mention alignment with change management procedures already in place.

Defining the rollout approach
The rollout is where you start to really go to market with your product, actual users actually using it. In order to not create chaos and therewith a negative image right from the start, good practice is to start the rollout slowly. In this way you can test the waters, gather feedback and iron out the last wrinkles before you “go big”. A thorough look at the first adopters is necessary, preferably you want a team with some experience and the ability to co-develop the chain from a user perspective. The next team or batch of teams can use the first team as a knowledge resource for their own onboarding.

On this note, forming a community with a corresponding knowledge base will certainly ease the transition for other onboarding teams, so it makes sense to facilitate communication and knowledge sharing, perhaps even in scope of the tool chain itself.

Onboarding
Onboarding the teams in scope of the rollout means quite some planning and convincing the teams that adoption is a great idea. Selling the benefits to potential users is key in this phase. The onboarding of the teams and their applications will have impact on the applications. The act of onboarding will be seen as “more work” and without a clearly defined benefit, the teams will not be keen to adopt. To smoothen the process it might help immensely to have a support structure with hands-on help, FAQ’s and manuals.

To tie it all together, continuous delivery facilitation with a shared tool chain is great, but I really recommend to take some time to design the change from a broader perspective than just the technological one!

More about Agile Transformation for your business?

Do you want to learn more about Agile Transformation? Gisbert is an Agile consultant and coach, delivering change in complex corporate environments for 20 years. He has helped multiple Fortune 500 companies in their journey toward (more) agility, and incorporating the DevOps way of working. If you’re interested in an Agile Round Table or if you do like to receive more information, please contact us!