In my previous blog, I argued that scrum and agile should not be confused, and that scrum was just the first step in shifting to an agile mindset with its emphasis on quality software in line with business needs delivered more quickly. But, of course, the process of development doesn’t happen in isolation; the new app or piece of software also has to be introduced into the production environment as well.
This can be challenging because it typically involves a hand-off from the development team to the operations team. Whether you’re the 4 x 100m relay team or two adjacent business teams, this passing of a baton is always where one can expect things to go wrong.
At best, the process slows down; at worst, the baton is dropped or fumbled. In the software development world, this is frequently a bottleneck as ops teams battle to integrate this particular job into overcrowded business schedules. For example, because neither the development team nor the business have any visibility into the ops diary, they just don’t realise that a major infrastructure or operating system upgrade is underway, which affects the specifications of the software.
Well, guess what? Ops teams are adopting the agile mindset to their work, and working backwards to the handover point. In the process, they are adapting and improving agile processes; more importantly, they are essentially creating a single process, governed by a single mindset (agile), right from concept to cash, as some of us say. Giving everybody visibility of the whole process helps remove bottlenecks, create efficiencies and prevent deployment challenges.
Hence the name DevOps, which combines “development” and “operations”. In fact, I sometimes think of DevOps as agile 2.0.
I am often asked, “Where should we start—with software development or operations?” The first point to make is that one should aim to do both in the end, so as to create the seamless, optimised, end-to-end process described above. But, that said, I advocate taking a pragmatic approach: establish where the challenges or bottlenecks are and begin there. If you have a problem with developing code fast and accurately enough, then begin by implementing agile in the development team; if deployment of the software is delaying projects, then focus on operations to begin with.
As an aside, it’s probably not a bad idea to get an outside consultant to help identify what the bottlenecks really are. By definition, a pre-agile process is a fragmented one, so each part of the process will see the location of the problem slightly differently—and will never own that they are the issue!
In the end, I believe that the application of agile principles to software development and operations—DevOps—will create a de facto single team across the whole application life cycle. The two teams may stay separate on the organogram, as they are now, but the greater collaboration between them will create a single, efficient process that produces software that the business wants, quickly and accurately, and then deploys it quickly for maximum impact on the bottom line.
Could one ask for more?