On May, 16th, 17th I was attending the OpenForum conference in Esslingen, see:
http://www.kuglermaag.de/open-forum-stuttgart-2013/

On that conference I gave a talk about the underlaying concepts of process development. Processes are mostly discussed in terms of operational aspects, which is true in terms of the goals we are following with our organisations. But mostly it is highly neglected which aspects come into picture for the design of the processes.

This article and presentation is the result and insight of experiences I gained starting from my childhood, schooldays, studies, my jobs in a small startup and in a big global operating company and last but not least my leadership position in a church.

I have been working for Robert Bosch GmbH now for 15 years and stayed all these years in the automotive division as well as working in the R&D departments. But I was involved for different products and in different roles. I have done system and software development for Diesel CommonRail injection systems, system integration for car multimedia, software architecture for powertrain and method and tool development for automotive software.

And though I was never responsible for the process development itself, I had to deal in all of these roles with processes. But I was never enthusiastic about process topics, because as an engineer I wanted to creat something meaningful, and the processes seemed to be dead weight that only hampers me from my real work. And to me processes were just common sense.

That I am now giving this presentation about processes is remarkable and it is due to my changed perspective on processes I developed over the years. Processes are more then roles, activities and guidelines. At the core of processes there is much more than just these aspects. These new perspectives are the central theme of this article.

Overview

I will start this essay with a story from my childhood which gives already the first basic message: processes are part of my whole life, even I was not aware of it.

In the second part I present an analogy between process development and contoller design.

The third perspective finally was name giving to this whole presentation, because especially for processes it holds true that the crucial things usually can be found underneath the waterline.

The last chapter has to do with the insight that in the core of processes we are dealing with humans and teams.

The Soap Box story

These soap boxes have been constructed by kids in former times from boxes which originally were used to carry soap bars. They simply constructed 4 wheels under that boxes and the race car was finished. This was also one of my projects in my childhood.

The „Soap Box“ Process

Though never formally documented, there were also frame conditions as constraints for my project handling:

The budget was simply limited by the available pocket money. The toolbox available for the construction was my father´s home workshop on the farm (I am a farm boy). In terms of working time I was free, but I was not allowed to work on the soap box during school lessons, homework hours and the duties I had to do on the farm. But in terms of project management I was completely free to organize myself. Finally I had to take care of some compliance topics like the rules in my father´s workshop.

Iteration 1

I was aware that soap box construction is a complete new domain, so I have to gain some experiences first. So I will construct a first prototype which I will most likely throw away again. Then I had to organize the material and components, the sources were the farm of the parents were I could sometimes find some discarded material and also the bulky waste was a rich source for me.

From that I build the version 0.1 which was a 2 seater, 6 wheeler car, which I used to gain some first field experiences. The roadholding of this 3-axis car was great, but I identified also some drawbacks of this construction. The wheels were too small, so at high speed the revolution speed was out specification, then the 3 axis caused problems in the curves, the brakes on the street surface were not strong enough (some test runs had a quit adventurous ending) and finally the steering with the cord expander on the front axis was not very reliable.

Iteration 2

Therefore I decided to rework the construction completely from which the version 0.2 arised. Especially the chassis frame was improved, more like a dragster construction. But also the steering was now with a real bowden cable and the brakes were constructed on the back wheels now. With this version I did regression testing as well as non-functional tests like reliability. But I also started caring about the compliance of the race organisation when finding that differnt wheel diameters are not allowed.

Iteration 3

That´s why I had to plan again for a complete redesign. This time I knew it must be the final construction since I was running out of budget. So, I created the version 0.9 which I tested thoroughly since I knew after finishing the case it will be much higher effort for changes in the car cabin. So, I was already aware of the frontloading paradigm at that young age, even I wouldn´t have named it like this.

Iteration 4

After successfully testing this version, I finished the final works on the body and cover of the car. Then I performed some acceptance tests. Finally I was accepted to the soap box races and achieved some good positions.

Why I am telling this story? The reason is that it shows in the centre of each project, each undertaking are first of all the involved people. In my soap box project it was me, my brother and friends who helped me building the car. But also my father who gave me quite much freedom, but still controlled the compliance of some rules. Within that constraints I was free in my working model or methods. But I also defined a framework for myself which can be considered as kind of a process that supported my to reach my goals. And these goals were:

Process Goals

