Cooperation in the development team in practice

Menu

Total Quality Management

Let’s assume that graphs above present the performance of two different teams in the same company. The black line is an external metric shared with the management, the blue one is observed internally. The black lines are exactly the same so both teams were able to reduce errors significantly to the same level – the goal was achieved. One may say that there is no difference between these two teams. For sure the difference is not observable for a management. Project was finished successfully so we are waiting for a next challenges.

The company measures our performance and effectiveness by looking on the charts, numbers. The theory is simple. The managers set up goals, priorities, coordinate tasks. The employees are responsible for the results. Who is responsible for the delays?

– I have a problem with the hardware and software. It didn’t work. I couldn’t do my tasks.– Oh… your performance is terrible. Take a look at this chart? Try to read the guidelines.– I have a problem with the hardware and software. It didn’t work. I couldn’t do my tasks.– Oh… this task is the most important now. You should finished as soon as possible. Try to restart your hardware next time.

Who is responsible for the delays in the above situation? Employee? Manager? Partners? None of them and all of them.

The question is not who is responsible for this situation but what to do now? Charts help us to identify the existence of the problem, not the reasons or solutions. The problem may be simple or complex but to solve it we have to start asking to understand its nature.

How asking about “who” helps? In my opinion it helps to increase the delay and nothing more.

How to deal with bugs? The first solution is to implement a control chain – an inspection process. Each part of the project (e.g a module, script, documentation) will be controlled by a number of people or systems during the development.

Quality Engineer: Hey, I have detected a bug that should be fixed till the end of the week.Developer: Oh, ok. I will fix it as soon as possible.

This is a standard dialogue between developer and quality engineer during the development process. The bug was detected and probably it will be fixed as developer said “as soon as possible”. From the quality engineer perspective it is something what should be done here.

Housing estate resident: Unauthorized cars shouldn’t be here!Housing estate administrator: Oh… I will install RFID based car authorization system, then we solve the problem. We need 10k dollars to implement such system.Another voice: Why unauthorized cars are the problem? Is it true that there are no parking for the guests? The RFID based car authorization system will deepen the problem only. This is not what you want!

How many times the bug solution is a reason of the next, more serious bug? To solve bugs we have to think about the whole context not the bugs only. We should learn how to ask about the reasons. How dilbert comic is related to the article? The bug is a lie. The more serious bug is an unsatisfied client. The most serious bug is a company culture represented by the manager.

I have no time to learn at home, I have no time to learn at work, I have time for wasting so much time.

In my opinion learning always means taking risk. Nowadays, companies encourage people for taking trainings but in the same time they do not tolerate mistakes and as a result they do not tolerate creativity. We have to risk our position, to do something in a different way, different than everyone before, change or improve something. What if we will fail? A disaster. We turned out to be irresponsible and stupid. What if we will succeeded? Nothing. Lucky guy, but nervous. In this case it is better to be like everyone. It is a trap …

How to be a good programmer? By programming. How to develop our skills by doing the same, well-known things? Impossible… We have to break such infinite loop to go further. Unfortunately, it will be uncomfortable for us, due to challenges on our way.

How to start? Let’s ask your colleagues about the worst task they performing. Ask about their ideas and design a small thing that will help them a lot. Small thing – small risk, but maybe a great improvement.

The goal is to do tasks immediately. Unfortunately in most cases tasks cannot be separated. When we build a house we start from foundations. We have to be sure that everything is good enough to start building a walls. Otherwise, after some period of time our house will be turned into a piles of rubble. Can we enjoy fast results if we will be forced to repeat everything? Sometimes we are doing our tasks ASAP, but like a hamster in a spinning-wheel we are stuck in the same place. What do you think about that?

Thinking about innovation and quality management may lead us to contradictions. Preparing to this article I have found number of empirical case studies that describe the relationship between quality management practices and innovation performance. One of such may be found here.

[…] several scholars reject the positive relationship between TQM and innovation for the reason that it possesses principles and practices that could hinder innovation. Slater and Narver (1998) and Wind and Mahajan (1997) agree that a customer focus philosophy could easily lead organizations to focus only on incremental improvements in their current products and service activities rather than trying to create novel solutions. Consequently, this leads to the development of uncompetitive “me-too” products rather than the development of real innovation. Customer focus, therefore, could build a “tyranny of the served market” in which managers see the world only through their current customers’ eyes. In this way, such firms could fail to explore customers’ latent needs.

Combining the two sections of the above analysis provides a plausible evidence and explanation on the positive and significant relationship between TQM practices and innovation performance because not only TQM itself would lead to innovation performance, but the quality performance resulting from TQM practices also contributes to innovation performance. […] This means that although quality management does not directly result in innovation, organizations that want to pursue a high innovation performance must have the capability to manage quality requirements of their products before hand, as asserted by Bolwijn and Kumpe (1990) and Ferdows and DeMeyer (1990). In other words, quality management is a prerequisite for innovation management, and, therefore, TQMis necessary although not sufficient for innovation

How it looks like from employee’s perspective? As an engineer I like discoveries, experiments and innovations. I realize that my interests may lead me to failures. In most cases unacceptable in a corporate environment. It is a difficult task to be innovative and reliable in the same time. It is difficult to be innovative inside the well-working factory. Where is the golden mean between standardization and innovations?