Hiring and Firing in a Scrum Team
Who is responsible for hiring and firing in a Scrum Team? While the Development Team is self-organizing, they might not have sufficient authority to recruit a new member or fire someone, if need be. So in my opinion, it should be the Product Owner who is not only in a position of authority, but is also responsible for optimising the value of work done by the Development team, that can include assisting them with additional resources, if required.
Let me know your thoughts about the same. Thanks.
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.
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.
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.