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

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)

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

  1. PHIL Gadzinski

    thanks mirco for sharing . What’s interesting though , and something I’ve been giving some thought too and have decided to pose the question , is the concept Or idea that product development is in fact both. Both the ‘studio’ and the ‘factory’. Much like the fashion industry . The way clothes are designed and then showcased on catwalks at fashion shows to build the markets interest. Then the repetitive development to churn out the volume in offshore factories at cheap cost. Consider that the design and creation of product is done in the studio by creative knowledge workers . But then the way that creativity is the tested and deployed to the market in a repetitive manner. So creativity at the design and develop stage but factory at the test deploy and run stage…we want our autmated Orchestrated pipelines to run like a factory, one piece flow with minimal hand offs, zero non value add activity and repeatable predictable practices .

    Thoughts?

    Like

    Reply
    1. Mirco Hering Post author

      Hi Phil – great thoughts. I think in my head factory conjures up pictures of labor intensive work done by specialists at one task, not the Toyota and other fully automated factories. But I can go along with your mix of studio and automated pipeline. Not sure how to merge the pictures yet.

      Like

      Reply
  2. markosrendell

    Brilliant: “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” !

    Like

    Reply
  3. markosrendell

    I’m conflicted on the “not a factory any more” idea because feel that most IT organisations / projects have still got a lot to learn from manufacturing -especially Lean factories. Do you mean “not a non-Lean factory any more”?

    Great blogs though!

    Like

    Reply
    1. Mirco Hering Post author

      Yes Mark as i said to Phil’s comment, i think the picture in my head for a factory is still a building full of specialists at work more than one full of robots and some engineers in the control room. And you are 100% right that even though manufacturing is not the accurate representation we in IT have not even learned all from manufacturing that we could, yet we have further problems to solve. Lots of catching up to do for us…

      Liked by 1 person

      Reply
  4. Pingback: Impressions from YOW15 | Not A Factory Anymore

  5. Pingback: Let’s burn the software factory to the ground – and from their ashes software studios shall rise | Agile Australia Blog

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s