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

Concept of "work ahead" team

Expand Messages
  • Richard Griffiths
    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,
    Message 1 of 25 , Aug 26, 2013
    • 0 Attachment

      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

       

    • Madhur Kathuria
      Hey Richard IMHO, Well the look ahead teams ( I call them planning teams) exist in organizations because of the basic SDLC and because of planning pressures (
      Message 2 of 25 , Aug 27, 2013
      • 0 Attachment
        Hey Richard

        IMHO, Well the look ahead teams ( I call them planning teams) exist in organizations because of the basic SDLC and because of planning pressures ( or lack of them there of)

        In an ideal world, teams would not only focus on current work but also look into the future and plan for what they need to do in next couple of Sprints but in most orgs, the team gets so drowned in the current work that they forget to look into future and the results are mid sprint surprises, half baked stories, Non existent Done criterion et al

        Yes, with better planning of capacity and in-sprint calendar and with a bit of vision, the team should be able to manage all things but till the time that happens, the Planning team(s) will continue to exist

        on the flip side, with some of my clients, I have seen the planning teams being the tech champions and they provide the direction and vision for product research and development because of their experience and deeper understanding of the product/domain/technology

        To summarize, the Planning teams may not be evil ( even useful) but there can also be better, collaborative ways to plan the future :)


        ---
        With Regards,
        Madhur Kathuria, CSC, CSP, CSM, CSA
        Chair, India Scrum Enthusiasts Community (ISEC)
        Founder, Agile Pune
         
        Call: +91.8506011150
        Skype: madhur.kathuria


        On 27 August 2013 12:28, 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

         


      • 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 3 of 25 , Aug 27, 2013
        • 0 Attachment
          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 4 of 25 , Aug 27, 2013
          • 0 Attachment
            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 5 of 25 , Aug 27, 2013
            • 0 Attachment
              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 6 of 25 , Aug 27, 2013
              • 0 Attachment
                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 7 of 25 , Aug 27, 2013
                • 0 Attachment

                  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 8 of 25 , Aug 27, 2013
                  • 0 Attachment
                    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 9 of 25 , Aug 27, 2013
                    • 0 Attachment
                      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 10 of 25 , Aug 28, 2013
                      • 0 Attachment
                        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 11 of 25 , Aug 28, 2013
                        • 0 Attachment

                          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 12 of 25 , Aug 29, 2013
                          • 0 Attachment
                            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 13 of 25 , Aug 31, 2013
                            • 0 Attachment
                              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 14 of 25 , Sep 3, 2013
                              • 0 Attachment
                                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 15 of 25 , Sep 3, 2013
                                • 0 Attachment
                                  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 16 of 25 , Sep 3, 2013
                                  • 0 Attachment

                                    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 17 of 25 , Sep 3, 2013
                                    • 0 Attachment
                                      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 18 of 25 , Sep 3, 2013
                                      • 0 Attachment
                                        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 19 of 25 , Sep 3, 2013
                                        • 0 Attachment
                                          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 20 of 25 , Sep 3, 2013
                                          • 0 Attachment
                                            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 21 of 25 , Sep 3, 2013
                                            • 0 Attachment
                                              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 22 of 25 , Sep 3, 2013
                                              • 0 Attachment

                                                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 23 of 25 , Sep 3, 2013
                                                • 0 Attachment
                                                  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 24 of 25 , Sep 3, 2013
                                                  • 0 Attachment
                                                    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 25 of 25 , Sep 3, 2013
                                                    • 0 Attachment
                                                      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.