Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


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


Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Community comments

  • its just mindset

    by puneet jain,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    what will happen when the 6 years experience guy will be put in a team having average experience of 7-8 years. In that team the person will not ask for authority and respect because he will be junior again. so IMO, at the end of the day, if you learning/contributing to the team, everything should be fine


  • The real measure...

    by Tero Vaananen,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    In a team, you have to earn your excellence each day and your strengths and weaknesses become obvious to you and your team members. But in a team, you can not look at the other members as competition, because a team is about collaboration. You do not exploit other people's weaknesses to promote your own strengths for your personal gain. You help the people in your team with your strengths and hopefully someone will help you when you need it. The team is not all about you, but about you all.

    I guess this can be threatening to people who feel a sense of entitlement. But if they are deserving, they will do well in teams as well because of their skill and experience. When things roll naturally, they will still be the leaders and have the respect of the team, in ways that it is not even possible with titles and positions.

  • Stop throwing people together; build teams instead

    by J. B. Rainsberger,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    My immediate reaction to this

    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”.
    is that it illustrates a lack of trust. The senior people don't trust the people they would work with on the new Agile team. Why do companies insist it's a good idea to ask people who don't trust each other to try to work closely together? That only ever works due to luck.

    Don't throw people together. Build teams. Start with people who trust each other and let them develop as a team. If you have to, start with only two people.

    If you prefer an analogy: diets fail for a majority of people, but those who make gradual sustainable lifestyle changes find they can keep their weight down.

  • Re: The real measure...

    by Vikas Hazrati,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    The team is not all about you, but about you all.

    I really like this line. I think a group of people can understand this and work together, they would end up in a TEAM.

  • Re: Stop throwing people together; build teams instead

    by Bruce Rennie,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Interesting. I don't disagree at all with your main point but my initial reaction to the quoted text was different.

    We've all been thrust into a newly formed team at one time or another. In the case of these senior developers, their first reaction is to search for the comfort of hierarchy based on years of experience. That's a bit concerning, isn't it?

    Still, your point about growing teams instead of looking at people as interchangeable is right on.

  • Authority,Respect, Seniority: A Cultural mindset

    by B Sudhakar,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    This is very true for organisations in cultures which believes in boss-subordinate relationship which stems from age-old traditions of respect for social hierarchy, caste system and patriarchal family setup. Certain cultures in Asia, e.g. in India requires one to respect seniority in age,male dominance and corelate it with wisdom. In such cases command and control type of management always work. This always leads to situations where subordinates hesitate to admit failure or communicate bad news for fear of being reprimanded. Trying to introduce Agile will not always work.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p