Scrum versus individual development, career path
We continue the analysis of the article linked in the previous post with the following half-sentence: ‘Scrum practice of ignoring peoples’ career goals and their individual talents’.
Unfortunately, the fact is that there are plenty of Scrum implementations where the above statement has become true. It is also a fact that basic, “out-of-the box” Scrum does not provide a solution to this problem. For this reason, the methodology can be criticised, but we think it is unnecessary. It is much more important to recognize that Scrum – even by its creators’ own admission – is a project management methodology. In itself, it does not solve everything; a successful implementation requires the addition of both technical and human (people management) practices.
So what is needed to maintain an individual career path?
One of the roots of the problem is that the introduction of Scrum has led to people with different skills needed to deliver the product (in the simplest breakdown, let’s say developers and testers) being put into a team to deliver complete features together in a releasable (tested, …) way. In many cases, before Scrum, an employee worked with up to 30-40 people of the same profession on a daily basis, and thus had the opportunity to communicate with them, discuss problems and learn from them. After the introduction of the methodology, you suddenly find yourself in a team where you are surrounded by only 1-2 people from this professional community. The exchange of information and the possibility for development are therefore drastically reduced.
The condition for success is that, although people have indeed been dispersed into Scrum teams, we still keep the former professional communities. To solve this, the community of practice was born, and we plan to write a separate post about it.
Another obstacle to individual career paths may be that the methodology also introduces the concept of team responsibility. This may indeed cause individuals to feel that they do not have enough control over their own success, depending on others for their recognition. The solution to this is even simpler: make part of the development and appraisal system individual goals that the employee can strive for on their own. Of course, it is important that these goals are in sync with the goals of the organisation, the product and the team. Such a goal could be to give an internal technical presentation to team members, to learn about a new technology, etc.
In addition to the career path issue, the article also mentions that Scrum ignores the talents and skills of individuals.
We can only guess why the author might think this. The aim of the methodology is to enable team members to work on as wide a range of the product as possible, learning each other’s areas. But that doesn’t mean you have to do anything other than what you’re good at. It simply means that what we do is not determined by what we have the people to do, but by what we need to succeed in business. If someone has a job in their favourite area, they are of course free to do it, in consultation with the team. But even if you don’t have such a role, it’s important that you can remain a valuable part of the team and actively contribute.