BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage News Seniority, Respect, Authority and an Agile Team

Seniority, Respect, Authority and an Agile Team

This item in japanese

Senior team members, coming from a traditional project setting to an Agile project might face a situation, where they feel that they are not adequately respected for their seniority. In certain circumstances they find it hard to adjust in Agile teams.

In an interesting thread running in parallel on Scrum Development group and Agile India group Vikram Dhiman brought an interesting situation for discussion. He shared an incident of a company in which 4 senior technical people refused to join the Agile team because they anticipated inadequate respect and authority. The senior members felt that their experience would be dishonored if they had to work in a team in which the only metric relevant was “team success”. As per Vikram one of the senior member said

I have slogged hard for over 06 years to reach where I have. I don't have an issue working with people much less in experience - I would learn something from them too. But, I find it degrading to discredit all my 06 years of experience. How do I know I have grown if all the time its just "team's success" that is the metric. Again, I am not against the team - I just want respect and slight authority.

Vikram further added

In older hierarchy - you had two paths of growth : technical [tech architect, enterprise designer etc] and managerial. How do we show this to the people in an Agile set up so that you do not end up losing good and experienced people?

Giving some support to the argument, Pankaj Chawla suggested that authority and power, in any sphere of life, do decide who will survive and who will perish. He quoted an example from animal kingdom where the animals with less power always perish in the battle of supremacy. He added that, though businesses work on the notion on increasing value of differentiation however, Agile tends to put all the team members in the same bucket.

Most of the other members on both the groups were unanimous in stating that authority and respect do not necessarily come from the years of experience a person has. Respect and authority are earned with the actions that one performs. Ajay Danait added that true leaders would not quit if they are not given authority, they would rather enable authority through consensus building.

So is there a way in which the senior members from a traditional setup ease their way into an Agile team?

Guido Schoonheim suggested that the team principle of “everyone is the same” indeed does not go well with the senior members. In his view to take care of the situation the teams should start with a norming session where the roles and standards are decided on. Then the senior members of the team, on account of their experience, should be made responsible for the project quality and mentorship. This would make the senior member make use of his experience.

Peter Goldey provided his thoughts on the aspect of recognition and growth. He suggested that even though the most important metric is team success it does not mean that metrics to measure an individual's performance do not exist. According to him, if one of a pair of individuals is performing better than the rest, then they would automatically get noticed. Now it is upto the Scrum master to reward the individuals accordingly.

So how does a team measure success of an individual so that he does not feel that his efforts are going unnoticed? How does an Agile team define the career progression for senior members?

Richard Banks suggested an MVP award where each member of the team votes for the most valuable player. He also suggests that senior people on the team should be valued for their experience and their progress should depend on their contributions and how their peers value their work.

David A Barrett added that with time the definition of great programmer has undergone a change. Initially great programmers were the ones who were technically sound, the next generation required them to have skills to relate to the community and the business, now the definition of great programmers has changed further. According to him

Now, I'd say that a "great" programmer needs to be able to work in a team environment. There's a whole new set of skills to be learned - things like influencing without authority - and personality traits that lead to success. To me, the effectiveness of Scrum (and Agile in general) is what makes this latest paradigm shift inevitable.

In conclusion David and Pankaj made somewhat tangent remarks. This is what they had to say

Dave Nicolette concluded that he would consider people who feel disregarded in Agile teams more as a personality issue. He suggests that Agile is a very different way of working and not everyone enjoys working in Agile teams. The key is to get people with the right frame of mind who can contribute with the team for the success of the project.

Pankaj made a very interesting comment. He suggested

The basic problem is that Agile is a very engineering solution created by engineers for a problem that is engineering in nature but is vastly a human problem (productivity, motivation, teaming etc) and like most engineering solutions to human problems this one will also show its weaknesses as more and more humans embrace it. The good thing is that Agile is based on the foundation of iterative improvement and embracing change and I hope that Agile will use its own founding principles to do course correction and find a better solution to a changing requirement of showing a 25 year career path to guys in the technical ladder.

Members on the Scrum Development and Agile India groups were unanimous that respect and authority need to be earned. They cannot be assumed on the basis of seniority. However, there was a small undercurrent in the threads which suggested that Agile might still have to provide some answers to senior members in terms of career path and growth.

Rate this Article

Adoption
Style

BT