vesterberg.se

Pehr Gyllenhammar, president of Volvo some thirty years ago, tried to find new ways to increase the productivity. He got the idea that he would build the technical environment in the factory with the workers as the starting point and not the other way around, as was the rule.

Assembly lines were the common way to build cars ever since Henry Ford. Volvo had developed the practice meticulously and every part of the work was optimized. Time was measured in seconds. The assembler did his work monotonously all day long and he was really seen as an extension of the hardware, the technical environment. The factory was organized like clockwork, planned in utmost detail. The problem was that productivity did not increase as expected as each part was optimized. The human side was forgotten and this resulted in people getting sick and staff turnover was great.

Pehr started to experiment with a new type of factory. He tried to do a paradigm shift. That was not an easy thing and many around him protested; Cars have been assembled this way for seventy years. In the new factory, the assemblers worked in teams and built sections of the car. They were able to control and plan their work and organize themselves. They were involved in decisions and quality control. The advantages of the small engineering workshop were rediscovered. Even the architecture of the factory was different. This factory in Kalmar eventually had the highest productivity of all factories for Volvo cars and visitors from all over the world came to see what was going on.

Interesting, isn’t it; people working in small teams, given the freedom to organize, to decide and take responsibility. Not an easy task to achieve, but the way to go in these days. The result is commitment and creativity and the gain is greater than if you control every part in detail. You cannot take apart a process and optimize every part in isolation. You have to consider the whole system and most of all you have to consider the human aspect. During the industrial revolution the machines ruled, consuming both man and environment in the long run. We must move on and learn from history. We must have a sustainable view of man.

After having completed a certification course at Citerus, I can now call myself a Certified Scrum Master. What is behind such a strange sounding title? It surely sounds mystical? But no, a Scrum Master is a project leader in software development according to the Scrum project model. They got inspiration from rugby when they chose the name Scrum. Luckily for a thin and lightweight guy like me, it is not about managing a project like a rugby game.

Scrum is about how to successfully manage projects in a complex and constantly changing world and challenges the present way of dealing with IT-projects. The project leader, the Scrum master, is more like a coach and does not control the details. The cross-functional development team has great freedom and responsibility and can decide how best to implement the specification. The product owner should be very involved in deciding and prioritizing the content of each increment. Development is done incrementally in short regular intervals, during which the specification is not allowed to change. This way, the developers can work undisturbed. The goal of the increment is to present a demo of the product with some real business value after the period.

As a preparation I read the books Agile Software Development With Scrum by Ken Schwaber/Mike Beedle and Agile Project Management With Scrum by Ken Schwaber. Both books describe Scrum theoretically and give a lot of examples. They are well worth reading.

The course was intensive, with many discussions and exercises. Many of the other participants were already applying Scrum, so I had many interesting discussions. I do believe in the foundational principles of the Scrum model and those days were very well invested time and money.

Having the right process control model when you develop software is of great importance. When I look back it seems that many of the projects I have been involved in have been very complex and most of them have had many areas of unpredictability. They have not at all been close to an assembly line. Treating them and controlling them like you would an assembly line would be frustrating and plain wrong. Sometimes projects are like assembly lines, we walk the path we have walked before and we know what will happen. We can predict the road ahead and estimate the time it will take correctly. But most of the times the projects are not like that. We estimate time, but that is just a guess and in the end the developer feels guilty because he could not estimate better.

We live in a fast changing and evolving time and we can only accept it. Requirements will change while we are building and the needs of management and customers will change. There is no time for the technology to settle, but in order to have competitive edge we constantly use bleeding edge technology. Wrong time estimates and unreached goals is not the developers fault. We must have a model that resembles reality.

I have been using the Agile approach for quite some time and lately been looking into Scrum. Scrum is a Process Control Model that fits the above scenario. It describes itself as an empirical model of process control and advocates a paradigm shift from the traditional view of process control modelling.