Hiring and Firing in a Scrum Team

Hi Aishwarya,

I think hiring and firing in a Scrum Team is a task for management (outside of the Scrum Team).

In a Scrum Team there should be a balance of powers between Product Owner, Scrum Master and Development Team. This mainly contributes to a team atmosphere, where everyone feels responsible for the Sprint outcomes and everyone has equal importance in the team.
The Product Owner owns the Product Backlog, NOT the Development Team and NOT even the Sprint Backlog.
It's the Scrum Master who can address management for getting additional resources in order to remove impediments from the team. He should be in a management position, so he has the power to remove impediments. But even the Scrum Master does NOT manage the Development Team.
The Development Team is self-organizing. So they should be able to determine, if they need additional resources. If they do, they address this to the Scrum Master.

If you organize your whole company according to Scrum, there is a bench for development team members who are not needed at the moment. Development teams can recruit members from this bench or move members to it. This works self-organizing. The hope is, that people who sit on the bench all the time will quit deliberately.
I have no experience with this approach, so I don't know if it works. Most companies only use Scrum PRN (pro re nata), so they still use the classic hiring and firing mechanism with functional managers.

Thanks Ludwig and AnotherDotCom for sharing your views.

My assumption is similar; that if an additional resource is required or someone needs to be removed, then the Development Team raises an impediment with the Scrum Master, who then takes up the matter with the (organisation's) management. But was confused if the "self-organising" development team is expected to handle these issues as well. Thanks for clarifying.

In an agile way if working responsibility and authority must go hand-in-hand. Therefore when a team is self-organizing, it will not only be responsible for self-organization but will also have the authority to do so.

If an external executive action is needed to implement any of a Scrum Team's decisions in this regard, then it is the duty of the Scrum Master to facilitate that action. This may include communicating a team's decisions regarding its composition to other stakeholders in the wider organization.

Thanks Ian for the explanation! Pretty much clears my confusion.

For a *new* Scrum Team management determines the size. The Scrum Team can’t self-organize in this stage because the team is not compiled yet.

Once the recruiters scout appropriate talent and feeds them to the hiring manager or whoever to staff, then the Scrum team is constructed.

If the Development team feels that they’re understaffed they can report this impediment to the Scrum Master who can therefore negotiate with management to add a new member to the team.

The Scrum Team should be empowered to self-organize but if they have complete autonomy over everything that’s Cowboy Coding: https://en.wikipedia.org/wiki/Cowboy_coding

Interesting point about Cowboy Coding there Doug.

However, the 3 pillars of Inspect, Adapt and Transparency (and the associated Scrum events and Scrum rules) would stop a development team - honestly practicing Scrum - from descending into chaos. On a related point - perhaps that is the reason why everyone is a Developer (no Senior/Junior etc.) and there are no hierarchy in the team.

The Daily Scrum, the 3 questions and the ownership of the Sprint backlog by the entire Dev team (and not by any individual Developer) also ensure that there is an inherent need in the team for self-regulation and self-governance.

> The Scrum Team should be empowered to self-organize
> but if they have complete autonomy over everything that’s
> Cowboy Coding

In my experience it is the absence of team autonomy which is more likely to result in cowboy coding. Team members are more likely to have work pushed onto them, or otherwise pressured to compromise quality, and less likely to have their professionalism respected.

However, it's true that organizations are stakeholders in quality. Not *everything* can be left to the individual team. That's why the organization ought to provide a Definition of Done, and sponsorship for Nexus and other transformational agile practices.

Follow up to a variation of this question: Who initially constructs the Scrum team? In other words, if the company identifies the need for a brand spanking new product, who is responsible for identifying the Scrum team members? I suspect that the first person who must be identified is the Product Owner (PO), since the PO must begin the work of creating the initial Product Backlog. And so I suspect the PO is usually appointed by a functional organization, such as Planning, which represents the voice of the customer and can best identify the PO best qualified for the particular product. But, from there, what is the process for selecting the Scrum Master and Development team members?

> I suspect that the first person who must be identified is
> the Product Owner (PO), since the PO must begin the
> work of creating the initial Product Backlog.

That is a reasonable assumption.

> And so I suspect the PO is usually appointed by a
> functional organization, such as Planning, which represents
> the voice of the customer and can best identify the
> PO best qualified for the particular product.

Wouldn't someone closer to the product itself be better? The person who has an entrepreneurial view of it and a vision of the value it should provide? Why isn't that ownership already clear? If a person has to be "appointed" to the role, doesn't that indicate systemic problems with product ownership before it even begins?

> But, from there, what is the process for selecting the
> Scrum Master and Development team members?

If Product Ownership is clear the definition of value will be clear. The next step is to identify a genuine team (as opposed to a mere selection of individuals) with the skills to deliver the increments of value articulated by the PO. The process, in other words, ought to be value-driven and team-focused.

new comment on an old post: 

i got confused here, who should do hiring and firing team members? i m not a native english speaker so i get easily confused.

i don't think that it can be given to the dev team itself. they can just have personal conflicts with a  member of the team and fire him just for that.

i think it's either the scrum master or for management (outside of the Scrum Team).

can someone explain that to me?

The "hiring and firing team of members" if a Scrum team has nothing to do with Scrum. If there are internal issues that can't be solved through common sense, negotiation, compromise, etc, then the team (likely the SM) would need to escalate to management/HR (that's for firing). For hiring, the Scrum team can do nothing. While there can be recommendations/referrals, hiring decisions are taken by others.

