Monthly Archives: November 2015

Let’s burn the software factory to the ground – and from their ashes software studios shall rise

8 Replies

torchInspired by recent events I thought it is time to revisit the premise of my private blog (“Not a Factory Anymore”). I have recently heard of the first delivery centers being called studios and as you can imagine I was happy to hear the word studio rather than factory (Link). So I thought it’s time for an update on my pet peeve by adding supporting arguments.

First of all, before you continue reading you should read Don Reinertsen’s HBR article (https://hbr.org/2012/05/six-myths-of-product-development ) who makes a brilliant case on why manufacturing is the wrong analogy for product development (and IT development ultimately is product development). He calls out that the misconception of product development as being similar to manufacturing causes a lot of problems for organisations. I will provide my thoughts on some aspects of his article where I feel I can add value, but if you only have a few minutes and have to choose, then read his article and not my blog post (no seriously – go read his article!) – his article blew me away when I first read it and I am sharing it with every IT executive I come across.

“Product development is profoundly different to manufacturing” – Don Reinertsen

There is so much to say about this article, I could write for hours about it, but I will focus on two aspects that I want to point your attention towards because the application to IT might not be as straight forward. Both having to do with batch sizes (and batch sizes is the secret ingredient to any Agile or DevOps adoption):

Firstly the optimal batch size is determined by the holding cost (driving smaller batch sizes) and transaction costs (driving larger batch sizes). In IT the holding costs are a combination of the increasing cost of fixing a problem later in the lifecycle and the missed benefit of functionality ready but not in production. These two factors don’t change much with DevOps. What changes are the transaction costs. Deployments, Testing efforts and migration to production are all aspects that DevOps has made cheaper through automation and through using the “minimum viable process” for governance. This means that the new batch size is much smaller than before. The relationship between DevOps maturity and batch size is something that I hope people start to appreciate more.

 “DevOps is not about making IT efficient, it’s about making business effective through IT.” – Mark Rendell

The second fantastic point that Don makes, which I want to elaborate on, is about effectiveness and efficiency in the context of quality – the smaller batch sizes at fast speed might cause more defects, but these are fixed faster and the learning from it leads to a better overall outcome. As I said in many other places defects are not a bad thing as long as you find them as early as possible and use them to learn. Driving down defects is not an outcome its a side effect of better DevOps practices. With the words of a colleague of mine: “DevOps is not about making IT efficient, it’s about making business effective through IT.”

The second publication that filled me with optimism that we can bury the factory analogy soon is Gary Gruver’s “Leading the Transformation” (http://itrevolution.com/books/leading-the-transformation/ ). He also calls out that executives have to accept the fundamental difference in complexity between IT work and manufacturing. Assuming that you can plan up-front and manage IT with the same tools as manufacturing leads to inappropriate behaviors. Especially his guidance on embarking on DevOps transformations is very valuable and provides a realistic experience.

“Executives need to understand that managing software and the planning process in the same way that they manage everything else in their organization is not the most effective approach. (…) First, each new software project is new and unique, so there is a higher degree of uncertainty in the planning.” – Gary Gruver

After reading Don’s article and Gary’s book – can any executive still argue that the principles of manufacturing still applies? Do we need more evidence? Cultural change is hard and takes a long time. But hopefully the IT industry will soon be filled with application studios full of skilled, creative and motivated knowledge workers and not with factories where each developer and tester is just a cog in the machine…thank you Don and Gary for putting a satisfied smile on my face while reading your publications. I have the torch in my hands and you have given me fire – lets burn those factories down… (in a figurative sense of course)

Picture: Hawaii – by Dan Tentler (Creative Commons License)

Is the DevOps the new black?

1 Reply

(This article was first published in the JAXmagazine)

jaxenterDevOps is everywhere: you can buy DevOps tools from vendors that used to sell ALM tools, you can buy DevOps from cloud vendors who used to sell you virtual infrastructure and you can buy DevOps from consulting companies who used to sell you IT strategies… How come that on close inspection a lot of the DevOps practices and tools look eerily familiar to those earlier products they tried to sell you?

I have been working in what used to be called Development Architecture for all my career – developing IDE extension and compilers in the beginning and later on setting up tooling solutions to support delivery. Reality is that tooling and methodology will only ever be part of the answer. The hard truth is that engineering skills are important in both your DevOps team (yes I dare call the team by this name, but feel free to call it tools team, platform team, technical service team, system team or by any other name you feel is most appropriate and will offend the least people) and your development and operations teams.

DevOps is both the best and worst thing that could have happened to people who work in this space. On the one side all of sudden the work we do has become sexy. For a long time looking for labour arbitrage through offshoring or investing in proprietary or commercial off the shelf products was the answer to increasing complexity and cost pressure in projects. Good old engineering practices and supporting developers with the right tools was not sexy. Now DevOps is the new black and people want to talk to me about supporting high performance delivery through engineering practices and the right tooling to support developers. Making this important aspect of IT delivery more visible was certainly great.

But… there is the dangerous flipside. All of sudden everyone is doing it. In my consulting role I spend quite a bit of time performing assessments for clients. And I come across the Dunning-Kruger effect way more often than I expected. For those of you who don’t know about Dunning-Kruger, check it out on Wikipedia (https://en.wikipedia.org/wiki/Dunning–Kruger_effect) – in short it is the common pattern that people who don’t know much about a certain area believe to be better at it than they really are. In my case the most common symptom of Dunning-Kruger involves Continuous Integration. I walk into an organisation and start working through my assessment framework and I ask the following question: “Do you practice Continuous Integration?” And the answer is “yes we do”. Here I could move on, tick the box for continuous integration and ask for the next practice. In my experience Continuous Integration is actually quite difficult, so I dig a bit deeper “How do you know you are doing Continuous Integration?” the answer “We have Jenkins as our Continuous Integration server.” Okay they use a common tool for CI. One more question I feel will not hurt: “What do you do with Jenkins and how often does it run?” and here Dunning-Kruger hits me “We run it weekly for our development branch”. Ah yes – here we are again I think. My assessment turns into an education exercise. Truth be told, I think this is actually what good assessments do, they are an educational tool. For some it is a tool for self reflection, for others it serves as a helpful guide to have these external discussions with a coach. But all too often exactly the described contradiction of self-perception “We practice Continuous Integration” and reality “We have a Jenkins server and run it occassionally” leads to people, teams or organisations saying that they are doing DevOps.

Of course I am not free of blame. Using the term DevOps is often a handy shortcut for the large set of practices that underpin DevOps as well as the cultural shift required for it. And when are you allowed to say you are doing DevOps anyway? For me the best way to deal with this is to say that we are on the DevOps journey. And we all are. Everyone who is involved in the delivery of IT solutions is on the DevOps journey. Its hardly ever a straight line, often people wander off the path or are lost on the way and get further and further away from the goal, but we are all on the DevOps journey to improve IT delivery. Because after all that is what DevOps is all about. And yes I don’t mind it being the new black and I take the negatives that come from the hype if it means we can have the discussion on improving delivery; not just because it matters to our businesses and clients. Because it makes IT delivery a more humane place to be, it removes stress from people’s life, it makes you enjoy work more than it used to and it provides all of us in society with better solutions for all our problems from the mundane (how to better post pictures on Facebook for example) to the impactful (how to support families in disaster areas with better information through crowdsourcing for example.)

Join me on the journey, it might be a long one, but one that is worth taking the next step on…