Tag Archives: Factory Analogy

The Software Factory Model Analogy – Appropriate or Not?

I felt compelled after some recent discussions to provide another blog post about the analogy I have been using in the title of this blog: The Software Delivery Factory model.

Let’s talk about the traditional way of thinking about Factories:
We start from the Wikipedia definition of factory system characteristics

  • Unskilled Labor – Now while labor arbitrage has certainly been a factor in the move towards a software factory model, I think we all agree that we are unlikely able to move away from at least a mix of experience levels and that we cannot sustain good software delivery without the right skills. In this model people are usually referred to as resources, but that’s for another post later. Inappropriate analogy!
  • Economies of Scale – By bringing together everyone involved in the delivery process and by centralising some of the functions like PMO we do see some economies of scale. Appropriate analogy!
  • Location – In the past this has been about factories being close to infrastructure like rivers, roads and railways, these days it is to be close to the right talent. This continues to be important as you can see in the move to India and China to get closer to large talent pools there, and also in Silicon valley where a lot of top talent is located these days. Appropriate analogy!
  • Centralisation – In a factory means for production were brought together which individuals were not able to afford (e.g. an assembly line or weaving machine). In software delivery we see heaps of small competitors taking on the big guys with sometimes more advanced open source technology. We also see a lot of distributed teams across the globe who work from different office or even home. Inappropriate analogy!
  • Standardisation and Uniformity – How often do we produce the same piece of software many times over. Not really that often. There are some cases where the same pattern is required for example for pricing changes, but more often than not each project requires a unique solution and is contextual to the client and technology used. Inappropriate analogy!
  • Guarantee of Supply – In a factory the work flows relatively smoothly and there are few hiccups if any in the production process. Looking at data from the chaos report and looking at my own experience, the smoothness of flow in software delivery is an illusion. And to be honest if I see a burnup or burndown graph that is smooth I suspect some gaming is going on. Inappropriate analogy!

So in summary the vote goes to it not being an appropriate analogy 4:2. It conjures up images of people sitting in their cubicles actioning work packages,

  • one person translating a requirement into a design handing it over to
  • the next person writing a bit of code
  • then to the next one testing it
  • and in all this no one talks to each other, it’s all done mechanical like people on an assembly line

In bad times software delivery in a factory model can feel a bit like Charlie Chaplin in Modern Times

Some of my colleagues talked to me about a new factory model, so let’s talk about the characteristics of this alternative model that people point out to me:

  • Orchestration of complex production process – software delivery today does require the delivery of many individual components very similar to the complex production process that for example is required to build a Boeing Dreamliner. Most systems are built of many components who are developed by many different team sometimes even across many locations and organisations thanks to the offshoring and outsourcing models. This examples of a modern factory does apply to software delivery. Appropriate analogy!
  • Automated Tool chains – If you look at modern factories from Toyota or BMW, you see very few works and a lot of automaton chains. This is very similar to this little video on CD. In that regard I agree that software delivery should be like these modern factories. Appropriate analogy!

I guess a modern BMW factory is the right analogy for this model:

Overall we end up with 4:4 votes on this list. In my head the image of a factory is not that of empowerment and of people working together to achieve great unique outcomes, its one of mass production and that just doesn’t work well with my understanding of software delivery. I guess I will keep the name of my blog as it is and just look forward to many more interesting discussions about this topic.

Here are some thoughts from others on Software Delivery Factory models (and yes of course it is more likely I come across things that confirm rather than oppose my view – please call out references to opposing views and I will post them here):

If software delivery is not a factory – what is it?

After posting my first blog I had a discussion with a friend of mine who is an Agile coach. He asked the obvious question: “Mirco, if you think it is not a factory anymore, what is it then?”.

Studio_AaltoNow that caused me to pause, but after a moment I remembered a discussion panel at a conference I attended. The topic was “Software Delivery Metrics” and the whole room was looking for answers on how to measure the effectiveness of software delivery teams or the even more elusive productivity. The discussion went around and around in circles and while I was hoping to get some good answers there was none to be had. People were talking about business outcomes and customer and employee satisfaction – which I agree with but are difficult to measure and to determine cause and effect. Before giving up I threw the following analogy in the room: “So what you are saying is that software delivery is like marketing? When you run a campaign and everyone is happy with the campaign and the product sells more than you consider yourself successful with your marketing campaign. But you don’t know whether your campaign was successful or whether your competitor did something stupid, and you don’t know whether there would have been a more productive way to deliver the campaign” – so perhaps software delivery is not a factory anymore, it is a studio (like a marketing or design studio).

Now this analogy might not be perfect either and I am sure some marketing buffs out there will tell me that marketing is very measurable. Especially if you consider the abilities that came with A/B testing in online marketing, but hey its closer to the truth than the factory model is.

I will close with a quote from John Wanamaker:

“Half the money I spend on advertising is wasted; the trouble is I don’t know which half”

– I leave it to you to see what this means for software delivery.

Picture for this post:
Studio Aalto, by Pepechibiryu, available from: http://en.wikipedia.org/wiki/Alvar_Aalto#mediaviewer/File:Studio_Aalto.jpg
License: CC BY-SA 3.0 

Welcome to Not A Factory Anymore

Hi everyone,

this is my first blog post. Yes I have finally made the leap into the blogosphere. Over time I will blog here about software delivery, agile, DevOps, Continuous Delivery and anything else that grabs my attention.

But first things first: Why ‘Not a factory anymore’?

I think many of us have heard over time the analogy of Software Delivery with a factory. In my mind that analogy is not accurate anymore and sends the wrong image. Software is not being produced, it is being created, it’s a creative process.

On my blog I will share with you my thoughts on everything that I think shows why the factory model is not appropriate and giving this blog that name leaves no doubt in the reader’s mind, where my allegiance lies in regards to how software based solutions should be delivered.

Looking forward to engage with the community via this blog and to see you around at conferences and meetups