Splitting up a team

[Guarino]

Hi all....

I have a project team that has grown over the past few months, and now that some of the newer guys are getting their feet under them, the team is "too big".  The team feels too big, and according to Scrum definition its too big.  We currently sit with 2 BA's, 4 QA's, 9 Devs.

So yeah, we have grown a bunch :0

Anyway, we have put off splitting due to a release we had coming up, but now that is over.  I dont want to split, just because we should, I see alot of risk in splitting the team, as well as some logistics to work out.

I was hoping some of the people on here have done a split before and can shed some light on good ways to approach it.

The major risk I see is code merging.  This is probably my #1 reason for not splitting before.  Also, some ideas I had was:

   One common backlog, shared by both teams (one PO for the backlog)

   Both teams groom backlog together

   Both teams Sprint Review together

   One member from each team must standup in the other teams Daily Standup.

   Each team will plan on their own

   Each team will retro on their own

These are just some guidelines I was thinking of, and was also wanting to ask the team their thoughts as well.

Any suggestions thoughts or comments??

(the reason the team has grown, is the project has become bigger, and a higher priority in the company)

Thanks in advance !

[Mark Levison]

I've seen over a hundred people (multiple teams) working off one main. Its possible. What stops you having 15 people working against one main? 

BTW Have you asked the team?

Cheers

Mark

--
Mark Levison
Sent with Airmail

--
You received this message because you are subscribed to the Google Groups "Scrum Alliance - transforming the world of work." group.
To unsubscribe from this group and stop receiving emails from it, send an email to scrumallianc...@googlegroups.com.
To post to this group, send email to scruma...@googlegroups.com.
Visit this group at http://groups.google.com/group/scrumalliance?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Chet Hendrickson]

HI,

Can you tell us a bit more about the team feeling it is too big.  What sorts of problems are they encountering?  

chet

	Chet Hendrickson ch...@hendricksonxp.com	Tel 248.345.7258 http://www.hendricksonxp.com

[Guarino]

@Mark I have only gone to a couple senior guys on the team so far, I plan to bring it up in our next retro.  Of course, it has come up here and there about if we are going to split.

@Chet Not sure I can to be honest.  Its by far the biggest scrum team I have been on, so maybe its just me :)  Our velocity seems to be taking a hit, again this is hard to judge, so dont jump on me quite yet.  But I have read lots of books talking about dimiishing returns on scrum teams, so its probably "normal" for me to begin feeling this may be happening.  The DSM has grown to about 20mins, team members get a bit antsy, I find myself asking people to listen, or just have one conversation at a time. 

Planning meetings seem to become less productive, lots of chefs in the room so to speak.  I find myself interjecting more than I normally would to try and keep the entire meeting into perspective.

Sorry Chet, not sure if this really gives a good answer, I am wishy washy on splitting at all.  Guess that is why i am looking for some other ideas, or some questions to ask myself even :)

[John Miller]

Hi,

I empathize with your situation.
Have you tried articulating what you said here to the team?
Perhaps during a retro, state "I find myself asking people to listen, or just have one conversation at a time. What is happening?"


Thank You,
John
Sent from my iPhone. It likes to sabotage my grammar.

[Mark Levison]

Guarino - you don't have one team. You have at least two teams. Beyond 9 people you will always get implicit sub-teams, its about social connections. The late Richard Hackman (researcher on teams) explained that teams work best up to about 6-7 people.

Cheers

Mark

--
Cheers
Mark Levison
Agile Pain Relief Consulting | Writing
Proud Sponsor of Agile Tour Gatineau Ottawa Nov 28, Toronto 26 and Montreal 24

[Markus Gärtner]

Guarino,

something to think about: if you don't formally split the team, it will informally split itself once it reaches a certain size. I am sure you already have some hunches about that informal organization. Do you want to have that split, or would you like to stay in control of that situation by coming up with the split yourself?

Best Markus

--

Dipl.-Inform. Markus Gärtner
Author of ATDD by Example - A Practical Guide to Acceptance
Test-Driven Development

Agile Team Academy, September, Amsterdam http://www.agileteamacademy.com/

http://www.shino.de/blog
http://www.mgaertne.de
http://www.it-agile.de
Twitter: @mgaertne

[Chet Hendrickson]

Hi,

Let me build a little on Mark's observations.  

Scrum has us construct a team with three nodes.  I will ignore the Process (ScrumMaster) node and concentrate on the other two.  Let's call those Vision (Product Owner) and Build (Development Team).  

You are posting on the ScrumAlliance list, so you must be doing Scrum, and if you are doing Scrum, you must have a ProductOwner.  Right?

Your stated concern is with the size of the Development Team.  My experience is that nine developers is not too many and would not in the absence of disfunction cause me to split the team.  

In addition to the devs, your Dev Team also has QA and BA folks.  I would look at those and ask if they are all really Build folks or do some of them rightly belong on the Vision side of the house with the PO.  

Scrum tells us that a Scrum Team's Product Owner is a single individual, but Scrum also tells us that we should pay attention and get better.

I can imagine that a significant portion of the QA and BA time is spent helping the PO understand what she wants and discover whether the Devs have actually built it.  I might decide that all of the BAs and half of the QAs are members of the Office of the Product Owner.  I would let them and the PO run their own lives.  This would reduce the size of the Development Team to a more manageable size and perhaps even reduce the length of the Daily Scrum.

chet

Chet Hendrickson ch...@hendricksonxp.com

[Michael James]

On Apr 22, 2013, at 6:15 AM, Guarino <sofa.k...@gmail.com> wrote:

The major risk I see is code merging.  This is probably my #1 reason for not splitting before.  Also, some ideas I had was:

   One common backlog, shared by both teams (one PO for the backlog)

   Both teams groom backlog together

   Both teams Sprint Review together

   One member from each team must standup in the other teams Daily Standup.

   Each team will plan on their own

   Each team will retro on their own

This turns out to be a controversial area so you'll probably get contradictory advice from this mailing list.  The ideas you laid out seem like a good starting point to me.  One thing I would add would be a large scale retrospective for the teams to inspect and adapt their coordination with each other.  You could use an open space format for that, see http://www.amazon.com/Open-Space-Technology-Users-Guide/dp/1576754766

As Mark wrote, multiple teams have succeeded at continuous integration.  You'll quickly find out how good your TDD practices actually are when they first try this.

Hope that helps.

--mj

http://ScrumTrainingSeries.com

[Guarino]

I wanted to thank everyone for their posts, and insights.  I have brought it up a few times in retro's "are we too big?", but we have not landed on a "yes" yet, so I guess we are not too big :)

On a side note, for anyone following the thread later, the team was "realigned" recently.  Due to another project taking some resource hits, 2 of the developers have moved to another team.

The only reason I bring this up, is I believe its due to us not splitting.  I feel if we had split our team a few weeks back, we would have had a good mix of senior, junior and new guys on each team, making it harder to "steal" resources away.  In this instance, I feel the move we made was the right one, but losing 2 experienced guys to another team will certainly takes it toll on our project.

Anyway, I wanted to say thanks for the help guys.

[Yves Hanoulle]

Hi,

We had a similar challenge in our team.

I blogged about how I helped the team to take the decision on splitting or not splitting

http://www.hanoulle.be/2013/05/challenge-to-split-or-not-to-split/

Yves

2013/5/8 Guarino <sofa.k...@gmail.com>

--