Formation of new Scrum Teams

I recently heard a story of a company inviting all its Developers (or potential Developers I suppose) to a huge room in which all current and potential products/projects were made extremely visible.  The Developers were then asked to go to the products/projects they were most interested in and would want to be a part of.   Problems with lack of skills, lack of Developers, or too many Developers, were then openly discussed and everyone came up with ideas on how to make a particular product/project more enticing.  Anything that was continuously problematic (such as no one wanted to take part), if I remember correctly, was then reassessed separately to try and see what a problem was.  Apparently this was a really successful workshop.

How important do you think it might be to first have a protected part of the organization within which teams can form?

@Alex Thank you for your input. Sounds like a good way to totally start from scratch with a lot of people and products/projects. Maybe this could also kinda work for a smaller amount of people with only one product/project.



@Ian: Unfortunately, I do not really understand the question. What do you mean with "protected part of the organization within which teams can form"?

I read a really interesting book on this topic: 'Creating Great Teams: How Self-Selection Lets People Excel'

You can find it on Amazon. 

Haven't been able to convince Management around here to try it out, but I'm still working on them:-)

I recently found this article online:

https://lithespeed.com/self-selecting-teams-work/

Hope this sheds a bit of light.

I have heard a lot of companies do what @Alex was suggesting.  I have also had a couple of Agile Coaches tell me the same exercise.  And I recently was reading about Microsoft Azure's agile processes.  They do the same thing on a periodic basis.  Google "Aaron Bjork Azure Agile Practices".  Somewhere in there is a video where he explains it towards the end.

At my current company it was done by having the Managers get in a room and assign people to teams based on their skills (as the Managers saw them) and the work that they would be doing (again based on what the Managers were deciding).  It has had some success and a lot of failures.  At the beginning there was quite a bit of swapping members and that is still happening 11 months later. 

I would love to try the approach that was originally suggested but have not had the opportunity yet. 

As for @Ian's question, what I get from that is how important would it be to an organization to create an culture where sections of the company are protected from the normal bureaucracy and allowed to self organize, self manage their own work.  I could be wrong because I frequently am, but that would be an ideal definition of an Agile company.

What do you mean with "protected part of the organization within which teams can form"?

A Scrum Studio would be an example:

"Scrum Teams don’t fit in a siloed organization. When you try to form a Scrum Team from members of a siloed organization, they are constantly being pulled away to do other work."

https://scrumorg-website-prod.s3.amazonaws.com/drupal/2017-12/Scrum%20Studio%20A%20Model%20for%20Innovation%20Dec%202017_0.pdf

@Ian.  Thank you for that article!!!!!  That is fabulous.  I read it and see some things that my current company is trying but not doing very well.  This will be a good guide for us and I am passing it along to a lot of people as soon as I hit "Submit" on this. 

@Steven, I suggest you read that and then have everyone in the management level of your org read it. 

Wow, that was great!

This approach has served me well when facilitating the self-formation of teams:

1. Gather all potential team members in a room
2. Even if they are not big sports fans, just about everyone is familiar with a "good" team.   Ask each individual to brainstorm for a few minutes on the attributes of a good team
3. Consolidate the responses in a checklist visible to everyone (i.e. - whiteboard)
4. As a facilitator of this exercise, try to ensure that the attributes received promote diversity.   Lead the discussion on this if necessary.   Be prepared to provide reasons why some attributes identified may be good and not so good. 
5. (For example, a team of all-stars might not be a good thing, as there isn't room for the team to grow and improve.   A team with a diverse makeup of gender/age/experience would be able to benefit from a variety of perspectives, etc)
6. Ask the individuals to then choose their teams.   When they have selected their team, compare the make-up of their team to the criteria they previously identified that make up a good team.   If there are differences, ask them what they could do to more closely match what they've identified as good team attributes

Thank you for all the reply. I especially liked the hands-on approach of the blog post mentioned by Robert Shandley and also the book’s ToC sounds very hands-on. Same for Timothy’s guide. This is kind of the thing I’m actually looking for. While I like the Scrum Studio paper mentioned by Ian, it is very high-level and more like a transformational topic for the whole (or part of the) organization. More describing a concept or idea than providing actual guidance on how it could (not has to) be implemented.

Hi

I stumbled over the following book, which I wanted to share, as I think it gives helpful inputs on the topic. While some stuff described like the spotify model is quite common-sense, there are many useful hints and practical descriptions of how self-selection of teams can be organized.

https://pragprog.com/book/mmteams/creating-great-teams