Loading ...
Sorry, an error occurred while loading the content.

RE: [scrumdevelopment] Re: Twin/Buddy system for a large team

Expand Messages
  • Joe M
    CAN SOMEONE UNSUBSCRIBE ME ? I have been trying for 6 months now, honestly To: scrumdevelopment@yahoogroups.com From: haricha@gmail.com Date: Sat, 6 Mar 2010
    Message 1 of 15 , Mar 20, 2010
    • 0 Attachment
       CAN SOMEONE UNSUBSCRIBE ME ?   I have been trying for 6 months now, honestly 

      To: scrumdevelopment@yahoogroups.com
      From: haricha@...
      Date: Sat, 6 Mar 2010 10:02:41 +0530
      Subject: Re: [scrumdevelopment] Re: Twin/Buddy system for a large team

       
      I agree with Mark here that its best to split teams based on architecture of product. I have experienced it with a product in which 30 members were there and we could split it after almost 3 days of debate among managers in 5 teams ranging from 4 to 9 individuals.

      - Hari

      On Fri, Mar 5, 2010 at 8:20 PM, woynam <woyna@argonne. com> wrote:
       


      It sounds like you have an architectural problem. The system should be able to be split into independent, or loosely coupled subsystems/services /components. Each team would work on a different subsystem. The interfaces between the subsystems would be defined early in the Sprint, and the two teams would work independently on their piece(s), mocking the dependent subsystems.

      Did you try splitting the teams along architectural boundaries? Having two teams work on stories that require the same subsystems is tricky.



      Mark

      --- In scrumdevelopment@ yahoogroups. com, "manojvp100" <manojvp100@. ..> wrote:
      >
      > Hello Mark,
      > There are some sprints we could split them to two teams and have them work on two different user stories. But in many cases, because of external dependencies and such, we didn't have many choices.
      >
      >
      >
      >
      > --- In scrumdevelopment@ yahoogroups. com, "woynam" <woyna@> wrote:
      > >
      > >
      > > Can you tell us why 2 teams can't work? There are plenty of companies that have scaled Scrum beyond 2 teams, so there's no reason it shouldn't work.
      > >
      > > How did you divide the work between the 2 teams?
      > >
      > > Mark
      > >
      > > --- In scrumdevelopment@ yahoogroups. com, "manojvp100" <manojvp100@> wrote:
      > > >
      > > > Hello folks,
      > > > We have a large size (13 or 14) team that we are having trouble keeping up with the number of tasks going on in a sprint. The team has a mix of senior/junior, on-site/off- site, have/don't have domain knowledge type of team members.
      > > >
      > > > We looked into having two scrum teams, that doesn't seem to work. We need to have a large team so that we can accomplish what we have to in the given time-frame. The problems we are facing now are, daily stand-ups are taking too long, the sprint backlog is getting too long that we cannot manage, and the like. We are also seeing some issues because of the lack of expertise (technical or business) in the work products of some of the team members – that are being found out during daily meetings or even later. (I know, we should try pair-programming. We are just starting with real agile now. So I am reluctant even to propose that! I know I can't sell that yet.)
      > > >
      > > > The idea we are playing with now is to have a Twin/Buddy system for our next sprint. Each team member will have a buddy and each set of buddies will work on one small part of a user story at a time. The buddies will be selected such a way that they complement each other. Only one of the twins will attend meetings. Twins will work together as many times as they can/want during the day.
      > > >
      > > > What are your thoughts? What pitfalls should we look out for in such a system? Any other recommendations?
      > > >
      > > > Thanks
      > > > Manoj
      > > >
      > >
      >




      --
      Regards,
      Hariprakash Agrawal (Hari),
      An Agile Coach (XP, Scrum), Certified Scrum Master, Trained Six Sigma Black Belt, CMMi Consultant, ISO 9001:2000 Lead Auditor, MTech (Reliability & Quality Engg) from IIT-KGP
      http://opcord. com - OpCord provides trainings/consultin g on many frameworks/processe s and testing services for organizations



      The New Busy is not the old busy. Search, chat and e-mail from your inbox. Get started.
    Your message has been successfully submitted and would be delivered to recipients shortly.