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

Re: Re: [scrumdevelopment] Non-cross functional team

Expand Messages
  • Diego Fontdevila
    Hi ... the problem? If I have understood correctly, the idea would be to split the product backlog items so that all would be of roughly equal and reasonable
    Message 1 of 20 , Nov 23, 2012
    • 0 Attachment

      Hi

      On Nov 23, 2012 2:27 PM, "Ron Jeffries" <ronjeffries@...> wrote:
      >
      >  
      >
      > Hi Marvin,
      >
      >
      > On Nov 23, 2012, at 10:33 AM, marvin438android <marvin.438@...> wrote:
      >
      > > As for not estimating - I don't understand how this alone would solve the problem? If I have understood correctly, the idea would be to split the product backlog items so that all would be of roughly equal and reasonable size (say 1-3 days of work) and then simply count items. While this may be a good idea, it still seems to me that the problem remains: some items would require mobile development skills and others server development skills and this makes it hard to select items for the sprint. It is difficult to compare to previous sprints - the ratio between mobile and server work is differs.
      >
      > Why is it difficult for the developers to select stories? Don't they
      > know what they can do? Is someone other than the team itself deciding what
      > the team will sign up for? That would be bad. The Product owner
      > prepares enough stories to be sure there is enough work. Then the team
      > pulls as much work as they forecast they can accomplish.
      >
      > The team is supposed to be producing a fully integrated version of the
      > product, in good working order, at the end of every Sprint. Are you
      > doing that? If so, then I should expect the a product owner to be able
      > to foresee rather well what else is needed to get a usable product.
      > What is causing difficulty in this?
      >
      > Also: Why do you want to "compare to previous Sprints"? This gives me concern.
      >
      > >
      > > Under-utilization is a problem and is not acceptable around here:-)
      >
      > Full utilization is a worse problem. It slows you down. Have someone
      > read Critical Chain, for example.
      Another great reading that might fit is Slack.

      Full cross-training helps, because
      > people become more capable. Pair programming will improve quality and
      > cross-functionality, without slowing you down. Plus most programmers
      > enjoy it. Doubtless management will kvetch about two people doing one
      > person's job ... but that's not how it works.
      >
      > Has your organization had any good Scrum and development coaching? It
      > sounds to me as if you all may need help on some basics, and perhaps
      > some advanced topics.
      >
      > Regards,
      >
      > Ron
      >
      >
      Best,
      Diego

    • marvin438android
      At least it has been easier to select stories before, when all devs have been strictly either mobile or server. Easier to grasp how much work you are
      Message 2 of 20 , Nov 25, 2012
      • 0 Attachment
        At least it has been easier to select stories before, when all devs have been strictly either mobile or server. Easier to grasp how much work you are committing to.

        Currently we estimate using story points, keep track of velocity and capacity in previous sprints. When starting to select stories for a new sprint we use old values as reference. Why is this concerning?

        We use story points for forecasting as well as for giving the PO something to deduce a price from. The points are multiplied by a coefficient (calculated from previous sprints) to give an estimate of actual hours which can then be priced.

        No scrum coaching here despite my requests. First a 2 day CSM course and then into the deep end.

        - Marv

        --- In scrumdevelopment@yahoogroups.com, Ron Jeffries <ronjeffries@...> wrote:
        >
        > Hi Marvin,
        >
        > On Nov 23, 2012, at 10:33 AM, marvin438android <marvin.438@...> wrote:
        >
        > > As for not estimating - I don't understand how this alone would solve the problem? If I have understood correctly, the idea would be to split the product backlog items so that all would be of roughly equal and reasonable size (say 1-3 days of work) and then simply count items. While this may be a good idea, it still seems to me that the problem remains: some items would require mobile development skills and others server development skills and this makes it hard to select items for the sprint. It is difficult to compare to previous sprints - the ratio between mobile and server work is differs.
        >
        > Why is it difficult for the developers to select stories? Don't they
        > know what they can do? Is someone other than the team itself deciding what
        > the team will sign up for? That would be bad. The Product owner
        > prepares enough stories to be sure there is enough work. Then the team
        > pulls as much work as they forecast they can accomplish.
        >
        > The team is supposed to be producing a fully integrated version of the
        > product, in good working order, at the end of every Sprint. Are you
        > doing that? If so, then I should expect the a product owner to be able
        > to foresee rather well what else is needed to get a usable product.
        > What is causing difficulty in this?
        >
        > Also: Why do you want to "compare to previous Sprints"? This gives me concern.
        > >
        > > Under-utilization is a problem and is not acceptable around here:-)
        >
        > Full utilization is a worse problem. It slows you down. Have someone
        > read Critical Chain, for example. Full cross-training helps, because
        > people become more capable. Pair programming will improve quality and
        > cross-functionality, without slowing you down. Plus most programmers
        > enjoy it. Doubtless management will kvetch about two people doing one
        > person's job ... but that's not how it works.
        >
        > Has your organization had any good Scrum and development coaching? It
        > sounds to me as if you all may need help on some basics, and perhaps
        > some advanced topics.
        >
        > Regards,
        >
        > Ron
        >
      • marvin438android
        No pair programming but I do see how it would help. Maybe I ll suggest it in the next retro. Developers write their own unit tests and then hand over the story
        Message 3 of 20 , Nov 25, 2012
        • 0 Attachment
          No pair programming but I do see how it would help. Maybe I'll suggest it in the next retro.

          Developers write their own unit tests and then hand over the story / feature to dedicated testers. Only after testing is the story done.

          Regards

          - Marv

          --- In scrumdevelopment@yahoogroups.com, Mark Levison <mark@...> wrote:
          >
          > One more question. Is most work being done with pair programming? It will
          > increase quality and help cross skill faster.
          >
          > Cheers
          > Mark
          > On Nov 23, 2012 11:35 AM, "Mark Levison" <mark@...> wrote:
          >
          > > You have an under utilization problem because people haven't cross skilled
          > > enough.
          > >
          > > Questions: do all of your team members pitch in for testing? Test
          > > automation? ...
          > >
          > > If the answer is no you don't have an under utilization problem you have a
          > > not done problem.
          > >
          > > Cheers
          > > Mark - from a phone
          > > On Nov 23, 2012 10:34 AM, "marvin438android" <marvin.438@...> wrote:
          > >
          > >> **
          > >>
          > >>
          > >>
          > >>
          > >> Thanks for all the answers!
          > >>
          > >> First, my misunderstanding, we do have a cross-functional team. It's just
          > >> that not all developers are capable of working on all stories.
          > >>
          > >> So one solution would be to train the team so that everyone can do any
          > >> work. We will strive towards this, but it will take some time.
          > >>
          > >> As for not estimating - I don't understand how this alone would solve the
          > >> problem? If I have understood correctly, the idea would be to split the
          > >> product backlog items so that all would be of roughly equal and reasonable
          > >> size (say 1-3 days of work) and then simply count items. While this may be
          > >> a good idea, it still seems to me that the problem remains: some items
          > >> would require mobile development skills and others server development
          > >> skills and this makes it hard to select items for the sprint. It is
          > >> difficult to compare to previous sprints - the ratio between mobile and
          > >> server work is differs.
          > >>
          > >> Under-utilization is a problem and is not acceptable around here:-)
          > >>
          > >> - Marv
          > >>
          > >> --- In scrumdevelopment@yahoogroups.com, RonJeffries <ronjeffries@>
          > >> wrote:
          > >> >
          > >> > Hi Mark,
          > >> >
          > >> > On Nov 22, 2012, at 6:28 PM, Mark Levison <mark@> wrote:
          > >> >
          > >> > > Marvin - the system is trying to give you a hint. The hint is you
          > >> need to start cross training the team so anyone can do the work. This blog
          > >> post tells you how I work with teams to grow that skill:
          > >> http://agilepainrelief.com/notesfromatooluser/2012/02/scrummaster-talesthe-team-gets-bottlenecked.html
          > >> >
          > >> >
          > >> > While I of course recommend additional cross-training, I see no
          > >> evidence that this is the hammer needed for Marvin's particular nail.
          > >> >
          > >> > Ron Jeffries
          > >> > www.XProgramming.com
          > >> > If another does not intend offense, it is wrong for me to seek it;
          > >> > if another does indeed intend offense, it is foolish for me to permit
          > >> it.
          > >> > -- Kelly Easterley
          > >> >
          > >>
          > >>
          > >>
          > >
          >
        • Steve Berczuk
          I ve found that it s generally more useful to have the stories be end to end; it will probably be hard to have any meaningful stories that are just mobile or
          Message 4 of 20 , Nov 25, 2012
          • 0 Attachment
            I've found that it's generally more useful to have the stories be end to end; it will probably be hard to have any meaningful stories that are just mobile or just web client or just server. (OK, maybe, but...) So it sounds like people will need to work together. 

            Try to estimate them together.  Treating them as end to end features might even give you some benefits; if you did the server side first then the UI next you might have more re-work then if you did them together. (Imagine a conversation that goes "if you did the server API _this way_ the client would be easier to code.)

            I can also imagine that there is more in common with the Web-server and mobile-server interfaces than not.

            And who knows, maybe people will learn to do different things and enjoy it :)

            On Thu, Nov 22, 2012 at 2:55 AM, marvin438android <marvin.438@...> wrote:

            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.




            --
            Steve Berczuk  | steve.berczuk@... | http://www.berczuk.com
            Twitter: @sberczuk
            ADN: @spb
            SCM Patterns:   www.scmpatterns.com
          • Charles Bradley - Professional Scrum Trai
            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
            Message 5 of 20 , Nov 26, 2012
            • 0 Attachment
              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/



            • Charles Bradley - Professional Scrum Trai
              ... (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
              Message 6 of 20 , 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/







              Your message has been successfully submitted and would be delivered to recipients shortly.