How to form the team

Hi Marek,

First, I have to ask you: Is there any trouble when the management form the team, or what is the benefit of letting everyone choose their partner? Then you can figure out what was good or bad and how your company can improve it. Please consider scrum as a guide rather than a rule. If things already work, then just keep it. Otherwise, improve it one bit a a time.

Regarding the distributed team, it is possible, at least in my previous company. Everything can be discussed through online tools. If there is a tough issue, then a video conference call will be made. Of course, there will be some difficulties for PO/SM as the development team work in different countries (we even have calls at night due to time zone difference). My advice in your situation is you should have one SM in your Asia office as, from your post, I think that members in your office are more familiar with Scrum. That SM will help the Asia team understand more about Scrum and educate them properly.

Regards,

Quang Bui

P.S. I think hiring people from Asia is much cheaper than Europe.

These are all nice suggestions. However in my organizations manager has been discussing how to form teams and they announce decision: "following teams are formed". Nobody asked me for opinion.

Are you sure that skills like collaboration, respecting opinion, and self-organization aren’t actually essential to Scrum?

If managers prefer a command-and-control approach, does that really reduce these skills to “nice suggestions”, rather than capabilities which are necessary for a Scrum implementation to work?

Thanks for response. For me personally it is not a big trouble to let managements decide about the team. Except the problems I see for distributed teams.

I posted this topic, because there were strong opinions in the other thread, that teams should be formed spontaneously. This in order to discuss this issue freely.

I know that labor is cheaper in Asian countries then in western countries in Europe. This has good and bad consequences. The good side for country in Asia is to develop more quickly and use new technology. There are also communication problems in case when we are working in international company. Not always remote communication can solve issues. Nothing can replace in-person meeting and talking in your mother language. Especially in agile methodology exchanging thoughts is important.

Some my collegues in the same office are still sceptical about agile. So the picture is more complicated then you think.

Regards,

Marek

As you can see the answer from Ian is totally different than the one from Quang Bui. Ian says that "self-organization" is essential to scrum. At this moment it is hard to judge for me whether we follow scrum really in our company or we only pretending it. 

Defending our managers I would say that forming a team is just one step. From the moment team is formed we can continue working in scrum. We appoint scrum master, define sprints, take some portion of work from backlog and we start working on it. It can be more or less "agile" regardless of how the team was formed.

Taking the opposite argument we can say that possibly "self-selected teams" would be fun and it will work better. However we never tried it so we don't know the answer.

The other features - "collaboration, respecting opinion" - can still be maintained in the company - even when the team was formed as management decision. We do not ask managers what to do in our daily work in the team. We just take the jira issue and work on it, discuss on daily standups and other meetings what should be done.

Regards,

Marek

Hi Marek,

Let me make it a bit clearer for you.

Forming a team is just a step for improvement and self-organizing is always a goal we need to aim for. What I am mentioning is please do not afraid if your company doesn't work well or apply Scrum correctly at the first time. As mentioned, pointing out what is bad or good and improve it one by one.

There are several aspects that we need to consider whether we want the team to decide this matter ( i.e. team's spirit and senority, high level management support, resource plan). As in my previous company, it simply couldn't work and we had more important improvements that could give us more value rather than trying to applying this method.

So, I can't say it a do or don't for your company. Do whatever you need to do (ask the team, management board, Scrum Masters in your company) and you may have the answer. And remember, do NOT force the team to do anything, especially if they are not ready to do that.

Good luck,

Quang Bui

My current company took the approach of having managers form the teams.  Over time the makeup of those teams have changed as the team members recognize skill deficiencies and others recognize skill overload.  So there can be a way for managers to start the teams but they should let the teams then take over to ensure that they get the proper skills on the teams.  This does allow self-management, self-forming but it also helps to get the team started.

I will say that I was one that supported the self-forming team concept.  I still firmly believe it is the best way. But I am also realistic and know that it isn't always an option.  I just try to help the organization move that direction as much as possible. 

Geographic distributed teams are very difficult to do with Scrum.  It is much easier to have co-located teams. I agree with the suggestions to have full teams at each location instead of splitting teams across.  Many companies see it as an advantage to have teams split because you get to have continuous work for longer hours.  But in my experience that usually causes more trouble because of the overhead associated to trying to pass work along each day. Those companies usually work themselves into having each location do different work on the same project or have the team take on 2 projects where each one is done in separate locations which is in essence two teams. 

You are not going to be able to make all the changes at once.  Pick a part and work on that.  Then move on to the next piece of the puzzle.  But also take into account that Scrum has no process. It is a framework that provides boundaries or "fences" to work within. Every organization that adopts the Scrum framework must define their own processes. And each organization will adopt different processes.  Just help yours to understand and appreciate how the Scrum framework provides benefits and when their process is going against or outside the framework.  Then have serious discussions and determine if you want to be true Scrum or Scrumbut.  

This statement is at the end of the Scrum Guide and for good reason.

Scrum’s roles, events, artifacts, and rules are immutable and although implementing only parts of Scrum is possible, the result is not Scrum. Scrum exists only in its entirety and functions well as a container for other techniques, methodologies, and practices.