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

Re: [scrumdevelopment] Daily standup in a multi-project team

Expand Messages
  • Kurt Häusler
    Talk about learning and the way the work flows through the system. Blockers, capacity imbalances, WIP buildups. Generally focus on the system itself. Most
    Message 1 of 6 , Sep 16, 2013
    • 0 Attachment
      Talk about learning and the way the work flows through the system.
      Blockers, capacity imbalances, WIP buildups. Generally focus on the
      system itself. Most (interesting) impediments are usually independent
      of any specific project.

      On Mon, Sep 16, 2013 at 3:51 AM, David Doyle <david@...> wrote:
      >
      >
      > Are there any suggestions/recommendations for the daily standup where team
      > members are not all working on the same project?
      >
      > The standup tends to focus on individual status and due to team members
      > working on different projects we don't seem to be getting as much value as
      > we would if we were all working on a single project. Rather than scrap the
      > standup as providing little value we'd like to consider other approaches
      > that teams similar to us might be using.
      >
      > Context: We are using a kanban approach rather than scrum. The team members
      > are a mix of developers, business analysts and a QA lead who are focused on
      > a large enterprise application (8 people plus a manager). Our work is spilt
      > between production support, smaller projects just for our application and
      > larger enterprise projects where we are developing the part of the solution
      > that impacts our application and needs to integrate with other applications.
      > The timelines for this work overlaps, is aligned to corporate dates for
      > design, development, QA and release; and is driven by business and external
      > factors (so not too many opportunities to line work up in a serial fashion).
      > There is a lot of 'subgroup' collaboration going on between the team members
      > who are on the same project. In our retrospective the topic of the value of
      > the standup has arisen - team members find it useful for information
      > exchange, but individual team members tune out when the person talking is
      > discussing a project the listener is not involved with.
    • Adam Sroka
      I m coaching a team in a similar situation right now. We use different colors for the distinct products on the Kanban board. There are two standups, and some
      Message 2 of 6 , Sep 16, 2013
      • 0 Attachment
        I'm coaching a team in a similar situation right now. We use different colors for the distinct products on the Kanban board. There are two standups, and some people have to attend both because their work impacts both programs. However, those who only attend one of the two standups still see the cards on the single board, and if they have questions about those there is usually someone there who can answer (or they know who to ask after the standup). Although this team is pretty new to Agile this approach seems to work well in their context. 

        As far as the "tuning out" I don't see how that is possible if the updates are as brief as they should be. Is it possible that people are giving more details than necessary? It is important to table any discussion or detailed updates until after the standup and reserve this time for talking about the status of things on the board. 

        Another possibility to consider is that the items on the board are too large causing their status to be somewhat nuanced or ambiguous. If that is the case you might want to encourage the team to spend some time splitting things down smaller. If the items on the board are the right size there should rarely be a whole lot more to say about them in the standup than that they moved or are blocked by something. 

        Finally, one of the things I often encounter as a coach is that discussions happen in the standup because they aren't happening at the right time. Make sure that your team understands that the daily meeting is not the only time they are allowed to talk to each other. Any issues that come up in the standup should be followed up on by the Scrummaster to make sure that they are being handled/discussed outside the meeting. Over time the team should get used to bringing them up at the right time rather than waiting until the next standup, and that should be actively encouraged. 


        On Sun, Sep 15, 2013 at 9:51 PM, David Doyle <david@...> wrote:
         

        Are there any suggestions/recommendations for the daily standup where team members are not all working on the same project?

        The standup tends to focus on individual status and due to team members working on different projects we don't seem to be getting as much value as we would if we were all working on a single project. Rather than scrap the standup as providing little value we'd like to consider other approaches that teams similar to us might be using.

        Context: We are using a kanban approach rather than scrum. The team members are a mix of developers, business analysts and a QA lead who are focused on a large enterprise application (8 people plus a manager). Our work is spilt between production support, smaller projects just for our application and larger enterprise projects where we are developing the part of the solution that impacts our application and needs to integrate with other applications. The timelines for this work overlaps, is aligned to corporate dates for design, development, QA and release; and is driven by business and external factors (so not too many opportunities to line work up in a serial fashion). There is a lot of 'subgroup' collaboration going on between the team members who are on the same project. In our retrospective the topic of the value of the standup has arisen - team members find it useful for information exchange, but individual team members tune out when the person talking is discussing a project the listener is not involved with.


      • Greg Lucas-Smith
        We saw this problem, for us it occurred when the developers needed to give technical updates and the testers couldn t understand (or weren t interested!). We
        Message 3 of 6 , Sep 16, 2013
        • 0 Attachment
          We saw this problem, for us it occurred when the developers needed to give technical updates and the testers couldn't understand (or weren't interested!).

          We resolved it in two steps:

          * We changed the team to use the "Walk the items" pattern from Charles' site (http://www.scrumcrazy.com/Daily+Scrum+Patterns+Summary).  Using this, only people that were involved with a task were allowed to speak on a task.  This provided the focus that was missing and uncovered a tendency for the status updates to turn into long winded discussions.
          * We implemented a formal "After Party" (also from Charles patterns site) that gave the developers the discussions that they needed at the right time.

          It's interesting that you have a lot of subgroup collaboration going on, have you considered splitting into smaller, project focused teams?  At the moment we are experimenting with having a team of only two developers and it seems to be working quite well.  The standups are short, sharp and focused.  The Scrum meetings are held around the board and are also shorter and sharper.  There's very little cost (except maybe wall space?) and the speed of the ceremonies has allowed us to move the team to weekly sprints.

          Greg


          On Mon, Sep 16, 2013 at 9:51 AM, David Doyle <david@...> wrote:
           

          Are there any suggestions/recommendations for the daily standup where team members are not all working on the same project?

          The standup tends to focus on individual status and due to team members working on different projects we don't seem to be getting as much value as we would if we were all working on a single project. Rather than scrap the standup as providing little value we'd like to consider other approaches that teams similar to us might be using.

          Context: We are using a kanban approach rather than scrum. The team members are a mix of developers, business analysts and a QA lead who are focused on a large enterprise application (8 people plus a manager). Our work is spilt between production support, smaller projects just for our application and larger enterprise projects where we are developing the part of the solution that impacts our application and needs to integrate with other applications. The timelines for this work overlaps, is aligned to corporate dates for design, development, QA and release; and is driven by business and external factors (so not too many opportunities to line work up in a serial fashion). There is a lot of 'subgroup' collaboration going on between the team members who are on the same project. In our retrospective the topic of the value of the standup has arisen - team members find it useful for information exchange, but individual team members tune out when the person talking is discussing a project the listener is not involved with.


        • Alan Dayley
          So, you have learned that giving one team multiple projects with different work prevents you from having a fully focused and cohesive team. Great information!
          Message 4 of 6 , Sep 16, 2013
          • 0 Attachment
            So, you have learned that giving one team multiple projects with different work prevents you from having a fully focused and cohesive team. Great information! And the team is saying that they really are not a team. Also great information!

            It seems that the team wants to stop pretending that they are a team. And it seems that you want to keep them together as a team. What can you do in your environment to help them want to stay a team? Adam had some good thoughts on this and maybe you can come up with more.

            Alan



            On Mon, Sep 16, 2013 at 6:38 AM, Adam Sroka <adam.sroka@...> wrote:
             

            I'm coaching a team in a similar situation right now. We use different colors for the distinct products on the Kanban board. There are two standups, and some people have to attend both because their work impacts both programs. However, those who only attend one of the two standups still see the cards on the single board, and if they have questions about those there is usually someone there who can answer (or they know who to ask after the standup). Although this team is pretty new to Agile this approach seems to work well in their context. 

            As far as the "tuning out" I don't see how that is possible if the updates are as brief as they should be. Is it possible that people are giving more details than necessary? It is important to table any discussion or detailed updates until after the standup and reserve this time for talking about the status of things on the board. 

            Another possibility to consider is that the items on the board are too large causing their status to be somewhat nuanced or ambiguous. If that is the case you might want to encourage the team to spend some time splitting things down smaller. If the items on the board are the right size there should rarely be a whole lot more to say about them in the standup than that they moved or are blocked by something. 

            Finally, one of the things I often encounter as a coach is that discussions happen in the standup because they aren't happening at the right time. Make sure that your team understands that the daily meeting is not the only time they are allowed to talk to each other. Any issues that come up in the standup should be followed up on by the Scrummaster to make sure that they are being handled/discussed outside the meeting. Over time the team should get used to bringing them up at the right time rather than waiting until the next standup, and that should be actively encouraged. 


            On Sun, Sep 15, 2013 at 9:51 PM, David Doyle <david@...> wrote:
             

            Are there any suggestions/recommendations for the daily standup where team members are not all working on the same project?

            The standup tends to focus on individual status and due to team members working on different projects we don't seem to be getting as much value as we would if we were all working on a single project. Rather than scrap the standup as providing little value we'd like to consider other approaches that teams similar to us might be using.

            Context: We are using a kanban approach rather than scrum. The team members are a mix of developers, business analysts and a QA lead who are focused on a large enterprise application (8 people plus a manager). Our work is spilt between production support, smaller projects just for our application and larger enterprise projects where we are developing the part of the solution that impacts our application and needs to integrate with other applications. The timelines for this work overlaps, is aligned to corporate dates for design, development, QA and release; and is driven by business and external factors (so not too many opportunities to line work up in a serial fashion). There is a lot of 'subgroup' collaboration going on between the team members who are on the same project. In our retrospective the topic of the value of the standup has arisen - team members find it useful for information exchange, but individual team members tune out when the person talking is discussing a project the listener is not involved with.



          • Adam Sroka
            I like walking the items. That s the way they do it in Kanban, and even though some Scrum purists object the only thing you need to add to make it compatible
            Message 5 of 6 , Sep 16, 2013
            • 0 Attachment
              I like walking the items. That's the way they do it in Kanban, and even though some Scrum purists object the only thing you need to add to make it compatible is to be sure that everyone speaks.

               If you get through all the items and someone has been silent the whole time just ask them what they're working on and if they have any blockers. Might also be a good idea to create a card for whatever it is. 

              I'm less of a fan of the after party. As a coach I work really hard to make sure conversations are happening just in time. If there is a designated time for them people will wait until the next meeting to discuss something which could be a whole day of wasted opportunity. 

              On Monday, September 16, 2013, Greg Lucas-Smith wrote:
               

              We saw this problem, for us it occurred when the developers needed to give technical updates and the testers couldn't understand (or weren't interested!).

              We resolved it in two steps:

              * We changed the team to use the "Walk the items" pattern from Charles' site (http://www.scrumcrazy.com/Daily+Scrum+Patterns+Summary).  Using this, only people that were involved with a task were allowed to speak on a task.  This provided the focus that was missing and uncovered a tendency for the status updates to turn into long winded discussions.
              * We implemented a formal "After Party" (also from Charles patterns site) that gave the developers the discussions that they needed at the right time.

              It's interesting that you have a lot of subgroup collaboration going on, have you considered splitting into smaller, project focused teams?  At the moment we are experimenting with having a team of only two developers and it seems to be working quite well.  The standups are short, sharp and focused.  The Scrum meetings are held around the board and are also shorter and sharper.  There's very little cost (except maybe wall space?) and the speed of the ceremonies has allowed us to move the team to weekly sprints.

              Greg


              On Mon, Sep 16, 2013 at 9:51 AM, David Doyle <david@...> wrote:
               

              Are there any suggestions/recommendations for the daily standup where team members are not all working on the same project?

              The standup tends to focus on individual status and due to team members working on different projects we don't seem to be getting as much value as we would if we were all working on a single project. Rather than scrap the standup as providing little value we'd like to consider other approaches that teams similar to us might be using.

              Context: We are using a kanban approach rather than scrum. The team members are a mix of developers, business analysts and a QA lead who are focused on a large enterprise application (8 people plus a manager). Our work is spilt between production support, smaller projects just for our application and larger enterprise projects where we are developing the part of the solution that impacts our application and needs to integrate with other applications. The timelines for this work overlaps, is aligned to corporate dates for design, development, QA and release; and is driven by business and external factors (so not too many opportunities to line work up in a serial fashion). There is a lot of 'subgroup' collaboration going on between the team members who are on the same project. In our retrospective the topic of the value of the standup has arisen - team members find it useful for information exchange, but individual team members tune out when the person talking is discussing a project the listener is not involved with.


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