A long time ago, I read a book written in 1969 by Laurence J. Peter called The Peter Principle. It explained that those who work well are promoted to better job positions bringing on more responsibility. And so, they will end up in a position in which they would not be able to even fulfill their work objectives, hence reaching their maximum level of incompetence. It makes sense, since when we see someone with certain abilities, we will always get the idea of promoting them.
According to Peter, the job would always be done by those employees who have not yet reached set level of incompetence. He calls it the Peter Principle and it is a classic in human-resource-applicants literature.
For very long now, I have lived all kinds of agile companies’ “transformations”. In most cases, the first step often takes place as a result of some CEO with true vision… finding a new team that has knowledge and used Scrum before, bringing them into the company, and so start down the path of agility.
This is the beginning of a frantic search or external staff selection, internal rake, having a chat with business partners with available “resources”, or any other activity that allows them to add the much desired new competent Scrum employees. The more experience, the more satisfaction for those who boost the “experiment”, giving the idea of soundness on the future success of the initiative. In most cases I have seen, one or two small groups with Scrum knowledge are brought in, and they will lead the way.
Let us have a look at the rest of the structure and senior positions. Do they generally have the right level of Agile and Scrum expertise? Generally, they do not. Here is where we come across the first paradox: the new competent teams will be managed by incompetent individuals in levels of Agile, Scrum, or Lean expertise.
And so the first principle applies: work is carried out by those employees that have not reached the level of incompetence.
In regular time intervals or timeboxes, teams will soon start to develop a software product and MVP’s, creating a high number of secondary tasks due to their higher productivity. Some of these tasks will have to be carried out by people without any Scrum or Agile expertise. Consequently, a cumulative dead weight of tasks will fall upon the executive or management level, formed by people and potential incompetence candidates created by the pressure from the new tasks and the lack of experience that would help them know which direction to take.
Another paradox is that the skills of the Scrum team employees will not be determined or evaluated by strangers, but by their direct supervisor in the organizational structure. If the supervisor had great knowledge on Agility/Scrum/Lean, he would be able to evaluate his subordinates on matters of how to reduce the waste of processes, innovation, how to bring more value to the business, code enhancing, or carrying out a better continuous integration for both software and processes. But if the supervisor is incompetent at a Scrum level (the most likely scenario), he will evaluate his employees according to the company values and the way things have always been done “there”. The result: he will consider competent those who follow the rules, rituals, and preserve the company’s status-quo, behaviour that is far from desirable should you want to create a progressive and adaptable company, with short product cycles towards the markets that generate innovation.
In these cases, internal consistency, status-quo, process standardization, and the obsession for measuring teams will be better appreciated than the value given to the clients, continuous improvement to all structural level, or the follow up of values and Agile principles.
This is why on those scenes where a route towards agility is started just by the entry of Scrum teams (or islands of happiness), the result will be several circles of competent people with high Agile/Scrum knowledge, and also a great majority of incompetent employees. And remember… some of the latter will be in charge of managing the Agile and Scrum processes!
A good idea would be to always ask the person “are you competent in Agile/Scrum?” This can help guide crucial conversations about skills and realise the things we hope to achieve.
I have also experienced companies with incompetent Scrum teams. Normally in this situation, self-organization turns into anarchy, the developed code for “right now” is more important that tests and quality, there are some Scrum roles that are merged and others brand new that appear, and the corporate vision is feeble or non-existent, leaving the responsibility of forging the uncertain and drifting path to the teams.
The solution to avoid a large number of incompetent employees in a future Agile company seems easily understandable. But there are few organizations that practice it: equipping the people that will lead or evaluate the teams with hard and soft skills on Scrum, Lean, and Agile, and letting out all of those who are not interested in proactively supporting the initiative or way of thinking… Especially a few months away from starting down the new path!
Otherwise, we will have a high number of incompetent managers leading, supporting, and helping competent employees. This will increase resilience, friction, and it will not help consolidate the company’s success.
Thanks for listening,