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

Agile Transition Challenges -

Expand Messages
  • Kalaiselvan
    All I welcome all to this forum and I personaly thank Pete for his initiative on this to bring all people together to discuss, debate on Agile dev. To share my
    Message 1 of 19 , Jan 8, 2008
    View Source
    • 0 Attachment
      All
      I welcome all to this forum and I personaly thank Pete for his
      initiative on this to bring all people together to discuss, debate on
      Agile dev.

      To share my experience, I've seen many people taling about Agile
      thinking that it's another software dev process like 'waterfall' and
      take it light to acknowledge that it's good and we will implement
      successfully etc while selling solutions to customer ( it could be
      internal/external). That's a great misjudgement - or to be honest the
      person who claims so haven't understood the difficulty in making
      agile development success.

      yes it is indeed another dev process - but more matured, mor epainful
      to implement and requires lot of decipline.

      I've a bitter experience where I had tough changing the mindset of my
      client to transition to Agile though they have been following
      waterfall ( or some thier own way of doing things design-dev-test
      etc). In the end, we failed to show case the credibility of agile
      development ( it goes with many valid reasons but i think it's out of
      discussino here) and customer insisting going back to his dev
      process.

      lessons learned was
      1. agile is not for every customer engagment / project
      2. approach customer transition more transparent and better
      commitment and involvement from customer team (upper mgt from
      customer)
      3. requires lot of decipline and no compramise on 'agile' way of
      doing things
      4. need right people in the team who could understand and appreciate
      the value of doing in 'agile' way
      5. technology choice to hande many aspects of agile dev ( TDD,Pair
      programming, incremental design and dev etc)
      6. proper role players upfront and commitment from project
      stakeholders
      7. identify artifacts that are relevant upfront
      8. enrichment of agile way of doing things which gives success.....

      Looking forward to others to share such experience here

      you are welcome ---- all the best!

      thanks
      Selvan
    • Pete Deemer
      Selvan, let s say another client came to you tomorrow, saying we d like to try scrum . based on your lessons learned below, what are the 5 (or however many
      Message 2 of 19 , Jan 8, 2008
      View Source
      • 0 Attachment
        Selvan, let's say another client came to you tomorrow, saying "we'd
        like to try scrum". based on your lessons learned below, what are the
        5 (or however many you like) things on your checklist, that you would
        want to make sure you did, to set you and your client up for success?
        What I have in mind are very practical steps you could take.

        for example, I've seen some teams actually come up with a scrum
        "contract" with the client. it's not really a contract, it's just a
        piece of paper laying out the groundrules of how we're going to do
        scrum, but it's really helpful in surfacing areas where the client
        either "understand scrum differently" (the polite way to say it!) or
        is unsure of whether they're going to be able to commit. obviously,
        you have to be careful about this -- they're the client, after all --
        so you want to make sure they understand you're doing this not to be
        difficult or demanding, but because you want to see the project succeed.

        I'd love to hear what other people would put on their checklist, based
        on their experiences...

        --p


        --- In Scrum-India@yahoogroups.com, "Kalaiselvan" <selmaks@...> wrote:
        >
        > All
        > I welcome all to this forum and I personaly thank Pete for his
        > initiative on this to bring all people together to discuss, debate on
        > Agile dev.
        >
        > To share my experience, I've seen many people taling about Agile
        > thinking that it's another software dev process like 'waterfall' and
        > take it light to acknowledge that it's good and we will implement
        > successfully etc while selling solutions to customer ( it could be
        > internal/external). That's a great misjudgement - or to be honest the
        > person who claims so haven't understood the difficulty in making
        > agile development success.
        >
        > yes it is indeed another dev process - but more matured, mor epainful
        > to implement and requires lot of decipline.
        >
        > I've a bitter experience where I had tough changing the mindset of my
        > client to transition to Agile though they have been following
        > waterfall ( or some thier own way of doing things design-dev-test
        > etc). In the end, we failed to show case the credibility of agile
        > development ( it goes with many valid reasons but i think it's out of
        > discussino here) and customer insisting going back to his dev
        > process.
        >
        > lessons learned was
        > 1. agile is not for every customer engagment / project
        > 2. approach customer transition more transparent and better
        > commitment and involvement from customer team (upper mgt from
        > customer)
        > 3. requires lot of decipline and no compramise on 'agile' way of
        > doing things
        > 4. need right people in the team who could understand and appreciate
        > the value of doing in 'agile' way
        > 5. technology choice to hande many aspects of agile dev ( TDD,Pair
        > programming, incremental design and dev etc)
        > 6. proper role players upfront and commitment from project
        > stakeholders
        > 7. identify artifacts that are relevant upfront
        > 8. enrichment of agile way of doing things which gives success.....
        >
        > Looking forward to others to share such experience here
        >
        > you are welcome ---- all the best!
        >
        > thanks
        > Selvan
        >
      • Vikrama Dhiman
        Hello Selvan: Transitioning to Agile is generally slow. Below assumes a service industry scenario. One of the mistakes you could do is converting whole
        Message 3 of 19 , Jan 8, 2008
        View Source
        • 0 Attachment
          Hello Selvan:

          Transitioning to Agile is generally slow. Below assumes a "service industry" scenario.

          One of the mistakes you could do is converting whole organization at one go. What I'd recommend is going one team at a time [and let one team *really* get it]. Its difficult selling this to a management looking at quick fix solutions - but I think you'd get a better success by implementing it team by team.

          Some of the things you will need to keep in mind [would help]:
          • Try and do the first projects in Scrum using time and materials basis and not fixed price [this is because welcoming change gets interpreted without the discipline aspect really sinking in at both the team and product owner end]
          • Try and use some XP engineering practices by the book
          • Do Scrum by the book
          • Have an on-site Scrum coach/ consultant
          • If you do want to do Scrum on a fixed price project, try and quote only for one release at a time and keep one release small enough to be able to estimate
          • Do it on a domain you are most comfortable with
          Hope that helps!

          Thanks

          Pete Deemer <petedeemer@...> wrote:
          Selvan, let's say another client came to you tomorrow, saying "we'd
          like to try scrum". based on your lessons learned below, what are the
          5 (or however many you like) things on your checklist, that you would
          want to make sure you did, to set you and your client up for success?
          What I have in mind are very practical steps you could take.

          for example, I've seen some teams actually come up with a scrum
          "contract" with the client. it's not really a contract, it's just a
          piece of paper laying out the groundrules of how we're going to do
          scrum, but it's really helpful in surfacing areas where the client
          either "understand scrum differently" (the polite way to say it!) or
          is unsure of whether they're going to be able to commit. obviously,
          you have to be careful about this -- they're the client, after all --
          so you want to make sure they understand you're doing this not to be
          difficult or demanding, but because you want to see the project succeed.

          I'd love to hear what other people would put on their checklist, based
          on their experiences. ..

          --p

          --- In Scrum-India@ yahoogroups. com, "Kalaiselvan" <selmaks@... > wrote:
          >
          > All
          > I welcome all to this forum and I personaly thank Pete for his
          > initiative on this to bring all people together to discuss, debate on
          > Agile dev.
          >
          > To share my experience, I've seen many people taling about Agile
          > thinking that it's another software dev process like 'waterfall' and
          > take it light to acknowledge that it's good and we will implement
          > successfully etc while selling solutions to customer ( it could be
          > internal/external) . That's a great misjudgement - or to be honest the
          > person who claims so haven't understood the difficulty in making
          > agile development success.
          >
          > yes it is indeed another dev process - but more matured, mor epainful
          > to implement and requires lot of decipline.
          >
          > I've a bitter experience where I had tough changing the mindset of my
          > client to transition to Agile though they have been following
          > waterfall ( or some thier own way of doing things design-dev-test
          > etc). In the end, we failed to show case the credibility of agile
          > development ( it goes with many valid reasons but i think it's out of
          > discussino here) and customer insisting going back to his dev
          > process.
          >
          > lessons learned was
          > 1. agile is not for every customer engagment / project
          > 2. approach customer transition more transparent and better
          > commitment and involvement from customer team (upper mgt from
          > customer)
          > 3. requires lot of decipline and no compramise on 'agile' way of
          > doing things
          > 4. need right people in the team who could understand and appreciate
          > the value of doing in 'agile' way
          > 5. technology choice to hande many aspects of agile dev ( TDD,Pair
          > programming, incremental design and dev etc)
          > 6. proper role players upfront and commitment from project
          > stakeholders
          > 7. identify artifacts that are relevant upfront
          > 8. enrichment of agile way of doing things which gives success.....
          >
          > Looking forward to others to share such experience here
          >
          > you are welcome ---- all the best!
          >
          > thanks
          > Selvan
          >



          Never miss a thing. Make Yahoo your homepage.

        • Prabhakar Karve
          I agree with Vikrama when he suggests creating a success story in one or two projects before going across to the whole organization. It also makes sense to do
          Message 4 of 19 , Jan 8, 2008
          View Source
          • 0 Attachment
            I agree with Vikrama when he suggests creating a success story in one or
            two projects before going across to the whole organization. It also
            makes sense to do scrum by the book (at least initially). If you are
            already doing iterative development, there are chances that some of the
            concepts are currently being applied. But the real benefits come from
            Scrum only when you follow all the aspects together, like insistance on
            a single person managing the backlog, no change accepted once a sprint
            starts, daily updation and visibility of progress etc.


            --- In Scrum-India@yahoogroups.com, Vikrama Dhiman <vickydhiman@...>
            wrote:
            >
            > Hello Selvan:
            >
            > Transitioning to Agile is generally slow. Below assumes a "service
            industry" scenario.
            >
            > One of the mistakes you could do is converting whole organization at
            one go. What I'd recommend is going one team at a time [and let one team
            *really* get it]. Its difficult selling this to a management looking at
            quick fix solutions - but I think you'd get a better success by
            implementing it team by team.
            >
            > Some of the things you will need to keep in mind [would help]:
            >
            > Try and do the first projects in Scrum using time and materials basis
            and not fixed price [this is because welcoming change gets interpreted
            without the discipline aspect really sinking in at both the team and
            product owner end]
            > Try and use some XP engineering practices by the book
            > Do Scrum by the book
            > Have an on-site Scrum coach/ consultant
            > If you do want to do Scrum on a fixed price project, try and quote
            only for one release at a time and keep one release small enough to be
            able to estimate
            > Do it on a domain you are most comfortable with
            >
            > Hope that helps!
            >
            > Thanks
            >
            > Pete Deemer petedeemer@... wrote: Selvan, let's say another client
            came to you tomorrow, saying "we'd
            > like to try scrum". based on your lessons learned below, what are the
            > 5 (or however many you like) things on your checklist, that you would
            > want to make sure you did, to set you and your client up for success?
            > What I have in mind are very practical steps you could take.
            >
            > for example, I've seen some teams actually come up with a scrum
            > "contract" with the client. it's not really a contract, it's just a
            > piece of paper laying out the groundrules of how we're going to do
            > scrum, but it's really helpful in surfacing areas where the client
            > either "understand scrum differently" (the polite way to say it!) or
            > is unsure of whether they're going to be able to commit. obviously,
            > you have to be careful about this -- they're the client, after all --
            > so you want to make sure they understand you're doing this not to be
            > difficult or demanding, but because you want to see the project
            succeed.
            >
            > I'd love to hear what other people would put on their checklist, based
            > on their experiences...
            >
            > --p
            >
            > --- In Scrum-India@yahoogroups.com, "Kalaiselvan" selmaks@ wrote:
            > >
            > > All
            > > I welcome all to this forum and I personaly thank Pete for his
            > > initiative on this to bring all people together to discuss, debate
            on
            > > Agile dev.
            > >
            > > To share my experience, I've seen many people taling about Agile
            > > thinking that it's another software dev process like 'waterfall' and
            > > take it light to acknowledge that it's good and we will implement
            > > successfully etc while selling solutions to customer ( it could be
            > > internal/external). That's a great misjudgement - or to be honest
            the
            > > person who claims so haven't understood the difficulty in making
            > > agile development success.
            > >
            > > yes it is indeed another dev process - but more matured, mor
            epainful
            > > to implement and requires lot of decipline.
            > >
            > > I've a bitter experience where I had tough changing the mindset of
            my
            > > client to transition to Agile though they have been following
            > > waterfall ( or some thier own way of doing things design-dev-test
            > > etc). In the end, we failed to show case the credibility of agile
            > > development ( it goes with many valid reasons but i think it's out
            of
            > > discussino here) and customer insisting going back to his dev
            > > process.
            > >
            > > lessons learned was
            > > 1. agile is not for every customer engagment / project
            > > 2. approach customer transition more transparent and better
            > > commitment and involvement from customer team (upper mgt from
            > > customer)
            > > 3. requires lot of decipline and no compramise on 'agile' way of
            > > doing things
            > > 4. need right people in the team who could understand and appreciate
            > > the value of doing in 'agile' way
            > > 5. technology choice to hande many aspects of agile dev ( TDD,Pair
            > > programming, incremental design and dev etc)
            > > 6. proper role players upfront and commitment from project
            > > stakeholders
            > > 7. identify artifacts that are relevant upfront
            > > 8. enrichment of agile way of doing things which gives success.....
            > >
            > > Looking forward to others to share such experience here
            > >
            > > you are welcome ---- all the best!
            > >
            > > thanks
            > > Selvan
            > >
            >
            >
            >
            >
            >
            >
            > ---------------------------------
            > Never miss a thing. Make Yahoo your homepage.
            >
          • Kalaiselvan
            Vikrama thanks for your comments. when we step into an organisation trying to sell agile based development highlighiting all benefits looks good to everyone
            Message 5 of 19 , Jan 10, 2008
            View Source
            • 0 Attachment
              Vikrama

              thanks for your comments.

              when we step into an organisation trying to sell agile based
              development highlighiting all benefits looks good to everyone
              including the client who listens to it. ofcourse it would doom to
              fail when we expect the whole org to change the process in day one -
              it happens like SOA movement within the org to reach business goals.

              but are we doing this in every engagement? i bet not - atleast in
              service segment where many of the client engagements are won what
              unique things that we get on board to client like cost effecice
              solutions through open source tools, ability to delivery what we
              committed, better project visibility ( through agile)

              but more often the change is at client org where client don't seem to
              understnd agile way of doing things. from my exp, my client
              complained to us their involvement is increasingly getting higher
              every iteration due to the kind of feedback we get on deliverables.
              they are just annoyed of thier involvement as they thought, it's
              vendor resp to deliver - which is also true.

              I agree that we should go one team at a time - but what if we don't
              do the transition at root (customer approach towards agile and its
              commitment) - that would eventually doom to fail subsequnt
              opportunities. In a service industry where one should bring high
              competitive offering is questioned serriously when you can't delvier
              what you have committed.

              I like the approach which Pete said that we need to have some kind of
              mutual agreement or a contract put inplace upfront to have sort of
              MSA - master agreement!

              --- In Scrum-India@yahoogroups.com, Vikrama Dhiman <vickydhiman@...>
              wrote:
              >
              > Hello Selvan:
              >
              > Transitioning to Agile is generally slow. Below assumes a "service
              industry" scenario.
              >
              > One of the mistakes you could do is converting whole organization
              at one go. What I'd recommend is going one team at a time [and let
              one team *really* get it]. Its difficult selling this to a management
              looking at quick fix solutions - but I think you'd get a better
              success by implementing it team by team.
              >
              > Some of the things you will need to keep in mind [would help]:
              >
              > Try and do the first projects in Scrum using time and materials
              basis and not fixed price [this is because welcoming change gets
              interpreted without the discipline aspect really sinking in at both
              the team and product owner end]
              > Try and use some XP engineering practices by the book
              > Do Scrum by the book
              > Have an on-site Scrum coach/ consultant
              > If you do want to do Scrum on a fixed price project, try and
              quote only for one release at a time and keep one release small
              enough to be able to estimate
              > Do it on a domain you are most comfortable with
              >
              > Hope that helps!
              >
              > Thanks
              >
              > Pete Deemer <petedeemer@...> wrote:
              Selvan, let's say another client came to you tomorrow, saying "we'd
              > like to try scrum". based on your lessons learned below, what are
              the
              > 5 (or however many you like) things on your checklist, that you
              would
              > want to make sure you did, to set you and your client up for
              success?
              > What I have in mind are very practical steps you could take.
              >
              > for example, I've seen some teams actually come up with a scrum
              > "contract" with the client. it's not really a contract, it's just
              a
              > piece of paper laying out the groundrules of how we're going to do
              > scrum, but it's really helpful in surfacing areas where the client
              > either "understand scrum differently" (the polite way to say it!)
              or
              > is unsure of whether they're going to be able to commit.
              obviously,
              > you have to be careful about this -- they're the client, after
              all --
              > so you want to make sure they understand you're doing this not to
              be
              > difficult or demanding, but because you want to see the project
              succeed.
              >
              > I'd love to hear what other people would put on their checklist,
              based
              > on their experiences...
              >
              > --p
              >
              > --- In Scrum-India@yahoogroups.com, "Kalaiselvan" <selmaks@> wrote:
              > >
              > > All
              > > I welcome all to this forum and I personaly thank Pete for his
              > > initiative on this to bring all people together to discuss,
              debate on
              > > Agile dev.
              > >
              > > To share my experience, I've seen many people taling about Agile
              > > thinking that it's another software dev process like 'waterfall'
              and
              > > take it light to acknowledge that it's good and we will
              implement
              > > successfully etc while selling solutions to customer ( it could
              be
              > > internal/external). That's a great misjudgement - or to be
              honest the
              > > person who claims so haven't understood the difficulty in making
              > > agile development success.
              > >
              > > yes it is indeed another dev process - but more matured, mor
              epainful
              > > to implement and requires lot of decipline.
              > >
              > > I've a bitter experience where I had tough changing the mindset
              of my
              > > client to transition to Agile though they have been following
              > > waterfall ( or some thier own way of doing things design-dev-
              test
              > > etc). In the end, we failed to show case the credibility of
              agile
              > > development ( it goes with many valid reasons but i think it's
              out of
              > > discussino here) and customer insisting going back to his dev
              > > process.
              > >
              > > lessons learned was
              > > 1. agile is not for every customer engagment / project
              > > 2. approach customer transition more transparent and better
              > > commitment and involvement from customer team (upper mgt from
              > > customer)
              > > 3. requires lot of decipline and no compramise on 'agile' way of
              > > doing things
              > > 4. need right people in the team who could understand and
              appreciate
              > > the value of doing in 'agile' way
              > > 5. technology choice to hande many aspects of agile dev (
              TDD,Pair
              > > programming, incremental design and dev etc)
              > > 6. proper role players upfront and commitment from project
              > > stakeholders
              > > 7. identify artifacts that are relevant upfront
              > > 8. enrichment of agile way of doing things which gives
              success.....
              > >
              > > Looking forward to others to share such experience here
              > >
              > > you are welcome ---- all the best!
              > >
              > > thanks
              > > Selvan
              > >
              >
              >
              >
              >
              >
              >
              > ---------------------------------
              > Never miss a thing. Make Yahoo your homepage.
              >
            • Vikrama Dhiman
              Hello Selvan: Thanks for your comments. This might go off topic - however, customer collaboration is one of the key challenges for sure. ... Why are they
              Message 6 of 19 , Jan 10, 2008
              View Source
              • 0 Attachment
                Hello Selvan:

                Thanks for your comments. This might go off topic - however, customer collaboration is one of the key challenges for sure.

                >> they are just annoyed of thier involvement as they thought, it's vendor resp to deliver - which is also true.

                Why are they annoyed? Is it because they are being asked to take time to review/ provide feedback? Did you talk to them about why you would like their feedback? If yes, why you think they continue to crib and be annoyed even after that?

                >> I like the approach which Pete said that we need to have some kind of
                mutual agreement or a contract put inplace upfront to have sort of
                MSA - master agreement!

                Yes, thats a fantastic idea - the earlier you set the expectations, the better. However, I am curious to know how do you think that would help dealing with an annoyed customer who does not want to provide feedback very often?

                Thanks

                Kalaiselvan <selmaks@...> wrote:
                Vikrama

                thanks for your comments.

                when we step into an organisation trying to sell agile based
                development highlighiting all benefits looks good to everyone
                including the client who listens to it. ofcourse it would doom to
                fail when we expect the whole org to change the process in day one -
                it happens like SOA movement within the org to reach business goals.

                but are we doing this in every engagement? i bet not - atleast in
                service segment where many of the client engagements are won what
                unique things that we get on board to client like cost effecice
                solutions through open source tools, ability to delivery what we
                committed, better project visibility ( through agile)

                but more often the change is at client org where client don't seem to
                understnd agile way of doing things. from my exp, my client
                complained to us their involvement is increasingly getting higher
                every iteration due to the kind of feedback we get on deliverables.
                they are just annoyed of thier involvement as they thought, it's
                vendor resp to deliver - which is also true.

                I agree that we should go one team at a time - but what if we don't
                do the transition at root (customer approach towards agile and its
                commitment) - that would eventually doom to fail subsequnt
                opportunities. In a service industry where one should bring high
                competitive offering is questioned seriously when you can't delvier
                what you have committed.

                I like the approach which Pete said that we need to have some kind of
                mutual agreement or a contract put inplace upfront to have sort of
                MSA - master agreement!

                --- In Scrum-India@ yahoogroups. com, Vikrama Dhiman <vickydhiman@ ...>
                wrote:
                >
                > Hello Selvan:
                >
                > Transitioning to Agile is generally slow. Below assumes a "service
                industry" scenario.
                >
                > One of the mistakes you could do is converting whole organization
                at one go. What I'd recommend is going one team at a time [and let
                one team *really* get it]. Its difficult selling this to a management
                looking at quick fix solutions - but I think you'd get a better
                success by implementing it team by team.
                >
                > Some of the things you will need to keep in mind [would help]:
                >
                > Try and do the first projects in Scrum using time and materials
                basis and not fixed price [this is because welcoming change gets
                interpreted without the discipline aspect really sinking in at both
                the team and product owner end]
                > Try and use some XP engineering practices by the book
                > Do Scrum by the book
                > Have an on-site Scrum coach/ consultant
                > If you do want to do Scrum on a fixed price project, try and
                quote only for one release at a time and keep one release small
                enough to be able to estimate
                > Do it on a domain you are most comfortable with
                >
                > Hope that helps!
                >
                > Thanks
                >
                > Pete Deemer <petedeemer@ ...> wrote:
                Selvan, let's say another client came to you tomorrow, saying "we'd
                > like to try scrum". based on your lessons learned below, what are
                the
                > 5 (or however many you like) things on your checklist, that you
                would
                > want to make sure you did, to set you and your client up for
                success?
                > What I have in mind are very practical steps you could take.
                >
                > for example, I've seen some teams actually come up with a scrum
                > "contract" with the client. it's not really a contract, it's just
                a
                > piece of paper laying out the groundrules of how we're going to do
                > scrum, but it's really helpful in surfacing areas where the client
                > either "understand scrum differently" (the polite way to say it!)
                or
                > is unsure of whether they're going to be able to commit.
                obviously,
                > you have to be careful about this -- they're the client, after
                all --
                > so you want to make sure they understand you're doing this not to
                be
                > difficult or demanding, but because you want to see the project
                succeed.
                >
                > I'd love to hear what other people would put on their checklist,
                based
                > on their experiences. ..
                >
                > --p
                >
                > --- In Scrum-India@ yahoogroups. com, "Kalaiselvan" <selmaks@> wrote:
                > >
                > > All
                > > I welcome all to this forum and I personaly thank Pete for his
                > > initiative on this to bring all people together to discuss,
                debate on
                > > Agile dev.
                > >
                > > To share my experience, I've seen many people taling about Agile
                > > thinking that it's another software dev process like 'waterfall'
                and
                > > take it light to acknowledge that it's good and we will
                implement
                > > successfully etc while selling solutions to customer ( it could
                be
                > > internal/external) . That's a great misjudgement - or to be
                honest the
                > > person who claims so haven't understood the difficulty in making
                > > agile development success.
                > >
                > > yes it is indeed another dev process - but more matured, mor
                epainful
                > > to implement and requires lot of decipline.
                > >
                > > I've a bitter experience where I had tough changing the mindset
                of my
                > > client to transition to Agile though they have been following
                > > waterfall ( or some thier own way of doing things design-dev-
                test
                > > etc). In the end, we failed to show case the credibility of
                agile
                > > development ( it goes with many valid reasons but i think it's
                out of
                > > discussino here) and customer insisting going back to his dev
                > > process.
                > >
                > > lessons learned was
                > > 1. agile is not for every customer engagment / project
                > > 2. approach customer transition more transparent and better
                > > commitment and involvement from customer team (upper mgt from
                > > customer)
                > > 3. requires lot of decipline and no compramise on 'agile' way of
                > > doing things
                > > 4. need right people in the team who could understand and
                appreciate
                > > the value of doing in 'agile' way
                > > 5. technology choice to hande many aspects of agile dev (
                TDD,Pair
                > > programming, incremental design and dev etc)
                > > 6. proper role players upfront and commitment from project
                > > stakeholders
                > > 7. identify artifacts that are relevant upfront
                > > 8. enrichment of agile way of doing things which gives
                success.....
                > >
                > > Looking forward to others to share such experience here
                > >
                > > you are welcome ---- all the best!
                > >
                > > thanks
                > > Selvan
                > >
                >
                >
                >
                >
                >
                >
                > ------------ --------- --------- ---
                > Never miss a thing. Make Yahoo your homepage.
                >



                Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now.

              • suresh adina
                What I have noticed that most customers are afraid of terminology more than the process itself. So the moment you say ISO , CMMI , Agile or Scrum to
                Message 7 of 19 , Jan 10, 2008
                View Source
                • 0 Attachment
                  What I have noticed that most customers are afraid of "terminology" more than the process itself. So the moment you say "ISO", "CMMI", "Agile" or "Scrum" to customers they tend to go into defensive mode. In some way same is the case with team members when they are not clear on the impact.

                  So instead of going into the semantics of what to call it, start by explaining the methodology to be applied and the activities that will be done there of including their roles. Whether it is customer or team members, they need to see an inherent benefit to themselves and not just to the project, which is an " unseen" entity.

                  Customer involvement in the project at all stages is beneficial all around. This is specially so when the customer plays the role of reviewer throughout since the final outcome impacts their business and any modifications can be identified in early stages.

                  However, it is important to remember one key aspect. We should be careful to ensure that Customer does not become our QA or QC. It is more about acceptance as we progress with Sprints and direct visibility into progress of the project. As long as we take these precautions, I do not see how any customer would be "annoyed" about being involved.

                  Look forward to more of these discussions tomorrow.

                  Suresh A
                • Prabhakar Karve
                  Another area of annoyance to the customers that we have come across is the strict discipline of not accepting any changes once a sprint starts. They are so
                  Message 8 of 19 , Jan 10, 2008
                  View Source
                  • 0 Attachment
                    Another area of annoyance to the customers that we have come across
                    is the strict discipline of not accepting any changes once a sprint
                    starts. They are so used to the freedom and power of making changes
                    whenever they wish. Has anyone faced this problem? What is the best
                    way to deal with it other than insisting that Scrum requires it?

                    --- In Scrum-India@yahoogroups.com, "suresh adina" <asuresh18@...>
                    wrote:
                    >
                    > What I have noticed that most customers are afraid of "terminology"
                    more
                    > than the process itself. So the moment you
                    say "ISO", "CMMI", "Agile" or
                    > "Scrum" to customers they tend to go into defensive mode. In some
                    way same
                    > is the case with team members when they are not clear on the impact.
                    >
                    > So instead of going into the semantics of what to call it, start by
                    > explaining the methodology to be applied and the activities that
                    will be
                    > done there of including their roles. Whether it is customer or team
                    members,
                    > they need to see an inherent benefit to themselves and not just to
                    the
                    > project, which is an " unseen" entity.
                    >
                    > Customer involvement in the project at all stages is beneficial all
                    around.
                    > This is specially so when the customer plays the role of reviewer
                    throughout
                    > since the final outcome impacts their business and any
                    modifications can be
                    > identified in early stages.
                    >
                    > However, it is important to remember one key aspect. We should be
                    careful to
                    > ensure that Customer does not become our QA or QC. It is more about
                    > acceptance as we progress with Sprints and direct visibility into
                    progress
                    > of the project. As long as we take these precautions, I do not see
                    how any
                    > customer would be "annoyed" about being involved.
                    >
                    > Look forward to more of these discussions tomorrow.
                    >
                    > Suresh A
                    >
                  • Sharanya Vemu
                    This can be dealt with , by setting expectations right at the begining ,either in the Statement of work , by clearly mandating and laying out the ground rules,
                    Message 9 of 19 , Jan 10, 2008
                    View Source
                    • 0 Attachment
                      This can be dealt with , by setting expectations right at the begining ,either in the Statement of work , by clearly mandating and laying out the ground rules, if that was not done , one sure way of convincing the customer is to show him the disadvantages in the form of cost and showing a dollar figure
                       
                      Typically show him the cost of the sprint
                       
                      1 . > Repriroritizing cost  ( time spent in looking at the new change + loss of time because of this by not working on the current backlog )
                      2.>  Cost of shelving a feature to accomodate the new feature
                       
                      This should deter them , usually after the first couple of iterations the customer gets used to the practice

                      On Jan 11, 2008 11:54 AM, Prabhakar Karve <prkarve@...> wrote:

                      Another area of annoyance to the customers that we have come across
                      is the strict discipline of not accepting any changes once a sprint
                      starts. They are so used to the freedom and power of making changes
                      whenever they wish. Has anyone faced this problem? What is the best
                      way to deal with it other than insisting that Scrum requires it?

                      --- In Scrum-India@yahoogroups.com, "suresh adina" <asuresh18@...>
                      wrote:
                      >
                      > What I have noticed that most customers are afraid of "terminology"
                      more
                      > than the process itself. So the moment you
                      say "ISO", "CMMI", "Agile" or
                      > "Scrum" to customers they tend to go into defensive mode. In some
                      way same
                      > is the case with team members when they are not clear on the impact.
                      >
                      > So instead of going into the semantics of what to call it, start by
                      > explaining the methodology to be applied and the activities that
                      will be
                      > done there of including their roles. Whether it is customer or team
                      members,
                      > they need to see an inherent benefit to themselves and not just to
                      the
                      > project, which is an " unseen" entity.
                      >
                      > Customer involvement in the project at all stages is beneficial all
                      around.
                      > This is specially so when the customer plays the role of reviewer
                      throughout
                      > since the final outcome impacts their business and any
                      modifications can be
                      > identified in early stages.
                      >
                      > However, it is important to remember one key aspect. We should be
                      careful to
                      > ensure that Customer does not become our QA or QC. It is more about
                      > acceptance as we progress with Sprints and direct visibility into
                      progress
                      > of the project. As long as we take these precautions, I do not see
                      how any
                      > customer would be "annoyed" about being involved.
                      >
                      > Look forward to more of these discussions tomorrow.
                      >
                      > Suresh A
                      >


                    • sharadbn2003
                      First of all, I dont think this is Scrum probel. Scrum in any case allows any one to plan sprint only after a thorugh analysis and estimates. No one is
                      Message 10 of 19 , Jan 10, 2008
                      View Source
                      • 0 Attachment
                        First of all, I dont think this is Scrum probel. Scrum in any case
                        allows any one to plan sprint only after a thorugh analysis and
                        estimates. No one is commiting anything more than they can deliver.

                        Secondly, there is an estimation process which decided the quantum
                        of delievarbles for a sprint.

                        Thridly, there is always a provison to terminate the sprint if there
                        is so much chaos.

                        So, to sum up, it is against the Scrum philosophy to allow changes
                        dueing the sprint.

                        Regards

                        Sharad B Nalawade



                        --- In Scrum-India@yahoogroups.com, "Prabhakar Karve" <prkarve@...>
                        wrote:
                        >
                        > Another area of annoyance to the customers that we have come
                        across
                        > is the strict discipline of not accepting any changes once a
                        sprint
                        > starts. They are so used to the freedom and power of making
                        changes
                        > whenever they wish. Has anyone faced this problem? What is the
                        best
                        > way to deal with it other than insisting that Scrum requires it?
                        >
                        > --- In Scrum-India@yahoogroups.com, "suresh adina" <asuresh18@>
                        > wrote:
                        > >
                        > > What I have noticed that most customers are afraid
                        of "terminology"
                        > more
                        > > than the process itself. So the moment you
                        > say "ISO", "CMMI", "Agile" or
                        > > "Scrum" to customers they tend to go into defensive mode. In
                        some
                        > way same
                        > > is the case with team members when they are not clear on the
                        impact.
                        > >
                        > > So instead of going into the semantics of what to call it, start
                        by
                        > > explaining the methodology to be applied and the activities that
                        > will be
                        > > done there of including their roles. Whether it is customer or
                        team
                        > members,
                        > > they need to see an inherent benefit to themselves and not just
                        to
                        > the
                        > > project, which is an " unseen" entity.
                        > >
                        > > Customer involvement in the project at all stages is beneficial
                        all
                        > around.
                        > > This is specially so when the customer plays the role of
                        reviewer
                        > throughout
                        > > since the final outcome impacts their business and any
                        > modifications can be
                        > > identified in early stages.
                        > >
                        > > However, it is important to remember one key aspect. We should
                        be
                        > careful to
                        > > ensure that Customer does not become our QA or QC. It is more
                        about
                        > > acceptance as we progress with Sprints and direct visibility
                        into
                        > progress
                        > > of the project. As long as we take these precautions, I do not
                        see
                        > how any
                        > > customer would be "annoyed" about being involved.
                        > >
                        > > Look forward to more of these discussions tomorrow.
                        > >
                        > > Suresh A
                        > >
                        >
                      • Vikrama Dhiman
                        Implementing No Change Rules - seems to be a major areas of concern. All the Scrum practitioners I talk to, always have a problem with this [or with customers
                        Message 11 of 19 , Jan 10, 2008
                        View Source
                        • 0 Attachment
                          "Implementing No Change Rules - seems to be a major areas of concern. All the Scrum practitioners I talk to, always have a problem with this [or with customers not defining priorities or giving any feedback what so ever].

                          One reason is [at least with us] that mostly the time and materials projects have transitioned to Agile, and time and materials have had a history of almost ad-hoc, no tracking management, at least with us. Bringing in the discipline that Scrum imposes is hard enough for the teams in this case and on top of it to get clients to get used to it requires some effort. I think clients are insisting on making changes through out the sprint only when:
                          • They are not doing enough ground work for the sprint/ iteration
                          • There is lack of product owner role
                          • There are too many customer representatives - one managing previous release, one planning next release, one is customer liaison officer and blah blah
                          • They don't realize the loss of business value of stability in a sprint
                          • Sprints are too long
                          We are still struggling in coming to terms with this. Hence, any ideas and thoughts would be really useful.

                          sharadbn2003 <sharadbn@...> wrote:
                          First of all, I dont think this is Scrum probel. Scrum in any case
                          allows any one to plan sprint only after a thorugh analysis and
                          estimates. No one is commiting anything more than they can deliver.

                          Secondly, there is an estimation process which decided the quantum
                          of delievarbles for a sprint.

                          Thridly, there is always a provison to terminate the sprint if there
                          is so much chaos.

                          So, to sum up, it is against the Scrum philosophy to allow changes
                          dueing the sprint.

                          Regards

                          Sharad B Nalawade

                          --- In Scrum-India@ yahoogroups. com, "Prabhakar Karve" <prkarve@... >
                          wrote:
                          >
                          > Another area of annoyance to the customers that we have come
                          across
                          > is the strict discipline of not accepting any changes once a
                          sprint
                          > starts. They are so used to the freedom and power of making
                          changes
                          > whenever they wish. Has anyone faced this problem? What is the
                          best
                          > way to deal with it other than insisting that Scrum requires it?
                          >
                          > --- In Scrum-India@ yahoogroups. com, "suresh adina" <asuresh18@>
                          > wrote:
                          > >
                          > > What I have noticed that most customers are afraid
                          of "terminology"
                          > more
                          > > than the process itself. So the moment you
                          > say "ISO", "CMMI", "Agile" or
                          > > "Scrum" to customers they tend to go into defensive mode. In
                          some
                          > way same
                          > > is the case with team members when they are not clear on the
                          impact.
                          > >
                          > > So instead of going into the semantics of what to call it, start
                          by
                          > > explaining the methodology to be applied and the activities that
                          > will be
                          > > done there of including their roles. Whether it is customer or
                          team
                          > members,
                          > > they need to see an inherent benefit to themselves and not just
                          to
                          > the
                          > > project, which is an " unseen" entity.
                          > >
                          > > Customer involvement in the project at all stages is beneficial
                          all
                          > around.
                          > > This is specially so when the customer plays the role of
                          reviewer
                          > throughout
                          > > since the final outcome impacts their business and any
                          > modifications can be
                          > > identified in early stages.
                          > >
                          > > However, it is important to remember one key aspect. We should
                          be
                          > careful to
                          > > ensure that Customer does not become our QA or QC. It is more
                          about
                          > > acceptance as we progress with Sprints and direct visibility
                          into
                          > progress
                          > > of the project. As long as we take these precautions, I do not
                          see
                          > how any
                          > > customer would be "annoyed" about being involved.
                          > >
                          > > Look forward to more of these discussions tomorrow.
                          > >
                          > > Suresh A
                          > >
                          >



                          Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now.

                        • Jay Mehta
                          Implementing No Change in SCRUM process. I gree with Vikram, there no fullhearted effort in sprint planning which results lots of chaos even in Sprint. I have
                          Message 12 of 19 , Jan 11, 2008
                          View Source
                          • 0 Attachment
                            Implementing No Change in SCRUM process. I gree with Vikram, there no fullhearted effort in sprint planning which results lots of chaos even in Sprint. I have seen in Indian scenario where Scrum Master, Product Owner have even terminated STORY in Sprint and not the Sprint. Most of the professional has either not understood the concept of SCRUM or they are taking advantage for the flexibility in the apporach or having double standards in the following the process.
                             


                            Vikrama Dhiman <vickydhiman@...> wrote:
                            "Implementing No Change Rules - seems to be a major areas of concern. All the Scrum practitioners I talk to, always have a problem with this [or with customers not defining priorities or giving any feedback what so ever].

                            One reason is [at least with us] that mostly the time and materials projects have transitioned to Agile, and time and materials have had a history of almost ad-hoc, no tracking management, at least with us. Bringing in the discipline that Scrum imposes is hard enough for the teams in this case and on top of it to get clients to get used to it requires some effort. I think clients are insisting on making changes through out the sprint only when:
                            • They are not doing enough ground work for the sprint/ iteration
                            • There is lack of product owner role
                            • There are too many customer representatives - one managing previous release, one planning next release, one is customer liaison officer and blah blah
                            • They don't realize the loss of business value of stability in a sprint
                            • Sprints are too long
                            We are still struggling in coming to terms with this. Hence, any ideas and thoughts would be really useful.

                            sharadbn2003 <sharadbn@gmail. com> wrote:
                            First of all, I dont think this is Scrum probel. Scrum in any case
                            allows any one to plan sprint only after a thorugh analysis and
                            estimates. No one is commiting anything more than they can deliver.

                            Secondly, there is an estimation process which decided the quantum
                            of delievarbles for a sprint.

                            Thridly, there is always a provison to terminate the sprint if there
                            is so much chaos.

                            So, to sum up, it is against the Scrum philosophy to allow changes
                            dueing the sprint.

                            Regards

                            Sharad B Nalawade

                            --- In Scrum-India@ yahoogroups. com, "Prabhakar Karve" <prkarve@... >
                            wrote:
                            >
                            > Another area of annoyance to the customers that we have come
                            across
                            > is the strict discipline of not accepting any changes once a
                            sprint
                            > starts. They are so used to the freedom and power of making
                            changes
                            > whenever they wish. Has anyone faced this problem? What is the
                            best
                            > way to deal with it other than insisting that Scrum requires it?
                            >
                            > --- In Scrum-India@ yahoogroups. com, "suresh adina" <asuresh18@>
                            > wrote:
                            > >
                            > > What I have noticed that most customers are afraid
                            of "terminology"
                            > more
                            > > than the process itself. So the moment you
                            > say "ISO", "CMMI", "Agile" or
                            > > "Scrum" to customers they tend to go into defensive mode. In
                            some
                            > way same
                            > > is the case with team members when they are not clear on the
                            impact.
                            > >
                            > > So instead of going into the semantics of what to call it, start
                            by
                            > > explaining the methodology to be applied and the activities that
                            > will be
                            > > done there of including their roles. Whether it is customer or
                            team
                            > members,
                            > > they need to see an inherent benefit to themselves and not just
                            to
                            > the
                            > > project, which is an " unseen" entity.
                            > >
                            > > Customer involvement in the project at all stages is beneficial
                            all
                            > around.
                            > > This is specially so when the customer plays the role of
                            reviewer
                            > throughout
                            > > since the final outcome impacts their business and any
                            > modifications can be
                            > > identified in early stages.
                            > >
                            > > However, it is important to remember one key aspect. We should
                            be
                            > careful to
                            > > ensure that Customer does not become our QA or QC. It is more
                            about
                            > > acceptance as we progress with Sprints and direct visibility
                            into
                            > progress
                            > > of the project. As long as we take these precautions, I do not
                            see
                            > how any
                            > > customer would be "annoyed" about being involved.
                            > >
                            > > Look forward to more of these discussions tomorrow.
                            > >
                            > > Suresh A
                            > >
                            >



                            Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now.


                            Never miss a thing. Make Yahoo your homepage.

                          • Pete Deemer
                            Yeah, I see this a lot as well. Client demands a change during the Sprint, team is forced to say yes. This makes client think I can make changes anytime ,
                            Message 13 of 19 , Jan 11, 2008
                            View Source
                            • 0 Attachment
                              Yeah, I see this a lot as well. Client demands a change during the
                              Sprint, team is forced to say yes. This makes client think "I can make
                              changes anytime", which makes them less disciplined about preparing
                              their Backlog for the Sprint Planning Meeting, which then causes MORE
                              change requests during the Sprint. Team never gets to 100% done by the
                              end of a Sprint, they feel stressed out all the time, and their software
                              is full of defects. Eventually, this may cause them to abandon Scrum.
                              The high degree of flexibility Scrum gives the Product Owner (ability to
                              change the backlog at the start of every Sprint) comes at a cost: the
                              team has to be protected from change during the Sprint, if you want them
                              to achieve anything.

                              One thing I strongly recommend is trying shorter Sprints. 30 days is
                              longer than most clients can wait to make new requests. But you may be
                              able to convince them to wait 2 weeks, or if not then 1 week. You can
                              try it for a Sprint or two and see if it helps.

                              Here's an idea. What if we got together as a community, and wrote
                              (using a wiki perhaps) a short article called "advice for clients about
                              using Scrum / Do's and Don'ts", that says all the things we'd like to
                              say to them but can't -- which we could then point clients about at the
                              start of a scrum project?

                              --Pete

                              Jay Mehta wrote:
                              > Implementing No Change in SCRUM process. I gree with Vikram, there no
                              > fullhearted effort in sprint planning which results lots of chaos even
                              > in Sprint. I have seen in Indian scenario where Scrum Master, Product
                              > Owner have even terminated STORY in Sprint and not the Sprint. Most of
                              > the professional has either not understood the concept of SCRUM or
                              > they are taking advantage for the flexibility in the apporach or
                              > having double standards in the following the process.
                              >
                              >
                              >
                              > */Vikrama Dhiman <vickydhiman@...>/* wrote:
                              >
                              > "Implementing No Change Rules - seems to be a major areas of
                              > concern. All the Scrum practitioners I talk to, always have a
                              > problem with this [or with customers not defining priorities or
                              > giving any feedback what so ever].
                              >
                              > One reason is [at least with us] that mostly the time and
                              > materials projects have transitioned to Agile, and time and
                              > materials have had a history of almost ad-hoc, no tracking
                              > management, at least with us. Bringing in the discipline that
                              > Scrum imposes is hard enough for the teams in this case and on top
                              > of it to get clients to get used to it requires some effort. I
                              > think clients are insisting on making changes through out the
                              > sprint only when:
                              >
                              > * They are not doing enough ground work for the sprint/ iteration
                              > * There is lack of product owner role
                              > * There are too many customer representatives - one managing
                              > previous release, one planning next release, one is customer
                              > liaison officer and blah blah
                              > * They don't realize the loss of business value of stability
                              > in a sprint
                              > * Sprints are too long
                              >
                              > We are still struggling in coming to terms with this. Hence, any
                              > ideas and thoughts would be really useful.
                              >
                              > */sharadbn2003 <sharadbn@...>/* wrote:
                              >
                              > First of all, I dont think this is Scrum probel. Scrum in any
                              > case
                              > allows any one to plan sprint only after a thorugh analysis and
                              > estimates. No one is commiting anything more than they can
                              > deliver.
                              >
                              > Secondly, there is an estimation process which decided the
                              > quantum
                              > of delievarbles for a sprint.
                              >
                              > Thridly, there is always a provison to terminate the sprint if
                              > there
                              > is so much chaos.
                              >
                              > So, to sum up, it is against the Scrum philosophy to allow
                              > changes
                              > dueing the sprint.
                              >
                              > Regards
                              >
                              > Sharad B Nalawade
                              >
                              > --- In Scrum-India@yahoogroups.com
                              > <mailto:Scrum-India%40yahoogroups.com>, "Prabhakar Karve"
                              > <prkarve@...>
                              > wrote:
                              > >
                              > > Another area of annoyance to the customers that we have come
                              > across
                              > > is the strict discipline of not accepting any changes once a
                              > sprint
                              > > starts. They are so used to the freedom and power of making
                              > changes
                              > > whenever they wish. Has anyone faced this problem? What is the
                              > best
                              > > way to deal with it other than insisting that Scrum requires it?
                              > >
                              > > --- In Scrum-India@yahoogroups.com
                              > <mailto:Scrum-India%40yahoogroups.com>, "suresh adina"
                              > <asuresh18@>
                              > > wrote:
                              > > >
                              > > > What I have noticed that most customers are afraid
                              > of "terminology"
                              > > more
                              > > > than the process itself. So the moment you
                              > > say "ISO", "CMMI", "Agile" or
                              > > > "Scrum" to customers they tend to go into defensive mode. In
                              > some
                              > > way same
                              > > > is the case with team members when they are not clear on the
                              > impact.
                              > > >
                              > > > So instead of going into the semantics of what to call it,
                              > start
                              > by
                              > > > explaining the methodology to be applied and the
                              > activities that
                              > > will be
                              > > > done there of including their roles. Whether it is
                              > customer or
                              > team
                              > > members,
                              > > > they need to see an inherent benefit to themselves and not
                              > just
                              > to
                              > > the
                              > > > project, which is an " unseen" entity.
                              > > >
                              > > > Customer involvement in the project at all stages is
                              > beneficial
                              > all
                              > > around.
                              > > > This is specially so when the customer plays the role of
                              > reviewer
                              > > throughout
                              > > > since the final outcome impacts their business and any
                              > > modifications can be
                              > > > identified in early stages.
                              > > >
                              > > > However, it is important to remember one key aspect. We
                              > should
                              > be
                              > > careful to
                              > > > ensure that Customer does not become our QA or QC. It is more
                              > about
                              > > > acceptance as we progress with Sprints and direct visibility
                              > into
                              > > progress
                              > > > of the project. As long as we take these precautions, I do
                              > not
                              > see
                              > > how any
                              > > > customer would be "annoyed" about being involved.
                              > > >
                              > > > Look forward to more of these discussions tomorrow.
                              > > >
                              > > > Suresh A
                              > > >
                              > >
                              >
                              >
                              > ------------------------------------------------------------------------
                              > Be a better friend, newshound, and know-it-all with Yahoo! Mobile.
                              > Try it now.
                              > <http://us.rd.yahoo.com/evt=51733/*http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ>
                              >
                              >
                              >
                              > ------------------------------------------------------------------------
                              > Never miss a thing. Make Yahoo your homepage.
                              > <http://us.rd.yahoo.com/evt=51438/*http://www.yahoo.com/r/hs>
                              >
                            • Vikrama Dhiman
                              ... (using a wiki perhaps) a short article called advice for clients about using Scrum / Do s and Don ts , that says all the things we d like to say to them
                              Message 14 of 19 , Jan 11, 2008
                              View Source
                              • 0 Attachment
                                >>What if we got together as a community, and wrote
                                (using a wiki perhaps) a short article called "advice for clients about
                                using Scrum / Do's and Don'ts", that says all the things we'd like to
                                say to them but can't -- which we could then point clients about at the
                                start of a scrum project?

                                Fantastic Idea!

                                We could have two Wikis actually, one for clients [what they wanted to tell the team from a Scrum Do's/ Dont's perspective] and one for the teams wanting to tell the clients. However, in true Scrum fashion - at present, lets focus on the latter one only at present. :)

                                Who would be creating it? Maybe we could have a Scrum India Wiki.

                                Pete Deemer <petedeemer@...> wrote:
                                Yeah, I see this a lot as well. Client demands a change during the
                                Sprint, team is forced to say yes. This makes client think "I can make
                                changes anytime", which makes them less disciplined about preparing
                                their Backlog for the Sprint Planning Meeting, which then causes MORE
                                change requests during the Sprint. Team never gets to 100% done by the
                                end of a Sprint, they feel stressed out all the time, and their software
                                is full of defects. Eventually, this may cause them to abandon Scrum.
                                The high degree of flexibility Scrum gives the Product Owner (ability to
                                change the backlog at the start of every Sprint) comes at a cost: the
                                team has to be protected from change during the Sprint, if you want them
                                to achieve anything.

                                One thing I strongly recommend is trying shorter Sprints. 30 days is
                                longer than most clients can wait to make new requests. But you may be
                                able to convince them to wait 2 weeks, or if not then 1 week. You can
                                try it for a Sprint or two and see if it helps.

                                Here's an idea. What if we got together as a community, and wrote
                                (using a wiki perhaps) a short article called "advice for clients about
                                using Scrum / Do's and Don'ts", that says all the things we'd like to
                                say to them but can't -- which we could then point clients about at the
                                start of a scrum project?

                                --Pete

                                Jay Mehta wrote:
                                > Implementing No Change in SCRUM process. I gree with Vikram, there no
                                > fullhearted effort in sprint planning which results lots of chaos even
                                > in Sprint. I have seen in Indian scenario where Scrum Master, Product
                                > Owner have even terminated STORY in Sprint and not the Sprint. Most of
                                > the professional has either not understood the concept of SCRUM or
                                > they are taking advantage for the flexibility in the apporach or
                                > having double standards in the following the process.
                                >
                                >
                                >
                                > */Vikrama Dhiman <vickydhiman@ yahoo.com>/* wrote:
                                >
                                > "Implementing No Change Rules - seems to be a major areas of
                                > concern. All the Scrum practitioners I talk to, always have a
                                > problem with this [or with customers not defining priorities or
                                > giving any feedback what so ever].
                                >
                                > One reason is [at least with us] that mostly the time and
                                > materials projects have transitioned to Agile, and time and
                                > materials have had a history of almost ad-hoc, no tracking
                                > management, at least with us. Bringing in the discipline that
                                > Scrum imposes is hard enough for the teams in this case and on top
                                > of it to get clients to get used to it requires some effort. I
                                > think clients are insisting on making changes through out the
                                > sprint only when:
                                >
                                > * They are not doing enough ground work for the sprint/ iteration
                                > * There is lack of product owner role
                                > * There are too many customer representatives - one managing
                                > previous release, one planning next release, one is customer
                                > liaison officer and blah blah
                                > * They don't realize the loss of business value of stability
                                > in a sprint
                                > * Sprints are too long
                                >
                                > We are still struggling in coming to terms with this. Hence, any
                                > ideas and thoughts would be really useful.
                                >
                                > */sharadbn2003 <sharadbn@gmail. com>/* wrote:
                                >
                                > First of all, I dont think this is Scrum probel. Scrum in any
                                > case
                                > allows any one to plan sprint only after a thorugh analysis and
                                > estimates. No one is commiting anything more than they can
                                > deliver.
                                >
                                > Secondly, there is an estimation process which decided the
                                > quantum
                                > of delievarbles for a sprint.
                                >
                                > Thridly, there is always a provison to terminate the sprint if
                                > there
                                > is so much chaos.
                                >
                                > So, to sum up, it is against the Scrum philosophy to allow
                                > changes
                                > dueing the sprint.
                                >
                                > Regards
                                >
                                > Sharad B Nalawade
                                >
                                > --- In Scrum-India@ yahoogroups. com
                                > <mailto:Scrum- India%40yahoogro ups.com>, "Prabhakar Karve"
                                > <prkarve@... >
                                > wrote:
                                > >
                                > > Another area of annoyance to the customers that we have come
                                > across
                                > > is the strict discipline of not accepting any changes once a
                                > sprint
                                > > starts. They are so used to the freedom and power of making
                                > changes
                                > > whenever they wish. Has anyone faced this problem? What is the
                                > best
                                > > way to deal with it other than insisting that Scrum requires it?
                                > >
                                > > --- In Scrum-India@ yahoogroups. com
                                > <mailto:Scrum- India%40yahoogro ups.com>, "suresh adina"
                                > <asuresh18@>
                                > > wrote:
                                > > >
                                > > > What I have noticed that most customers are afraid
                                > of "terminology"
                                > > more
                                > > > than the process itself. So the moment you
                                > > say "ISO", "CMMI", "Agile" or
                                > > > "Scrum" to customers they tend to go into defensive mode. In
                                > some
                                > > way same
                                > > > is the case with team members when they are not clear on the
                                > impact.
                                > > >
                                > > > So instead of going into the semantics of what to call it,
                                > start
                                > by
                                > > > explaining the methodology to be applied and the
                                > activities that
                                > > will be
                                > > > done there of including their roles. Whether it is
                                > customer or
                                > team
                                > > members,
                                > > > they need to see an inherent benefit to themselves and not
                                > just
                                > to
                                > > the
                                > > > project, which is an " unseen" entity.
                                > > >
                                > > > Customer involvement in the project at all stages is
                                > beneficial
                                > all
                                > > around.
                                > > > This is specially so when the customer plays the role of
                                > reviewer
                                > > throughout
                                > > > since the final outcome impacts their business and any
                                > > modifications can be
                                > > > identified in early stages.
                                > > >
                                > > > However, it is important to remember one key aspect. We
                                > should
                                > be
                                > > careful to
                                > > > ensure that Customer does not become our QA or QC. It is more
                                > about
                                > > > acceptance as we progress with Sprints and direct visibility
                                > into
                                > > progress
                                > > > of the project. As long as we take these precautions, I do
                                > not
                                > see
                                > > how any
                                > > > customer would be "annoyed" about being involved.
                                > > >
                                > > > Look forward to more of these discussions tomorrow.
                                > > >
                                > > > Suresh A
                                > > >
                                > >
                                >
                                >
                                > ------------ --------- --------- --------- --------- --------- -
                                > Be a better friend, newshound, and know-it-all with Yahoo! Mobile.
                                > Try it now.
                                > <http://us.rd. yahoo.com/ evt=51733/ *http://mobile. yahoo.com/ ;_ylt=Ahu06i62sR 8HDtDypao8Wcj9tA cJ>
                                >
                                >
                                >
                                > ------------ --------- --------- --------- --------- --------- -
                                > Never miss a thing. Make Yahoo your homepage.
                                > <http://us.rd. yahoo.com/ evt=51438/ *http://www. yahoo.com/ r/hs>
                                >



                                Never miss a thing. Make Yahoo your homepage.

                              • Pete Deemer
                                scrum-india wiki... cool! is there anyone in the group with a burning passion on the topic below, who d like to volunteer to set up the wiki and facilitate
                                Message 15 of 19 , Jan 12, 2008
                                View Source
                                • 0 Attachment
                                  scrum-india wiki... cool!

                                  is there anyone in the group with a burning passion on the topic below,
                                  who'd like to volunteer to set up the wiki and facilitate creating the
                                  lists? whoever volunteers first gets it...

                                  Vikrama Dhiman wrote:
                                  >
                                  > >>What if we got together as a community, and wrote
                                  > (using a wiki perhaps) a short article called "advice for clients about
                                  > using Scrum / Do's and Don'ts", that says all the things we'd like to
                                  > say to them but can't -- which we could then point clients about at the
                                  > start of a scrum project?
                                  >
                                  > Fantastic Idea!
                                  >
                                  > We could have two Wikis actually, one for clients [what they wanted to
                                  > tell the team from a Scrum Do's/ Dont's perspective] and one for the
                                  > teams wanting to tell the clients. However, in true Scrum fashion - at
                                  > present, lets focus on the latter one only at present. :)
                                  >
                                  > Who would be creating it? Maybe we could have a Scrum India Wiki.
                                  >
                                  > */Pete Deemer <petedeemer@...>/* wrote:
                                  >
                                  > Yeah, I see this a lot as well. Client demands a change during the
                                  > Sprint, team is forced to say yes. This makes client think "I can
                                  > make
                                  > changes anytime", which makes them less disciplined about preparing
                                  > their Backlog for the Sprint Planning Meeting, which then causes MORE
                                  > change requests during the Sprint. Team never gets to 100% done by
                                  > the
                                  > end of a Sprint, they feel stressed out all the time, and their
                                  > software
                                  > is full of defects. Eventually, this may cause them to abandon Scrum.
                                  > The high degree of flexibility Scrum gives the Product Owner
                                  > (ability to
                                  > change the backlog at the start of every Sprint) comes at a cost: the
                                  > team has to be protected from change during the Sprint, if you
                                  > want them
                                  > to achieve anything.
                                  >
                                  > One thing I strongly recommend is trying shorter Sprints. 30 days is
                                  > longer than most clients can wait to make new requests. But you
                                  > may be
                                  > able to convince them to wait 2 weeks, or if not then 1 week. You can
                                  > try it for a Sprint or two and see if it helps.
                                  >
                                  > Here's an idea. What if we got together as a community, and wrote
                                  > (using a wiki perhaps) a short article called "advice for clients
                                  > about
                                  > using Scrum / Do's and Don'ts", that says all the things we'd like to
                                  > say to them but can't -- which we could then point clients about
                                  > at the
                                  > start of a scrum project?
                                  >
                                  > --Pete
                                  >
                                  > Jay Mehta wrote:
                                  > > Implementing No Change in SCRUM process. I gree with Vikram,
                                  > there no
                                  > > fullhearted effort in sprint planning which results lots of
                                  > chaos even
                                  > > in Sprint. I have seen in Indian scenario where Scrum Master,
                                  > Product
                                  > > Owner have even terminated STORY in Sprint and not the Sprint.
                                  > Most of
                                  > > the professional has either not understood the concept of SCRUM or
                                  > > they are taking advantage for the flexibility in the apporach or
                                  > > having double standards in the following the process.
                                  > >
                                  > >
                                  > >
                                  > > */Vikrama Dhiman <vickydhiman@...
                                  > <mailto:vickydhiman%40yahoo.com>>/* wrote:
                                  > >
                                  > > "Implementing No Change Rules - seems to be a major areas of
                                  > > concern. All the Scrum practitioners I talk to, always have a
                                  > > problem with this [or with customers not defining priorities or
                                  > > giving any feedback what so ever].
                                  > >
                                  > > One reason is [at least with us] that mostly the time and
                                  > > materials projects have transitioned to Agile, and time and
                                  > > materials have had a history of almost ad-hoc, no tracking
                                  > > management, at least with us. Bringing in the discipline that
                                  > > Scrum imposes is hard enough for the teams in this case and on top
                                  > > of it to get clients to get used to it requires some effort. I
                                  > > think clients are insisting on making changes through out the
                                  > > sprint only when:
                                  > >
                                  > > * They are not doing enough ground work for the sprint/ iteration
                                  > > * There is lack of product owner role
                                  > > * There are too many customer representatives - one managing
                                  > > previous release, one planning next release, one is customer
                                  > > liaison officer and blah blah
                                  > > * They don't realize the loss of business value of stability
                                  > > in a sprint
                                  > > * Sprints are too long
                                  > >
                                  > > We are still struggling in coming to terms with this. Hence, any
                                  > > ideas and thoughts would be really useful.
                                  > >
                                  > > */sharadbn2003 <sharadbn@...
                                  > <mailto:sharadbn%40gmail.com>>/* wrote:
                                  > >
                                  > > First of all, I dont think this is Scrum probel. Scrum in any
                                  > > case
                                  > > allows any one to plan sprint only after a thorugh analysis and
                                  > > estimates. No one is commiting anything more than they can
                                  > > deliver.
                                  > >
                                  > > Secondly, there is an estimation process which decided the
                                  > > quantum
                                  > > of delievarbles for a sprint.
                                  > >
                                  > > Thridly, there is always a provison to terminate the sprint if
                                  > > there
                                  > > is so much chaos.
                                  > >
                                  > > So, to sum up, it is against the Scrum philosophy to allow
                                  > > changes
                                  > > dueing the sprint.
                                  > >
                                  > > Regards
                                  > >
                                  > > Sharad B Nalawade
                                  > >
                                  > > --- In Scrum-India@yahoogroups.com
                                  > <mailto:Scrum-India%40yahoogroups.com>
                                  > > <mailto:Scrum-India%40yahoogroups.com>, "Prabhakar Karve"
                                  > > <prkarve@...>
                                  > > wrote:
                                  > > >
                                  > > > Another area of annoyance to the customers that we have come
                                  > > across
                                  > > > is the strict discipline of not accepting any changes once a
                                  > > sprint
                                  > > > starts. They are so used to the freedom and power of making
                                  > > changes
                                  > > > whenever they wish. Has anyone faced this problem? What is the
                                  > > best
                                  > > > way to deal with it other than insisting that Scrum requires it?
                                  > > >
                                  > > > --- In Scrum-India@yahoogroups.com
                                  > <mailto:Scrum-India%40yahoogroups.com>
                                  > > <mailto:Scrum-India%40yahoogroups.com>, "suresh adina"
                                  > > <asuresh18@>
                                  > > > wrote:
                                  > > > >
                                  > > > > What I have noticed that most customers are afraid
                                  > > of "terminology"
                                  > > > more
                                  > > > > than the process itself. So the moment you
                                  > > > say "ISO", "CMMI", "Agile" or
                                  > > > > "Scrum" to customers they tend to go into defensive mode. In
                                  > > some
                                  > > > way same
                                  > > > > is the case with team members when they are not clear on the
                                  > > impact.
                                  > > > >
                                  > > > > So instead of going into the semantics of what to call it,
                                  > > start
                                  > > by
                                  > > > > explaining the methodology to be applied and the
                                  > > activities that
                                  > > > will be
                                  > > > > done there of including their roles. Whether it is
                                  > > customer or
                                  > > team
                                  > > > members,
                                  > > > > they need to see an inherent benefit to themselves and not
                                  > > just
                                  > > to
                                  > > > the
                                  > > > > project, which is an " unseen" entity.
                                  > > > >
                                  > > > > Customer involvement in the project at all stages is
                                  > > beneficial
                                  > > all
                                  > > > around.
                                  > > > > This is specially so when the customer plays the role of
                                  > > reviewer
                                  > > > throughout
                                  > > > > since the final outcome impacts their business and any
                                  > > > modifications can be
                                  > > > > identified in early stages.
                                  > > > >
                                  > > > > However, it is important to remember one key aspect. We
                                  > > should
                                  > > be
                                  > > > careful to
                                  > > > > ensure that Customer does not become our QA or QC. It is more
                                  > > about
                                  > > > > acceptance as we progress with Sprints and direct visibility
                                  > > into
                                  > > > progress
                                  > > > > of the project. As long as we take these precautions, I do
                                  > > not
                                  > > see
                                  > > > how any
                                  > > > > customer would be "annoyed" about being involved.
                                  > > > >
                                  > > > > Look forward to more of these discussions tomorrow.
                                  > > > >
                                  > > > > Suresh A
                                  > > > >
                                  > > >
                                  > >
                                  > >
                                  > > ----------------------------------------------------------
                                  > > Be a better friend, newshound, and know-it-all with Yahoo! Mobile.
                                  > > Try it now.
                                  > >
                                  > <http://us.rd.yahoo.com/evt=51733/*http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
                                  > <http://us.rd.yahoo.com/evt=51733/*http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ>>
                                  > >
                                  > >
                                  > >
                                  > > ----------------------------------------------------------
                                  > > Never miss a thing. Make Yahoo your homepage.
                                  > > <http://us.rd.yahoo.com/evt=51438/*http://www.yahoo.com/r/hs
                                  > <http://us.rd.yahoo.com/evt=51438/*http://www.yahoo.com/r/hs>>
                                  > >
                                  >
                                  >
                                  > ------------------------------------------------------------------------
                                  > Never miss a thing. Make Yahoo your homepage.
                                  > <http://us.rd.yahoo.com/evt=51438/*http://www.yahoo.com/r/hs>
                                  >
                                • suresh adina
                                  Scrum or otherwise, changes are difficult to handle and greatly impact project performance in terms of time, cost and quality. While providing the flexibility
                                  Message 16 of 19 , Jan 13, 2008
                                  View Source
                                  • 0 Attachment
                                    Scrum or otherwise, changes are difficult to handle and greatly impact project performance in terms of time, cost and quality. While providing the flexibility to customer to accommodate changes in the project, we need to maintain the disciple of "no changes" during Sprint.

                                    I agree with Sharanya, that key aspect is going to be stake holder management, with customer being the key stake holder. This is absolutely required even if not following Scrum. I have seen too many projects run into trouble even with formal requirements documents signed off. This is because, while the project requirements are understood, the customer expectations are not. So better to start communicating with customer from day one. I would even go to the extant of suggesting over-communicating at the beginning of an engagement and slowly taper off as the project progresses. Explain to the customer that you would require their support at the start of the project to avoid any mistakes that may prove to be very expensive at a later stage. Care should be taken that a 'dependency' is not perceived. So effective communication is critical.

                                    One key point that Scrum has highlighted is that communication levels are quite poor amongst project teams in India. This needs to be worked on very carefully, since now every team member has to communicate on a regular basis.

                                    Suresh A


                                  • enigma76_in
                                    I wonder if Scrum is the right methodology to be used in this scenario. Scrum is a Project management methodology! IMO, T&M engagements are not projects in
                                    Message 17 of 19 , Mar 11, 2008
                                    View Source
                                    • 0 Attachment
                                      I wonder if Scrum is the right methodology to be used in this
                                      scenario. Scrum is a "Project" management methodology! IMO, T&M
                                      engagements are not projects in the 1st place. Its more
                                      ticket/request based work that is done. A proper queue management
                                      methodology like Kanban is more suited for such kind of work.

                                      Any comments?

                                      regards,

                                      Ashish

                                      --- In Scrum-India@yahoogroups.com, Vikrama Dhiman <vickydhiman@...>
                                      wrote:
                                      >
                                      > "Implementing No Change Rules - seems to be a major areas of
                                      concern. All the Scrum practitioners I talk to, always have a problem
                                      with this [or with customers not defining priorities or giving any
                                      feedback what so ever].
                                      >
                                      > One reason is [at least with us] that mostly the time and materials
                                      projects have transitioned to Agile, and time and materials have had
                                      a history of almost ad-hoc, no tracking management, at least with us.
                                      Bringing in the discipline that Scrum imposes is hard enough for the
                                      teams in this case and on top of it to get clients to get used to it
                                      requires some effort. I think clients are insisting on making changes
                                      through out the sprint only when:
                                      >
                                      > They are not doing enough ground work for the sprint/ iteration
                                      > There is lack of product owner role
                                      >
                                      > There are too many customer representatives - one managing
                                      previous release, one planning next release, one is customer liaison
                                      officer and blah blah
                                      >
                                      > They don't realize the loss of business value of stability in a
                                      sprint
                                      >
                                      > Sprints are too long
                                      >
                                      > We are still struggling in coming to terms with this. Hence, any
                                      ideas and thoughts would be really useful.
                                      >
                                      > sharadbn2003 <sharadbn@...> wrote:
                                      First of all, I dont think this is Scrum probel. Scrum in any case
                                      > allows any one to plan sprint only after a thorugh analysis and
                                      > estimates. No one is commiting anything more than they can
                                      deliver.
                                      >
                                      > Secondly, there is an estimation process which decided the quantum
                                      > of delievarbles for a sprint.
                                      >
                                      > Thridly, there is always a provison to terminate the sprint if
                                      there
                                      > is so much chaos.
                                      >
                                      > So, to sum up, it is against the Scrum philosophy to allow changes
                                      > dueing the sprint.
                                      >
                                      > Regards
                                      >
                                      > Sharad B Nalawade
                                      >
                                      > --- In Scrum-India@yahoogroups.com, "Prabhakar Karve" <prkarve@>
                                      > wrote:
                                      > >
                                      > > Another area of annoyance to the customers that we have come
                                      > across
                                      > > is the strict discipline of not accepting any changes once a
                                      > sprint
                                      > > starts. They are so used to the freedom and power of making
                                      > changes
                                      > > whenever they wish. Has anyone faced this problem? What is the
                                      > best
                                      > > way to deal with it other than insisting that Scrum requires it?
                                      > >
                                      > > --- In Scrum-India@yahoogroups.com, "suresh adina" <asuresh18@>
                                      > > wrote:
                                      > > >
                                      > > > What I have noticed that most customers are afraid
                                      > of "terminology"
                                      > > more
                                      > > > than the process itself. So the moment you
                                      > > say "ISO", "CMMI", "Agile" or
                                      > > > "Scrum" to customers they tend to go into defensive mode. In
                                      > some
                                      > > way same
                                      > > > is the case with team members when they are not clear on the
                                      > impact.
                                      > > >
                                      > > > So instead of going into the semantics of what to call it,
                                      start
                                      > by
                                      > > > explaining the methodology to be applied and the activities
                                      that
                                      > > will be
                                      > > > done there of including their roles. Whether it is customer or
                                      > team
                                      > > members,
                                      > > > they need to see an inherent benefit to themselves and not
                                      just
                                      > to
                                      > > the
                                      > > > project, which is an " unseen" entity.
                                      > > >
                                      > > > Customer involvement in the project at all stages is
                                      beneficial
                                      > all
                                      > > around.
                                      > > > This is specially so when the customer plays the role of
                                      > reviewer
                                      > > throughout
                                      > > > since the final outcome impacts their business and any
                                      > > modifications can be
                                      > > > identified in early stages.
                                      > > >
                                      > > > However, it is important to remember one key aspect. We should
                                      > be
                                      > > careful to
                                      > > > ensure that Customer does not become our QA or QC. It is more
                                      > about
                                      > > > acceptance as we progress with Sprints and direct visibility
                                      > into
                                      > > progress
                                      > > > of the project. As long as we take these precautions, I do not
                                      > see
                                      > > how any
                                      > > > customer would be "annoyed" about being involved.
                                      > > >
                                      > > > Look forward to more of these discussions tomorrow.
                                      > > >
                                      > > > Suresh A
                                      > > >
                                      > >
                                      >
                                      >
                                      >
                                      >
                                      >
                                      >
                                      > ---------------------------------
                                      > Be a better friend, newshound, and know-it-all with Yahoo! Mobile.
                                      Try it now.
                                      >
                                    • Sharanya Vemu
                                      Here is another perspective T&M contracts are usually taken up in some of the services organizations, where the requirements are not very clear, in which case
                                      Message 18 of 19 , Mar 11, 2008
                                      View Source
                                      • 0 Attachment
                                        Here is another perspective
                                         
                                        T&M contracts are usually taken up in some of the services organizations, where the requirements are not very clear, in which case the customer does have the flexibility to see what he is getting sprint after sprint and can give inputs to the product backlog accordingly.
                                         
                                        making the customer understand the methodology and letting him know , how he could use this to his advantage definitely helps.
                                         
                                        Thanks,
                                        -Sharanya Vemu

                                        On Tue, Mar 11, 2008 at 3:58 PM, enigma76_in <enigma76_in@...> wrote:

                                        I wonder if Scrum is the right methodology to be used in this
                                        scenario. Scrum is a "Project" management methodology! IMO, T&M
                                        engagements are not projects in the 1st place. Its more
                                        ticket/request based work that is done. A proper queue management
                                        methodology like Kanban is more suited for such kind of work.

                                        Any comments?

                                        regards,

                                        Ashish

                                        --- In Scrum-India@yahoogroups.com, Vikrama Dhiman <vickydhiman@...>
                                        wrote:
                                        >
                                        > "Implementing No Change Rules - seems to be a major areas of
                                        concern. All the Scrum practitioners I talk to, always have a problem
                                        with this [or with customers not defining priorities or giving any
                                        feedback what so ever].
                                        >
                                        > One reason is [at least with us] that mostly the time and materials
                                        projects have transitioned to Agile, and time and materials have had
                                        a history of almost ad-hoc, no tracking management, at least with us.
                                        Bringing in the discipline that Scrum imposes is hard enough for the
                                        teams in this case and on top of it to get clients to get used to it
                                        requires some effort. I think clients are insisting on making changes
                                        through out the sprint only when:
                                        >
                                        > They are not doing enough ground work for the sprint/ iteration
                                        > There is lack of product owner role
                                        >
                                        > There are too many customer representatives - one managing
                                        previous release, one planning next release, one is customer liaison
                                        officer and blah blah
                                        >
                                        > They don't realize the loss of business value of stability in a
                                        sprint
                                        >
                                        > Sprints are too long
                                        >
                                        > We are still struggling in coming to terms with this. Hence, any
                                        ideas and thoughts would be really useful.
                                        >
                                        > sharadbn2003 <sharadbn@...> wrote:
                                        First of all, I dont think this is Scrum probel. Scrum in any case
                                        > allows any one to plan sprint only after a thorugh analysis and
                                        > estimates. No one is commiting anything more than they can
                                        deliver.
                                        >
                                        > Secondly, there is an estimation process which decided the quantum
                                        > of delievarbles for a sprint.
                                        >
                                        > Thridly, there is always a provison to terminate the sprint if
                                        there
                                        > is so much chaos.
                                        >
                                        > So, to sum up, it is against the Scrum philosophy to allow changes
                                        > dueing the sprint.
                                        >
                                        > Regards
                                        >
                                        > Sharad B Nalawade
                                        >
                                        > --- In Scrum-India@yahoogroups.com, "Prabhakar Karve" <prkarve@>
                                        > wrote:
                                        > >
                                        > > Another area of annoyance to the customers that we have come
                                        > across
                                        > > is the strict discipline of not accepting any changes once a
                                        > sprint
                                        > > starts. They are so used to the freedom and power of making
                                        > changes
                                        > > whenever they wish. Has anyone faced this problem? What is the
                                        > best
                                        > > way to deal with it other than insisting that Scrum requires it?
                                        > >
                                        > > --- In Scrum-India@yahoogroups.com, "suresh adina" <asuresh18@>
                                        > > wrote:
                                        > > >
                                        > > > What I have noticed that most customers are afraid
                                        > of "terminology"
                                        > > more
                                        > > > than the process itself. So the moment you
                                        > > say "ISO", "CMMI", "Agile" or
                                        > > > "Scrum" to customers they tend to go into defensive mode. In
                                        > some
                                        > > way same
                                        > > > is the case with team members when they are not clear on the
                                        > impact.
                                        > > >
                                        > > > So instead of going into the semantics of what to call it,
                                        start
                                        > by
                                        > > > explaining the methodology to be applied and the activities
                                        that
                                        > > will be
                                        > > > done there of including their roles. Whether it is customer or
                                        > team
                                        > > members,
                                        > > > they need to see an inherent benefit to themselves and not
                                        just
                                        > to
                                        > > the
                                        > > > project, which is an " unseen" entity.
                                        > > >
                                        > > > Customer involvement in the project at all stages is
                                        beneficial
                                        > all
                                        > > around.
                                        > > > This is specially so when the customer plays the role of
                                        > reviewer
                                        > > throughout
                                        > > > since the final outcome impacts their business and any
                                        > > modifications can be
                                        > > > identified in early stages.
                                        > > >
                                        > > > However, it is important to remember one key aspect. We should
                                        > be
                                        > > careful to
                                        > > > ensure that Customer does not become our QA or QC. It is more
                                        > about
                                        > > > acceptance as we progress with Sprints and direct visibility
                                        > into
                                        > > progress
                                        > > > of the project. As long as we take these precautions, I do not
                                        > see
                                        > > how any
                                        > > > customer would be "annoyed" about being involved.
                                        > > >
                                        > > > Look forward to more of these discussions tomorrow.
                                        > > >
                                        > > > Suresh A
                                        > > >
                                        > >
                                        >
                                        >
                                        >
                                        >
                                        >
                                        >
                                        > ---------------------------------
                                        > Be a better friend, newshound, and know-it-all with Yahoo! Mobile.
                                        Try it now.
                                        >


                                      • Kumar Sindhurakshit
                                        We have used SCRUM for T&M projects successfully. , contract type has no impact in project execution , but it is nature of work , if you have team and you can
                                        Message 19 of 19 , Mar 11, 2008
                                        View Source
                                        • 0 Attachment
                                          We have used SCRUM for T&M projects successfully. ,
                                          contract type has no impact in project execution , but
                                          it is nature of work , if you have team and you can
                                          plan for few weeks in advance then better do SCRUM .

                                          Agree that maintenance/support type of work where
                                          requirements/tasks comes almost on daily basis , SCRUM
                                          may not be good , but even in maintenance project
                                          SCRUM can be used for CR etc, when planned work is
                                          more than a week,
                                          -Sindhurakshit

                                          --- enigma76_in <enigma76_in@...> wrote:

                                          > I wonder if Scrum is the right methodology to be
                                          > used in this
                                          > scenario. Scrum is a "Project" management
                                          > methodology! IMO, T&M
                                          > engagements are not projects in the 1st place. Its
                                          > more
                                          > ticket/request based work that is done. A proper
                                          > queue management
                                          > methodology like Kanban is more suited for such kind
                                          > of work.
                                          >
                                          > Any comments?
                                          >
                                          > regards,
                                          >
                                          > Ashish
                                          >
                                          > --- In Scrum-India@yahoogroups.com, Vikrama Dhiman
                                          > <vickydhiman@...>
                                          > wrote:
                                          > >
                                          > > "Implementing No Change Rules - seems to be a
                                          > major areas of
                                          > concern. All the Scrum practitioners I talk to,
                                          > always have a problem
                                          > with this [or with customers not defining priorities
                                          > or giving any
                                          > feedback what so ever].
                                          > >
                                          > > One reason is [at least with us] that mostly the
                                          > time and materials
                                          > projects have transitioned to Agile, and time and
                                          > materials have had
                                          > a history of almost ad-hoc, no tracking management,
                                          > at least with us.
                                          > Bringing in the discipline that Scrum imposes is
                                          > hard enough for the
                                          > teams in this case and on top of it to get clients
                                          > to get used to it
                                          > requires some effort. I think clients are insisting
                                          > on making changes
                                          > through out the sprint only when:
                                          > >
                                          > > They are not doing enough ground work for the
                                          > sprint/ iteration
                                          > > There is lack of product owner role
                                          > >
                                          > > There are too many customer representatives -
                                          > one managing
                                          > previous release, one planning next release, one is
                                          > customer liaison
                                          > officer and blah blah
                                          > >
                                          > > They don't realize the loss of business value
                                          > of stability in a
                                          > sprint
                                          > >
                                          > > Sprints are too long
                                          > >
                                          > > We are still struggling in coming to terms with
                                          > this. Hence, any
                                          > ideas and thoughts would be really useful.
                                          > >
                                          > > sharadbn2003 <sharadbn@...> wrote:
                                          >
                                          > First of all, I dont think this is Scrum probel.
                                          > Scrum in any case
                                          > > allows any one to plan sprint only after a
                                          > thorugh analysis and
                                          > > estimates. No one is commiting anything more than
                                          > they can
                                          > deliver.
                                          > >
                                          > > Secondly, there is an estimation process which
                                          > decided the quantum
                                          > > of delievarbles for a sprint.
                                          > >
                                          > > Thridly, there is always a provison to terminate
                                          > the sprint if
                                          > there
                                          > > is so much chaos.
                                          > >
                                          > > So, to sum up, it is against the Scrum philosophy
                                          > to allow changes
                                          > > dueing the sprint.
                                          > >
                                          > > Regards
                                          > >
                                          > > Sharad B Nalawade
                                          > >
                                          > > --- In Scrum-India@yahoogroups.com, "Prabhakar
                                          > Karve" <prkarve@>
                                          > > wrote:
                                          > > >
                                          > > > Another area of annoyance to the customers that
                                          > we have come
                                          > > across
                                          > > > is the strict discipline of not accepting any
                                          > changes once a
                                          > > sprint
                                          > > > starts. They are so used to the freedom and
                                          > power of making
                                          > > changes
                                          > > > whenever they wish. Has anyone faced this
                                          > problem? What is the
                                          > > best
                                          > > > way to deal with it other than insisting that
                                          > Scrum requires it?
                                          > > >
                                          > > > --- In Scrum-India@yahoogroups.com, "suresh
                                          > adina" <asuresh18@>
                                          > > > wrote:
                                          > > > >
                                          > > > > What I have noticed that most customers are
                                          > afraid
                                          > > of "terminology"
                                          > > > more
                                          > > > > than the process itself. So the moment you
                                          > > > say "ISO", "CMMI", "Agile" or
                                          > > > > "Scrum" to customers they tend to go into
                                          > defensive mode. In
                                          > > some
                                          > > > way same
                                          > > > > is the case with team members when they are
                                          > not clear on the
                                          > > impact.
                                          > > > >
                                          > > > > So instead of going into the semantics of
                                          > what to call it,
                                          > start
                                          > > by
                                          > > > > explaining the methodology to be applied and
                                          > the activities
                                          > that
                                          > > > will be
                                          > > > > done there of including their roles. Whether
                                          > it is customer or
                                          > > team
                                          > > > members,
                                          > > > > they need to see an inherent benefit to
                                          > themselves and not
                                          > just
                                          > > to
                                          > > > the
                                          > > > > project, which is an " unseen" entity.
                                          > > > >
                                          > > > > Customer involvement in the project at all
                                          > stages is
                                          > beneficial
                                          > > all
                                          > > > around.
                                          > > > > This is specially so when the customer plays
                                          > the role of
                                          > > reviewer
                                          > > > throughout
                                          > > > > since the final outcome impacts their
                                          > business and any
                                          > > > modifications can be
                                          > > > > identified in early stages.
                                          > > > >
                                          > > > > However, it is important to remember one key
                                          > aspect. We should
                                          > > be
                                          > > > careful to
                                          > > > > ensure that Customer does not become our QA
                                          > or QC. It is more
                                          > > about
                                          > > > > acceptance as we progress with Sprints and
                                          > direct visibility
                                          > > into
                                          > > > progress
                                          > > > > of the project. As long as we take these
                                          > precautions, I do not
                                          > > see
                                          > > > how any
                                          > > > > customer would be "annoyed" about being
                                          > involved.
                                          > > > >
                                          > > > > Look forward to more of these discussions
                                          > tomorrow.
                                          > > > >
                                          > > > > Suresh A
                                          > > > >
                                          > > >
                                          > >
                                          > >
                                          > >
                                          > >
                                          > >
                                          > >
                                          > > ---------------------------------
                                          > > Be a better friend, newshound, and know-it-all
                                          > with Yahoo! Mobile.
                                          > Try it now.
                                          > >
                                          >
                                          >
                                          >



                                          ____________________________________________________________________________________
                                          Be a better friend, newshound, and
                                          know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
                                        Your message has been successfully submitted and would be delivered to recipients shortly.