In this, the third, part of the series on why a digital transformation fails we are going to talk about the fallacy of the development factory analogy.

When trying to modernize the development process it is very easy to use a factory as an analogy. Factories have a flow of goods where each step in the process adds value until the product is done and leaves the factory. Similarly, there are multiple steps in developing a feature until the feature is done and leaves the “development factory”.

It is also a convenient analogy because there is a long history of optimizing factories and by thinking of the development process as production in a factory, it makes it easy for us to make carbon copies of factory type improvements and make it sound scientific and proven to work.

Leading us further into thinking the analogy is good is that it actually, sort of, work. When we start analyzing the development process as a factory, we do improve it. Just by being methodical and focused on optimizing the development process, we do make improvements.

Glass ceiling

By copying Scrum from the world of agile and making the teams work according to this well-defined process instead of a homegrown ad hoc process, things usually improve a great deal. And by stealing the concept of flow efficiency from the world of Lean production we do improve the time to market. What we often see in organizations are teams working according to the Scrum process taking features from a backlog and optimizing on delivering them as fast as possible. This is not bad in itself.

So, if these great improvements are a result from thinking of the development as a factory, why are we listing this analogy as a top reason for digital transformation failure. The reason is that by improving the organization along these lines, we will hit a glass ceiling in our improvement efforts. Why is this?
It all comes back to the complexity of what we are doing. Producing value in a factory is simple. We just follow the instructions at each production station. That is not to say that designing the products for productions is simple or that setting up the factory is simple, but the actual production is simple. With simple, we mean that it is that the output of our actions is obvious. And when you have produced 1000 thingamajigs which gives your customers value, so will the 1001th thingamajig.

However, while this is true for production, it is not true for development, and this is where the fallacy of the factory analogy exists. Output from a development organization does not automatically equal customer value. This needs repeating; output is not equivalent to customer value! It could be, but it certainly does not have to be. The reason for this is that development is not simple. Instead it exists in the borderlands between complex and complicated.

Complexity

With complicated we mean something where the output of our actions is predictable, but not obvious. For example, it takes an expert to design a circuit board for high-speed low-noise analog signals or to implement a signal-processing algorithm that utilizes the processor to the maximum but still the output of their expert actions is predictable.

However, when we go into the land of the complex, this is no longer true. When something is complex it is easy in hindsight to explain why our actions lead to a certain outcome, but beforehand, it is impossible. For example, it is not obvious if building a semi-autonomous car which lets the driver momentarily let go of the wheel in certain situations, will increase or decrease accidents. Or if a certain new user interface will be understandable by the user or not.

[image of the stacey complexity matrix with a cross in the simple domain saying Factory and a cross in the border between complicated and complex saying development]

We must first recognize that there is this fundamental difference in domains between factory production and product development and then act according to it. To develop in a world which is increasingly more complex, and to escape the development factory, we must avoid trying to maximize our output of functionality and take one step further, we must optimize our output of value.

Feedback loops

To do this we must add feedback loops to our development. These feedback loops must include the whole value chain from the customer to the developer and to our suppliers. Sometimes even the customer’s customer. This way we can evaluate if our actions produce value and when they are not producing the optimal value, we can make corrections.
In practice, the actions required may include:

• Bringing business and customer representatives into the development teams, thus creating truly cross-functional teams.
• Designing products which sends usage data back to the development teams.
• Not having a separate maintenance team but letting the original developers get feedback from what they built.
• Cooperating closer with the customers
• Cooperating closer with suppliers
• Building truly autonomous teams

All of these bullets are subjects large enough to warrant their own articles and we will definitely get back to them later. So, let us just end this article with a question, how long time does it take for a developer in your organization to know if what she built has brought value to the customer?

This article was also published on Transforming Embedded here.