Engineering roles inside Scrum team

In my experience, many technical professionals do not concern themselves with the HR/business titles on a daily basis. One purpose of the Scrum Master is to coach the Scrum Team. If the team members are behaving in such a manner, then the Scrum Master should be coaching them to understand what it means to be a collaborative team and not a group of self-centered individuals.

The bigger hurdle in corporate cultures with respect to this topic, in my humble opinion, is addressing the accountability of the Scrum Team as a team. The whole idea of yearly performance evaluations is contrary to the agile philosophy. Inspection and adaptation needs to be continuous and not focused on individuals. Improvements in corporate culture regarding coaching and mentoring employees needs to evolve.

Though the Scrum guide doesn't say anything about it however while forming Scrum teams I recommend that "No one in the Scrum team should report to anyone within the team"

Hi Aleksander,
In my opinion, in theory as per first line of Scrum Guide - Scrum is a framework for developing and sustaining complex products.

With respect to IT delivery and structuring, SCRUM is a proven framework for delivery and can have members with different background experience, seniority etc. but will have the common goal to meet.

While senior and more experience people can influence the team - sometimes for good and for bad, it in principle should benefit the team to nurture others and meet the goal. This depends upon building up the culture to respect others and follow the Scrum theory where Scrum Master plays key role.

Ex - The estimations can follow the story point, where the points have given weight and not who weigh it, this can be a very powerful tool.


Pankaj

Hi Aleksandar,

I will just share my point of view, based on my experience. And my experience shows that Scrum is the cure for "titles" behavior.

"The title that the person has can lead to him to take leadership role in the team"
"enforce his opinion on others or cause other members of the team with lower title to be afraid to argue about differences in opinions. "

It is not a title, per se, that calls a person to lead, it is rather that person's experience and personal desire to lead. I am talking about developers titles. A title is merely a reflection that the person had worked longer, has more experience.
Btw, not all people even with experience strive to lead.

Each Team consist of individuals. No matter how much we enforce the "Team" term, there will be always individuals who like to lead, to whom it is important to lead, and people who care less about leading. What, I believe, Scrum helps with, is a Team building.
" It is the Team who is responsible for a working product delivery." - This helps to shift minds towards: not individual leading/enforcing opinions but rather collaboration. If the Team learnt/adopted the Scrum values, such team eventually becomes: experienced and non experienced work together towards one goal: Deliver a product to a customer. Notice, that I used "experienced and not experienced', not engineer and senior engineer.

You as a Scrum Master, can promote an environment in the Team where nobody is afraid to voice opinions, nobody enforces their opinions and so on. It might take time, but believe it or not, it can be done. And these two Scrum values are to help:
values of ..... openness and respect.

Use these values, put them on the white board. Refer to them all time.

Many Agile companies used to be a Waterfall companies. And it seems like, even with still having the titles in place, the companies that decided to go Agile did not get destroyed, and the Agile Teams now deliver great products.

I do feel this hierarchy is a trouble some one especially in medium and large scale companies. where the developer will get into a mind block and it also spoils the team spirit if it is not addressed early.

I believe this model will work for a developer who has high communication skills, competing mindset, a person who is good at presenting individual KPI's. This model excluding the people who are trying to improvise their communication skills, who are shy to talk about their success stories, Technically strong, working as team contributor without individual KPI's.