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

Re: [scrumdevelopment] Concept of "work ahead" team

Expand Messages
  • Michael James
    Yeah, manager-assigned roles don t strike me as consistent with the spirit of team self organization. When you refer to the chosen few I m curious who is
    Message 1 of 25 , Aug 27, 2013
      Yeah, manager-assigned roles don't strike me as consistent with the spirit of team self organization.  When you refer to the "chosen few" I'm curious who is doing that choosing.

      In theory the whole team should be allowed to reject or revise the tentative decisions of its subcommittee, but in practice I've seen a kind of momentum preventing this.

      I'd want the Product Owner involved too.

      --mj
      (Michael)


      On Aug 26, 2013, at 11:58 PM, "Richard Griffiths" <richard@...> wrote:

       

      Hi all, I’ve started to hear this more often – the “work ahead” team being a smaller group out of the team (BA, Architect, UX) who will groom the stories, relatively size them, have them ready for the team to do further work on.

       

      Shouldn’t the whole team be involved in these exercises, not the chosen few?

       

      --

      Richard

       

      Speed is n0 subsitute fnor accurancy

       



    • Kevin Callahan
      As long as there are representatives from the team in the developer and test capabilities this approach seems sound. If this condition is not true, the issues
      Message 2 of 25 , Aug 27, 2013
        As long as there are representatives from the team in the developer and test capabilities this approach seems sound. If this condition is not true, the issues are many :/

        As the stories are broken down and clarified, involving the whole team for sizing, enforcement of ready criteria, shared understanding, etc, is required if they're to succeed in high quality implementation.

        -k


        On Aug 27, 2013, at 2:58 AM, Richard Griffiths wrote:

         

        Hi all, I’ve started to hear this more often – the “work ahead” team being a smaller group out of the team (BA, Architect, UX) who will groom the stories, relatively size them, have them ready for the team to do further work on.

         

        Shouldn’t the whole team be involved in these exercises, not the chosen few?

         

        --

        Richard

         

        Speed is n0 subsitute fnor accurancy

         



        Kevin Callahan
        ---------------------------------
        Enterprise Agile Coach
        LiveWorld

        Direct   +1 (207) 691-2997
        Skype   kevmocal

        Follow Us   Facebook | Twitter | LinkedIn

      • srinivas chillara
        Hello Richard, Quite right you are. A sub-team (of a chosen few) which regularly does this tends to form a unspoken (maybe even spoken) hierarchy which is best
        Message 3 of 25 , Aug 27, 2013
          Hello Richard,
          Quite right you are. A sub-team (of a chosen few) which regularly does this tends to form a unspoken (maybe even spoken) hierarchy which is best avoided. 

          However, sometimes it is difficult to get everyone in on these "work ahead" sessions/meetings.
          So we can rotate people in/out of this. A good ScrumMaster will facilitate this (possibly using some form of volunteering). In addition a good Scrum Master can keep an eye out for problems that may be originating from the "work ahead" team. 

          Of course we can inspect and adapt, as always.

          cheers
          Srinivas
          http://ceezone.wordpress.com



          From: Richard Griffiths <richard@...>
          To: scrumdevelopment@yahoogroups.com
          Sent: Tuesday, 27 August 2013 12:28 PM
          Subject: [scrumdevelopment] Concept of "work ahead" team

           
          Hi all, I’ve started to hear this more often – the “work ahead” team being a smaller group out of the team (BA, Architect, UX) who will groom the stories, relatively size them, have them ready for the team to do further work on.
           
          Shouldn’t the whole team be involved in these exercises, not the chosen few?
           
          --
          Richard
           
          Speed is n0 subsitute fnor accurancy
           


        • Cass Dalton
          It s not just the hierarchy. The team contributes to the story decomposition, estimation, and refinement because they re the ones that will be doing the work.
          Message 4 of 25 , Aug 27, 2013
            It's not just the hierarchy.  The team contributes to the story decomposition, estimation, and refinement because they're the ones that will be doing the work.  They are the ones with skin in the game.  Having someone else refine stories leads to unrealistic estimates and allows ambiguities about the Definition of Done to slip through.  It short circuits the "Conversation" part of the 3 C's of user stories because the team is not part of the story conversation.  It also adds back some of the waterfall handoffs in the form of analysts and architects handing off work to developers.

            If you find yourself falling into the practice because iteration sessions are too long and devs get bored, then 1) have them attend a grooming session elsewhere in the iteration, and 2) make sure that you're not splitting work along resource/architecture boundaries.  If you split work along architecture and resource boundaries, the UI guy will be board while the team discusses non-UI stories, but that's an indication that the work is being stovepiped in the old waterfall fashion.

            If you find yourself falling into the practice because the dev team feels like they can't meet their commitments if they take time out of the iteration to refine stories, then you should probably reevaluate the pressures that the PO and SM are putting on the team.


            On Tue, Aug 27, 2013 at 10:47 AM, srinivas chillara <ceezone@...> wrote:
             

            Hello Richard,
            Quite right you are. A sub-team (of a chosen few) which regularly does this tends to form a unspoken (maybe even spoken) hierarchy which is best avoided. 

            However, sometimes it is difficult to get everyone in on these "work ahead" sessions/meetings.
            So we can rotate people in/out of this. A good ScrumMaster will facilitate this (possibly using some form of volunteering). In addition a good Scrum Master can keep an eye out for problems that may be originating from the "work ahead" team. 

            Of course we can inspect and adapt, as always.

            cheers
            Srinivas



            From: Richard Griffiths <richard@...>
            To: scrumdevelopment@yahoogroups.com
            Sent: Tuesday, 27 August 2013 12:28 PM
            Subject: [scrumdevelopment] Concept of "work ahead" team

             
            Hi all, I’ve started to hear this more often – the “work ahead” team being a smaller group out of the team (BA, Architect, UX) who will groom the stories, relatively size them, have them ready for the team to do further work on.
             
            Shouldn’t the whole team be involved in these exercises, not the chosen few?
             
            --
            Richard
             
            Speed is n0 subsitute fnor accurancy
             



          • Richard Griffiths
            Michael, Srinivas, Madhur Thanks for the responses (condensed for brevity) ... Actually the sub team has formed from within the team - PO, BA and architect,
            Message 5 of 25 , Aug 27, 2013

              Michael, Srinivas, Madhur

               

              Thanks for the responses (condensed for brevity)

               

              > When you refer to the "chosen few" I'm curious who is doing that choosing.

               

              Actually the sub team has formed from within the team - PO, BA and architect, they very much look at up-coming stories to get them in some form of shape for the whole team to review them at story sizing/grooming sessions.

               

              > A sub-team (of a chosen few) which regularly does this tends to form a unspoken (maybe even spoken) hierarchy which is best avoided. 

               

              We do have some time-zone issues and not everyone is able to meet to plan for the future and groom the backlog on a daily basis; this way we get team input, and as noted, we do rotate people in and out, but it seems to be working.

               

              We have planned grooming sessions (one per week) where everyone attends and we refine and size as appropriate

               

              I was more concerned that there was an expectation that the sub-team/work ahead group would estimate the stories.

               

              My answer was, fine, as long as they, and they only, are happy to take on the work J

               

              Richard

               


              From: Richard Griffiths <richard@...>
              To: scrumdevelopment@yahoogroups.com
              Sent: Tuesday, 27 August 2013 12:28 PM
              Subject: [scrumdevelopment] Concept of "work ahead" team

               

               

              Hi all, I’ve started to hear this more often – the “work ahead” team being a smaller group out of the team (BA, Architect, UX) who will groom the stories, relatively size them, have them ready for the team to do further work on.

               

              Shouldn’t the whole team be involved in these exercises, not the chosen few?

               

              --

              Richard

               

              Speed is n0 subsitute fnor accurancy

               

               

            • srinivas chillara
              The last point made is a good one.  However much of the conversation for a user story taken up in a given sprint happens during the sprint. So no worries
              Message 6 of 25 , Aug 27, 2013
                The last point made is a good one. 
                However much of the conversation for a user story taken up in a given sprint happens during the sprint. So no worries there. 

                I don't think the "look ahead" team mentioned by Richard was an exclusive set. 

                cheers
                srinivas


                From: Cass Dalton <cassdalton73@...>
                To: scrumdevelopment@yahoogroups.com
                Sent: Tuesday, 27 August 2013 9:10 PM
                Subject: Re: [scrumdevelopment] Concept of "work ahead" team

                 
                It's not just the hierarchy.  The team contributes to the story decomposition, estimation, and refinement because they're the ones that will be doing the work.  They are the ones with skin in the game.  Having someone else refine stories leads to unrealistic estimates and allows ambiguities about the Definition of Done to slip through.  It short circuits the "Conversation" part of the 3 C's of user stories because the team is not part of the story conversation.  It also adds back some of the waterfall handoffs in the form of analysts and architects handing off work to developers.

                If you find yourself falling into the practice because iteration sessions are too long and devs get bored, then 1) have them attend a grooming session elsewhere in the iteration, and 2) make sure that you're not splitting work along resource/architecture boundaries.  If you split work along architecture and resource boundaries, the UI guy will be board while the team discusses non-UI stories, but that's an indication that the work is being stovepiped in the old waterfall fashion.

                If you find yourself falling into the practice because the dev team feels like they can't meet their commitments if they take time out of the iteration to refine stories, then you should probably reevaluate the pressures that the PO and SM are putting on the team.


                On Tue, Aug 27, 2013 at 10:47 AM, srinivas chillara <ceezone@...> wrote:
                 
                Hello Richard,
                Quite right you are. A sub-team (of a chosen few) which regularly does this tends to form a unspoken (maybe even spoken) hierarchy which is best avoided. 

                However, sometimes it is difficult to get everyone in on these "work ahead" sessions/meetings.
                So we can rotate people in/out of this. A good ScrumMaster will facilitate this (possibly using some form of volunteering). In addition a good Scrum Master can keep an eye out for problems that may be originating from the "work ahead" team. 

                Of course we can inspect and adapt, as always.

                cheers
                Srinivas



                From: Richard Griffiths <richard@...>
                To: scrumdevelopment@yahoogroups.com
                Sent: Tuesday, 27 August 2013 12:28 PM
                Subject: [scrumdevelopment] Concept of "work ahead" team

                 
                Hi all, I’ve started to hear this more often – the “work ahead” team being a smaller group out of the team (BA, Architect, UX) who will groom the stories, relatively size them, have them ready for the team to do further work on.
                 
                Shouldn’t the whole team be involved in these exercises, not the chosen few?
                 
                --
                Richard
                 
                Speed is n0 subsitute fnor accurancy
                 





              • Kurt Häusler
                Hi Richard, I have heard the term be used to describe something else, other than grooming, or backlog refinement as it is now called. I think it is ok to have
                Message 7 of 25 , Aug 27, 2013
                  Hi Richard,

                  I have heard the term be used to describe something else, other than grooming, or backlog refinement as it is now called. I think it is ok to have a subset of the team do this.

                  To me "work ahead" has another connotation. Where the roles you mention essentially solve the problem, they have the discussions with the customer, they prepare assets, they write specifications, they design the UI, maybe even go so far as producing or modifying wireframes or mockups.

                  it is a horrible horrible anti-pattern. If the team receives essentially solved problems to merely type in then they will be extremely demotivated.

                  It is also highly wasteful, as there is no guarantee this work will even be used.

                  There is plenty of time within the sprint to do this work, together as a team and if there isn't the stories need to be made smaller.

                  Kurt

                  On 27 Aug 2013, at 09:58, "Richard Griffiths" <richard@...> wrote:

                  >
                  > Hi all, I’ve started to hear this more often – the “work ahead” team being a smaller group out of the team (BA, Architect, UX) who will groom the stories, relatively size them, have them ready for the team to do further work on.
                  >
                  >
                  >
                  > Shouldn’t the whole team be involved in these exercises, not the chosen few?
                • Peter Trudelle
                  While I largely agree with Kurt s characterization of the extreme version of such meetings, I think that that a simple form of them may be useful at early
                  Message 8 of 25 , Aug 28, 2013
                    While I largely agree with Kurt's characterization of the extreme
                    version of such meetings, I think that that a simple form of them may be
                    useful at early stages of an organization's transition to Agile. I've
                    recently set a couple of these up, calling them "Epic Time", but more
                    along the lines of Customer Teams, or Three Amigos, to source and refine
                    stories to ensure they are ready for the team to take up at Story Time.
                    The Scrum teams had been agonizing over stories that weren't ready,
                    spending 30+ minutes per story trying to figure out what they might
                    mean, with the POs trying to act as intermediary with
                    customers/stakeholders, who were not engaging directly with the teams.
                    These Epic Time meetings involve the PO, customers/stakeholders, SMEs,
                    and team members sent by the team to represent development, testing, and
                    user experience. We try to ensure a flow of higher-quality stories to
                    the team, so as not to waste the entire team's time.

                    Peter

                    On 8/27/13 9:54 PM, Kurt Häusler wrote:
                    > Hi Richard,
                    >
                    > I have heard the term be used to describe something else, other than grooming, or backlog refinement as it is now called. I think it is ok to have a subset of the team do this.
                    >
                    > To me "work ahead" has another connotation. Where the roles you mention essentially solve the problem, they have the discussions with the customer, they prepare assets, they write specifications, they design the UI, maybe even go so far as producing or modifying wireframes or mockups.
                    >
                    > it is a horrible horrible anti-pattern. If the team receives essentially solved problems to merely type in then they will be extremely demotivated.
                    >
                    > It is also highly wasteful, as there is no guarantee this work will even be used.
                    >
                    > There is plenty of time within the sprint to do this work, together as a team and if there isn't the stories need to be made smaller.
                    >
                    > Kurt
                    >
                    > On 27 Aug 2013, at 09:58, "Richard Griffiths" <richard@...> wrote:
                    >
                    >> Hi all, I’ve started to hear this more often – the “work ahead” team being a smaller group out of the team (BA, Architect, UX) who will groom the stories, relatively size them, have them ready for the team to do further work on.
                    >>
                    >>
                    >>
                    >> Shouldn’t the whole team be involved in these exercises, not the chosen few?
                    >
                    >
                    >
                    > ------------------------------------
                    >
                    > To Post a message, send it to: scrumdevelopment@...
                    > To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...! Groups Links
                    >
                    >
                    >
                  • Prashant Pund
                    Hello Richard, We have seen the limitations of such a group ( I reserve the term Team). In our case, the group consisted of a few senior team members plus
                    Message 9 of 25 , Aug 28, 2013

                      Hello Richard,
                      We have seen the limitations of such a group ( I reserve the term Team). In our case, the group consisted of a few senior team members plus other stakeholders like Engg Manager.The estimates of the stories is based on understanding and in turn conversation within this group. The limitation is about transfer of this understanding to the Team. There are disagreements about the work involved and estimates. Also, this group, later on, becomes the one who " assigns" the job to the Team.
                      If appropriate care is taken about collaboration between this group and the Team; these limitations can be overcome.
                      The idea of rotating the members suggested by Srinivas in this discussion sounds good and we'll try it.
                      Prashant Pund
                      AgileSoft Methodologies
                      www.agilesoft.in

                      On Aug 27, 2013 8:17 PM, "srinivas chillara" <ceezone@...> wrote:
                      >
                      >  
                      >
                      > Hello Richard,
                      > Quite right you are. A sub-team (of a chosen few) which regularly does this tends to form a unspoken (maybe even spoken) hierarchy which is best avoided. 
                      >
                      > However, sometimes it is difficult to get everyone in on these "work ahead" sessions/meetings.
                      > So we can rotate people in/out of this. A good ScrumMaster will facilitate this (possibly using some form of volunteering). In addition a good Scrum Master can keep an eye out for problems that may be originating from the "work ahead" team. 
                      >
                      > Of course we can inspect and adapt, as always.
                      >
                      > cheers
                      > Srinivas
                      > http://ceezone.wordpress.com
                      >
                      >
                      > ________________________________
                      > From: Richard Griffiths <richard@...>
                      > To: scrumdevelopment@yahoogroups.com
                      > Sent: Tuesday, 27 August 2013 12:28 PM
                      > Subject: [scrumdevelopment] Concept of "work ahead" team
                      >
                      >  
                      > Hi all, I’ve started to hear this more often – the “work ahead” team being a smaller group out of the team (BA, Architect, UX) who will groom the stories, relatively size them, have them ready for the team to do further work on.
                      >  
                      > Shouldn’t the whole team be involved in these exercises, not the chosen few?
                      >  
                      > --
                      > Richard
                      >  
                      > Speed is n0 subsitute fnor accurancy
                      >  
                      >
                      >
                      >

                    • Alex Pereira
                      I Agree with Peter here. Although my Agile experience is far lower than a lot of people in this group, I came to realize that it probably depends on what stage
                      Message 10 of 25 , Aug 29, 2013
                        I Agree with Peter here. Although my Agile experience is far lower than a lot of people in this group, I came to realize that it probably depends on what stage of Agile the organization is, and also, the domain experience of developers/QA on the team.

                        Take for example my current job (as a sr. dev), in which I have been for only 3 1/2 months - I was also hired for my previous experience as a Scrum Master. The company is in the early (really crawling) stages of Scrum, and the VP wants all developers/QA to participate in the backlog refining meetings. This is by far the worse arrangement, which I have been trying to persuade them to change.

                        My team consists of:
                        1 Team Lead/Sr. Dev - been here for over 5 years, so lots of domain knowledge
                        1 Jr. Dev - been here about 2 years
                        1 Mid Dev. - been here about 6 months
                        1 Sr Dev (me) - been here about 4 months
                        1 Jr. Dev - been here about 2 months
                        1 Sr QA - been here for over 9 years, so lots of domain knowledge

                        We have about 2-3 backlog refining meetings each week, and for the most part, with the exception of the team lead and QA, the rest of the team have very little input to give. Which means we are wasting time. I understand we have a lot of issues to overcome here, but for the context of this email, I will just stick with the "work ahead" team concept.

                        Based on my past and my current experience, I think the best "lean" approach would be to have a group consisting of the most knowledgeable team members (team lead/sr. dev + QA), together with PO, UX, and other stakeholders create and expand user stories as much as they can. We could probably cut down meetings involving all devs/qa to 1 per week, in which we could discuss the approach to be taken (further refining) and also estimate. I believe this would be the most lean and optimal approach. 



                        Alex Pereira
                        http://www.brainstack.net/ (Professional Blog)


                        From: Peter Trudelle <trudelle@...>
                        To: scrumdevelopment@yahoogroups.com
                        Cc: Kurt Häusler <kurt.haeusler@...>
                        Sent: Wednesday, August 28, 2013 8:43 PM
                        Subject: Re: [scrumdevelopment] Concept of "work ahead" team

                        While I largely agree with Kurt's characterization of the extreme
                        version of such meetings, I think that that a simple form of them may be
                        useful at early stages of an organization's transition to Agile.  I've
                        recently set a couple of these up, calling them "Epic Time", but more
                        along the lines of Customer Teams, or Three Amigos, to source and refine
                        stories to ensure they are ready for the team to take up at Story Time. 
                        The Scrum teams had been agonizing over stories that weren't ready,
                        spending 30+ minutes per story trying to figure out what they might
                        mean, with the POs trying to act as intermediary with
                        customers/stakeholders, who were not engaging directly with the teams.
                        These Epic Time meetings involve the PO, customers/stakeholders, SMEs,
                        and team members sent by the team to represent development, testing, and
                        user experience.  We try to ensure a flow of  higher-quality stories to
                        the team, so as not to waste the entire team's time.

                        Peter
                      • Jesse Houwing
                        Keep in mind that these sessions are not only meant to get a clear backlog item, but also to transfer knowledge from the domain expert, stakeholders and po to
                        Message 11 of 25 , Aug 31, 2013
                          Keep in mind that these sessions are not only meant to get a clear backlog item, but also to transfer knowledge from the domain expert, stakeholders and po to all team members.

                          Since the other team members have relatively recently started, they should have a gap in their domain knowledge, these sessions should give them a lit of insights when the contents are presented in a way that really explains them.

                          It might feel like a lot of unrequired work to get the backlog in shape, but it is a lot of really needed work to get your team members in shape.

                          Get them to ask questions. Get them,to ask the same question over and until you get to the real why. That way your team members will be able to understand and carry the vision in all their work.

                          Sent from my Windows Phone

                          From: Alex Pereira
                          Sent: ‎29-‎8-‎2013 15:05
                          To: scrumdevelopment@yahoogroups.com
                          Subject: Re: [scrumdevelopment] Concept of "work ahead" team



                          I Agree with Peter here. Although my Agile experience is far lower than a lot of people in this group, I came to realize that it probably depends on what stage of Agile the organization is, and also, the domain experience of developers/QA on the team.

                          Take for example my current job (as a sr. dev), in which I have been for only 3 1/2 months - I was also hired for my previous experience as a Scrum Master. The company is in the early (really crawling) stages of Scrum, and the VP wants all developers/QA to participate in the backlog refining meetings. This is by far the worse arrangement, which I have been trying to persuade them to change.

                          My team consists of:
                          1 Team Lead/Sr. Dev - been here for over 5 years, so lots of domain knowledge
                          1 Jr. Dev - been here about 2 years
                          1 Mid Dev. - been here about 6 months
                          1 Sr Dev (me) - been here about 4 months
                          1 Jr. Dev - been here about 2 months
                          1 Sr QA - been here for over 9 years, so lots of domain knowledge

                          We have about 2-3 backlog refining meetings each week, and for the most part, with the exception of the team lead and QA, the rest of the team have very little input to give. Which means we are wasting time. I understand we have a lot of issues to overcome here, but for the context of this email, I will just stick with the "work ahead" team concept.

                          Based on my past and my current experience, I think the best "lean" approach would be to have a group consisting of the most knowledgeable team members (team lead/sr. dev + QA), together with PO, UX, and other stakeholders create and expand user stories as much as they can. We could probably cut down meetings involving all devs/qa to 1 per week, in which we could discuss the approach to be taken (further refining) and also estimate. I believe this would be the most lean and optimal approach. 



                          Alex Pereira
                          http://www.brainstack.net/ (Professional Blog)


                          From: Peter Trudelle <trudelle@...>
                          To: scrumdevelopment@yahoogroups.com
                          Cc: Kurt Häusler <kurt.haeusler@...>
                          Sent: Wednesday, August 28, 2013 8:43 PM
                          Subject: Re: [scrumdevelopment] Concept of "work ahead" team

                          While I largely agree with Kurt's characterization of the extreme
                          version of such meetings, I think that that a simple form of them may be
                          useful at early stages of an organization's transition to Agile.  I've
                          recently set a couple of these up, calling them "Epic Time", but more
                          along the lines of Customer Teams, or Three Amigos, to source and refine
                          stories to ensure they are ready for the team to take up at Story Time. 
                          The Scrum teams had been agonizing over stories that weren't ready,
                          spending 30+ minutes per story trying to figure out what they might
                          mean, with the POs trying to act as intermediary with
                          customers/stakeholders, who were not engaging directly with the teams.
                          These Epic Time meetings involve the PO, customers/stakeholders, SMEs,
                          and team members sent by the team to represent development, testing, and
                          user experience.  We try to ensure a flow of  higher-quality stories to
                          the team, so as not to waste the entire team's time.

                          Peter


                        • Alix Moghdam
                          *It seems that this team is helping the PO to create a better backlog. If so, I think it does not harm. But they should remain at the PO fields and boundaries:
                          Message 12 of 25 , Sep 3, 2013
                            It seems that this team is helping the PO to create a better backlog. If so, I think it does not harm. But they should remain at the PO fields and boundaries: Defining Stories from business point of view and prioritizing them. And the PO should still be responsible about the final decisions. This team just helps him/her.
                            If this team falls into technical fields, then it could be an anti-pattern. They should not decide about implementation, design, and other development-related topics. 
                             
                            @Alix


                            On Tue, Aug 27, 2013 at 10:48 PM, Richard Griffiths <richard@...> wrote:
                             

                            Michael, Srinivas, Madhur

                             

                            Thanks for the responses (condensed for brevity)

                             

                            > When you refer to the "chosen few" I'm curious who is doing that choosing.

                             

                            Actually the sub team has formed from within the team - PO, BA and architect, they very much look at up-coming stories to get them in some form of shape for the whole team to review them at story sizing/grooming sessions.

                             

                            > A sub-team (of a chosen few) which regularly does this tends to form a unspoken (maybe even spoken) hierarchy which is best avoided. 

                             

                            We do have some time-zone issues and not everyone is able to meet to plan for the future and groom the backlog on a daily basis; this way we get team input, and as noted, we do rotate people in and out, but it seems to be working.

                             

                            We have planned grooming sessions (one per week) where everyone attends and we refine and size as appropriate

                             

                            I was more concerned that there was an expectation that the sub-team/work ahead group would estimate the stories.

                             

                            My answer was, fine, as long as they, and they only, are happy to take on the work J

                             

                            Richard

                             


                            From: Richard Griffiths <richard@...>
                            To: scrumdevelopment@yahoogroups.com
                            Sent: Tuesday, 27 August 2013 12:28 PM
                            Subject: [scrumdevelopment] Concept of "work ahead" team

                             

                             

                            Hi all, I’ve started to hear this more often – the “work ahead” team being a smaller group out of the team (BA, Architect, UX) who will groom the stories, relatively size them, have them ready for the team to do further work on.

                             

                            Shouldn’t the whole team be involved in these exercises, not the chosen few?

                             

                            --

                            Richard

                             

                            Speed is n0 subsitute fnor accurancy

                             

                             


                          • Ron Jeffries
                            Alix, ... The team that does this helping is learning things. It would be better if the team that was doing the building could get that learning first hand.
                            Message 13 of 25 , Sep 3, 2013
                              Alix,

                              On Sep 3, 2013, at 9:36 AM, Alix Moghdam <ali.moghadam@...> wrote:

                              It seems that this team is helping the PO to create a better backlog. If so, I think it does not harm. But they should remain at the PO fields and boundaries: Defining Stories from business point of view and prioritizing them. And the PO should still be responsible about the final decisions. This team just helps him/her.

                              The team that does this helping is learning things. It would be better if the team that was doing the building could get that learning first hand.

                              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?

                            • Cass Dalton
                              I still feel that this makes the dev team lose out on some of that good conversation. Understanding what makes a story better gives the dev team valuable
                              Message 14 of 25 , Sep 3, 2013

                                I still feel that this makes the dev team lose out on some of that good conversation.  Understanding what makes a story "better" gives the dev team valuable context for that story

                                On Sep 3, 2013 9:52 AM, "Alix Moghdam" <ali.moghadam@...> wrote:
                                 

                                It seems that this team is helping the PO to create a better backlog. If so, I think it does not harm. But they should remain at the PO fields and boundaries: Defining Stories from business point of view and prioritizing them. And the PO should still be responsible about the final decisions. This team just helps him/her.
                                If this team falls into technical fields, then it could be an anti-pattern. They should not decide about implementation, design, and other development-related topics. 
                                 
                                @Alix


                                On Tue, Aug 27, 2013 at 10:48 PM, Richard Griffiths <richard@...> wrote:
                                 

                                Michael, Srinivas, Madhur

                                 

                                Thanks for the responses (condensed for brevity)

                                 

                                > When you refer to the "chosen few" I'm curious who is doing that choosing.

                                 

                                Actually the sub team has formed from within the team - PO, BA and architect, they very much look at up-coming stories to get them in some form of shape for the whole team to review them at story sizing/grooming sessions.

                                 

                                > A sub-team (of a chosen few) which regularly does this tends to form a unspoken (maybe even spoken) hierarchy which is best avoided. 

                                 

                                We do have some time-zone issues and not everyone is able to meet to plan for the future and groom the backlog on a daily basis; this way we get team input, and as noted, we do rotate people in and out, but it seems to be working.

                                 

                                We have planned grooming sessions (one per week) where everyone attends and we refine and size as appropriate

                                 

                                I was more concerned that there was an expectation that the sub-team/work ahead group would estimate the stories.

                                 

                                My answer was, fine, as long as they, and they only, are happy to take on the work J

                                 

                                Richard

                                 


                                From: Richard Griffiths <richard@...>
                                To: scrumdevelopment@yahoogroups.com
                                Sent: Tuesday, 27 August 2013 12:28 PM
                                Subject: [scrumdevelopment] Concept of "work ahead" team

                                 

                                 

                                Hi all, I’ve started to hear this more often – the “work ahead” team being a smaller group out of the team (BA, Architect, UX) who will groom the stories, relatively size them, have them ready for the team to do further work on.

                                 

                                Shouldn’t the whole team be involved in these exercises, not the chosen few?

                                 

                                --

                                Richard

                                 

                                Speed is n0 subsitute fnor accurancy

                                 

                                 


                              • George Dinwiddie
                                Hi, Richard, ... I ve found that grooming stories with the whole team can drag on and on, accomplishing relatively little and frustrating everyone. On the
                                Message 15 of 25 , Sep 3, 2013
                                  Hi, Richard,

                                  On 8/27/13 2:58 AM, Richard Griffiths wrote:
                                  >
                                  >
                                  > Hi all, I’ve started to hear this more often – the “work ahead” team
                                  > being a smaller group out of the team (BA, Architect, UX) who will groom
                                  > the stories, relatively size them, have them ready for the team to do
                                  > further work on.
                                  >
                                  > Shouldn’t the whole team be involved in these exercises, not the chosen few?

                                  I've found that grooming stories with the whole team can drag on and on,
                                  accomplishing relatively little and frustrating everyone. On the other
                                  hand, it's important that everyone have some involvement. It's
                                  particularly important that someone doing the work not be handed an
                                  estimate made by someone not doing the work.

                                  About 5 years ago we pioneered a "Three Amigos" process at a client
                                  where a small group containing the product owner, a tester, and a
                                  programmer (and sometimes more, particularly UX in that client) would
                                  discuss a story or two to get it clear on the details. Today I recommend
                                  that this discussion result in acceptance scenarios that clarify the
                                  story and indicate minimum acceptance criteria. Often there are many
                                  such scenarios, and the story can be split along the lines of the scenarios.

                                  Different sets of "Three Amigos" would work on grooming different
                                  stories on different days, giving everybody involvement in the process
                                  but not everybody involved in the same stories.

                                  This clarification would happen before the planning meeting. At the
                                  planning meeting, everyone took part in estimation and determining how
                                  many stories fit. The clarity brought by having explicit examples in the
                                  acceptance scenarios made the estimation and planning proceed much more
                                  quickly.

                                  You might be interested in this article from Better Software:
                                  http://manage.techwell.com/articles/weekly/three-amigos

                                  - George

                                  --
                                  ----------------------------------------------------------------------
                                  * George Dinwiddie * http://blog.gdinwiddie.com
                                  Software Development http://www.idiacomputing.com
                                  Consultant and Coach http://www.agilemaryland.org
                                  ----------------------------------------------------------------------
                                • Adrian Howard
                                  ... Are there other ways to drop the annoyance level? For example: * grooming less at a time (my preference) * things like affinity estimation
                                  Message 16 of 25 , Sep 3, 2013
                                    On 3 September 2013 17:52, George Dinwiddie <lists@...> wrote:
                                    > I've found that grooming stories with the whole team can drag on and on,
                                    > accomplishing relatively little and frustrating everyone. On the other
                                    > hand, it's important that everyone have some involvement. It's
                                    > particularly important that someone doing the work not be handed an
                                    > estimate made by someone not doing the work.

                                    Are there other ways to drop the annoyance level? For example:

                                    * grooming less at a time (my preference)
                                    * things like affinity estimation
                                    (http://kanemar.com/2008/04/21/scrum-trainers-gathering-44-affinity-estimating/)

                                    Not arguing that 3 Amigos is a useful approach... but as years go buy
                                    I'm more and more hesitant about approaches that stop the whole team
                                    participating.

                                    Cheers,

                                    Adrian
                                    --
                                    adrianh@... / +44 (0)7752 419080 / @adrianh / quietstars.com
                                    Subscribe to the latest Agile & Lean UX news here > http://is.gd/KREt5S
                                  • Ron Jeffries
                                    Hi Adrian, ... I tend to agree. Limiting knowledge / learning to a few seems off to me. Ron Jeffries www.XProgramming.com I know we always like to say it ll be
                                    Message 17 of 25 , Sep 3, 2013
                                      Hi Adrian,

                                      On Sep 3, 2013, at 8:34 PM, Adrian Howard <adrianh@...> wrote:

                                      Not arguing that 3 Amigos is a useful approach... but as years go buy
                                      I'm more and more hesitant about approaches that stop the whole team
                                      participating.

                                      I tend to agree. Limiting knowledge / learning to a few seems off to me.

                                      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?

                                    • Adam Sroka
                                      My interpretation of three amigos is that it does not preclude whole team participation but describes the three viewpoints required to have a quorum on any
                                      Message 18 of 25 , Sep 3, 2013
                                        My interpretation of three amigos is that it does not preclude whole team participation but describes the three viewpoints required to have a quorum on any story. On a high functioning team anyone should be able to represent any of the three. So, you need a pair to have the conversation and the customer/PO to make the final call. 

                                        On Tuesday, September 3, 2013, Adrian Howard wrote:
                                         

                                        On 3 September 2013 17:52, George Dinwiddie <lists@...> wrote:
                                        > I've found that grooming stories with the whole team can drag on and on,
                                        > accomplishing relatively little and frustrating everyone. On the other
                                        > hand, it's important that everyone have some involvement. It's
                                        > particularly important that someone doing the work not be handed an
                                        > estimate made by someone not doing the work.

                                        Are there other ways to drop the annoyance level? For example:

                                        * grooming less at a time (my preference)
                                        * things like affinity estimation
                                        (http://kanemar.com/2008/04/21/scrum-trainers-gathering-44-affinity-estimating/)

                                        Not arguing that 3 Amigos is a useful approach... but as years go buy
                                        I'm more and more hesitant about approaches that stop the whole team
                                        participating.

                                        Cheers,

                                        Adrian
                                        --
                                        adrianh@... / +44 (0)7752 419080 / @adrianh / quietstars.com
                                        Subscribe to the latest Agile & Lean UX news here > http://is.gd/KREt5S

                                      • Adam Sroka
                                        Perhaps, if we are planning in a manner that feels like it is a waste of time for some of the folks on the team, it is, in fact, a waste of the time for
                                        Message 19 of 25 , Sep 3, 2013
                                          Perhaps, if we are planning in a manner that feels like it is a waste of time for some of the folks on the team, it is, in fact, a waste of the time for everyone on the team, and we should find a leaner and more effective way to plan. Conversations that are valuable are not a waste of anyone's time. 


                                          On Tue, Sep 3, 2013 at 8:38 PM, Ron Jeffries <ronjeffries@...> wrote:
                                           

                                          Hi Adrian,


                                          On Sep 3, 2013, at 8:34 PM, Adrian Howard <adrianh@...> wrote:

                                          Not arguing that 3 Amigos is a useful approach... but as years go buy
                                          I'm more and more hesitant about approaches that stop the whole team
                                          participating.

                                          I tend to agree. Limiting knowledge / learning to a few seems off to me.


                                          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?


                                        • Adrian Howard
                                          ... That feels right to me. Cheers, Adrian -- adrianh@quietstars.com / +44 (0)7752 419080 / @adrianh / quietstars.com Join my Fundamentals of Lean UX workshop,
                                          Message 20 of 25 , Sep 3, 2013

                                            On 4 September 2013 02:05, Adam Sroka <adam.sroka@...> wrote:
                                            Perhaps, if we are planning in a manner that feels like it is a waste of time for some of the folks on the team, it is, in fact, a waste of the time for everyone on the team, and we should find a leaner and more effective way to plan. Conversations that are valuable are not a waste of anyone's time. 

                                            That feels right to me.

                                            Cheers,

                                            Adrian
                                            -- 
                                            adrianh@... / +44 (0)7752 419080 / @adrianh / quietstars.com
                                            Join my Fundamentals of Lean UX workshop, Sep 4, http://uxcambridge.net

                                          • George Dinwiddie
                                            Adrian, ... That s part of this. But when we first did this, it was also part of the whole team exercise. ... Estimating is not part of the grooming. That s
                                            Message 21 of 25 , Sep 3, 2013
                                              Adrian,

                                              On 9/3/13 8:34 PM, Adrian Howard wrote:
                                              > On 3 September 2013 17:52, George Dinwiddie <lists@...> wrote:
                                              >> I've found that grooming stories with the whole team can drag on and on,
                                              >> accomplishing relatively little and frustrating everyone. On the other
                                              >> hand, it's important that everyone have some involvement. It's
                                              >> particularly important that someone doing the work not be handed an
                                              >> estimate made by someone not doing the work.
                                              >
                                              > Are there other ways to drop the annoyance level? For example:
                                              >
                                              > * grooming less at a time (my preference)

                                              That's part of this. But when we first did this, it was also part of the
                                              whole team exercise.

                                              > * things like affinity estimation
                                              > (http://kanemar.com/2008/04/21/scrum-trainers-gathering-44-affinity-estimating/)

                                              Estimating is not part of the grooming. That's generally done at the
                                              planning meeting by the whole team. And, yes, I find affinity estimating
                                              a better technique than most. I've considered counting the scenarios. I
                                              generally recommend calling them all "1."

                                              > Not arguing that 3 Amigos is a useful approach... but as years go buy
                                              > I'm more and more hesitant about approaches that stop the whole team
                                              > participating.

                                              I suppose you can do mob programming, but most teams don't have
                                              everybody working together on every task.

                                              The Three Amigos approach doesn't stop the whole team from
                                              participating. It does gain a lot of clarity in small group discussions,
                                              but that clarity is then brought to the whole team at planning time. The
                                              whole team is then able to assess each story more quickly. In my
                                              experience, if people think that important scenarios are missing,
                                              they'll generally say something.

                                              The use of acceptance scenarios makes it easy to keep straight on what
                                              is in a particular story, and what is out. Confusion over what's in and
                                              what's out seems to cause most of the problems in whole-team grooming
                                              exercises, in my experience. After a discussion that says "this part is
                                              in and that part is out," invariably someone brings up the need for
                                              "that part" later in the discussion.

                                              Breaking into small groups and bringing it back to the larger group is a
                                              time-honored and effective facilitation technique. But if you're
                                              uncomfortable with it, by all means try it with the whole team. I think
                                              the most important part of this is generating explicit scenarios to
                                              illustrate the story. Doing so more efficiently is much less important.

                                              - George

                                              --
                                              ----------------------------------------------------------------------
                                              * George Dinwiddie * http://blog.gdinwiddie.com
                                              Software Development http://www.idiacomputing.com
                                              Consultant and Coach http://www.agilemaryland.org
                                              ----------------------------------------------------------------------
                                            • George Dinwiddie
                                              Ron, ... That would seem off to me, also. That s not what I recommend. - George -- ... * George Dinwiddie * http://blog.gdinwiddie.com
                                              Message 22 of 25 , Sep 3, 2013
                                                Ron,

                                                On 9/3/13 8:38 PM, Ron Jeffries wrote:
                                                >
                                                >
                                                > Hi Adrian,
                                                >
                                                > On Sep 3, 2013, at 8:34 PM, Adrian Howard <adrianh@...
                                                > <mailto:adrianh@...>> wrote:
                                                >
                                                >> Not arguing that 3 Amigos is a useful approach... but as years go buy
                                                >> I'm more and more hesitant about approaches that stop the whole team
                                                >> participating.
                                                >
                                                > I tend to agree. Limiting knowledge / learning to a few seems off to me.

                                                That would seem off to me, also. That's not what I recommend.

                                                - George

                                                --
                                                ----------------------------------------------------------------------
                                                * George Dinwiddie * http://blog.gdinwiddie.com
                                                Software Development http://www.idiacomputing.com
                                                Consultant and Coach http://www.agilemaryland.org
                                                ----------------------------------------------------------------------
                                              • George Dinwiddie
                                                Adam, ... Yes, it s viewpoints, not job roles, that count. At a minimum, - someone to keep an eye on the business desires - someone to keep an eye on
                                                Message 23 of 25 , Sep 3, 2013
                                                  Adam,

                                                  On 9/3/13 8:54 PM, Adam Sroka wrote:
                                                  >
                                                  >
                                                  > My interpretation of three amigos is that it does not preclude whole
                                                  > team participation but describes the three viewpoints required to have a
                                                  > quorum on any story. On a high functioning team anyone should be able to
                                                  > represent any of the three. So, you need a pair to have the conversation
                                                  > and the customer/PO to make the final call.

                                                  Yes, it's viewpoints, not job roles, that count. At a minimum,
                                                  - someone to keep an eye on the business desires
                                                  - someone to keep an eye on implementation issues
                                                  - someone to keep an eye on edge cases and what might go wrong.
                                                  I've found it better if these viewpoints are embodied in three separate
                                                  people in the discussion. Often one person CAN hold these three
                                                  viewpoints, but it's hard to do so simultaneously. And I caution people
                                                  that there may be other important viewpoints. Some common examples:
                                                  - someone to keep an eye on UX issues
                                                  - someone to keep an eye on security issues
                                                  - someone to keep an eye on specialized business desires that are
                                                  separate from user needs, such as accounting or legal

                                                  - George

                                                  --
                                                  ----------------------------------------------------------------------
                                                  * George Dinwiddie * http://blog.gdinwiddie.com
                                                  Software Development http://www.idiacomputing.com
                                                  Consultant and Coach http://www.agilemaryland.org
                                                  ----------------------------------------------------------------------
                                                Your message has been successfully submitted and would be delivered to recipients shortly.