But the influence of the processes was mainly on the behavior of me and the other project people, i.e. processes supported the achievement of project goals, but affecting did they only people.

And this holds true for all processes: Controlling people and teams in the way that the desired project goals are achieved with the acceptable quality and in prescribed timeframe.

This thought brings us to a complete new perspective how can understand processes: they can be considered as the controller for an organisation which acts as the plant or path in the controller system.

Process as Controller

On the left side are the goals which are given to a team, e.g. business goals, requirements to a software system, available budget, timeline, etc. These goals can be considered as set values in a controller system and are the input to the controller which are the processes in the organisation. The controller transforms these set values into control values which is done by the process rules, e.g. requirements analysis, work package breakdown, work item creation, workflow, risk list, quality gates, reportings, releases. These control values are the input to the system to be controlled which is the team in our case. And the system produces the outputs which are ideas or concepts in case of a creative or research team, releases, dates, profits. These outputs are the actual values in the controller system. In each controller system the is always a feedback loop, i.e. the actual value is measured, subtracted from the set value and this control deviation is again the input to the controller.

With the help of this diagram I will explain the difficulties with process development in general and the problems with the traditional planning driven processes (e.g. V model)

The problem already starts with the set values, the requirements. In the fewest projects we are able to specify all requirements in detail at the beginning of the project completely. This is the reason why our roadmaps are outdated already 2 days after creation, because the customer changes his mind or the markets are changing. But we still like drawing our 3..5 years roadmaps in Powerpoint or Gantt charts.

The next problem has to do with the control path itself. Most processes consider it as simple, linear and deterministic system. But in reality this system is complex, non-linear and highly dynamic.

But is getting even worse, there are even impacting disturbances on this system. E.g. associates are getting sick or quit, know-how is getting lost or the budget is running out.

And finally in each control system there is usually a dead time which has a big effect in the loopback. The highter the dead time the smaller phase margin and the more instable and more susceptible to vibrations is the system getting.

These mentioned 4 points are the reasons why the traditional waterfall process are not really working in reality:
1. We can´t know the goals exactly, because we can´t predict the future
2. the human as the control path is not considered in his psychosocial structure
3. disturbances are being ignored
4. The feedback loop if existing at all has high dead times

Process: Goals and effectiveness

With the perspective that the system to be controlled are actually humans, we can conclude that:

• The goals which are intended with processes are of organisational, economical and technical level
• Whereas the effectiveness of processes are mostly related to human, psychological and sociological aspects, sinde processes want to influence humans and teams. And humans are probably one of the most complex systems we can imagine, i.e. not trivial to control that system.
• The most important job for any controller engineer: to analyse and understand the control plant.
• This means finally: all process developers should be in fact psychologists or sociologists, of course with enough understanding of the domain for which they design the processes. Like a software developer has to know his software technology as well as to understand the domain for which he is developing the software.
• And this is the core of this article: we have to understand what underlies the human behavior, so that we are able to control or influence it. And „influence“ has to be understood explicitely not as „manipulate“. Each leader has to influence the behavior of its associats and he hopefully does it in a positive and constructive way.

The Process Iceberg

But to do so, it is necessary to deal with the human behavior and what is relevant for it, this means to look under the water surface which brings us back to the iceberg. From outside we can easily see how people behave, what they say, see their results they produce and the working hours they spent in office:

But this is only the summit of the iceberg. Below that there is a huge chunk which influences the behavior of the iceberg much more which is: human nature, human needs, education, cultural background, character, values, emotions, habits:

We have to seize what is underneath the water surface to influence what is above the surface. But we can tacke the iceberg only on the waterline, and that is also the point where processes are located, in between the visible and the invisible:

Human Characteristics

This leads us finally to psychology which deals with the question how the humans are constituted or created. The famous picture of Michelangelo „Creation of Adam“ serves as an animation of this question: 

The human characteristic is separated into 3 different categories:

• Human Nature: Here we find that humans fear to be rejected, and the don´t like to be controlled or even manipulated. However they appreciate a lot transparency and trust
• Human Operation: Humans are highly iterative beings, because the learn from experiences and from mistakes. Then humans are very oriented to perception and they imitate and copy things from other humans.
• Human Needs: People need appreciation, they want to advance and grow. Then humans seek for self-fulfilment, but they also want to do something with purpose that goes beyond what they can achieve for themselves.

