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

56272Re: [scrumdevelopment] Non-cross functional team

Expand Messages
  • Charles Bradley - Professional Scrum Trai
    Nov 26, 2012
    • 0 Attachment
      Correction:
      > Sure.  Why not?
      Should read:
      > Bundled estimates -- Sure.  Why not?

      (Separate estimates wouldn't be horrible either, but I prefer the Dev Team do as many things as possible in a "we are one unified team" type of way)

      I should have also mentioned that I strongly encourage that you try to encourage the team to increase the cross functionality of the *individuals* -- so maybe that's what people can do when they are a little under-utilized.  Read, pair, learn, experiment, etc.  I also agree with Ron that 100% utilization of individuals is a fool's errand in this context.
       
      -------
      Charles Bradley
      http://www.ScrumCrazy.com




      From: Charles Bradley - Professional Scrum Trainer and Coach <chuck-lists2@...>
      To: "scrumdevelopment@yahoogroups.com" <scrumdevelopment@yahoogroups.com>
      Sent: Monday, November 26, 2012 5:09 PM
      Subject: Re: [scrumdevelopment] Non-cross functional team



      Marv,

      I'll take a different tack here...

      First, I agree with Alan, your team is cross functional, and the *individuals* on the team are not 100% cross functional(which is quite common).  The more cross functional your *individuals* become in the long run, the better.

      > Should we try to estimate mobile / server work for stories separately (i.e. each story get two differently point-estimates) or bundle all work into one estimate?

      Sure.  Why not?  This is uncomfortable for most at the beginning, but it's amazing how good people can be (~90% of the time) at estimating work outside their own skill set, if you practice it enough.  In these situations, I usually emphasize something along the lines of "It is a team estimate, and if you have varying levels/skillsets on your team, then just estimate for a 'mythical average Scrum developer' on the team.  Have quick discussions to justify large estimate variances just like described in the 'Planning Poker' practice.  Trust me, you'll get used to it after a while."  As a rule of thumb, I generally don't like to let teams discuss an estimate for a story more than about 2 minutes. 

      > If we have only one bundled estimate it becomes difficult to select stories in planning since mobile
      > and server capacities are not the same. We may end up in a situation where mobile developers have
      > too much work and server developers too little.

      Is this not something your team can analyze in the Sprint planning meetings?  Sure, it might take more than just "Pick the first X points worth of stories on the backlog," but you can your team give some thought to such things.  I've had a couple of teams that took a few extra minutes each sprint to look for the critical path of the work for the sprint -- and they really enjoyed understanding those risks at the beginning of the sprint.

      I agree with others that sending a single person to CSM is really not enough -- My personal recommendation is training for all on the team *and* 3-6 months of coaching.  Having said that, I'm possibly biased because I'm a Scrum Coach and (now) a Scrum Trainer.  If you can't get the training and coaching, then my recommendation would be to:
      • Post here on the list like you just did. 
        • Caveat:  Understand that a) you may not always like the answers you get, or they may seem confusing and b) it may take you a while to separate the noise from the signal.  Having said that, you've gotten some great advice from some of the best in the business on this thread already.
      • Another good forum is here:  https://www.scrum.org/Forums
        • Same caveat as above.
      • I don't really trust most of the LinkedIn forums, but if you get an answer from a Scrum Alliance or Scrum.org trainer on LinkedIn, then that's probably good info.
      The CSM and this list were all I had to go on at first as well... and it has been a long road for me with Scrum.  Training for the rest of my team members/orgs,  and coaching, would have benefited me and my orgs much more.  The Scrum road for those of us forced to learn mostly on our own(and by doing) is tough and long, but I'd recommend Scrum #'s 1, 3, and 5 on this list of resources for you, especially #3.
       
      -------
      Charles Bradley
      http://www.ScrumCrazy.com




      From: marvin438android <marvin.438@...>
      To: scrumdevelopment@yahoogroups.com
      Sent: Thursday, November 22, 2012 12:55 AM
      Subject: [scrumdevelopment] Non-cross functional team

      I am working as Scrum Master for a team of 6 developers. We are building a system with a server, a mobile client and a web client.

      The team is not cross-functional. We have
      1 mobile developer
      2 server & web client developers
      2 developers capable of doing server, web client and mobile development

      Should we try to estimate mobile / server work for stories separately (i.e. each story get two differently point-estimates) or bundle all work into one estimate?
      If we have only one bundled estimate it becomes difficult to select stories in planning since mobile and server capacities are not the same. We may end up in a situation where mobile developers have too much work and server developers too little.
      Even if we give separate mobile / server estimates for all stories (and measure velocity separately), forecasting is difficult because some team members can do both kinds of work.

      Any practical advice for working with this kind of team would be greatly appreciated.

      Regards,

      - Marv



      ------------------------------------

      To Post a message, send it to:  scrumdevelopment@...
      To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...! Groups Links

      <*> To visit your group on the web, go to:
          http://groups.yahoo.com/group/scrumdevelopment/

      <*> Your email settings:
          Individual Email | Traditional

      <*> To change settings online go to:
          http://groups.yahoo.com/group/scrumdevelopment/join
          (Yahoo! ID required)

      <*> To change settings via email:
          scrumdevelopment-digest@yahoogroups.com
          scrumdevelopment-fullfeatured@yahoogroups.com

      <*> To unsubscribe from this group, send an email to:
          scrumdevelopment-unsubscribe@yahoogroups.com

      <*> Your use of Yahoo! Groups is subject to:
          http://docs.yahoo.com/info/terms/







    • Show all 20 messages in this topic