Well, the Scrum Team can notice a problem of not enough developers, and then can try to solve it by involving parties that can do something about it, like HR.

Back in the day, when there was only the scrum guide, this question might have been outside the scope of scrum. Nowadays with Agile Leadership being a part of scrum.org, we should be able to answer this question.

When a team needs additional devs they should be empowered to do so with help by HR (posting job openings, handling communication etc.). They should communicate what skills they need, conduct the interviews and decide whom to hire.

When it comes to removing someone from the team, the team should try to solve problems within the development team first. When there is no way in doing so, they should consult with the Scrum Master. If there is no solution to their problem after that, the team should be able to make the decision of removing the colleague from the team. But removing someone from a team and firing someone are two different things. Firing someone is not the teams decision from my point of view. This is where other stakeholders within the company should take over.

Hi This is a grey area.

Scrum.Org guide, on page 6 para 1 says:  "The Scrum Team consists of....." then it mentions the three roles. 

One can't extend self-organising to self-appointing.

Tricky

Regards

Pat

I think @Sven has the right idea.  The problem as I see it is that the Scrum Guide is written as a framework and intentionally does not address the reality that in the corporate world we have hierarchical structures of positions and responsibilities.  So in reality, we have to involve HR and Managers and such.  But everything should start with the teams.  I had one agile coach pose the idea of if multiple Scrum Teams need to be formed why not let all of the Scrum Masters, Developers and Product Owners decide among themselves who will be on the teams. Give guidelines like "No team can have more that 6 developers" if needed.  But let the Product Owner present their problem space, then let the rest of them self organize into teams.  If they understand the concept of cross functional, they will organically combine into teams that have all of the skills needed. 

For creating a new team, it varies.  If you have the luxury of being able to hire an entirely new team, then I would rely on other teams to help define the skills and interview the candidates. That way they can find people that will fit into the culture of the company AND have the skills needed for that team plus add skills to the entire organization. 

If you do not have the luxury of hiring all new people, again I'd go to the existing teams.  Present the problem space to all of the existing teams and let them work together to identify the appropriate people to form the new team. It might require that in order for Bob to leave Team A to join Team Z, Mary might have to switch from Team C to Team A to balance out the skills. Self organization is not limited to the immediate team. True self organizing teams are capable of organizing cross units as well.

All of my thoughts are based on @Sven's concept of having Agile Management as well as a larger organizational acceptance of agile practices.  If you don't have that, you just have to take the best you can and let the organization reap what it sows.  There is very little you can do about it as a Scrum Master or Product Owner.

I am re-reading the question as .. According to Scrum guidelines, who is responsible for  assigning a new person into scrum team or removing from the scrum team?

Agree with Sven's approach, that bringing someone to the scrum team, the Dev. team should evaluate what skills are required and empowered to conduct interviews with the help of HR or related function in the organization.

Similarly for removing someone, Dev. team with all openness should try to first resolve issues within  themselves by talking out what is required to complete the item in hand.

In both cases, Scrum Master will be there to remove the impediment arising out of such situations to have a high performing team.

Regards,

In many companies, the three roles of the Scrum Team report up to different line managers. If an individual's performance is affecting the team, the Scrum Master can try coaching or facilitating a mentoring path, and if that doesn't work, the Scrum Master and the Product Owner can sync up on next steps and take it to HR or the individual's line manager.

Hello, but, if you've the choice to the question that a new Developer is having continuing conflicts with existing Developers, and if needed, who is responsible to remove the new Developer from the team, what would be the right choice? Possible answers are the management, the Scrum Master (as he is responsible to remove impediments) or the Developers themselves (here no indication to the Scrum Master).

