DevOps is a Trojan Horse. Of the Indispensable Kind

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/

For more advice on Obeya
Join our network of Obeya professional
  • Get access to exclusive templates, training material, photo’s and guides
  • Be part of the active Obeya Community
  • Add to the knowledge base and join discussions
Recommended2 recommendationsPublished in Articles, Recommended

Related Articles

Responses

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

  1. 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?