Tag: Scrum

Agile Hierarchy – a universal remedy for software development?

The concept of all agile methods such as Scrum, Design Thinking, Holacracy  as well as their diverse spin-offs is based on the approach that hierarchies are to vanish and each individual is to participate more in the overall development of the company.  This process of collaboration enhances creativity, motivation and personal responsibility. When focus centres on public reporting, the impression is given that disruptive technologies/business concepts only evolve in agile organisations. Inspired by the success of Google & Co., it would seem that new ideas cannot develop unless the office equipment includes table football, a fitness club, colourful furniture and children’s slides. It is quite obvious that agile organisations assume that any form of hierarchy inhibits innovation and new ideas or at least discusses them to death.

Apparently, Laurence J. Peter was right in assuming that ‘In a hierarchy, every employee tends to rise to his level of incompetence’.
Peter’s theory is that each member of a sufficiently complex hierarchy is promoted until the extent of his absolute incompetence is reached, which is usually the highest rung on the career ladder and the end of further promotion. Peter: ‘After a certain time, each position is filled by an employee who is unable to carry out his work’.

Or, perhaps the Dilbert Principle is right. According to this, the most incompetent workers are systematically placed in management since they can, allegedly, do the least damage there. The individuals in such positions have neither the social skills needed for a manager nor the special business skills necessary to head the department in question.

On the other hand, it seems to me that agility is simply a thesis contrary to those classic management theories, so popular in recent years, such as Management by Objectives or Management by Results or similar methods in which the higher levels of hierarchy set out what they expect from their subordinates. The difficulty that managers experience with classic management theories is that they have to exactly assess what is still feasible without making demands that are too simple, but rather challenging and ambitious so that workers remain motivated. Obviously, this is only possible when a manager has the necessary skills and expertise to express the targets in question. According to Peter’s principle, this would be possible in the least of all cases.

If regarded in this light, the anti-thesis ‘Agility’ would seem to be the right answer to classic management theories and leadership concepts.

However, in my opinion, there is a great danger in agile organisation that Parkinson’s law will apply.

Basically, Parkinson states that the simplest topics are discussed in greatest detail by committees because most participants know something about them. According to his law of triviality, it is stated: ‘The time spent on any item of the agenda will be in inverse proportion to the sum involved’.

What I am trying to say is precisely what Henry Ford is supposed to have said about his customers: ‘If I had asked people what they wanted, they would have said faster horses!’

Interpolation from existing values is always easier and more explicit that disruption for an average decision maker or an average group. Therefore, the question to be asked is what should the mission of an agile group be: Further development or new discoveries?

The complexity of topics from scientific research, basic legal regulations, corporate innovations and the resulting business concepts is increasing more rapidly. Products are being replaced faster and markets are changing more quickly and erratically. It is also becoming more difficult for one person to possess all this knowledge.

However I do not believe that agile forms of organisation inevitably react agilely to market changes.

One of the oldest operational forms of organisation can be found among tradesmen where there are apprentices, assistants, skilled tradesmen and master craftsmen. At a first glance, it seems to represent a classic hierarchy. However, the difference is that the groups are usually relatively small and the master craftsman also acts as a foreman in the sense that he can show the skilled tradesman how to improve his work. In turn, the skilled craftsman passes on his knowledge to the assistant and the assistant to the apprentice.

In this example, the hierarchy is based on skill and expertise that can be perceived and demonstrated on a daily basis. This is exactly what an apprentice or an assistant needs so as to learn and advance in their profession. To this end, they need a role model and specific instructions to improve or change their skills. Criticism from the master craftsman highlights any weak points to be remedied and praise makes the workers satisfied.

Have you not experienced this at school, during sports or as a trainee and realised how useful a certain role model, coach or instructor was?

Who would benefit if a skilled construction worker with two years’ experience was allocated to an agile working group, who was assigned the task of planning and calculating the price of a residential area under the title of ‘A new definition of urban diversity’?

I believe that both an agile and hierarchical organisation, operating in parallel, is necessary.

The master craftsman/the experienced expert should work with his equals in an agile organisation/in groups. Such individuals have the knowledge, skills and experience to discuss solutions with like-minded partners on an equal footing.

All the others are better off in a hierarchical organisation where they are trained and further trained systematically by coaches and managers.

Nevertheless, miracles cannot be expected from the agile part of the organisation in the face of a changing business world. In my opinion, it is better to further develop existing circumstances in a linear manner than newly develop a business model or a product entirely. The danger remains, however, that the ‘law of triviality’ will creep into agile teams. Football teams are also agile but not infallible; they are people with social and individual idiosyncrasies.

Besides, the mistake of putting additional pressure on the master craftsman/expert by imposing conventional organisational tasks that would usually be carried out by departmental managers, should be avoided. Departmental managers should continue to perform these tasks as assistants to the experts. These managers’ mission should be to remove all organisational excesses, such as reports and expense forms, from the experts’ workload so that the experts can work in an optimum and undisturbed manner in the agile organisation. Managers should assist in this case, and not guide the experts because they are not capable of doing this. If a manager is able to do this, then he is not a manager but rather an expert and should therefore work in the agile teams.

This procedure calls to mind professional bureacracy /expert organisation that can be found in lawyers’ offices and hospitals where experts work in a largely autonomous way with the support of a team.

In our concept for an agile hierarchy, the agile experts – only these experts work agilely- have to cooperate with the scrum/team members and find common solutions.

Only the boss is needed for disruption. Someone has to accept responsibility, be an evangelist and give everything he’s got for an idea. However, he would be well advised to discuss this with his experts. By no means should he present disruptive ideas to an agile team and allow them to make a decision.

Advertisements