Author: Goran

An important element of a management philosophy is the way that management looks upon employees. It is reasonable to assume that where one is located on the scale between McGregor’s Theory X and Y plays a significant role in how management systems are designed. According to Theory X, people exhibit an instinctive reluctance to work and must subsequently be forced, monitored and controlled in order to carry out the task at hand. The perception is that people prefer to be controlled and seek to avoid taking responsibility. According to Theory Y, on the other hand, work comes as naturally to people as rest, and they can control their own work in relation to objectives that they find important. Under favorable conditions, people seek responsibility and have a vast ability to invent and create things independently.

Some time ago one of us studied a number of companies which had implemented flexible work flow philosophies. They argued that workers preferred to keep their old and boring, but also simple and safe, tasks. The only way to make them take more responsibility was to force or trick them into new roles, which is entirely in line with Theory X.

Atlas Copco Tools in Tierp, Sweden

The only exception was Atlas Copco Tools’ manufacturing plant in Tierp, Sweden. In the plant they successfully decentralized its decision-making process and transferred more qualified tasks to employees on the floor as the firm introduced a more flexible work flow. A source of inspiration for this was that top management had noticed that the employees frequently performed highly qualified tasks in their leisure time (e.g., in the form of volunteer positions in sports associations, political parties or the union). The thinking behind this, very much in line with Theory Y, was that “if they can carry out qualified tasks in their leisure time, there is no reason why they can only perform simple tasks at work”. This led management to conclude that the organization was actually restraining the abilities of its employees.

Do we need to say that the firm applying Theory Y was clearly the most successful in its implementation, with drastically cut lead times, much less capital tied up in stock, increased delivery efficiency and exceptionally satisfied employees?

You can read more about this very interesting case in our book The Agile Company - Beyond Project Management!

In the large majority of cases so-called agile organizations are only agile in part of the organization, if at all. (geek & poke, 2016)

The term agile is typically associated with project management. Agile project management has been highly successful in a large number of contexts, but it has also been criticized and lately even declared dead! But even if we believe that the reports of its death are greatly exaggerated, there usually are some problems related to it and we will discuss one of them below.

This problem relates to being agile in just part of the organization. Our view is that in our current dynamic world, agile approaches (i.e., characterized by adaptability, flexibility and speed) are just as relevant in ongoing activities as in individual projects. And even though the number of organizations claiming to have implemented agile methods or carried out an agile transformation is growing every day, it is in 99 percent of cases only implemented in some part of the organization. Frequently, what has changed is just the mentioned project management or perhaps only the management of IT projects. In some cases, it only concerns one single team having started to experiment with agile methods. Of course, this does not mean that the entire organization has become agile, far from it. We do not wish to downplay the importance of agile methods in IT projects and elsewhere, but one agile leg in an otherwise clumsy body does not make the dog supple and flexible.

Moreover, there is a great risk that the agile parts of the organization end up in conflict with the rest of the organization and its traditional management and bureaucratic culture. Not only are other departments used to longer planning cycles, they also tend to have a different attitude with regard to following plans and rules in a way that agile teams often find rigid. Conversely, what the agile team members think of as agile and effective, people in other departments often consider unprofessional and sloppy.

Sometimes, the management systems are in direct opposition to each other. One example of this is a large Nordic bank using the agile framework SAFe to manage all its IT projects. At the same time, they create a project budget every year, specifying exactly which projects they are going to carry out and how much each project is going to cost. Since deviations from the budget are not acceptable, it is basically impossible to apply SAFe and be agile when it comes to the overall management of IT projects.

You can read much more about this in our book The Agile Company - Beyond Project Management that you find in the links below.

Göran Nilsson & Lennart Francke

eBook: https://www.kobo.com/ww/en/ebook/the-agile-company

PDF: https://bbhub.org/b/K6fBx

Agile frameworks like SAFe have had a large impact on practice. If this is a good thing or not is a matter of fierce debate. However, one unfortunate thing about the popularity of SAFe and other similar methodologies is that the first principle in The Agile Manifesto seem to have been abandoned:

We value individuals and interactions over processes and tools

We could not agree more with this principle, but we fear that just like in Lean Management the tools and methods are taking precedence over people and culture in the agile movement; both agility and Lean Management have taken a turn in a less agile and more mechanistic direction.

Our conviction is that people in general want to be agile, even if they may sometimes need some persuasion. However, they can never be agile if we bury them in methods, tools, budgets, monitoring and performance-based pay. We must remove bureaucratic obstacles if managers and their staff are to make decisions based on their own good judgement of what is best for the customers, and thereby for the firm. Every measure we take to limit their freedom to do this makes them less agile, not more. This does not mean that we should abandon all methods, rules and monitoring. What we are saying is that in an overwhelming majority of organizations we overdo these things, thus suppressing agility.