The Journey Begins

Thanks for joining me!

Several years ago, I landed the job opportunity of a lifetime.  It gave me the chance to work for an organization with an extremely low appetite for risk, unbelievable political power struggles, isolated organization silos, an imperial styled Project Management Office with a culture that lacked uniform trust and respect.

How is this the opportunity of a lifetime you ask.  Clearly, I didn’t have this insight when I joined but it turns out that it would be the start on a journey of discovery.  Also, I knew starting with the interview process, that I would work with some of the most amazing people I have ever met.

One of the most profound and admirable people was my friend, peer and eventual boss.  He and I were incredibly like minded and I drew great inspiration from him.  We started a mission, wanting to build software in a far different way than had ever been seen in the organization.  We wanted full transparency and traceability as a means of improving quality in both the process and the product. We started the journey in much the same way many do, by focusing on tools best capable of delivering the transparency and traceability we were desperate for.  At the time it seemed our only option was a patchwork of multiple tools linked and tracked by key values in Excel spreadsheets.  Unfortunately, this was neither scalable nor transferable; if we were going to make any real impact, we needed both.  

At the same time, we were trying to solve our transparency and traceability problem, the development community was expressing frustration with their source code management (SCM) tool. Compounding their issue was that no one was listening to or acknowledging their frustration.  There was an opportunity in our combined problem to try to solve both and thus became my first organizational epiphany; silos, politics and centers of power were real and have real impacts on how we feel about what we do. 

My friend and I took our case up the chain.  We wanted to find a tool that both gave the development community the experience they wanted and provided us the means to establish transparency and traceability.  In short order we were informed that the operations team who owned, managed and supported both the process and SCM tool were quite happy with their choice and no changes would be allowed nor further discussion on the topic necessary.  We could not accept that answer and for the next several years continued, every chance we got, to everyone we could, to bring up the topic. Eventually we found an ally within our leadership that gained approval for us to pilot a new SCM tool and style of work.

With our new SCM we set out to automate our check-in and software build process thus opening our first chapter into a journey to understand this thing people were calling DevOps.  Because Agile was all the rage we established a study group to learn Agile and Scrum and adopt the proven practices.  The challenge remained. We were an automated and agile executing team working in a quarterly release cycle as part of a waterfall project.  Ultimately the automation and process approach were a bit like filling a five-gallon bucket with a cup of water and trying to put out a fire.  We had achieved a new level of capacity and velocity but were still being spoon fed.

At this point we were five plus years into a local transformation that was underappreciated and overlooked by the global IT organization. The frustration was high and the hope was waning.  For me this became my motivation to start a journey to understand why some organization can adopt DevOps strategies successfully and other struggle.  My conclusion: culture.

Since that time, I have focused almost all of my investigations, research and learning into cultural change within large scale organizations.  What are the complexities?  Is it possible to change the core DNA of a multi-national or Fortune 50 organization?  What are the pros and cons of culture change?

Over the coming months I plan to share some of the insight I have gained on this journey to understand DevOps.   I hope you will check back for future blog posts.