DevOps 101 for Product Management – how it can empower you!

Introduction

Many of you may have heard the word DevOps come up over the past few years. If so, you may have wondered what it involves and, more specifically, what it means for product management.

In this blog, we’ll examine what exactly DevOps is and what effects it has on product management models. I want to thank the team from DevOpsGroup for collaborating with us on this post and for helping me get ‘under the skin’ of what DevOps really means.

With many online products moving to a service model, DevOps has become an increasingly growing trend in companies that have software as a service (SaaS) products. While it seems that DevOps is a relatively new trend, it has been around for ten years. Started by members of both the development and operations functions, DevOps grew online through development forums and groups. In 2009, the first DevOpsDays conference was held in Ghent, Belgium, bringing the movement to a wider audience.

Coinciding with growth in Agile development practices has meant that DevOps models are now more accessible to a broader range of companies.

What is DevOps?

So, what is DevOps? Well, much like product management, it can vary from company to company and product to product. DevOps is hard to define as it also changes depending on the company and its products/services. At its most basic, DevOps is about bringing together the people, processes, and tools involved in the development and IT operations.

In a DevOps model, teams are no longer ‘siloed,’ and integration between groups is the norm. Collaboration around shared objectives is common. Occasionally, teams will merge, and roles that would have traditionally been limited to one part of the development lifecycle will work over a much wider scope – for example, the rise of ‘Software Developers in Test’, or SDET. Rather than traditional user acceptance testing, SDETs create and run automated test codes.

So, if we can’t easily ask, “what is DevOps?”, maybe we should look at “Why DevOps?”, instead. Or, to put it another way, what is DevOps trying to achieve? Well, DevOps grew up around the increasing demand to deliver new features and new technology quickly, without sacrificing the performance and stability of the product – allowing companies to deliver releases more rapidly, more often and more easily. This practice is often known as continuous delivery.

DevOps principles

With DevOps being a collection of philosophies, tools, and practices, rather than a single defined process, how can a company be sure that they are working towards a culture of continuous delivery? Well, there are some principles and best practices that companies can employ to maximize their chances of delivering faster and more reliable updates.

DevOpsGroup considers there to be five main principles that any DevOps model should be founded on – this is known as the CALMS model.

In this model, culture sits at the foundation of any business transformation supporting the other principles. It is of critical importance that a DevOps team embraces the change and works toward fostering a culture of collaboration, openness, and shared objectives.

Supported by the culture are the 4 other key principles to ensure DevOps is successful. Automation is a significant ‘pillar’ of DevOps methodologies, ensuring that near-instantaneous feedback can be gathered through automated processes. Lean IT is about instilling an agile mindset into the team and its processes, ensuring the focus is always on producing value for the end-user by taking a lean approach to system thinking and requirements.

This lean thinking extends to the next principle; Measurement. It’s important in any continuous delivery environment that teams do not spend time measuring extraneous KPI’s. Keep it simple and measure the right things – those stats that will help guide you to customer value and allow you to find and fix faults quickly. The final principle in this model is a practical application of the cultural foundation – make sure you collaborate and share experiences and learnings. Take responsibility for sharing goals.

What are the benefits?

DevOps has some big advantages, both on the processes and culture of an organization.

The cultural mindset change, that is necessary to facilitate the move to a DevOps model, leads to a much more collaborative environment. The culture of shared responsibility should foster a greater feeling of trust between teams, as all are now working toward the same outcomes and objectives.

The emphasis on repeatability and automation means that it also becomes easier to scale development processes, allowing for greater flexibility and agility within the company. The increase in the speed and availability of feedback afforded by automation allows for teams to react quicker to create faster fixes to any issues that arise.

If you’d like to read more on DevOps, two books that I’d recommend you add to your reading list are “The Goal: A Process of Ongoing Improvement” by Eliyahu M. Goldratt (an older and less IT-focused look at continuous improvement), and “The Phoenix Project” by Gene Kim, Kevin Behr, and George Spafford (a more recent and IT-focused novel about DevOps).

What does it mean for Product Management?

So, what does DevOps mean for product management? Fundamentally, the approach enables product managers to embrace lean and agile practices – maybe even to go beyond them.

