DevOps - achieving end-to-end agility

DevOps – achieving end-to-end agility

DevOps is a new buzz word around IT and businesses that have or are embracing agile software development. I’ve been doing DevOps since way before it was ever called DevOps, so let’s talk a bit about why this is such a hot topic now.

I believe there is one primary driver to all the hype and attention that DevOps is getting: pressure to shorten release cycles.  There are other considerations and reasons for taking on a DevOps initiative but getting products and updates released faster is a big win for most organizations.  Here is why shorter release cycles matter.

·      Time to market – the sooner we get something in the hands of our customer, the sooner we generate revenue and test the market

·      Reduced risk - frequent, smaller releases are less risky because there are less changes to the code and quality is easier to control

·      Reduced cost – less friction between development and operations leads to greater efficiency

·      Customer satisfaction – shorter feedback loops allows for new features to be more in tune with what customers want

·      Increase market share – there is competitive advantage in being able to release features faster than your competition

Sign me up! Why isn’t everybody focusing on this?  Because, like most things that sound so great, they can be very difficult to achieve.  Moving from releasing software every 6 – 12 months to releasing software weekly, daily or even multiple times a day, is a huge shift and requires significant organizational changes, new tools and processes, and cooperation/collaboration from lots of folks who may not have worked all that closely before.

I find the attention on DevOps fascinating because I come from an IT Operations background.  I came up through the ranks as a System Admin/Engineer/Architect and then Manager.  I was a gatekeeper for software development teams and was responsible to make sure they didn’t release software that would either kill the infrastructure (crash the servers), or cause some horrible security risk that put valuable, confidential information at risk of being stolen or corrupted.  I was viewed as the speedbump on the information superhighway because I had all my checklists and validation steps and rollback plans and disaster recovery considerations. They pretty much hated me.

About 10 years ago, I switched teams.  I moved into software development, making video games for EA Sports.  After all of the years of trying to get developers to consult with me early and often so we could anticipate what they were doing and be ready to launch when they were ready to launch, now I was on the other side and knew how to collaborate with Operations. Did this magically solve all the problems and smooth the way to quick and stable releases on shortened cycles?  Hell no. I was just one guy trying to get lots of other people to play nice together. There were years of distrust, disrespect and policies and processes in place that made the relationship between Development and Operations difficult.

So, if this rocky relationship between Development and Operations has been a pain point for decades, why is it now the focus of such attention?  Because the motivation is much greater (see my list of benefits above), the tools have improved dramatically, and there are plenty of organizations that have proved it can be done.  DevOps will quickly move from being a competitive advantage for those that achieve it to a competitive disadvantage for those that don’t.  It is that simple.

I’m reminded of an old saying.  “There are those who make things happen, those that watch things happen, and those that wonder what happened. Who will you be?” DevOps is one of these opportunities.  You need to make things happen and it isn’t easy so you better get started.

My first piece of advice on getting started with DevOps is to begin with the understanding that the solutions are mostly about people.  You need to get people working together from multiple disciplines. If there is distrust or disrespect between groups you must solve that before you can solve anything else.  You need senior level sponsorship so all involved understand the desired outcomes and their importance to the organization. Of course, you need to understand the challenges within your organization because every organization is unique and no consultant, not even me, can come in and tell you what to do.  A good consult, should be able to jump in, roll up their sleeves and work with you get the wheels in motion.  There’s probably some “low hanging fruit” around test automation, and improving tools and processes for continuous integration, build and release management, configuration management, etc. Get some early wins so people see progress and gain confidence in the plan and achievability of the goals.

Now, go start your DevOps initiative, and may the force be with you!