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)