The IEEE 2675 Standard for DevOps: Building Reliable and Secure Systems Including Application Build, Package, and Deployment does a good job of setting out the basic practices needed for quality across the product development lifecycle. So what is still missing?

If you try to get a definition of DevOps from anywhere outside of the standard you will find many different and competing characteristics described. The term DevOps is a poor choice for the concept as it highlights two areas and omits many others. This is why you will see terms such as WebOps, DataOps, DevSecOps, and so on. The silo’s are back. Why? The need to emphasize the importance of any given area can be due to job insecurity or it can be down to the structure and politics within an organization. There are many other reasons but I will focus on just these two for today.

Job Insecurity

Consider the stakeholders involved in your team when developing software. Do you have a team with developers and a product owner? Do the developers consider themselves individually more as front end developers or back end developers? Do you have a team member who is the lead architect for the product? The word ‘Dev’ in DevOps may cover a number of roles but each role is important. Internal structure may dictate how much pay each role will draw particularly if there are junior and senior roles. Simply stating ‘Dev’ may lead to less senior roles and therefore less opportunity for recognition for work within the organization. This can cause issues amongst team members.

Structure and Internal Politics

Now consider the process of software development within the organization. Do the developers release code, after testing, to the operations team to work out the most efficient way to deploy the product? Is there any representative of operations involved in the product development from the outset? If not problems can arise later. This is not a new problem so why are we still talking about it? The inclusion of stakeholders such as operations must be supported by management in order for it to become the normal structure of teams. This requires releasing resources including time to collaborate with the team and funding to support the collaboration.

Stakeholders

Now comes the problem of including other stakeholders. If you have ever been involved in an audit you know exactly how time consuming they can be. Think carefully, when was the last time you invited a member of the legal and compliance team to a meeting? Management and leadership may facilitate stakeholder involvement but you need to invite the stakeholders to the table. Not all stakeholders will be required for every meeting but setting out a clear process of communications at the beginning will help elevate the problem.

Stakeholders come from many roles across an organization. Their perspectives on a task differ which can provide valuable insight into a problem or it’s solution. So now comes the important bit… collaboration can only happen if you talk to the right person. You need to seek them out. You need to collaborate with them, not just at the start or end of the project, but throughout. Keeping a knowledge repository of information on the requirements, processes and practices can enable improved quality of the software/product development process.

By understanding the simultaneous processes and perspectives we can reduce waste and continuously improve quality.