Software Dev... Production
The conventional approach to software development creates friction in our organizations which manifests in various undesirable effects like disengagement, low quality, low creativity, slow response to change, developing the wrong things, among others. The common and conventional approach makes software development more a matter of a kind of industrial production performed in a factory.
The common and conventional approach to software development is a fundamental trait of organizations that find themself below 1.6 in relative effectiveness in the Marshall Model, i.e. a fairly ineffective strategy.
The western industrialized style of management has spread to every institution in society, and organizations that are involved with knowledge work, like software development, are unfortunately not excluded. It has trapped our way of thinking in an industrial manner - work is organized and approached in functionalized silos where we are occupied in producing units-of-output and keeping everyone busy in a giant game of resource optimization and synchronization.
It is not only managers that are affected by this way of thinking; it affects most people's way of thinking about work. For exempel, people feel obligated to be busy, to be “productive” all the time, otherwise they become stressed and feel useless. It does not matter what we are doing, it is like being busy is valuable in itself. Most people have not experienced any other type of organization - it is even highly likely that you, the reader, have not experienced anything else than this relatively ineffective way of working (the Marshall Model informs us once again).
This, of course, means that most people have never experienced effective software development. Just think about it - most people join companies that are already successful. In general - a company, once small and innovative (but most likely not effective), discovered one or several products or services that a specific market needs; started to grow and in time became structured in a top down hierarchy, divided into fragmented functional silos. Like Harrison Owen observes “Sooner or later, somebody says the fateful words: We have to get organized. With that, structures, procedures, tables of organization, and all the rest, make their appearance.” [1] This is the conventional or traditional type of organization most people join. The effect is that when the company tries to do new development or improve current product lines, they do it in the way they know of: in bureaucratic, top-down, factory-like ways.
It is sometimes hard to remember that, in many cases, there is no connection between the new controlled and structured organization and its former and future success, it is the original product(s) that continues to deliver its value to the customers and other stakeholders separated from the specific form of the organization or management.
The conventional approach
The conventional approach to software development often looks something like this (I have tried to describe the approach in the most general way I can muster):
- Manager(s), decides what to do.
- Expert(s) then defines the solutions and plans upfront.
- Developer(s) does the work in terms of e.g. making, producing, building, implementing, delivering, etc.
What is the rationale for this approach? Simply that, we believe, in this way the developer knows what to build (control over the workers), we know what we will get (control over the outcome), when we will get it (control of time), and we will obtain the believed value in the most efficient manner (control of the process). The use of resources will be optimal, and costs will be low. Just follow the plan. Right?
Recognize this? It is not strange if you do; like I wrote previously, this is the way most organization approaches software development.
What is the core conflict?
The software factory
Konosuke Matsushita, called the father of management in Japan, does not mince his words when he describes the deep crisis the western management styled organizations are in:
Your firms are built on the Taylor model. Even worse, so are your heads. With your bosses doing the thinking while workers wield the screwdrivers [or slamming on the keyboards], you’re convinced deep down that is the right way to run a business. For the essence of management is getting the ideas out of the heads of the bosses and into the heads of labor. [2]
Consider “the essence of management is getting the ideas out of the heads of the bosses and into the heads of labor”, then put it in relation to the three bullet list above that describes the conventional approach to software development.
What does Matsushita mean with the Taylor model? Dr. Allen C. Ward, expert on product development, describes the assumptions that Taylorism is built upon like this:
Scientific/conventional management is based on two 17th century assumptions: Order in any system must be created by a greater intelligence operating from outside the system, and systems are predictable. So, management’s job is to tell people to follow the one best way. The company then will run as designed. [3]
We generally believe that it is the managements job to instruct people, the workers, on what to do, and we believe we can predict the outcome upfront - perfectly in line with the underlying assumptions of Taylorism. John Seddon writes in his book “Freedom From Command And Control” that “[t]he separation of decision making from work, [is] the cornerstone of command-and-control thinking” [4], and “[t]he management factory [...] is a place that works with information that is abstracted from work.” [5]
We bring these beliefs and assumptions into the realm of software development. We separate the act of management and decision making from the actual work, which in turn is reduced to a matter of making, producing, building, implementing, delivering etc., on the things that are already decided on. We are in fact trying to get the managers’ ideas into the heads of the workers via some kind of experts, which are expected to just deliver. This is a sequential, controlled, and deterministic approach to software development.
When we prepare “solutions” for the developers to make, we are actually trying to produce software like in a factory. We focus on output, just making and delivering the features, solutions, product, service, etc. There are no oil spills and conveyor belts to be seen with the naked eye in our modern offices, but our thinking is still based upon old thoughts that originated from the industrial revolution.
But software development is not a matter of processing defined, decided, abstracted, and objective information through developers, like if it was a matter of refining raw material through production lines consisting of different kind of machinery in a factory. It is this, to a large extent, unconscious assumption that creates a lot of frictions in our organizations today. Software (or product) development is too uncertain to be approached in this way; the inner nature of it will resist the mechanistic cage we are trying to confine it in.
The conflict is in our heads, it is the way we think about organizations, work, and software development that hinders us from being or becoming more effective.
New assumptions
The conventional assumptions and beliefs about work is not well suited for software development. Dr. Allen C. Ward continues:
Modern science shows that order emerges from interactions inside certain kinds of systems, and most systems are not predictable. Therefore [...] management’s job is to continuously help order emerge by learning and helping others to learn. [6]
In other words it is the opposite to the 17th century assumptions that conventional management is built upon. We do not find ourselves in an environment that is completely predictable, but we act like it is. Instead of trying to structure work as if we are in a fully predictable environment and control our way forward, we need to find new ways to organize in order to let knowledge grow while working. Working with developing software is a learning endeavour; we will learn and obtain new knowledge about both needs and the specific design as we go. It is not a matter of just producing software or products - as in the first product in a serie.
Let's have a look at the original meaning of the of the word “develop”:
The modern uses are figurative and emerged in English 18c. and after: Transitive meaning "unfold more fully, bring out the potential in" is by 1750; intransitive sense of "come gradually into existence or operation" is by 1793; that of "advance from one stage to another toward a finished state" is by 1843. The intransitive meaning "become known, come to light" is by 1864, American English. [7]
This is not how most organization treat development and why I call the conventional approach "software production" instead of "software development".
Are your organization trying to produce or develop software? What is missing in order to be successful?
/M
Sources
[1] Owen, Harrison. Riding The Tiger (p. 43-44). Abbott Publishing.
[2] Seddon, John. Freedom from Command and Control: Rethinking Management for Lean Service (Kindle Locations 99-102). CRC Press. Kindle Edition.
[3] Ward, Allen. Lean Product and Process Development, 2nd ed. (Kindle Locations 443-448). Lean Enterprise Institute, Inc.. Kindle Edition.
[4] Seddon, John. Freedom from Command and Control: Rethinking Management for Lean Service (Kindle Locations 102-103). CRC Press. Kindle Edition.
[5] Ibib.. (Kindle Locations 225-226).
[6] Ward, Allen. Lean Product and Process Development, 2nd ed. (Kindle Locations 443-448). Lean Enterprise Institute, Inc.. Kindle Edition.
[7] https://www.etymonline.com/word/develop
About the author
I am a passionate reader that is interested in nature and how it all relates to organization and Software Intensive Product Development (SIPD).
Are you interested in truly different ways to organize and approach collective knowledge work or SIPD far away from fads, methods, frameworks, etc. that does not deliver the promised results? Then feel free to contact me; I will happily engage in a conversation, online or offline.