Scrum vs. Individual Development and Career Goals
We continue analyzing the blogpost that we have been covering in the previous posts by taking a look at the next phrase: “Scrum practice of ignoring peoples’ career goals and their individual talents”.
Unfortunately there are quite a number of Scrum implementations, where the above statement is true. It is also true that basic, out-of-the-box Scrum does not provide a solution to overcome this problem. In this regard, Scrum is vulnerable to criticism, but there is no point in it. It is much more important to understand, that Scrum is – as its creators state in the Scrum Guide – a “a framework for developing and sustaining complex products”. As it is not intended to solve all problems, it has to be complemented with technical and people management practices in order to be successfully implemented.
What do we need in order to respect individual career paths?
The root of the problem is that as a result of Scrum transformation, people with different professions (in the most simple case, developers and testers) needed for delivering the product are put together in a team in order to be able to deliver a full, deliverable (tested, etc.) feature set. It is not uncommon, that before the Scrum transformation, employees work together daily with 30-40 people with the same profession, having continuous opportunities to share information, discuss problems and learn from each other. After the transformation, they find themselves in a team, where there are only one or two persons left from the previous professional community. Therefore, the amount of information sharing and development opportunities is reduced drastically. That is why it is essential that although people are delegated to Scrum teams, former professional communities should not be abandoned. Such are the communities of practice which will be covered in a future post.
Another hindrance for an individual career path can be that transforming to an agile methodology introduces the concept of team responsibility. This can make team members feel that they have little influence over their achievements, because their professional recognition depends on others. This problem is really easy to solve: individual goals, for which the team member is solely responsible can be introduced as part of the professional development and employee performance management system. Of course, these goals need to be in aligned with the organisational, product and team goals. Such can be for example holding an internal presentation for the team, researching a new technology and so on.
Besides challenging the career path opportunities in an agile environment, the blogpost accuses Scrum of ignoring peoples’ individual talents.
We can only guess why this is the author’s opinion. One of the goals of the methodology is for team members to get acquainted with each other’s segments of expertise in order to be able to work on the widest possible area of the product. This however, doesn’t mean that they have to do something else than what they are good at. It merely means that work is not determined by what we have the skills for, but by what is needed for success. If there are tasks in a team member’s favourite area, she or he is naturally – in agreement with the team – free to work on it. However, if there are no such tasks, the team member still has to provide value and actively participate in the work.