Skip to main content

Who assigns dev team ?

Last post 12:55 pm May 21, 2018 by Simon Mayer
6 replies
08:26 pm May 17, 2018

I would like to know if the dev Team is assigned by a specific scrum role?  


08:59 pm May 17, 2018

No, nor should they be assigned by any particular authority. In Scrum, teams are expected to self-organize and select the most appropriate members to do specific work.


07:25 am May 18, 2018

There are no specific scrum role. As per Scrum

- Development team size should small enough to remain nimble and large enough to complete significant work within a Sprint (recommended team size in between 3 - 9 member).

- Self organizing and cross-functional with all the skills to create a product Increment

 


07:44 pm May 19, 2018

Thanks,  doubt clarified 


04:29 am May 21, 2018

I was recently at a seminar that focused heavily on how autonomous teams are formed.

It was suggested that one effective way would be to first agree on a set of guiding principles for team creation. Used well, the principles help all team members understand what is expected, and allow everyone to trust in the process.

These principles should be specific to the organization, but could be things such as ensuring a proportional mix of senior/junior or onshore/offshore staff across all teams, advising teams to keep between 3 and 9 members, and guaranteeing that the exercise is not used as a way to leave people without a team to go to.

Next, with these principles in mind, the team members should understand what they are being asked to work on, so perhaps the Product Owners would make a pitch to encourage people to work on their product.

Finally, the team members are given an opportunity to work together, face to face, to put themselves in to teams; choosing who they want to work with, and organizing amongst themselves to ensure that every team can effectively develop its product, and that the guiding principles have been respected.

Here's an example of such a technique being used: https://www.youtube.com/watch?v=bzTS-5c-UfQ


09:35 am May 21, 2018

" guaranteeing that the exercise is not used as a way to leave people without a team to go to" - wow, this sounds like a pretty nasty situation. Why would an organisation use such a way to separate an employee from all others?

"ensuring a proportional mix of (...) onshore/offshore staff across all teams" - from your experience, dear Scrum practitioners, do you think it is better to mix local with remote employees, or just form a 100% remote team?

 


12:55 pm May 21, 2018

wow, this sounds like a pretty nasty situation. Why would an organisation use such a way to separate an employee from all others?

Why would an organization [insert any verb]? Sometimes they just do; and sometimes there is simply a fear that they will.

An exercise like this shouldn't be used to single people out with nowhere to go; but it is a natural side-effect that if you allow people to choose their teams and team mates, that you might uncover that there are some people that others do not want to work with. 

It may then follow that management (or whoever) decides that this person does not belong in the organization. Using this exercise to get rid of poor-performing or unpopular staff could severely compromise trust, and limit its effectiveness.

This principle helps by safeguarding the self-selection exercise against being used to compromise anyone's future within the company.

"ensuring a proportional mix of (...) onshore/offshore staff across all teams"

I think this is very specific to the demands of an organization and perhaps the countries it operates in.

There are good arguments for not constraining the teams in such a way, but it might also be that the organization does not yet feel comfortable with changing too much at once, and may ask for teams to respect some existing conventions, whilst being open for more radical change in the future.

It might even be a harmful constraint, but a necessary compromise to allow management to get behind such an idea. If teams are already mixed in such a way, I think at worst it will limit, but not negate the gains from this exercise.

It could be that there is empirical evidence within the specific organization that mixing the teams works better than keeping them apart.


By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.