Your browser version is outdated. We recommend that you update your browser to the latest version.

Explore DevOps before you start your next Initiative (Business or IT)!

In July 2013, the GTA (Greater Toronto Area) and many of the surrounding cities experienced rapid and heavy rainfall which caused flooding of many homes. The unexpected storm caught everyone off-guard. 

A few years before the flood, I decided to take on waterproofing of the external walls of my 60 year old house. If you own a new home, you don’t have this problem. In the old days, they used so-called ‘clay weeping tiles’ which over the years would move, break and get clogged. Eventually they do not do their intended job which is routing the water away from the house and almost any amount of rain can cause basement damage. Many friends advised me against this messy and costly home renovation project that nobody could see, and suggested I renovate my kitchen instead. After all, the kitchen renovation was visible and far prettier... Obstinately, I went ahead with the waterproofing.

After the unfortunate 2013 flood, I watched neighbors and friends going through lengthy and costly repairs and loss of belongings. My house was not damaged in any way.

Sometimes we need to fix things that have greater impact than just the looks!

Over the years, organizations have taken on new initiatives, projects and programs that have swelled with more people, more technology, more complexity, more cost and more risk. Confidently we start even more while we are still recovering from the last large-scale implementation. Often, we deem these implementations as a ‘success’ since we went ‘live’ in production and the project concluded. What about the aftermath? If we honestly went back and reviewed a project or large program a year after, would we still call it a success? We see symptoms of worsening illnesses from previous projects but yet we prefer to start another one since it is prettier ­ just like we prefer a kitchen renovation over waterproofing.

What might be those worsening symptoms?

1.      Fragile systems that break often and badly … just as we are adding more functions to them

2.      Production data we don’t trust  

3.      Data Visualization dashboards that we need to tweak to reflect data we think is right

4.      Access Databases and Excel sheets with vital data that were created as workaround which now are part of our production and  reside on individual desktops

5.      Silo IT processes where  we are not sure of the hand-offs or cycle time

6.      Outdated Business process maps that were created for individual projects and are not reliable anymore and have not been looked at since

7.      System upgrades that were put on hold until the project went live and are now more outdated than ever

8.      Manual test cases created for the project that have not been refreshed since

9.      Pre-production environment(s) that are a year old

10.  Production incidents that have piled up and we cannot fix due to resource scarcity or their complexity

11.  Monitoring tool sets that nobody is monitoring since nobody knows how to use them

12.  Developers who have no understanding of how production operations work

13.  Operations support teams who have little understanding what they are supporting in production and why they are doing it

14.  Outstanding transactional and analytical reports that were put on hold until the project completed, and for which we have not received capital funding to do them

If you are a large organization, it is likely that these symptoms do exist though some of them will be hidden.

To connect your IT teams together, you should consider DevOps to see how it can help your organization regardless of the vertical you are in. The aim of DevOps is to unify everyone in software development and software operation.

DevOps is cultural change more than anything else and it is a movement to bring together our Development and Operations people to work towards common goals. It is about curing an illness and its symptoms, visible and hidden.

As a leader how would I get my teams connected? These are my very first steps:

1.  Embark upon a new life and journey! Don’t call it a project and definitely not a ‘DevOps Project’!

2.      Run semi-formal technology process reviews daily.

a.      Run a one day process mapping training for your group so they know what it is and have them run the session. Do not bring external consultants to do this.

b.     Use VSM (Value Stream Mapping) so make sure you get to know process flow, the ones that bring you Value and pin point Non-Value processes.

c.      Audio and video record the session and have group review before start of next session

d.     Anyone who does anything in the process even if a small job, should be present. Do not leave out anyone.

e.     Group the teams by subject area, or other logical groupings, and start with small groups.

f.       DevOps is about everyone in IT! Don’t forget Regulatory, Security and Audit!

3.      Make  small changes to your processes to enhance the flow

a.       Reduce unnecessary hand-offs and obstacles but make sure the teams are the ones suggesting them and help where you can. They must agree ­ if you force it, it will not work.

b.     Avoid formal approvals

c.      Let everyone outside the group know about the changes being made. You never know what process change will do to other groups and you are about to find out.

d.     If you have team members who are resistant to change, leave them out. Check periodically to see if they are willing to join back and if not, you have a decision to make!

4.      Make all the generated information available to everyone and run information sharing sessions. You should use Social Media type tools - the only tools that I would invest in at this stage.

5.      Iterate steps 1, 2 and 3 over and over. It will become your culture!    

Though great vendors and tools exist today for DevOps, I believe these should not be the priority at this phase. Neither should the fanciful renaming of roles such as QA Analyst or DBA or Server Administrator to DevOps Engineers. DevOps is not moving to Cloud infrastructure or dismantling your IT teams either. It is not about creating beautiful shared spaces and garages with the hope that our silo teams with low trust will eventually talk and work with each other. 

DevOps is a fun journey that embraces cultural change and is a movement that brings our Development and Operations people together to work towards common goals. It is about curing an illness and its symptoms, visible and hidden, from which we have been suffering. Only then will we be able to weather the forthcoming storm!