I'm really confused if removing someone from the team is part of the self-management and lies with the Developers.

Can please someone help and explain?

Thanks!

Perhaps everyone has something to do when managing such a difficult situation, as well as in trying to avoid it.

Possible answers are the management, the Scrum Master (as he is responsible to remove impediments) or the Developers themselves (here no indication to the Scrum Master).

If a Scrum Master was given the accountability to fire a Scrum Team member, what might be the impact on trust and transparency? 

Of course it's not mentioned in the scrum guide, but the reality in many companies or Orgs, is that someone on the team is unofficially appointed as a "manager" or "team leader" to do the liaise with the functional managers

When it comes to firing/hiring there is always that one member who pulls the trigger on decision

I've been in companies where that might be the scrum master or the lead developer who is also responsible for assessing performance and other "employee" metrics or behaviours.

This could be possibly the way of "self organizing", as in how the scrum team organizes itself to decide on who will make that decision when it comes to these employee/Hr related matters

Though not explicitly mentioned in the scrum guide, this is the reality for many Orgs, especially when bonusus or salary incentives are involved.

Of course it's not mentioned in the scrum guide, but the reality in many companies or Orgs, is that someone on the team is unofficially appointed as a "manager" or "team leader" to do the liaise with the functional managers

When it comes to firing/hiring there is always that one member who pulls the trigger on decision

I've been in companies where that might be the scrum master or the lead developer who is also responsible for assessing performance and other "employee" metrics or behaviours.

The reality described above may be a reason why an organization never realizes all the benefits of Scrum, as it will most likely kill trust on a team. Because without trust, the pillars of empiricism are most likely to crumble.

This is why a Scrum Master does not have the accountability to hire and fire team members, and is not the "manager", "team leader", or "boss of the team". I don't see self-management prospering, either, when the Scrum Master is the "team leader".

Rather, a Scrum Master is a leader who serves.

IMO,

If one has never led a team of developers or it personnel, then the idea of scrum teams being autonomous , sounds good in theory, but there has to be a clear leadership role on the team, with some sort of power to enforce rules if necessary.The entire team isn’t going to produce and there I’ll be member who need a kick in the ass or a sit down every now and again. Done!

If one has never led a team of developers or it personnel, then the idea of scrum teams being autonomous , sounds good in theory,[...]

Have you tried Scrum and self-managing Teams in practice? What were the outcomes?

[...]but there has to be a clear leadership role on the team, with some sort of power to enforce rules if necessary.

If you're referring to formal / appointed leaders, Scrum accountabilities are not the same as jobs. Scrum doesn't say anything and doesn't exclude Team Leaders, Technical Leaders or PMs, for example. They will be, from a Scrum point of view, Developers. And from a managerial point, they will lead or manage.

On the other hand, there's also informal leadership - people with experience and skills who rise as de-facto leaders because their knowledge is highly praised.

Moreover, take a look at the Definition of Done.

The entire team isn’t going to produce and there I’ll be member who need a kick in the ass or a sit down every now and again. Done!

A team that "isn’t going to produce" has deeper problems and just appointing a "leader" will not fix them. From my experience, self-managing groups of people can yield great value without a "local baron" - and sometimes in spite of one.

Interesting read...

I would tend to approach this topic from the perpective of team pay, initially.

• How is a team paid and how do they get their pay awards/bonuses?
• Is pay allocated equally between all members of the team?
• Do the team decide among themselves who gets what proportion of the pay award?

Whatever the answer to these questions in your specific setting (I doubt there is a textbook 'Agile' answer that should be applied to all agile teams), the answer will likely trigger the follow up thoughts / team discussions around 'fairness' / playing the system / etc

• my pay is being held back because "xxxx" is not very good
• can we get "xxxx" into the team - we'll really start doing well then, and our pay will benefit
• I really want to bring in a 'junior' and develop them into a high-performing member of the team
• what about teams made up of a mix of permanent and contractors?
• how does development of new talent affect the team's likelihood of achieving as high a pay agreement as they are expecting. How do you factor this into things? Is there some form of weighting of pay offer for teams with 'juniors' in the team, but who have a good track record of developing them into 'seniors'?

Teams will quickly realise that being empowered to do the hiring is a very good thing.

But, as with many things, this is a double-edged sword. The empowerment to hire also means the empowerment to "move people out of the team".

The team needs to decide. Anything less than this will materially affect individual's pay, feeling of empowerment and ability to nurture new talent. Any one of these things will quickly eat away at morale...