This picture shows the control plant for which we have to develop a process. When this perspective grew in my mind, I was reflecting again the Agile Manifest. At that moment I got a new insight about processes, agility and the correlation to psychology.

Agile Manifesto

The first two paradigms in the agile manifesto say that:

• Individuals and interactions over processes and tools
• Customer collaboration over contract negotiation

These rules are not by accident, but they simply reflect the human nature. Because people feel more comfortable in a faithful atmosphere than in a climate of distrust and people are much more productive in such an environment. And People like to be informed and they appreciate transparency and the feel better when taken serious. In this context we also have to refer to the topic of contracts: there are spent so much effort to protect each other on the level of teams, between departments and between companies. There is no added value in these effort but only prevent us from being productive.

The next paradigm in the Agile Manifesto says:

• Responding to change over following a plan

This means, reacting to changes is more important than keeping dogmatic to a plan that is outdated. The psychology related explanation to this is that people are an iterative being, and „try-and-error“ is nothing condemnable, but it simply reflects the human nature. And because it is important to make experiences and finally the humans have the ability to react to changed constraints, otherwise we could not even survive. The mechanism to react to changes is recursion and iteration. Iteration is nothing being invented by Agile Manifesto, it is as old as the humans are. The agile processes just discovered this principle again.

The last paradigm says

• Working software over comprehensive documentation

It means that the actual product, the runnable software is more important than a bunch of paperwork. To put priority on that makes sense, since it is the nature of the humans to create something of value, something that procures him with appreciation.

Productivity

After this excursion into psychology we can get back to the reasons why we define processes at all. The main goals are to influence teams in a way that we achieve our project goals as effecient and as effective as possible, this means it is all about productivity.

Kondratiev waves

With this productivity aspect we can have another link, namely a link to a historical reflection: Nikolai Kondratiev was living at the beginning of the 20th centry, he was a Russian econmist and developed the so called „cyclic economic theory“. This says that the economical development is following long waves. And these waves are induced by basic technical innovations like steam engine, railway, electricity, automobiles and finally computer and information technology:

Remarkably, the growth in these waves was not primarily gained with these innovations but through these technologies:

• the growth in the times of the steam engine was not caused by production and sale of the steam engines itself, but by the usage of steam engines, e.g. in mines. It was now possible to drainage the mine tunnels mechanically and no longer manually which increased the productivity
• By the railways it was now possible to make unreached land ready for transportation which increased the transportation productivity
• By electricity it was possible to have mass production and mass consumption
• Computers increased productivity in the the area of production control, in administration and in eduction

The question now is: what will be the 6th Kondratiev cycle and which innovation will be the carrier of this wave? There are different theories about this, some claim that bio-technology, nano-technology, medicine or health industry will be this technology. The Kondratiev theory says that during a growth period at a certain point a specific factor of production is getting short. E.g. in the mine epoch, the mechanical energy was scarce which was a big driver for the invention of the steam engine. This means with our todays shortage we can predict how the markets will develop tomorrow.

The shortage in our modern working environment is that we are very inefficient with information in our systems, teams, departments, organisations. Frankly speaking the inter-human information exchange is as bad as the transport effort before the invention of the railway. And now we are coming back to our process topic, since with the right processes we can solve this shortage. Therefore the thesis is that the productivity increase in the 6th Kondratiev wave will be fed by psycho-social innovations in the area of cooperations in and between teams. This includes cooperation and communication skills, trust, responsibility and conflict management.

Another thesis is that the agile processes are just the beginning of a complete new development in companies and in our society. It will be an innovation which will exploit the psycho-social potentials.

And again this trend will be guided and supported by the new technological innovations like social media, social networkds, BYOD technologies, GTD tools, IOTS and big-data analysis. E.g. by collaborative tools and technologies the transparency will be increased which fosters the trust and makes it less important to protect each other by huge contracts.

Summary

We have learned that the process development requires more psycho-social skills and less technical skills. Then the agile approaches are only the beginning of such a development. These new processes address the current lack in our organisations, i.e. efficient interpersonal information exchange. This improved social behavior leads to productivity increase and to a growth motor. And this growth will contribute to the 6th Kondratiev wave. Finally we can assume that this psycho-social innovation will be guided and levered by massive technological support. Due to this I am postulating the emergence of a new science that will combine sociological and technological sciences which we can call Psycho-Social-Technology.

Exploit the productivity potential in psycho-social innovation!