When I wrote on attitude, it was also because attitude is a critical factor for pushing quality to the next level. While one might get the impression that quality doesn’t seem to mean a lot to some people, it is important to realize that approaches such as continuous deployment and devops require a new level of quality. Let’s have a closer look.
In a more traditional (or shall I say “corporate”?) setup development and operations are usually two different groups. Development is expected to deliver new features (or value) which in turn means change and which in turn means inherent risk. Operations, those who keep the systems running that came from development, are measured against up-time, speed, disaster prevention and recovery, etc. Effectively operations try to minimize the risk which in turn also means the fewer changes you have the lower the risk. This creates the dilemma: development is inherently creating risk (caused by change) and operations is risk averse.
Of course this can be addressed to some degree by ramping up testing – manual (less ideal) or automatically (much better) –, selecting tools and technologies that foster better quality, designing the system for better encapsulation and testing, and similar more. Equally you can design the development, the hand-over, and the operational processes to avoid defects getting into the live deployment in the first place. All of these activities will help improving quality aspects.
However, quality is more than just good development processes, system design, tools and technology. When users of your system have an awesome experience, they will come back for more. Engagement increases and they may even refer other people to give your system a go. By instrumenting your system accordingly – and Google Analytics is only one of many options – you can gather data from how users interact with your system. I’ll leave it to another post what data you want to gather. For now, just gather everything that you can gather without slowing down the system, including every single request (if web based) and every single database transaction (if your system uses a database). You can always analyze the data later and throw away what you no longer need.
Often these kinds of data is not readily accessible to the developers if they are separate from operations. This typically slows down the speed at which usage data reaches development. The impact on their backlog is delayed.
To address this you can combine operations and development into a single group. Quite a few companies have already done that. Searching the internet you will find an increasing number of job openings specifically for roles in what is called “devops”.
Here are the advantages of using a single devops team: The feedback loop from users of the system into devops is much shorter. Data travels much faster, both positive and negative. Processes can be optimized across all activities, not just for development or just operations. The system can be designed in a way that considers both the requirements of developing as well as operating the system. The conflicting goals need to be addressed and balanced within the same group. Stay away, though, from accidentally building a “wall” within the devops team. It doesn’t hurt if people work on a mix of development and operational tasks. Perhaps, you even come up with better metrics for the combined team, e.g. user engagement or referrals.
Of course, a change towards devops represents a risk by itself, depending on your perspective. If you are a developer you might feel that you can do less because of all the red tape that new processes may introduce. If you have an operations background you might be concerned that you can no longer guarantee the high service level that you provided in the past. None of these fears needs to materialize. By collaborating and by pushing all quality related efforts to the next level, both developers and operations people have a huge opportunity to do an even better job than ever before. All the sudden systems are developed that are easier to operate as well. And all of the sudden systems are operated in such a way that developers can respond much quicker to intelligence collected from user interactions.
And that is why quality still matters. And maybe even more than in the past. You have an opportunity to push the boundaries and address areas of quality which you always wanted to influence, and which you finally can in a devops environment combined with the right attitude and quality.
Posted: Sunday, July 27, 2014 10:54:44 PM UTC
Share