A Brief History of Change

Companies used to be pretty static. Small changes were introduced over years. As a Global marketplace started to open up, companies realized the need to  change in order to remain relevant and competitive. Small changes can be effected by the in house BAU team whereas large changes are renamed as projects and these are facilitated by project managers. (That’s why there are so many project managers now compared to 15 or 20 years ago.)

As changes in companies multiplied some problems developed. Changes sometimes broke things and running multiple projects concurrently required changes to be carefully co-ordinated. This led to change management becoming another drain on resources. Companies would create change boards or CABs and these have to be staffed by operationally responsible people.

Most people think of a CAB as Change Approvals Board. In fact ITIL refers to a CAB as a Change Advisory Board. There is a world of difference between the two! Changes are often reviewed in CABs by those who know the existing state of play well, but know little about the change being introduced. These people rely on getting the right information from the PM and the Project’s architect. This in turn reduces the CAB to a paper exercise. “Fill in this 8 page document and we will consider whether your change should be allowed to go ahead”. This is exacerbated by the CAB being staffed by people who have the responsibility to keep things working. So there is a general reticence to introduce change.

A CAB should of course be a forum to schedule changes that might interfere with each other not a hurdle to progression.

(Almost) Up-toDate

So now to Etsy and Amazon.

In 2011 Amazon explained that they introduce one change every 11.6 seconds. That’s a lot of changes to get through CAB… unless of course they have a better solution?

Etsy have a policy of asking their new developers to release change to live on DAY ONE of their employment. This allows them to get into the right mindset for introducing change. And the correct mindset is “Go for it!”

How can that work? Isn’t it dangerous? Well there are a number of tools and processes that can help. Perhaps the over-riding consideration is Fail-Fast (an Agile Teaching) but you need an infrastructure that can provide you with the security you need, one that can facilitate the Fail-Fast approach. This CAN be accomplished without reference to Cloud Services, but in reality Cloud will provide you with the easiest solution.

In terms of acronyms we can talk about DevOps, DevSecOps and WebOps. Also important are CI, CD and Agile. Each of these deserves its own paper. But the bottom line is that CABs ARE HISTORY. If your company has one.. you have a problem. You dont need it. Its slowing you down. Move on.

If you would like a FREE REVIEW to see how your business can benefit from Cloud Solutions then fill in your details on the contact page and I will get be delighted to help.