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

RE: [scrumdevelopment] Hyper productive...

Expand Messages
  • Roy Morien
    Frankly, I am at a total loss as to how to measure either personal or team productivity in any statistical or mathematical manner. First, you must define
    Message 1 of 22 , May 26, 2009
    • 0 Attachment
      Frankly, I am at a total loss as to how to 'measure' either personal or team productivity in any statistical or mathematical manner.
       
      First, you must define your concept of 'productivity'. Is it 'lines of code per hour'? Is it 'story points achieved?'. Is it hours to do a particular job? What?
       
      I believe that productivity is almost entirely a qualitative measure, in software development. In manufacturing you can measure producivity in terms of machine utilisation, units produced per hour, etc. etc. Of course, these may be dud values, useless for any real purpose, because you may be utilising your machines at close to 100% (which is a good thing) to produce more items per hour than last time (which is also a good thing) so that you have a large on-hand stock (which is not a good thing) because there is noone to buy those highly-productively produced items (which really is a very bad thing).
       
      If we look at the old management saying that 'if you can't measure it you can't manage it', there may be a grain of truth in that. BUT agile practices indicate that you do not have 'managers', you have leaders, you have mentors and helpful people like Scrum Masters. Is there a saying amongst agile practitioners 'you can't provide leadership if you can't measure it'?
       
      Why do we have this incessant discussion about something as, frankly, inappropriate and irrelevant in agile systems development as 'productivity measurement'? Isn't delivering useful, working software as fast as the team can manage to do so, and doing that apparently better than last 'time', a sufficient measure? 

      Regards,
      Roy Morien

      To: scrumdevelopment@yahoogroups.com
      From: adam.sroka@...
      Date: Thu, 21 May 2009 15:27:36 -0700
      Subject: Re: [scrumdevelopment] Hyper productive...



      Most of us believe that teams become progressively more productive
      (i.e. deliver more running, tested features) during the early stages
      of a project. Some of us have seen this happen. Nonetheless, I am
      quite dubious of any attempts to quantify this. Story points are not
      necessarily comparable, although they seem to converge over time (e.g.
      five story points in iteration one is likely not comparable to five
      story points in iteration five. However, five story points in
      iteration five likely is comparable to five story points in iteration
      six.)

      So, the increases in productivity we see through the course of an
      Agile project are anecdotal. We have seen them. We know they exist,
      but we lack any definitive way to measure them.

      To truly quantify increases in productivity we would need a measure
      that was always comparable. For instance, other methods might measure
      something like KLOC/man-month and see how that changes over time,
      attempting to correlate changes to different practices. We reject KLOC
      as a measure of productivity, because it measures only work done and
      not value produced.

      In order to make story points comparable we would have to be comparing
      stories that were very similar. However, if I have any idea what I am
      doing then comparable stories should require progressively less effort
      to complete (Through generalization, reuse, accumulation of knowledge,
      etc.) If stories aren't similar it is very difficult to equate them. I
      have a general sense of how much effort each takes, but that is
      subjective (by design.)

      In my personal opinion, this whole line of inquiry while quite well
      intentioned is a waste of time. The things that matter are:

      1) Are we delivering working software that is valuable - continuously,
      every iteration?

      2) Are we expending effort in a manner which is sustainable? Can we
      continue to deliver at this pace indefinitely? Can we improve?

      3) Are we wasting effort on things which do not contribute directly to
      the delivery of value? How do we eliminate such waste?

      On Thu, May 21, 2009 at 12:35 PM, D <dmahlitz@gmail. com> wrote:
      >
      >
      > I hear the term hyper productive a lot but I'm confused about how the
      > measurement is calculated.
      >
      > In a recent paper
      > (http://jeffsutherla nd.com/scrum/ SelfOrganization ShockTherapyBT2A pr2009.pdf)
      > from Jeff Sutherland, Scott Downey & Bjorn Granvik they have some sample
      > tables (p.40) that they reference hyper productive numbers. In the tables
      > they calculate % increase by taking the story points delivered in Sprint 1
      > from a team and divide that by each delivery for the next n sprints. So in
      > one of the examples Team E commits to 24 story points and delivers 5, making
      > 5 the baseline number for that team. In Sprint 2 they commit to 26 story
      > points and deliver 22, given them a 440% increase in productivity after 1
      > week. Are they now hyper productive?
      >
      > Is sprint 1 a good baseline measurement of a new team to scrum, don't most
      > teams over commit? What if they delivered 1 story point Sprint 1, then 22
      > Sprint 2? 2200% increase. wooohoooo!!!
      >
      > Does anyone else have a measurement for hyper-productive?
      >
      >



      Click Here View photos of singles in your area
    • Vikas Atri
      Hi Petri, Thanks for the reply. Infact, it was a real detailed reply, in context to CMMI practices. I come from CMMI background and your inputs have really
      Message 2 of 22 , May 27, 2009
      • 0 Attachment
        Hi Petri,
         
        Thanks for the reply.
        Infact, it was a real detailed reply, in context to CMMI practices.
        I come from CMMI background and your inputs have really helped out.
        I really want to understand the measures for evaluating the performance of integrated teams.
        What kind of measures is one supposed to look for?
        for "Assessments of the product and product architectures, including risk and complexity"
        My understanding for this point is that it happens in Pre-Gaming phase wherein the
        product backlog evolves and the product owner continuously  assess the product and product
        architectures, including risk and complexity.
        Please let me know, if I ma thinking in the right direction.
        And I was looking forward to really demonstarte it using some form of template as an evidence.
        Regards,
        Vikas



        From: Petri Heiramo <petri.heiramo@...>
        To: scrumdevelopment@yahoogroups.com
        Sent: Sunday, 24 May, 2009 12:46:34 AM
        Subject: [scrumdevelopment] Re: IPM @CMMIL3

        Hi,

        Some comments, then a story. Comments first.

        > Practice 1: Establish the Project’s Shared Vision
        > Expected: Documented shared vision, Communications strategy, Published principles, shared vision statement, mission statement, and objectives (e.g., posters, wallet cards, and presentations)

        Expected: PO has defined and shared the project vision and mission with development team(s) and stakeholders, the PO and the development team have agreed the principles and objectives of the project

        > Practice 2:  Establish the Integrated Team Structure
        > Expected:
        > a. Assessments of the product and product architectures, including risk and complexity
        > b. Integrated team structure

        I don't see what a. has to do with "Integrated Team Structure".

        I assume "integrated team" to mean a cross-functional team. Right?

        b. probably assumes that there is a fixed responsibility structure between the teams. If not, merely list the teams and their members (see 4 also).

        > Practice 3. Allocate Requirements to Integrated Teams
        > Expected:
        >   a. Responsibilities allocated to each integrated team
        >   b. Work product requirements, technical interfaces, and business (e.g., cost accounting and project management) interfaces each integrated team will be responsible for satisfying
        >   c. List of integrated team sponsors

        Expected:
        a. At each sprint planning, each integrated team accepts user stories to be developed in the iteration
        b. There are existing agreed practices for communicating and agreeing dependencies between the teams

        What are c.?
         
        > Practice 4: Establish Integrated Teams
        > Expected:  
        > a. List of team leaders
        >   b. List of team members assigned to each integrated team
        >   c. Integrated team
        charters
        >   d. Measures for evaluating the performance of integrated teams

        a. is not there in Scrum environment.
        b. is okay.
        c. What are these??
        d. Watch out for these, they tend screw up things....

        > 5. Ensure Collaboration among Interfacing Teams
        > Expected:
        > a. Work product ownership agreements
        >   b. Team work plans
        >   c. Commitment lists

        a. sounds a bit silly, given that all teams contribute to the same product. These are ofc made during sprint planning for each sprint.

        b. Sprint backlogs.

        c. Happen daily as team members pick up tasks. If necessary, show the names from the sprint backlog at the end of a sprint.

        Looks to me, you either have to make up a lot of things, or you have some explaining to do.

        > According to me, lot of things will happen during sprint planning and they will be tracked during sprint execution to closure.
        >
        Looking for opinions from you guys, on how to accomplish any or all of above mentioned practices in sprint planning, execution and closure.

        I'll share a recent story from a colleague. We had an external audit recently and one of the assessed projects was a Scrum project where this colleague was the Scrum Master. The auditor, a lady, had a lot of experience on assessments, projects and the traditional way, so she had trouble getting into grips with the project. The discussions were typically something like this:

        Auditor: Do you have a quality plan?
        SM: Well... no, not really, as a document, but we have a Definition of Done. <showed and explained it>
        A: How do you ensure the quality of the final product to avoid surprises at the end?
        SM: Well, we don't have a final product release per se, since we deliver a working version from every iteration. We want every iteration to meet the quality criteria, so we don't really see how we could have any surprises since we know any problems immediately.
        A: Do you have any quality metrics you track?
        SM: No, not really...
        A: Well, what could you measure to follow the quality of the project?
        SM: <thinks hard> ... how about bugs in sprint releases?
        A: <excited> Yes, for example! Do you have a database or similar where you store the bugs?
        SM: No, we don't... How many bugs have we had reported by the customer in the last 5 months?
        Developer: Two?
        ...

        And so on :).

        The auditor said that she didn't really understand how the project worked, but could clearly see that the project had everything in control. She was clearly intrigued by the approach and its results.

        Bottom line, I wouldn't try to conform to any waterfall-based process framework, but if you do have to, do stand tall and show what you have. It is very likely to be something much better than what the framework expects. This ofc assuming that you do have the project under control the Scrum way. :)

        Yours Sincerely,

        Petri

        ---
        Petri Heiramo
        Process Development Manager, Agile Coach (CST)
        Digia Plc., Finland



        Own a website.Get an unlimited package.Pay next to nothing.* Click here!.
      • Vikas Atri
        Guys, Any thoughts on mail below. I would really appreciate , if anyone can guide me on mail below. Regards, Vikas ________________________________ From: Vikas
        Message 3 of 22 , May 28, 2009
        • 0 Attachment
          Guys,
           
          Any thoughts on mail below.
           
          I would really appreciate , if anyone can guide me on mail below.
           
          Regards,
          Vikas


          From: Vikas Atri <vikasait25@...>
          To: scrumdevelopment@yahoogroups.com
          Sent: Wednesday, 27 May, 2009 6:12:22 PM
          Subject: Re: [scrumdevelopment] Re: IPM @CMMIL3

          Hi Petri,
           
          Thanks for the reply.
          Infact, it was a real detailed reply, in context to CMMI practices.
          I come from CMMI background and your inputs have really helped out.
          I really want to understand the measures for evaluating the performance of integrated teams.
          What kind of measures is one supposed to look for?
          for "Assessments of the product and product architectures, including risk and complexity"
          My understanding for this point is that it happens in Pre-Gaming phase wherein the
          product backlog evolves and the product owner continuously  assess the product and product
          architectures, including risk and complexity.
          Please let me know, if I ma thinking in the right direction.
          And I was looking forward to really demonstarte it using some form of template as an evidence.
          Regards,
          Vikas



          From: Petri Heiramo <petri.heiramo@ sysopendigia. com>
          To: scrumdevelopment@ yahoogroups. com
          Sent: Sunday, 24 May, 2009 12:46:34 AM
          Subject: [scrumdevelopment] Re: IPM @CMMIL3

          Hi,

          Some comments, then a story. Comments first.

          > Practice 1: Establish the Project’s Shared Vision
          > Expected: Documented shared vision, Communications strategy, Published principles, shared vision statement, mission statement, and objectives (e.g., posters, wallet cards, and presentations)

          Expected: PO has defined and shared the project vision and mission with development team(s) and stakeholders, the PO and the development team have agreed the principles and objectives of the project

          > Practice 2:  Establish the Integrated Team Structure
          > Expected:
          > a. Assessments of the product and product architectures, including risk and complexity
          > b. Integrated team structure

          I don't see what a. has to do with "Integrated Team Structure".

          I assume "integrated team" to mean a cross-functional team. Right?

          b. probably assumes that there is a fixed responsibility structure between the teams. If not, merely list the teams and their members (see 4 also).

          > Practice 3. Allocate Requirements to Integrated Teams
          > Expected:
          >   a. Responsibilities allocated to each integrated team
          >   b. Work product requirements, technical interfaces, and business (e.g., cost accounting and project management) interfaces each integrated team will be responsible for satisfying
          >   c. List of integrated team sponsors

          Expected:
          a. At each sprint planning, each integrated team accepts user stories to be developed in the iteration
          b. There are existing agreed practices for communicating and agreeing dependencies between the teams

          What are c.?
           
          > Practice 4: Establish Integrated Teams
          > Expected:  
          > a. List of team leaders
          >   b. List of team members assigned to each integrated team
          >   c. Integrated team
          charters
          >   d. Measures for evaluating the performance of integrated teams

          a. is not there in Scrum environment.
          b. is okay.
          c. What are these??
          d. Watch out for these, they tend screw up things.....

          > 5. Ensure Collaboration among Interfacing Teams
          > Expected:
          > a. Work product ownership agreements
          >   b. Team work plans
          >   c. Commitment lists

          a. sounds a bit silly, given that all teams contribute to the same product. These are ofc made during sprint planning for each sprint.

          b. Sprint backlogs.

          c. Happen daily as team members pick up tasks. If necessary, show the names from the sprint backlog at the end of a sprint.

          Looks to me, you either have to make up a lot of things, or you have some explaining to do.

          > According to me, lot of things will happen during sprint planning and they will be tracked during sprint execution to closure.
          >
          Looking for opinions from you guys, on how to accomplish any or all of above mentioned practices in sprint planning, execution and closure.

          I'll share a recent story from a colleague. We had an external audit recently and one of the assessed projects was a Scrum project where this colleague was the Scrum Master. The auditor, a lady, had a lot of experience on assessments, projects and the traditional way, so she had trouble getting into grips with the project. The discussions were typically something like this:

          Auditor: Do you have a quality plan?
          SM: Well... no, not really, as a document, but we have a Definition of Done. <showed and explained it>
          A: How do you ensure the quality of the final product to avoid surprises at the end?
          SM: Well, we don't have a final product release per se, since we deliver a working version from every iteration. We want every iteration to meet the quality criteria, so we don't really see how we could have any surprises since we know any problems immediately.
          A: Do you have any quality metrics you track?
          SM: No, not really...
          A: Well, what could you measure to follow the quality of the project?
          SM: <thinks hard> ... how about bugs in sprint releases?
          A: <excited> Yes, for example! Do you have a database or similar where you store the bugs?
          SM: No, we don't... How many bugs have we had reported by the customer in the last 5 months?
          Developer: Two?
          ...

          And so on :).

          The auditor said that she didn't really understand how the project worked, but could clearly see that the project had everything in control. She was clearly intrigued by the approach and its results.

          Bottom line, I wouldn't try to conform to any waterfall-based process framework, but if you do have to, do stand tall and show what you have. It is very likely to be something much better than what the framework expects. This ofc assuming that you do have the project under control the Scrum way. :)

          Yours Sincerely,

          Petri

          ---
          Petri Heiramo
          Process Development Manager, Agile Coach (CST)
          Digia Plc., Finland



          Own a website.Get an unlimited package.Pay next to nothing.* Click here!.


          Explore and discover exciting holidays and getaways with Yahoo! India Travel Click here!
        • Dorin Ioan Marinca
          Message 4 of 22 , Jun 14, 2009
          • 0 Attachment
            On Tue, May 26, 2009 at 09:16, Roy Morien <roymorien@...> wrote:

            If we look at the old management saying that 'if you can't measure it you can't manage it', there may be a grain of truth in that. BUT agile practices indicate that you do not have 'managers', you have leaders, you have mentors and helpful people like Scrum Masters. Is there a saying amongst agile practitioners 'you can't provide leadership if you can't measure it'?

             


             


             
            Why do we have this incessant discussion about something as, frankly, inappropriate and irrelevant in agile systems development as 'productivity measurement'? Isn't delivering useful, working software as fast as the team can manage to do so, and doing that apparently better than last 'time', a sufficient measure? 

            .


          • Dorin Ioan Marinca
            Sorry for previous useless message sent accidentally. If we look at the old management saying that if you can t measure it you ... I think these measurements
            Message 5 of 22 , Jun 14, 2009
            • 0 Attachment
              Sorry for previous useless message sent accidentally.

              If we look at the old management saying that 'if you can't measure it you can't manage it', there may be a grain of truth in that. BUT agile practices indicate that you do not have 'managers', you have leaders, you have mentors and helpful people like Scrum Masters. Is there a saying amongst agile practitioners 'you can't provide leadership if you can't measure it'?
               
              Why do we have this incessant discussion about something as, frankly, inappropriate and irrelevant in agile systems development as 'productivity measurement'? Isn't delivering useful, working software as fast as the team can manage to do so, and doing that apparently better than last 'time', a sufficient measure?

              I think these measurements are at least useful during Scrum adoption phase where existing 'old management' should believe that the change to Agile/Scrum worth the effort (i.e. should be convinced in a language that they understand before paradigm shift).

              And yes, after the shift, we may want to measure other things for other purposes, removing waste.

              Dorin
            • Nancy Van Schooenderwoert
              Hi Tobias, Apologies for coming late to this discussion but I feel I can add something worthwhile. ... It *can* be that but it does not have to. Estimation of
              Message 6 of 22 , Jun 14, 2009
              • 0 Attachment
                Hi Tobias,

                Apologies for coming late to this discussion but I feel I can add
                something worthwhile.

                Tobias Mayer wrote:
                >
                > I agree with Adam, this "hyper-productivity" measuring is mostly a waste of time
                > -- and a way of selling snake oil.

                It *can* be that but it does not have to.

                Estimation of stories is not a constant
                > thing; teams change the way they do this over time as much as they improve their
                > ability to deliver. And as Adam points out comparably complex stories require
                > less and less effort as we get better.
                >
                > I think such "quantified" claims do a disservice to Scrum, and as the original
                > poster points out, if you set your baseline low enough, everything can appear as
                > hyper-productive. What if a team completed nothing at all in sprint one? Then
                > getting one story point done in sprint two would represent an infinity%
                > increase. It is all nonsense.

                Well, what if a team measured their work in iteration 1 and used the
                prevailing metrics in the software industry as well as those metrics are
                being used by anyone else in the industry? How big an increase would it
                take to have significance?

                I agree that using iteration 1 story points, as determined by a newly
                agile team is very weak. Early on when I first had the chance to have my
                team use agile methods, I needed to have something more than anecdotes
                to help me keep interference away and show skeptics that this was
                valuable, and not just some fluke. Metrics, so long as they were no more
                flawed than everyone else's, served that purpose.

                But the metrics I took did something totally unexpected - even by me,
                and I thought I had a very complete view of things since I was coding
                plus managing every day. "It's what you learn *after* you know it all
                that really counts", as one of my college profs used to say.

                When I analyzed our numbers (many months after starting because I'd
                been "too busy" - another mistake, I learned from) I found that the team
                was far more productive than I had believed. Not so sure of my data and
                its validity, I searched for comparisons. It was at least a couple more
                years before I was satisfied with the info I found, and yes, our truly
                the amazing productivity increase was real. *

                So my view is that we should try to think of meaningful, honest
                measurements and use them. We have to watch for sub-optimization of
                course. Metrics is a way to get a new vantage point on a situation that
                you think you know well. Radio telescopes changed astronomy hugely by
                making new views available.

                Too often people are using metrics either to sell snake oil, or to
                convince people whose minds are made up and aren't going to change no
                matter what. But there's a 3rd use - to give ourselves new insights and
                confidence in what we've discovered.

                >
                > Yes, we do see teams improve over time. Let's just use that shared knowledge.
                > Scrum does better with real-life subjective metrics than fake objective ones. I
                > reckon.
                >

                It is true that if we simply do better this iteration than last, we
                are on the right track. I respect those who want to leave it at that.
                But I want more insight. Exploring different people's views helps me get
                that. So does the attempt to measure what we're doing. I say "attempt"
                because I doubt there will ever be a clear definitive measure, but I
                find much value in the attempt, so long as it is conducted *primarily*
                to understand, and does not take much overhead to conduct.

                - njv


                * I presented this at Agile 2006 as "Embedded Agile Project by the
                Numbers With Newbies". The paper is on the Publications page of
                leanagilepartners.com - you can download it for free. By the way, Jeff
                Sutherland has used Capers Jones' figures for metrics and so did I in
                that paper. There's even a way you can compare your own team's metrics
                with charts given in the paper.

                --
                ............................................
                Nancy Van Schooenderwoert, Lean-Agile Partners Inc.

                781 301 1822 US mobile
                nancyv@...

                http://www.leanagilepartners.com

                Specialties: Agile coaching for Embedded Systems, for Data Migrations,
                and for leadership of Lean-Agile change organization wide
                ............................................
              • Tobias Mayer
                Hi Nancy, Thanks for your thoughtful response. I agree that sometimes metrics present themselves and we d be foolish to discard them. When I first used
                Message 7 of 22 , Jun 14, 2009
                • 0 Attachment
                  Hi Nancy,

                  Thanks for your thoughtful response.  I agree that sometimes metrics present themselves and we'd be foolish to discard them. 

                  When I first used Scrum-like methods at Yahoo! the project was a complete rebuild of a previous product that was basically a mess in all the usual waterfall ways.  The metric I discovered to be useful, after the implementation was complete, was a measure of bugs filed in Bugzilla on the two projects.  The Scrum-like project showed a clear 700% improvement, and no bug was open for more than a couple of days (compared to about 3-4 weeks in the previous project).  This was useful data, and I used it to say to management "look what we did -- other properties could do this too".  I like to believe it played some small part in the Scrum adoption that followed a few months later.

                  Tobias

                • Roy Morien
                  Tobias, Interesting information. In your Scrum like project, using Bugzilla, when was a bug recognised and acknowledged as a bug to be recorded in
                  Message 8 of 22 , Jun 14, 2009
                  • 0 Attachment
                    Tobias,
                     
                    Interesting information. In your 'Scrum like' project, using Bugzilla, when was a 'bug' recognised and acknowledged as a bug to be recorded in Bugzilla?
                     
                    Anticipating your answer a little, if 'bugs' were recorded during post-sprint usage of the processes, doesn't that imply that your in-sprint and sprint review activities failed, inasmuch as the bugs should have been discovered then, and not allowed through to become part of the released software?
                     
                    Regards,
                    Roy Morien  
                     

                    To: scrumdevelopment@yahoogroups.com
                    From: scrum@...
                    Date: Sun, 14 Jun 2009 15:25:35 -0700
                    Subject: Re: [scrumdevelopment] Hyper productive...



                    Hi Nancy,

                    Thanks for your thoughtful response.  I agree that sometimes metrics present themselves and we'd be foolish to discard them. 

                    When I first used Scrum-like methods at Yahoo! the project was a complete rebuild of a previous product that was basically a mess in all the usual waterfall ways.  The metric I discovered to be useful, after the implementation was complete, was a measure of bugs filed in Bugzilla on the two projects.  The Scrum-like project showed a clear 700% improvement, and no bug was open for more than a couple of days (compared to about 3-4 weeks in the previous project).  This was useful data, and I used it to say to management "look what we did -- other properties could do this too".  I like to believe it played some small part in the Scrum adoption that followed a few months later.

                    Tobias




                    Click here to find out more POP access for Hotmail is here!
                  • Tobias Mayer
                    Hi Roy, Scrum-like isn t Scrum. There was no active product owner, and therefore no reviews. There were also not clearly delineated sprints. Most bugs were
                    Message 9 of 22 , Jun 14, 2009
                    • 0 Attachment
                      Hi Roy,

                      Scrum-like isn't Scrum.  There was no active product owner, and therefore no reviews.  There were also not clearly delineated sprints.  Most bugs were caught and fixed within a few days as the testers worked side by side with the developers (this was innovative for Yahoo! at that time; almost all testing was of the "over-the-wall" type).  Bugzilla was the tracking system we had been using, and we had not yet thought not to use it.  Which, as it turned out, was just as well as we were able to generate the reports I mentioned.

                      So, if you are looking to be critical of our Scrum-like process, be my guest :-)  There is much to criticize. And yet, it was a first step on a great journey -- I mean for me, not Yahoo! ;-)  But enough of that. 

                      I should also add, that at the time I wasn't looking to sell Scrum to Yahoo!, but to encourage teams to use the Agile development practices of collaborative team work, pair programming, TDD, early acceptance testing, continuous refactoring and build scripting.

                      Tobias


                      --
                      Tobias Mayer
                      Agile Thinking | Agile Anarchy

                    • Roy Morien
                      No, No ... never critical ... I was honestly seeking an explanation. I very much understand about the often necessary implementation of Scrum like
                      Message 10 of 22 , Jun 14, 2009
                      • 0 Attachment
                        No, No ... never critical ... I was honestly seeking an explanation. 

                        I very much understand about the often necessary implementation of 'Scrum like' development processes, and introducing concepts and practices slowly, to avoid 'change indigestion'. Change is often opposed because, to change, can be seen as an implication that what you have been doing (particularly if you have been earnestly supporting and advocating, maybe in the face of opposing views) is wrong, and you have been making a mistake all this time. This is, of course, an unfortunate attitude, very real, but is denying 'progress' and 'learning' as valid activities.

                        Regards,
                        Roy Morien


                        To: scrumdevelopment@yahoogroups.com
                        From: scrum@...
                        Date: Sun, 14 Jun 2009 23:06:09 -0700
                        Subject: Re: [scrumdevelopment] Hyper productive...



                        Hi Roy,

                        Scrum-like isn't Scrum.  There was no active product owner, and therefore no reviews.  There were also not clearly delineated sprints.  Most bugs were caught and fixed within a few days as the testers worked side by side with the developers (this was innovative for Yahoo! at that time; almost all testing was of the "over-the-wall" type).  Bugzilla was the tracking system we had been using, and we had not yet thought not to use it.  Which, as it turned out, was just as well as we were able to generate the reports I mentioned.

                        So, if you are looking to be critical of our Scrum-like process, be my guest :-)  There is much to criticize. And yet, it was a first step on a great journey -- I mean for me, not Yahoo! ;-)  But enough of that. 

                        I should also add, that at the time I wasn't looking to sell Scrum to Yahoo!, but to encourage teams to use the Agile development practices of collaborative team work, pair programming, TDD, early acceptance testing, continuous refactoring and build scripting.

                        Tobias



                        --
                        Tobias Mayer
                        Agile Thinking | Agile Anarchy




                        Click Here View photos of singles in your area
                      Your message has been successfully submitted and would be delivered to recipients shortly.