DevOps can lead to a culture where product managers can run experiments with confidence, testing different versions quickly and easily with a small number of customers. For example, having monitoring in-place to know how those tests are going gives confidence to the product manager to know they can switch back to a safe version quickly and consistently if needed.

With the rise of concepts such as Continuous Integration and Continuous Delivery (or Deployment – but let’s stay out of that religious war!) in the development and operations world, many of the barriers to putting new versions out to customers have fallen away. The development team has confidence that what they have built passes all the tests virtually instantly in many cases. And operations can put things live at the drop of a hat.

But, is it always sensible to do this? To quote Nicole Forsgren, a leading voice in the DevOps world and author of Accelerate. She has been quoted as saying “Pushing code to production should be a business decision and not a technical constraint.” By this, she means that having that technical capability to put the code onto your servers instantly is a great and powerful capability, which is the best practice to have. But, when it comes to actually make it live for a customer to use and release it, that is a choice that is for the business. Often that business decision belongs to the product manager. In a B2C context, the implications may be minor. So, you might be able to release 100 times a day. But, in a B2B context, every time you change the product that might trigger a wave of changes and integration work that your clients have to do – only doing this every month or more might make more sense. If there is a problem, though, you shouldn’t have to wait for a monthly release window to go live with a fix. This is when the capability comes in very important!

As anyone who has attended our 3-day training course will know, we recommend that collaboration between three key groups (product, development/test and design/UX) is best practice for ensuring requirements that deliver. Through this team, we can ensure that the 4 big risks as identified by Marty Cagan are covered.

● Valuable – Product usually lead on this dimension
● Usable – Design / UX usually lead on this dimension
● Feasible – Development / Test usually lead on this dimension
● Viable – Product usually lead on this dimension

Maybe with the inclusion of DevOps, we should be expanding that team and adding a 5th significant risk to consider:

● Operatable – Operations would hopefully take the lead here!

Ensuring that those operational requirements are covered, that may have traditionally been covered as “non-functional” requirements, is increasingly important. It ensures that when a product is in-life it can be run and maintained in an efficient manner. If you consider a SaaS platform, in particular, this is important.

As an example, Netflix has a DevOps culture, although it doesn’t call it by that name. The team focuses on ensuring that the development team doesn’t get bogged down in operational details. For example, instead of asking the software engineers to figure out how to spin-up a host on a cloud provider, they take care of it. But they don’t do it for them; they do it by building tools that the team can use to do the job. They ensure that development teams can be efficient and focus on adding value without dealing with this detail.

DevOps emphasizes the shift from a Project to a Product mindset, especially for the IT community. For a long time, they have used the language of projects. Those projects were run for a finite amount of time to achieve something and then ended. If you have a product with customers, using this approach of taking the team away doesn’t fit. The product needs to be maintained and evolved; the team that created it are the ones best suited to do that work, so keeping the team together makes a lot of sense. Marty Cagan classifies businesses as either IT companies, with the old project mindset, or Product companies, the Product mindset. Mik Kersten also looks at this in his book Project to Product.

One operating difference I have found is that DevOps teams tend to prefer Kanban as their working model. Kanban emphasizes the flow of work through the system, delivering quickly, but accepts constant chop and change. Most development teams, on the other hand, tend to prefer Scrum, which emphasizes small batches of work delivered in a (short) time-bound manner. This can cause some friction when working closely together, especially if working in the same fully cross-functional team. It may be one reason why there is the rise of the so-called ‘Scrumban’.

Conclusion

DevOps offers enormous potential for improving the effectiveness and efficiency with which a genuinely cross-functional product team can deliver. It ensures that development, in particular, can focus on adding customer value and not get lost in the weeds of operational tasks. It allows product management to confidently experiment and monitor how their product is performing; while giving the ability to respond quickly to issues in a live product. If you are interested, the DevOpsGroup might be able to help you learn more about it and even help you build the capabilities.

DevOps is not a new fad; it is a philosophy that has been around for some time and looks to be here to stay. It is highly complementary to how modern digital product teams work and if you are not already doing some (or all) of it, we would lay odds on it coming to your business soon

Authors:

Phil Hornby
Independent Consultant

Thanks to and contributions by:

Rael Winters and Edward Pearson

DevOpsGroup Product Managers