DevOps is a Trojan Horse. Of the Indispensable Kind

Share with:

LinkedIn


DevOps is usually brought within the walls of an organisation to improve IT. However, once the DevOps horse is inside, odds are that Value Stream warriors will step out who take customer-centricity, end-to-end responsibility and cross-functionality literally. The organisation itself however is in most cases still inspired by the scientific management principles that Frederick Winslow Taylor published in 1911. No kidding. In those days business environments were stable, the mass production work was simple and labour-intensive and employees were low-skilled. More than 100 years later the warriors find themselves in the midst of a silo array that has been erected to support an increasing number of processes. And if improvements have been made along the way, it led to subsilo’s and reinforcement of silo walls.

The warriors pursue a noble goal but are going to have a really hard time. Business agility requires a business level commitment to product and value stream thinking. But that’s new to most executives. So when the warriors start to roll out an end-to-end Continuous Delivery Pipeline they do create the foundation that enables enterprises to release value. But as soon as they start to pierce silo walls they will meet a lot of resistance. Resistance from silo management of course after they realise that the holes in the lower part of the wall will not only be used to build the pipeline but also to drain all the silo workers from their silos into new cross-functional value stream teams. As soon as drilling noises and protests increase, higher management layers will get involved to investigate what kind of trouble the DevOps horse brought in.

But wait a minute. If business agility is so important for every organisation, and product thinking and value streams are the way to get there, wouldn’t it be better to start this entire enterprise rebuilding from a board level? YES, it would be better but it won’t happen in most cases. Just like a frog that is put in tepid water which is then brought to a boil slowly, most companies will not perceive this specific type of danger that is at play here.

And they certainly won’t see the danger if they look at the wrong side, their direct competitors. As explained in Mik Kersten’s brilliant book ‘Project to product’, “Tech giants are taking over as they are mastering traditional business more quickly than the world’s established companies are mastering software delivery. Most companies don’t have the right set of tools and models to properly assess risk and capitalise on opportunity in the Age of Software. Companies that master the new means of production will displace the companies that take more time to adapt. But if the sector does not move fast enough, the tech giants will move into that market. Instead of displacing specific companies, they will disrupt an entire market.”

Meanwhile, we will have to place our hopes in the warriors who may just have begun a new battle. The one with support staff. Like HR (“let’s cut this department down to a Minimum Viable HR and have the teams do their own HR”), like Control (“from now on value stream funding will be leading. All other funding will be ceased to reinforce the value streams”), like Compliance (“we are going to switch to compliance as code, don’t need a department for that anymore”) and like Testing (“for test automation we don’t need testers, we need developers”). Like I mentioned before, the warriors take end-to-end responsibility and cross-functionality literally. And sometimes they exaggerate.

Whether those value stream warriors sneaked in in a horse’s belly or were hired deliberately, in both cases they will have to answer some questions related to the development of speed and spent in the graph below. Between t0 and t1, the speed of a company continues to decrease while at the same time costs increase. Something has to be done. At t1 the decision is made to start working with DevOps and Continuous Delivery, after which the company initially becomes even slower and costs increase even further. From t2, the speed increases again and the company will become faster than it has ever been. And at the same time, costs will decrease to a level never seen before. Relatively speaking. And of course, the question most often asked is how long it takes to get from t1 to t2.

In summary, this article is about tilting an organisation, the reluctance to start, the need to do it anyway, the initial resistance, the amount of patience and money needed to achieve a successful tilting, and finally, the fact that we have no choice.

So, when this horse shows up at your front door, that means good news. Eventually. And a huge amount of work. And an increased chance of survival.

I think Obeya can help in bringing the worlds of DevOps, Control, HR, Compliance and Testing closer together. Please let me know if you’ve come across any specific examples.

This article has  also been published on my LinkedIn page: https://www.linkedin.com/pulse/devops-trojan-horse-indispensable-kind-jan-de-vries/

Share with:

LinkedIn


Recommended2 recommendationsPublished in Articles

Related Articles

YOU DON’T NEED A GURU TO MAP YOUR VALUE STREAM

Share with:

LinkedIn


Share with:KEY TAKE AWAYS A Value Stream Map indicates at a macro level how the work flows through your organization, from request to fulfilment to…

Share with:

LinkedIn


Virtual Obeya – tooling comparison

Share with:

LinkedIn


Share with:What do you do with your physical Obeya wall when everybody’s working remotely? How will you keep the richness of context creation that you…

Share with:

LinkedIn


Experiencing Obeya In Our Way

Share with:

LinkedIn


Share with:Few years back I was working in a leather goods manufacturing company. I started a working as a Lean officer and got the opportunity…

Share with:

LinkedIn


What is Obeya – articles and videos

Share with:

LinkedIn


Share with: Our belief is better leadership will lead to a better world for all of us. Sharing knowledge and building skills on Obeya for…

Share with:

LinkedIn


Lean and Agile in the jungle

Share with:

LinkedIn


Share with:One in eleven children die in Liberia. If we step up now, we might be able to save some of them. For this, we…

Share with:

LinkedIn


Responses

Your email address will not be published. Required fields are marked *

  1. Good article Jan, thanks for sharing! I agree that in Obeya, because you’re looking at the full system of things as a team, you’re including topics like Development, Operations, Control, HR, Compliance and Testing (or perhaps we’ll call it product/service quality).
    One application of Obeya in such an environment can be found at ING, where they’ve been working with DevOps and Obeya for years now. I’ve been privileged to work a bit with the coaches there and they’ve really nailed it if you ask me. If you’re interested, you can read about it in Steve Bell’s contribution to ‘Accelerate’ describing how they work.

    1. Hi Tim, Accelerate is on my book shelf! 🙂 I think I’ll read the part that your refer to again with a different perspective.

  2. Nice article Jan. Could you allborate a bit on why you think an Obeya can help? Or in what way an Obeya will help with the adoption of Value streams?

    1. Thanx Florian, I think that an Obeya will help in bringing support staff stakeholders together with the value stream stakeholders. To enable them to share their vision, data, ideas and fears. In order to decide what is the best way forward for their organisation and to align their plans accordingly.