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

Non-cross functional team

Expand Messages
  • marvin438android
    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
    Message 1 of 20 , Nov 21, 2012
    • 0 Attachment
      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
    • Michael Vizdos
      Ask the team. Mike Vizdos
      Message 2 of 20 , Nov 22, 2012
      • 0 Attachment

        Ask the team.

        Mike Vizdos

        On Nov 22, 2012 1:28 PM, "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.

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

        Regards,

        - Marv

      • Alan Dayley
        Let me comment on the definition of cross functional team. Cross functional team means all the skills needed to get done exist ON THE TEAM. Cross functional
        Message 3 of 20 , Nov 22, 2012
        • 0 Attachment
          Let me comment on the definition of "cross functional team."

          Cross functional team means all the skills needed to get done exist ON THE TEAM.

          Cross functional team does NOT mean each individual on the team has all the skills.

          As you have laid it out, you do have a cross functional team. Great!

          Next, please consider that you should not be striving for 100% utilization of every team member all the time. It is ok for a sprint to have little work for one skill and another sprint to have little work for a different skill sometimes. The team's goal is to deliver the currently most valuable portion of the work.

          Knowing that your team IS cross functional and it is actually better in the long run for individuals on the team to sometimes not use their primary skills, you might think about your question a little differently.

          And, like Mike said, ask the team what they think should happen.

          Alan

          On Nov 22, 2012, at 12: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.

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

          Regards,

          - Marv

        • RonJeffries
          Hi Marvin, ... Why are you estimating? What are you trying to forecast? Why can t the actual amount of work getting done give you all teh forecasting power you
          Message 4 of 20 , Nov 22, 2012
          • 0 Attachment
            Hi Marvin,

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

            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.

            Why are you estimating? What are you trying to forecast? Why can't the actual amount of work getting done give you all teh forecasting power you need?

            Ron Jeffries
            www.XProgramming.com
            Sometimes I give myself admirable advice, but I am incapable of taking it.
            -- Mary Wortley Montagu



          • Mark Levison
            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
            Message 5 of 20 , Nov 22, 2012
            • 0 Attachment
              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

              Cheers
              Mark

              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.

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

              Regards,

              - Marv




              --
              Cheers
              Mark Levison
              Agile Pain Relief Consulting | Writing
              Proud Sponsor of Agile Tour Gatineau Ottawa Nov 28, Toronto 26 and Montreal 24
            • RonJeffries
              Hi Mark, ... 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
              Message 6 of 20 , Nov 22, 2012
              • 0 Attachment
                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
                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

              • Mark Levison
                Ok so I jumped the gun, however the urge to do separate estimation usually hints at silos and bottlenecks. I m tired at the end of a long week. Cheers Mark ...
                Message 7 of 20 , Nov 22, 2012
                • 0 Attachment
                  Ok so I jumped the gun, however the urge to do separate estimation usually hints at silos and bottlenecks.

                  I'm tired at the end of a long week.

                  Cheers
                  Mark


                  RonJeffries wrote:
                  Ok so I jumped the gun, however the urge to do separate estimation usually hints at silos and bottlenecks.

                  I'm tired at the end of a long week.

                  Cheers
                  Mark

                  --
                  Cheers
                  Mark Levison
                  Agile Pain Relief Consulting | Writing
                  Proud Sponsor of Agile Tour Gatineau Ottawa Nov 28, Toronto 26 and Montreal
                  24
                • RonJeffries
                  Mark ... ... Well, if my estimation lights can light up, your silo lights can light up. :) Ron Jeffries www.XProgramming.com I know we always like to say it ll
                  Message 8 of 20 , Nov 22, 2012
                  • 0 Attachment
                    Mark ...

                    On Nov 22, 2012, at 7:28 PM, Mark Levison <mark@...> wrote:

                    Ok so I jumped the gun, however the urge to do separate estimation usually hints at silos and bottlenecks.

                    I'm tired at the end of a long week.

                    Well, if my estimation lights can light up, your silo lights can light up. :)

                    Ron Jeffries
                    I know we always like to say it'll be easier to do it now than it
                    will be to do it later. Not likely. I plan to be smarter later than
                    I am now, so I think it'll be just as easy later, maybe even easier.
                    Why pay now when we can pay later?

                  • marvin438android
                    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
                    Message 9 of 20 , Nov 23, 2012
                    • 0 Attachment
                      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
                      >
                    • Kurt Häusler
                      ... You should split the stories so that they are actual stories, and involve a user wanting to do something for some reason. Not split them according to
                      Message 10 of 20 , Nov 23, 2012
                      • 0 Attachment


                        On Fri, Nov 23, 2012 at 3:05 PM, 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.


                        You should split the stories so that they are actual stories, and involve a user wanting to do something for some reason. Not split them according to technical layer. A story should usually, in your case, have both mobile parts and server parts. When (and if) you split them into tasks you can have mobile and server tasks. This way most developers should be able to do something on any story. (But not necessarily have the skills to do any task)
                         


                        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.


                        Yeah it is better to have people on the team that can take on at least the "easy bits" of other areas. Especially in your case. Programming is programming, and most common languages are not that different to each other. An Objective C programmer should be able to handle the basics in c# after a couple of sprints pair programming with the c# guy when his objective c tasks run out. And they should be able to help out with writing tests, or doing code reviews too. A lot of anti-patterns and logic errors are noticeable in a "foreign" programming language.
                         


                        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.


                        How about not even splitting the tasks along mobile and server lines, and standardizing on pair programming. Have a pair, consisting of a "mobile dev" and a "server dev" take a story (a proper story, split "vertically" rather than along technology layers), and complete all work involved together?
                         


                        Under-utilization is a problem and is not acceptable around here:-)


                        You could also hire more developers with the right skills so that the ratio of capacity matches the ratio of demand. This is probably a plan B if your devs do not want to learn new skills.
                      • Mark Levison
                        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
                        Message 11 of 20 , Nov 23, 2012
                        • 0 Attachment

                          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
                          >

                        • Michael Vizdos
                          Have you spoken to the team about this, asked for their thoughts on this, and help start some conversations where they -- not you -- own the outcomes? Mike
                          Message 12 of 20 , Nov 23, 2012
                          • 0 Attachment
                            Have you spoken to the team about this, asked for their thoughts on this, and help start some conversations where they -- not you -- own the outcomes?

                            Mike Vizdos 

                            On Friday, November 23, 2012, Mark Levison 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
                            >



                            --
                             
                            Thank you.

                            - mike vizdos
                               www.michaelvizdos.com/contact
                          • Ron Jeffries
                            Hi Marvin, ... 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
                            Message 13 of 20 , Nov 23, 2012
                            • 0 Attachment
                              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
                            • Mark Levison
                              One more question. Is most work being done with pair programming? It will increase quality and help cross skill faster. Cheers Mark
                              Message 14 of 20 , Nov 23, 2012
                              • 0 Attachment

                                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
                                >

                              • 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 15 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 16 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 17 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 18 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 19 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 20 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.