Prioritizing in a DevOps environment – the Priomide

by Jan Martijn Everts

More and more organisations are implementing DevOps way of working. This means that a product’s development is being done by the same team that does the operations of this product. What does this mean for prioritizing the work within the team? It concerns different types of work with different goals. In order to make the right choice, i will propose a framework that could help in making the choice, the ‘prio-mide’.

Maslow’s hierarchy of needs

In a nutshell, Maslow’s hierarchy of needs describes the sequence of needs one has in life. Starting point of his theory is that you don’t feel the need for the next step until you have fulfilled the needs in the current steps and below. The thought is that you won’t be developing your painting skills when you don’t have shelter of food. Maslow has received criticism from various peers due to the fact that one can imagine many examples where someone would have the need for things that are in the next step while the current needs are not completely fulfilled. I think the nuance to this theory is that if you no longer lay awake anymore of the lack completing the needs due to a potential plan, you can already focus on the next step.

DevOps hierarchy of priorities

In the choice that a PO must make with his team every day, similar needs arise. With Maslow’s mindset in one hand and the different types of work in a devops team in the other, you can come to the following version of Maslow hierarchy of needs. I call it the DevOps hierarchy of priorities.

Delivery / security / stability of current services / products
Just like with Maslow’s need hierarchy, which starts at the bottom with survival, so does the priomide. As a product owner of course you always want the products and services that you have already developed to be (able to be) delivered and to continue to do so. Security patches, incidents and problem solving will almost always be given priority over other activities. This step is for guaranteeing the effectiveness of your current product today.

Capacity / performance current services / products
When you have solved all the problems that your product, service or customers have today, you can start working on preventing the problems of tomorrow. Not only the number of customers is increasing, the use per customer is also increasing and that is why we must continuously work on growing to face demand. This step is for guaranteeing the effectiveness of your current product tomorrow.

Life Cycle Management
If you have hedged today and tomorrow, you can look a little further ahead. In the future, support contracts will expire, and the upgrades may take longer, for example if a newer software version is no longer supported on your current hardware. LCM activities are number 3 because you can generally always contractually extend these support contracts after agreements with your supplier. This step is for guaranteeing the effectiveness of your current product in the future.

When you have done everything to guarantee the delivery of your current products and services now and in the future, you can think about the efficiency of your products and services and how you deliver them. It is good to have an effective product, but if its costs are now rising, you cannot guarantee the continuity of your product in the long term. That is why you must always continue to rationalize. How can we continue to deliver the same products and services but in a simpler way? This step is for guaranteeing the efficiency of your current product.

Innovation is the implementation of new products and services that ensure that you continue to offer a meaningful product to your customers in the future. Innovation is also the organization of your products and services in such a way that you can also do this efficiently in the future. If you innovate completely, your innovations will also ensure that in the future you spend less and less time on the underlying steps. Innovate to be able to deliver easier and faster, to grow more easily and to continue to meet your LCM without impact. This step is for guaranteeing effectiveness and efficiency in the future.

Just as with Maslow’s hierarchy of needs, you only get to the real innovative work once you have the underlying work completed. At least, according to the theory. Innovation is easier and faster if you don’t have to figure out complex and complicated infrastructure. So, you should preferably rationalize in advance. You can innovate more creatively and better if you do not have flashing alarm bells due to a service failure. So this should all be taken care of in advance. But just as with Maslow’s theory, the same criticism applies here. Because work for the future generally also takes longer, you will also have to start this while at the same time making deliveries and performing security and software patches. Sometimes you just have to do innovations to be able to rationalize well and sometimes you no longer want to expand your capacity on an old platform, but you first want to develop a new platform to expand on.

In the end it is always up to the team and its PO to determine the priority for the coming period and to make a well-considered choice, looking at today as well as the future. Working too much on your safety and stability today prevents you from working on the safety and stability of tomorrow. To end with a quote from Maslow:

Wait! Before you go.

Choose how you want the latest innovation content delivered to you:

As innovation consultant, Jan Martijn Everts has facilitated more than 60 online idea challenges for a wide range of organisations and he has a lot of experience at community management. While working at the largest Dutch telecom operator, KPN, he has learned how to get things done in a large and complex organisation. Nowadays he is focusing on the Agile transformation of a large department and the new innovation process that it requires.


Article by channel:

Read more articles tagged: