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

Scrum with Distributed Team

Expand Messages
  • Huet Landry
    I serving as the ScrumMaster to roll out the Scum approach win a government organization. The organization has traditionally used a waterfall approach, but
    Message 1 of 11 , Oct 2, 2007
    • 0 Attachment
      I serving as the ScrumMaster to roll out the Scum approach win a
      government organization. The organization has traditionally used a
      waterfall approach, but since our user requirements picture is in
      constant change, the management has been very supportive of this
      change.

      The team I am working with is facing several challenges which we are
      addressing, but I'd like some other opinions.

      Project Summary: Rehosting and redesign of a contractor-developed
      web application to a government site. Delivery to Acceptance
      Testing at the end of December. Delivery to Production at end of
      February. (Yes, there is considerable organizational overhead.)

      Location: Government PM for the new system at one site, development
      team offsite (15 minute trip - due to space limitations), product
      owners at a third site - out of state.

      Current practice: Weekly teleconferences (one day each week, plus
      another day every other week) with product owners to work on product
      backlog (use cases/scenarios.) Daily Scrum with developers working
      on Sprint tasks. Weekly PM status meetings. First Sprint completed
      with successful demo.

      Issues from Sprint 1 Retrospective: Work on backlog lagging due to
      lack of time to work with the product owners. Difficulty in getting
      Sprint plan completed in a day - first one had several sets
      of "discovered" tasks added. Difficulty in embracing discipline of
      recording actual hours by task and recording task completion. Need
      to establish more frequent communication with product owners.

      Plans: Starting daily email summary of Scrum to product owners,
      with follow-up (by me). Videoconferencing with product owners has
      proved more effective than teleconference (duh) but we have limited
      access at present, though new equipment is being installed. Setting
      up product owner access to demo software. Plan for this Sprint is
      to require developers to report against named tasks in the daily
      Scrum to emphasize attention to the burndown chart.

      As Johnny Five would say "Input! Neeed More Input!"

      Huet Landry, PMP, CSM
      DHS (Unisys)
    • Wolfgang Schulze Zachau
      Aaarrrrgghhh. Product Owners out of state. Why the plural? Is there more than one of them? If there is more than one, it would be (much much) better to find a
      Message 2 of 11 , Oct 2, 2007
      • 0 Attachment
        Aaarrrrgghhh. Product Owners out of state. Why the plural? Is there more than one of them?
        If there is more than one, it would be (much much) better to find a PO who can be on site with the team and who can funnel their (probably contradicting) requests into ONE product backlog.
        Team on different site to the PM. Why? If there is enough space for the team, can the PM not fit in? What does the PM actually do? Is he the Scrum Master? I thought it was you? Or are you the government PM?
        Why are you recording actual hours? Scrum does not require this. Scrum (by the book) only requires estimation of hours remaining for incomplete tasks.
        I am going to be a heretic here: I found out that the estimation of remaining hours on open tasks was being abused by everybody and in the end we still had not completed all tasks, so I abolished this and now we only use three different states for each task: Initial, WIP, Done. Any task that was in WIP yesterday has to finish today, otherwise there is a problem (task to big, some impediment or someone slacking or some new discovery). KISS, all the way.
         
        Don't worry about the discovered tasks, that's normal, especially in your first couple of sprints. All it does is show that your team is being honest (which is good) and they are not afraid of reporting issues (also good). But do worry about your offsite product owners.
         

        Regards,

        Wolfgang

         


        From: scrumdevelopment@yahoogroups.com [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of Huet Landry
        Sent: 02 October 2007 16:10
        To: scrumdevelopment@yahoogroups.com
        Subject: [scrumdevelopment] Scrum with Distributed Team

        I serving as the ScrumMaster to roll out the Scum approach win a
        government organization. The organization has traditionally used a
        waterfall approach, but since our user requirements picture is in
        constant change, the management has been very supportive of this
        change.

        The team I am working with is facing several challenges which we are
        addressing, but I'd like some other opinions.

        Project Summary: Rehosting and redesign of a contractor-develope d
        web application to a government site. Delivery to Acceptance
        Testing at the end of December. Delivery to Production at end of
        February. (Yes, there is considerable organizational overhead.)

        Location: Government PM for the new system at one site, development
        team offsite (15 minute trip - due to space limitations) , product
        owners at a third site - out of state.

        Current practice: Weekly teleconferences (one day each week, plus
        another day every other week) with product owners to work on product
        backlog (use cases/scenarios. ) Daily Scrum with developers working
        on Sprint tasks. Weekly PM status meetings. First Sprint completed
        with successful demo.

        Issues from Sprint 1 Retrospective: Work on backlog lagging due to
        lack of time to work with the product owners. Difficulty in getting
        Sprint plan completed in a day - first one had several sets
        of "discovered" tasks added. Difficulty in embracing discipline of
        recording actual hours by task and recording task completion. Need
        to establish more frequent communication with product owners.

        Plans: Starting daily email summary of Scrum to product owners,
        with follow-up (by me). Videoconferencing with product owners has
        proved more effective than teleconference (duh) but we have limited
        access at present, though new equipment is being installed. Setting
        up product owner access to demo software. Plan for this Sprint is
        to require developers to report against named tasks in the daily
        Scrum to emphasize attention to the burndown chart.

        As Johnny Five would say "Input! Neeed More Input!"

        Huet Landry, PMP, CSM
        DHS (Unisys)

      • Hubert Smits
        Hi Huet, Let me give you some feedback below. --Hubert Huet Landry wrote: I serving as the ScrumMaster to roll out the Scum
        Message 3 of 11 , Oct 2, 2007
        • 0 Attachment
          Hi Huet,

          Let me give you some feedback below.

          --Hubert

          Huet Landry <huet.landry@...> wrote:
          I serving as the ScrumMaster to roll out the Scum approach win a
          government organization. The organization has traditionally used a
          waterfall approach, but since our user requirements picture is in
          constant change, the management has been very supportive of this
          change.

          Cool

          The team I am working with is facing several challenges which we are
          addressing, but I'd like some other opinions.
          Still cool

          Project Summary: Rehosting and redesign of a contractor-developed
          web application to a government site. Delivery to Acceptance
          Testing at the end of December. Delivery to Production at end of
          February. (Yes, there is considerable organizational overhead.)
          UAT not in the team: not cool, if you can get those people in the team you can save a lot of time, 20% or more.

          Location: Government PM for the new system at one site, development
          team offsite (15 minute trip - due to space limitations), product
          owners at a third site - out of state.
          You didn't mention team sizes, I assume that it is a single dev team, around 10 people. Where are the UAT folks located? I'm not sure what the role of the GOv. pm is, if there is a PO available then the PM feels like overhead. Not harmful or anything, just overhead.

          Current practice: Weekly teleconferences (one day each week, plus
          another day every other week) with product owners to work on product
          backlog (use cases/scenarios.) Daily Scrum with developers working
          on Sprint tasks. Weekly PM status meetings. First Sprint completed
          with successful demo.
          Congrats on the first Sprint, that is good news as it shows that all involved want to make it work.

          PO and backlog: how independent are those people? I know that they need to talk to the dev people to prepare stories, and to prepare for planning, but you shouldn't need to chase them weekly. Why are they writing design, and not just stories?

          Daily Scrum: good, are the UAT and PO people calling in?

          Weekly status meeting: not sure why you need this, it feels like overhead, but I can understand that a (government) organization requests this. The PM should get all info from the burndown and the stand-ups.

          Issues from Sprint 1 Retrospective: Work on backlog lagging due to
          lack of time to work with the product owners.
          Can you move this work into the sprint? Can the product owners be on-site for x days a week? Can you create a block of time every day or every other day to work with the PO, have you tried pairing tools like Google Docs?

          Difficulty in getting
          Sprint plan completed in a day - first one had several sets
          of "discovered" tasks added.
          No surprise for a first sprint planning, you will do better next time until you take only 3 - 4 hours. Are all people (team, PO, UAT, PM) in the room for the planning session, that saves a lot of time.

          Difficulty in embracing discipline of
          recording actual hours by task and recording task completion.
          Don't do actuals, or don't do them too precise. Only work with the required estimate to complete for every task. That should take less then a minute a day for the developers and testers.

          Need
          to establish more frequent communication with product owners.
          See above.
          Plans: Starting daily email summary of Scrum to product owners,
          with follow-up (by me).
          Why? You're creating work and they can attend the meeting. If they say they can't than they have not enough interest and won't read your reports either.
          Videoconferencing with product owners has
          proved more effective than teleconference (duh) but we have limited
          access at present, though new equipment is being installed.
          Go cheap with a webcam and messenger, works like a charm for quick meetings. Put the webcam on expenses as 'cheap lunch with customer' :-)
          Setting
          up product owner access to demo software.
          Should be easy with a good build process.
          Plan for this Sprint is
          to require developers to report against named tasks in the daily
          Scrum to emphasize attention to the burndown chart.
          Hmm, it may work but you're creating a status meeting, not a stand-up. Be very careful here, let the team self-organize (and the PO is part of the team).

          As Johnny Five would say "Input! Neeed More Input!"

          Huet Landry, PMP, CSM
          DHS (Unisys)





          To Post a message, send it to: scrumdevelopment@...
          To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...
          Yahoo! Groups Links

          <*> To visit your group on the web, go to:
          http://groups.yahoo.com/group/scrumdevelopment/

          <*> Your email settings:
          Individual Email | Traditional

          <*> To change settings online go to:
          http://groups.yahoo.com/group/scrumdevelopment/join
          (Yahoo! ID required)

          <*> To change settings via email:
          mailto:scrumdevelopment-digest@yahoogroups.com
          mailto:scrumdevelopment-fullfeatured@yahoogroups.com

          <*> To unsubscribe from this group, send an email to:
          scrumdevelopment-unsubscribe@yahoogroups.com

          <*> Your use of Yahoo! Groups is subject to:
          http://docs.yahoo.com/info/terms/


        • srinivas chillara
          ... I disagree. UAT is often a formal checkpoint, and a necessary step before s/w is taken up by user groups, or rolled out organisation wide. In case of
          Message 4 of 11 , Oct 3, 2007
          • 0 Attachment
            > UAT not in the team: not cool, if you can get those
            > people in the team you can save a lot of time, 20%
            > or more.

            I disagree. UAT is often a formal checkpoint, and a
            necessary step before s/w is taken up by user groups,
            or rolled out organisation wide.

            In case of complicated and large fuctionality being
            built the PO cannot be certain that software is "done"
            simply by spending time on the sprint review meeting.
            All he can make out is if the s/w is hopeless or not,
            and ofcourse if there are changes he/other users want
            based on what they can see.
            It might not be sufficient to decide if the number of
            bugs is at a tolerable level.
            UAT can be conducted under the supervision ofthe PO.


            However the team has to make the s/w sufficinetly good
            by thier own testing activities, and as such testers
            should be part of the team.

            Hopefully testers will learn some other skills and
            the others will learn some testing skills as sprints
            progress.

            cheers
            Cheenie








            Why delete messages? Unlimited storage is just a click away. Go to http://help.yahoo.com/l/in/yahoo/mail/yahoomail/tools/tools-08.html
          • Hubert Smits
            Hi Cheenie, Sorry to be unclear, UAT is absolutely necessary for the all the reasons you mention. It can be done as part of the Sprint though, and that saves
            Message 5 of 11 , Oct 3, 2007
            • 0 Attachment
              Hi Cheenie,

              Sorry to be unclear, UAT is absolutely necessary for the all the reasons you mention. It can be done as part of the Sprint though, and that saves lots of time because the Analysts can pair with the testers to write design and tests, then the developers can run the tests while they are coding, and finally the UAT folks can run the tests in a separate environment for final verification. This way the find bug / fix bug cycle becomes very short, unlike when the dev team has moved on to the next sprint and has to re-open the old code to fix bugs (which they had already modified because of the requirements in the new Sprint).

              Hope this helps,

              --Hubert

              srinivas chillara <ceezone@...> wrote:


              > UAT not in the team: not cool, if you can get those
              > people in the team you can save a lot of time, 20%
              > or more.

              I disagree. UAT is often a formal checkpoint, and a
              necessary step before s/w is taken up by user groups,
              or rolled out organisation wide.

              In case of complicated and large fuctionality being
              built the PO cannot be certain that software is "done"
              simply by spending time on the sprint review meeting.
              All he can make out is if the s/w is hopeless or not,
              and ofcourse if there are changes he/other users want
              based on what they can see.
              It might not be sufficient to decide if the number of
              bugs is at a tolerable level.
              UAT can be conducted under the supervision ofthe PO.


              However the team has to make the s/w sufficinetly good
              by thier own testing activities, and as such testers
              should be part of the team.

              Hopefully testers will learn some other skills and
              the others will learn some testing skills as sprints
              progress.

              cheers
              Cheenie








              Why delete messages? Unlimited storage is just a click away. Go to http://help.yahoo.com/l/in/yahoo/mail/yahoomail/tools/tools-08.html


              To Post a message, send it to: scrumdevelopment@...
              To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...
              Yahoo! Groups Links

              <*> To visit your group on the web, go to:
              http://groups.yahoo.com/group/scrumdevelopment/

              <*> Your email settings:
              Individual Email | Traditional

              <*> To change settings online go to:
              http://groups.yahoo.com/group/scrumdevelopment/join
              (Yahoo! ID required)

              <*> To change settings via email:
              mailto:scrumdevelopment-digest@yahoogroups.com
              mailto:scrumdevelopment-fullfeatured@yahoogroups.com

              <*> To unsubscribe from this group, send an email to:
              scrumdevelopment-unsubscribe@yahoogroups.com

              <*> Your use of Yahoo! Groups is subject to:
              http://docs.yahoo.com/info/terms/


            • srinivas chillara
              Hallo Hubert, ... By this if you mean the dev team running UAT tests (which have been made available) during the sprint that s OK and is a good idea.
              Message 6 of 11 , Oct 3, 2007
              • 0 Attachment
                Hallo Hubert,


                > Hi Cheenie,
                >
                > Sorry to be unclear, UAT is absolutely necessary for
                > the all the reasons you mention. It can be done as
                > part of the Sprint though,


                By this if you mean the dev team running UAT tests
                (which have been made available) during the sprint
                that's OK and is a good idea. Otherwise the activity
                of UAT itself cannot be run within the sprint, because
                the user or user groups are the only ones who can
                conduct the UAT (maybe under some guidance) and they
                are not part of the team.
                Also UAT must give confidence to the users (and the
                PO), so I'd suppose that the sponsors would wish that
                the UAT is done outside the sprint by non-dev-team
                members. (Here the dev-team can and should consist of
                testers)




                >and that saves lots of
                > time because the Analysts can pair with the testers
                > to write design and tests, then the developers can
                > run the tests while they are coding, and finally the
                > UAT folks can run the tests in a separate
                > environment for final verification.

                True, this is a good idea.


                cheers
                Cheenie




                Chat on a cool, new interface. No download required. Go to http://in.messenger.yahoo.com/webmessengerpromo.php
              • Hubert Smits
                Hi Cheenie, Remember the art of the possible exercise from the CSM class? There is no reason why the majority of the UAT tests can t be run in the Sprint.
                Message 7 of 11 , Oct 3, 2007
                • 0 Attachment
                  Hi Cheenie,

                  Remember 'the art of the possible' exercise from the CSM class? There is no reason why the majority of the UAT tests can't be run in the Sprint. Issues with users and environments can easily be solved, if the team wants to solve them.

                  --Hubert

                  srinivas chillara <ceezone@...> wrote:

                  Hallo Hubert,


                  > Hi Cheenie,
                  >
                  > Sorry to be unclear, UAT is absolutely necessary for
                  > the all the reasons you mention. It can be done as
                  > part of the Sprint though,


                  By this if you mean the dev team running UAT tests
                  (which have been made available) during the sprint
                  that's OK and is a good idea. Otherwise the activity
                  of UAT itself cannot be run within the sprint, because
                  the user or user groups are the only ones who can
                  conduct the UAT (maybe under some guidance) and they
                  are not part of the team.
                  Also UAT must give confidence to the users (and the
                  PO), so I'd suppose that the sponsors would wish that
                  the UAT is done outside the sprint by non-dev-team
                  members. (Here the dev-team can and should consist of
                  testers)




                  >and that saves lots of
                  > time because the Analysts can pair with the testers
                  > to write design and tests, then the developers can
                  > run the tests while they are coding, and finally the
                  > UAT folks can run the tests in a separate
                  > environment for final verification.

                  True, this is a good idea.


                  cheers
                  Cheenie




                  Chat on a cool, new interface. No download required. Go to http://in.messenger.yahoo.com/webmessengerpromo.php


                  To Post a message, send it to: scrumdevelopment@...
                  To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...
                  Yahoo! Groups Links

                  <*> To visit your group on the web, go to:
                  http://groups.yahoo.com/group/scrumdevelopment/

                  <*> Your email settings:
                  Individual Email | Traditional

                  <*> To change settings online go to:
                  http://groups.yahoo.com/group/scrumdevelopment/join
                  (Yahoo! ID required)

                  <*> To change settings via email:
                  mailto:scrumdevelopment-digest@yahoogroups.com
                  mailto:scrumdevelopment-fullfeatured@yahoogroups.com

                  <*> To unsubscribe from this group, send an email to:
                  scrumdevelopment-unsubscribe@yahoogroups.com

                  <*> Your use of Yahoo! Groups is subject to:
                  http://docs.yahoo.com/info/terms/


                • srinivas chillara
                  Hello Hubert Smits This is a different way of looking at it, and I admit you are right. However (there is always a however) this is possible only after the
                  Message 8 of 11 , Oct 3, 2007
                  • 0 Attachment
                    Hello Hubert Smits

                    This is a different way of looking at it, and I admit
                    you are right. However (there is always a however)
                    this is possible only after the user groups and PO
                    already have a high level of confidence in the teams
                    ability to deliver the right software and of a high
                    quality.

                    So indeed it is possible. I havent seen this myself
                    personally.

                    cheers
                    Cheenie


                    > Hi Cheenie,
                    >
                    > Remember 'the art of the possible' exercise from the
                    > CSM class? There is no reason why the majority of
                    > the UAT tests can't be run in the Sprint. Issues
                    > with users and environments can easily be solved, if
                    > the team wants to solve them.
                    >
                    > --Hubert
                    >
                    > srinivas chillara <ceezone@...> wrote:
                    > Hallo Hubert,
                    >
                    >
                    > > Hi Cheenie,
                    > >
                    > > Sorry to be unclear, UAT is absolutely necessary
                    > for
                    > > the all the reasons you mention. It can be done as
                    > > part of the Sprint though,
                    >
                    >
                    > By this if you mean the dev team running UAT tests
                    > (which have been made available) during the sprint
                    > that's OK and is a good idea. Otherwise the activity
                    > of UAT itself cannot be run within the sprint,
                    > because
                    > the user or user groups are the only ones who can
                    > conduct the UAT (maybe under some guidance) and they
                    > are not part of the team.
                    > Also UAT must give confidence to the users (and the
                    > PO), so I'd suppose that the sponsors would wish
                    > that
                    > the UAT is done outside the sprint by non-dev-team
                    > members. (Here the dev-team can and should consist
                    > of
                    > testers)
                    >
                    >
                    >
                    >
                    > >and that saves lots of
                    > > time because the Analysts can pair with the
                    > testers
                    > > to write design and tests, then the developers can
                    > > run the tests while they are coding, and finally
                    > the
                    > > UAT folks can run the tests in a separate
                    > > environment for final verification.
                    >
                    > True, this is a good idea.
                    >
                    >
                    > cheers
                    > Cheenie
                    >
                    >
                    >
                    >
                    > Chat on a cool, new interface. No download
                    > required. Go to
                    > http://in.messenger.yahoo.com/webmessengerpromo.php
                    >
                    >
                    > To Post a message, send it to:
                    > scrumdevelopment@...
                    > To Unsubscribe, send a blank message to:
                    > scrumdevelopment-unsubscribe@...
                    > Yahoo! Groups Links
                    >
                    >
                    >
                    >
                    >



                    Chat on a cool, new interface. No download required. Go to http://in.messenger.yahoo.com/webmessengerpromo.php
                  • Huet Landry
                    Hubert (and others) Thanks for your comments and insight. ... Well, we re not chasing them weekly. Since they are both internal users and help desk support
                    Message 9 of 11 , Oct 12, 2007
                    • 0 Attachment
                      Hubert (and others)

                      Thanks for your comments and insight.

                      > PO and backlog: how independent are those people? I know that they
                      > need to talk to the dev people to prepare stories, and to prepare
                      > for planning, but you shouldn't need to chase them weekly. Why are
                      > they writing design, and not just stories?

                      Well, we're not 'chasing' them weekly. Since they are both internal
                      users and help desk support for external users, they have limited
                      time when the whole group can meet. They have committed to
                      answering email and phone questions within 24 hrs from developers.
                      They also have design/dev experience, since they also designed the
                      system we are porting. Our use cases are written at the system
                      level, with scenarios that detail system and user interactions.
                      Screen development is being done in parallel with the use cases.

                      >
                      > Daily Scrum: good, are the UAT and PO people calling in?

                      We're working on UAT folks calling in, but at present they are
                      writing tests from the use case scenarios. I'm having trouble
                      getting the PO folks convinced to call in daily, but they are also
                      commenting on the use cases regularly.

                      Due to the critical nature of some of our software and some poor
                      development practices in the past, our organization has two levels
                      of independant testing. This system also requires interface testing
                      with another major financial system and our PM is 'negotiating' a
                      timeframe with them (i.e. he's allowing them to test parallel with
                      the other two groups or - not at all.)

                      >
                      > Weekly status meeting: not sure why you need this, it feels like
                      overhead, but I can understand that a (government) organization
                      requests this. The PM should get all info from the burndown and the
                      stand-ups.

                      Due to the critical nature of some of our software and some poor
                      development practices in the past, our organization has two levels
                      of independant testing. This system also requires interface testing
                      with another major financial system and our PM is 'negotiating' a
                      timeframe with them (i.e. he's allowing them to test parallel with
                      the other two groups or - not at all.)

                      > Issues from Sprint 1 Retrospective: Work on backlog lagging due
                      to
                      > lack of time to work with the product owners.
                      > Can you move this work into the sprint? Can the product owners be
                      on-site for x days a week? Can you create a block of time every day
                      or every other day to work with the PO, have you tried pairing tools
                      like Google Docs?

                      That was what I was thinking, and we've done this with the second
                      sprint. We've also gotten some more interest from the local PO in
                      laying out a better backlog description.

                      >
                      > Difficulty in getting
                      > Sprint plan completed in a day - first one had several sets
                      > of "discovered" tasks added.
                      > No surprise for a first sprint planning, you will do better next
                      time until you take only 3 - 4 hours. Are all people (team, PO, UAT,
                      PM) in the room for the planning session, that saves a lot of time.

                      We have had good participation from all for at least the first 2 hrs
                      of planning.

                      >
                      > Difficulty in embracing discipline of
                      > recording actual hours by task and recording task completion.
                      > Don't do actuals, or don't do them too precise. Only work with the
                      required estimate to complete for every task. That should take less
                      then a minute a day for the developers and testers.

                      We've gone to the three-state (planned, in progreee, done) method,
                      and the oversight scheduler has agreed to allow this.

                      >
                      > Need
                      > to establish more frequent communication with product owners.
                      > See above.
                      > Plans: Starting daily email summary of Scrum to product owners,
                      > with follow-up (by me).
                      > Why? You're creating work and they can attend the meeting. If they
                      say they can't than they have not enough interest and won't read
                      your reports either.

                      Well, this is a busy organization, so most people have more than one
                      iron in the fire. The interest is there, but getting a time when
                      everyone's schedule is free is a miracle. We are seeing improvement
                      in their willingness to comment on use cases and attend the weekly
                      working sessions. The implemented functionality is updated daily on
                      a web server that all can access, so we're getting feedback from
                      that as well.

                      > Videoconferencing with product owners has
                      > proved more effective than teleconference (duh) but we have
                      limited
                      > access at present, though new equipment is being installed.
                      > Go cheap with a webcam and messenger, works like a charm for quick
                      meetings. Put the webcam on expenses as 'cheap lunch with
                      customer' :-)

                      Customer is footing the bill - they had some spare equipment in a
                      warehouse, so they just need to get the line connected.

                      > Plan for this Sprint is
                      > to require developers to report against named tasks in the daily
                      > Scrum to emphasize attention to the burndown chart.
                      > Hmm, it may work but you're creating a status meeting, not
                      > a stand-up. Be very careful here, let the team self-organize
                      > (and the PO is part of the team).

                      What I started doing was looking at the burndown before the scrum
                      and raising an issue if I saw few tasks completed from one day to
                      the next. So far, it's working well.

                      Huet
                    • Malcolm Anderson
                      I m not sure what you development environment is (Java - C# - Other), but I would highly recommend looking up a version of cruise control and having the
                      Message 10 of 11 , Oct 12, 2007
                      • 0 Attachment
                        I'm not sure what you development environment is (Java - C# - Other), but I would highly recommend looking up a version of cruise control and having the product built out and "deployed" to the UAT server EVERY time a successful check in happens.
                         
                        Continuous Integration is a VERY cool and useful thing.
                         
                        This way the users can actually see the current state of the product.  I think you will find that the feedback you get from this process will knock your socks off, not to mention surprising the PO.
                         
                        Malcolm
                        Agile Engineering Coach, CSP

                         
                        On 10/3/07, Hubert Smits <hubert.smits@...> wrote:

                        Hi Cheenie,

                        Sorry to be unclear, UAT is absolutely necessary for the all the reasons you mention. It can be done as part of the Sprint though, and that saves lots of time because the Analysts can pair with the testers to write design and tests, then the developers can run the tests while they are coding, and finally the UAT folks can run the tests in a separate environment for final verification. This way the find bug / fix bug cycle becomes very short, unlike when the dev team has moved on to the next sprint and has to re-open the old code to fix bugs (which they had already modified because of the requirements in the new Sprint).

                        Hope this helps,

                        --Hubert



                        srinivas chillara <ceezone@yahoo.co.in> wrote:


                        > UAT not in the team: not cool, if you can get those
                        > people in the team you can save a lot of time, 20%
                        > or more.

                        I disagree. UAT is often a formal checkpoint, and a
                        necessary step before s/w is taken up by user groups,
                        or rolled out organisation wide.

                        In case of complicated and large fuctionality being
                        built the PO cannot be certain that software is "done"
                        simply by spending time on the sprint review meeting.
                        All he can make out is if the s/w is hopeless or not,
                        and ofcourse if there are changes he/other users want
                        based on what they can see.
                        It might not be sufficient to decide if the number of
                        bugs is at a tolerable level.
                        UAT can be conducted under the supervision ofthe PO.


                        However the team has to make the s/w sufficinetly good
                        by thier own testing activities, and as such testers
                        should be part of the team.

                        Hopefully testers will learn some other skills and
                        the others will learn some testing skills as sprints
                        progress.

                        cheers
                        Cheenie








                        Why delete messages? Unlimited storage is just a click away. Go to http://help.yahoo.com/ l/in/yahoo/mail/yahoomail/tools/tools-08.html


                        To Post a message, send it to: scrumdevelopment@...
                        To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...
                        Yahoo! Groups Links

                        <*> To visit your group on the web, go to:
                        http://groups.yahoo.com/group/scrumdevelopment/

                        <*> Your email settings:
                        Individual Email | Traditional

                        <*> To change settings online go to:
                        http://groups. yahoo.com/group/scrumdevelopment/join
                        (Yahoo! ID required)

                        <*> To change settings via email:
                        mailto: scrumdevelopment-digest@yahoogroups.com
                        mailto:scrumdevelop ment-fullfeatured@yahoogroups.com

                        <*> To unsubscribe from this group, send an email to:
                        scrumdevelopment-unsubscribe@yahoogroups.com

                        <*> Your use of Yahoo! Groups is subject to:
                        http://docs. yahoo.com/info/terms/



                      • David Milner
                        Totally agree. Also - incorporating unit tests (Junit, Nunit) into the CI builds really helps. And as the product comes along having regression scripts
                        Message 11 of 11 , Oct 12, 2007
                        • 0 Attachment
                          Totally agree.  Also - incorporating unit tests (Junit, Nunit) into the CI builds really helps.
                          And as the product comes along having regression scripts automated is great too, like fitnesse or fit,
                          or other tools like Mercury scripts.  Automate the old, granny test the new.
                           
                          Dave Milner

                          ----- Original Message ----
                          From: Malcolm Anderson <malcolm.b.anderson@...>
                          To: scrumdevelopment@yahoogroups.com
                          Sent: Friday, October 12, 2007 12:40:16 PM
                          Subject: Re: [scrumdevelopment] Scrum with Distributed Team

                          I'm not sure what you development environment is (Java - C# - Other), but I would highly recommend looking up a version of cruise control and having the product built out and "deployed" to the UAT server EVERY time a successful check in happens.
                           
                          Continuous Integration is a VERY cool and useful thing.
                           
                          This way the users can actually see the current state of the product.  I think you will find that the feedback you get from this process will knock your socks off, not to mention surprising the PO.
                           
                          Malcolm
                          Agile Engineering Coach, CSP

                           
                          On 10/3/07, Hubert Smits <hubert.smits@ btinternet. com> wrote:

                          Hi Cheenie,

                          Sorry to be unclear, UAT is absolutely necessary for the all the reasons you mention. It can be done as part of the Sprint though, and that saves lots of time because the Analysts can pair with the testers to write design and tests, then the developers can run the tests while they are coding, and finally the UAT folks can run the tests in a separate environment for final verification. This way the find bug / fix bug cycle becomes very short, unlike when the dev team has moved on to the next sprint and has to re-open the old code to fix bugs (which they had already modified because of the requirements in the new Sprint).

                          Hope this helps,

                          --Hubert



                          srinivas chillara <ceezone@yahoo.co.in> wrote:


                          > UAT not in the team: not cool, if you can get those
                          > people in the team you can save a lot of time, 20%
                          > or more.

                          I disagree. UAT is often a formal checkpoint, and a
                          necessary step before s/w is taken up by user groups,
                          or rolled out organisation wide.

                          In case of complicated and large fuctionality being
                          built the PO cannot be certain that software is "done"
                          simply by spending time on the sprint review meeting.
                          All he can make out is if the s/w is hopeless or not,
                          and ofcourse if there are changes he/other users want
                          based on what they can see.
                          It might not be sufficient to decide if the number of
                          bugs is at a tolerable level.
                          UAT can be conducted under the supervision ofthe PO.


                          However the team has to make the s/w sufficinetly good
                          by thier own testing activities, and as such testers
                          should be part of the team.

                          Hopefully testers will learn some other skills and
                          the others will learn some testing skills as sprints
                          progress.

                          cheers
                          Cheenie








                          Why delete messages? Unlimited storage is just a click away. Go to http://help.yahoo.com/ l/in/yahoo/mail/ yahoomail/ tools/tools- 08.html


                          To Post a message, send it to: scrumdevelopment@ eGroups.com
                          To Unsubscribe, send a blank message to: scrumdevelopment- unsubscribe@ eGroups.com
                          Yahoo! Groups Links

                          <*> To visit your group on the web, go to:
                          http://groups.yahoo.com/group/scrumdevelopm ent/

                          <*> Your email settings:
                          Individual Email | Traditional

                          <*> To change settings online go to:
                          http://groups. yahoo.com/group/scrumdevelopm ent/join
                          (Yahoo! ID required)

                          <*> To change settings via email:
                          mailto: scrumdevelopment-digest@ yahoogroups. com
                          mailto:scrumdevelop ment-fullfeatured@ yahoogroups. com

                          <*> To unsubscribe from this group, send an email to:
                          scrumdevelopment- unsubscribe@ yahoogroups. com

                          <*> Your use of Yahoo! Groups is subject to:
                          http://docs. yahoo.com/info/terms/






                          Be a better Globetrotter. Get better travel answers from someone who knows.
                          Yahoo! Answers - Check it out.
                        Your message has been successfully submitted and would be delivered to recipients shortly.