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

Hyper productive...

Expand Messages
  • D
    I hear the term hyper productive a lot but I m confused about how the measurement is calculated. In a recent paper
    Message 1 of 22 , May 21, 2009
    • 0 Attachment
      I hear the term hyper productive a lot but I'm confused about how the measurement is calculated.

      In a recent paper (http://jeffsutherland.com/scrum/SelfOrganizationShockTherapyBT2Apr2009.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?
    • Adam Sroka
      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
      Message 2 of 22 , May 21, 2009
      • 0 Attachment
        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@...> wrote:
        >
        >
        > I hear the term hyper productive a lot but I'm confused about how the
        > measurement is calculated.
        >
        > In a recent paper
        > (http://jeffsutherland.com/scrum/SelfOrganizationShockTherapyBT2Apr2009.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?
        >
        >
      • Tobias Mayer
        I agree with Adam, this hyper-productivity measuring is mostly a waste of time -- and a way of selling snake oil. Estimation of stories is not a constant
        Message 3 of 22 , May 21, 2009
        • 0 Attachment
          I agree with Adam, this "hyper-productivity" measuring is mostly a waste of time -- and a way of selling snake oil.  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.

          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.

          Tobias



        • Ron Jeffries
          Hello, Tobias. On Thursday, May 21, 2009, at 6:46:40 PM, you ... I m not sure why I think this, not having visited them, but my money says Jeff s teams really
          Message 4 of 22 , May 21, 2009
          • 0 Attachment
            Hello, Tobias. On Thursday, May 21, 2009, at 6:46:40 PM, you
            wrote:

            > I agree with Adam, this "hyper-productivity" measuring is
            > mostly a waste of time -- and a way of selling snake oil. 
            > 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'm not sure why I think this, not having visited them, but my money
            says Jeff's teams really do kick butt. And he does have some
            external productivity measures that back that up ...

            Ron Jeffries
            www.XProgramming.com
            www.xprogramming.com/blog
            The lyf so short, the craft so long to lerne. -- Geoffrey Chaucer
          • Vikas Atri
            Dear All, We have recently defined initial draft of scrum processes.I am trying to integrate Specific practices from IPM-Integrated project management (at
            Message 5 of 22 , May 21, 2009
            • 0 Attachment
              Dear All,
              We have recently defined initial draft of scrum processes.I am trying to integrate Specific practices from IPM-Integrated project management (at CMMIL3) with SCRUM Planning.
              Problem 1 : The following was the trigger for this thought:
              There are teams following scrum cycle at multiple locations (more than 2 ) with only 1 scrum master and product owner.
              I found it little strange , as to how is possible for scrum master to manage sprint with teams located at multiple locations
              and also stand-up meetings(daily scrum) are really difficult in this scenario.This makes me think that , may be
              it will be good idea if we include some practices from IPM at CMMIL3 to ensure integrated teaming.
              I am looking at two aspects:
              Involving scrum teams (from multiple locations with only one scrum master or may be 2) effectively in sprint planning
              Involving scrum teams (from multiple locations with only one scrum master or may be 2) effectively in sprint execution and closure
               
              Just to share my thought on :
              Daily scrums:
              Here scrum master sets up daily scrum meeting with the Scrum Team for 10-15 mins.
              Typically focus is on:
              • What was done yesterday?
              • What is planned for today/next working day?
              • What are the impediments faced?
              • What the status of previously identified impediments?

              Scrum of scrums:
              Here scrum master (scrum masters , in case of multiple scrum masters) sets up weekly scrum meeting with PO and update the status
              of sprint in terms of:
              • What was done last week?
              • What is the plan for next week?
              • What are the impediments faced
              Problem 2 : When does really the resource allocation takes place in scrum.To my knowledge, scrum is project management methodology.
              I have no where found planning for resources (human and non-human).Is it during the release planning or sprint planning.To my knowledge during the release planning the scrum master may get involved the very first time,but I am not sure, if the scrum team is really decided here at this stage.Request someone to guide me on this.
               
              I need expert advice on whether my thought (in problem 1) is feasible and if yes, has anyone done this earlier and what chalenges are there in doing it.
              It will be really great, if anyone amongst you can throw some light on it.I have already referred to couple of websites on agile-scrum, but they do not address my 2 problems.
               
              Regards,
              Vikas




              From: Ron Jeffries <ronjeffries@...>
              To: scrumdevelopment@yahoogroups.com
              Sent: Friday, 22 May, 2009 6:52:19 AM
              Subject: Re: [scrumdevelopment] Hyper productive...

              Hello, Tobias. On Thursday, May 21, 2009, at 6:46:40 PM, you
              wrote:

              > I agree with Adam, this "hyper-productivity " measuring is
              > mostly a waste of time -- and a way of selling snake oil. 
              > 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'm not sure why I think this, not having visited them, but my money
              says Jeff's teams really do kick butt. And he does have some
              external productivity measures that back that up ...

              Ron Jeffries
              www.XProgramming. com
              www.xprogramming. com/blog
              The lyf so short, the craft so long to lerne. -- Geoffrey Chaucer



              Explore and discover exciting holidays and getaways with Yahoo! India Travel Click here!
            • Peter Stevens (calendar)
              Hi Vikas, Your analysis of the Daily Scrum is basically correct, except you don t need the fourth question. If something is still an impediment, it should be
              Message 6 of 22 , May 21, 2009
              • 0 Attachment
                Hi Vikas,

                Your analysis of the Daily Scrum is basically correct, except you don't need the fourth question. If something is still an impediment, it should be mentioned as an answer to the third question.

                Regarding the Scrum of Scrums - I have seen a lot of variation in this. The book gives you a suggestion for where to start, but teams should self organize and figure out what works for them.

                Like the Daily Scrum, the purpose of the Scrum of Scrums is to enable self organization. The teams keep each other up to date and warn each other when they may cause each other problems. ("Hey, we want to upgrade the jquery library next week..."). The teams coordinate with *each other*.

                It is not a status update for the benefit of the Product Owner. The status update occurs and the Sprint Review.

                My experience with the SoS between the Scrum Masters has not been very good. The S-M is responsible for Process, not Substance (even worse is if the Scrum Master also has some leadership role, like team leader and/or chief architect). The Team is responsible for the substance.  In a recent project with two teams on two sites, the teams decided to designate one person responsible for each major topic, e.g. build master, architect, technical infrastructure, testing, etc. These people then decided how often they needed to talk to each other, which ranged from once / day, to once per week, depending on how intense the actual problems were. Some of them followed the SoS structure and others did not. This worked much better.

                You question actually touches on one of the philosophical differences (at least as I understand it) between Scrum and CMMI - Scrum says, "ensure the communication and let people self organize and continuously improve". CMMI gets translated to "write it down from the top". As soon as you write it down, the self organization and continuous improvement stop.

                Having the Scrum Master remote (either to the team or two management) is a problem - it makes it difficult to accomplish the primary task, recognize and resolve impediments. Co-location is almost always better, if you can make it happen.

                Personel planning in Scrum should occur at the team level. As a manager, you put a team together, provide them with a coach (the Scrum Master) to help them get the optimal performance out of the team, but let the coach and team worry about how the team actually plays the game. Yes, there will occasionally be changes in the team, but that should happen infrequently. At the program management level, consider the team to be your atomic entity which you manage and allocate to projects.

                Hope this helps,

                Cheers,

                Peter


                Vikas Atri schrieb:
                Dear All,
                We have recently defined initial draft of scrum processes.I am trying to integrate Specific practices from IPM-Integrated project management (at CMMIL3) with SCRUM Planning.
                Problem 1 : The following was the trigger for this thought:
                There are teams following scrum cycle at multiple locations (more than 2 ) with only 1 scrum master and product owner.
                I found it little strange , as to how is possible for scrum master to manage sprint with teams located at multiple locations
                and also stand-up meetings(daily scrum) are really difficult in this scenario.This makes me think that , may be
                it will be good idea if we include some practices from IPM at CMMIL3 to ensure integrated teaming.
                I am looking at two aspects:
                Involving scrum teams (from multiple locations with only one scrum master or may be 2) effectively in sprint planning
                Involving scrum teams (from multiple locations with only one scrum master or may be 2) effectively in sprint execution and closure
                 
                Just to share my thought on :
                Daily scrums:
                Here scrum master sets up daily scrum meeting with the Scrum Team for 10-15 mins.
                Typically focus is on:
                • What was done yesterday?
                • What is planned for today/next working day?
                • What are the impediments faced?
                • What the status of previously identified impediments?

                Scrum of scrums:
                Here scrum master (scrum masters , in case of multiple scrum masters) sets up weekly scrum meeting with PO and update the status
                of sprint in terms of:
                • What was done last week?
                • What is the plan for next week?
                • What are the impediments faced
                Problem 2 : When does really the resource allocation takes place in scrum.To my knowledge, scrum is project management methodology.
                I have no where found planning for resources (human and non-human).Is it during the release planning or sprint planning.To my knowledge during the release planning the scrum master may get involved the very first time,but I am not sure, if the scrum team is really decided here at this stage.Request someone to guide me on this.
                 
                I need expert advice on whether my thought (in problem 1) is feasible and if yes, has anyone done this earlier and what chalenges are there in doing it.
                It will be really great, if anyone amongst you can throw some light on it.I have already referred to couple of websites on agile-scrum, but they do not address my 2 problems.
                 
                Regards,
                Vikas




                From: Ron Jeffries <ronjeffries@ acm.org>
                To: scrumdevelopment@ yahoogroups. com
                Sent: Friday, 22 May, 2009 6:52:19 AM
                Subject: Re: [scrumdevelopment] Hyper productive.. .

                Hello, Tobias. On Thursday, May 21, 2009, at 6:46:40 PM, you
                wrote:

                > I agree with Adam, this "hyper-productivity " measuring is
                > mostly a waste of time -- and a way of selling snake oil. 
                > 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'm not sure why I think this, not having visited them, but my money
                says Jeff's teams really do kick butt. And he does have some
                external productivity measures that back that up ...

                Ron Jeffries
                www.XProgramming. com
                www.xprogramming. com/blog
                The lyf so short, the craft so long to lerne. -- Geoffrey Chaucer



                Explore and discover exciting holidays and getaways with Yahoo! India Travel Click here!


                -- 
                Peter Stevens, CSM, CSP
                Ken Schwaber CSM Training in Zürich: www.tinyurl.com/Ken-in-ZH
                www.scrum-breakfast.com
                tel: +41 44 586 6450 
                
              • jaibeer_malik
                Hi Vikas, One of the major things you need to do for the distributed teams is that how efficiently you can handle the communication between the teams. I did a
                Message 7 of 22 , May 21, 2009
                • 0 Attachment
                  Hi Vikas,

                  One of the major things you need to do for the distributed teams is that how efficiently you can handle the communication between the teams. I did a write some time back for the distributed teams to handle typical scrum meetings in case of distributed teams with some overlap time difference and with no overlapping time difference.

                  http://jaibeermalik.wordpress.com/2009/03/30/sprint-in-action-typical-vs-distributed-team/

                  This can give you some idea:
                  -how you can break up the stanup into local and distributed stanups.
                  -how you can break the planning meetings into first and second part of planning meetings etc.
                  -how can you share demo updated with other teams
                  -what you can do in terms of communication and knowledge sharing.

                  And to have a local Scrum master can definitely help the team in terms of communication and resolving the impediments more effectively.


                  -Jai

                  --- In scrumdevelopment@yahoogroups.com, Vikas Atri <vikasait25@...> wrote:
                  >
                  > Dear All,
                  > We have recently defined initial draft of scrum processes.I am trying to integrate Specific practices from IPM-Integrated project management (at CMMIL3) with SCRUM Planning.
                  > Problem 1 : The following was the trigger for this thought:
                  > There are teams following scrum cycle at multiple locations (more than 2 ) with only 1 scrum master and product owner.
                  > I found it little strange , as to how is possible for scrum master to manage sprint with teams located at multiple locations
                  > and also stand-up meetings(daily scrum) are really difficult in this scenario.This makes me think that , may be
                  > it will be good idea if we include some practices from IPM at CMMIL3 to ensure integrated teaming.
                  > I am looking at two aspects:
                  > Involving scrum teams (from multiple locations with only one scrum master or may be 2) effectively in sprint planning
                  > Involving scrum teams (from multiple locations with only one scrum master or may be 2) effectively in sprint execution and closure
                  >
                  > Just to share my thought on :
                  > Daily scrums:
                  > Here scrum master sets up daily scrum meeting with the Scrum Team for 10-15 mins.
                  > Typically focus is on:
                  > • What was done yesterday?
                  > • What is planned for today/next working day?
                  > • What are the impediments faced?
                  > • What the status of previously identified impediments?
                  >
                  > Scrum of scrums:
                  > Here scrum master (scrum masters , in case of multiple scrum masters) sets up weekly scrum meeting with PO and update the status
                  > of sprint in terms of:
                  > • What was done last week?
                  > • What is the plan for next week?
                  > • What are the impediments faced
                  >
                  > Problem 2 : When does really the resource allocation takes place in scrum.To my knowledge, scrum is project management methodology.
                  > I have no where found planning for resources (human and non-human).Is it during the release planning or sprint planning.To my knowledge during the release planning the scrum master may get involved the very first time,but I am not sure, if the scrum team is really decided here at this stage.Request someone to guide me on this.
                  >
                  > I need expert advice on whether my thought (in problem 1) is feasible and if yes, has anyone done this earlier and what chalenges are there in doing it.
                  > It will be really great, if anyone amongst you can throw some light on it.I have already referred to couple of websites on agile-scrum, but they do not address my 2 problems.
                  > www.implementingscr um.com
                  > www.mountaingoatsof tware.com
                  > www.scrumalliance. org
                  >
                  > Regards,
                  > Vikas
                  >
                  >
                  >
                  >
                  >
                  > ________________________________
                  > From: Ron Jeffries <ronjeffries@...>
                  > To: scrumdevelopment@yahoogroups.com
                  > Sent: Friday, 22 May, 2009 6:52:19 AM
                  > Subject: Re: [scrumdevelopment] Hyper productive...
                  >
                  >
                  >
                  >
                  >
                  > Hello, Tobias. On Thursday, May 21, 2009, at 6:46:40 PM, you
                  > wrote:
                  >
                  > > I agree with Adam, this "hyper-productivity " measuring is
                  > > mostly a waste of time -- and a way of selling snake oil. 
                  > > 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'm not sure why I think this, not having visited them, but my money
                  > says Jeff's teams really do kick butt. And he does have some
                  > external productivity measures that back that up ...
                  >
                  > Ron Jeffries
                  > www.XProgramming. com
                  > www.xprogramming. com/blog
                  > The lyf so short, the craft so long to lerne. -- Geoffrey Chaucer
                  >
                  >
                  >
                  >
                  >
                  > Explore and discover exciting holidays and getaways with Yahoo! India Travel http://in.travel.yahoo.com/
                  >
                • Joseph Little
                  Hi, I will extend Ron s thought. I agree there can be a lot of gush in talk about hyperproductivity. This does not mean all talk about hyperproductivity is
                  Message 8 of 22 , May 21, 2009
                  • 0 Attachment
                    Hi,

                    I will extend Ron's thought.

                    I agree there can be a lot of gush in talk about hyperproductivity. This does not mean all talk about hyperproductivity is gush.

                    Specifically, I think it is the more adult teams that challenge themselves to become hyperproductive (and at the same time use known velocity to push back at those magical-thinking managers who "demand" double the productivity in one Sprint...this 2nd use seems contradictory to the 1st, but still right and important).

                    While I agree that delivery of BV is more important, teams must have a known velocity (at least for the 2 reasons mentioned above).

                    And, having the known velocity, they must say "which impediments do we remove to double velocity?" Usually the comment comes back: "Well, if we just make a few minor changes, we can't double productivity (velocity)!" And then someone must say: "OK, let's make major changes. What do we have to change?" (Ron might well say, "right, and that's why we call it extreme programming".)

                    A velocity measure (and a velocity challenge) allows you to learn which impediments removed will lead to greater velocity. In a fact-based way, rather than hand-waving and stamping of feet.

                    As to others' comments about BV. Yes, important. From my experience, usually I find that teams need some minimal help first with BV. Then need to get a known velocity. Then need to focus on removing impediments so that improvement is demonstrable. And then can come back to improving what I will call BV Engineering.

                    How: Well, if I were doing Shock Therapy, I would take the average Velocity of the 1st three sprints. I would also gut check with key people that "if you had to guess, does this feel like as productive on avg as we used to be??" Usually they have no clue, but at least the avg seems like as reasonable a baseline as we can get (usually somewhat high). Then the next challenge, to the team as professionals, is to figure out what to change to double the velocity.
                    Often one must say forcefully "No, we don't want muri!!" (overstressing the system).

                    One might say the whole thing is like a koan. It is only by transcending seeming contradictions that the team bursts through to a new level of productivity.

                    To a lot of the complaints some of you have about this: you are looking at explicit things and ignoring the Tacit Knowledge. The Team and the Coach must have established the right relationship. Done badly, yes this could be bad. Done by the right coach (and, yes, the right Team), this is completely in alignment with Agile principles. And successful...for the customers, for the workers, for the stakeholders.

                    To another complaint: Yes, this is all problematic. (Ex: fudging the metrics.) Yes, and all of life is problematic. You know enough already to make it work. Tell the truth, work hard (in a reasonable timebox), be creative.

                    Let me be a tad blunter: Things are so screwed up in SW dev, that doubling a team's productivity is not that hard. Still, this approach is not a silver bullet, and, for many reasons, it might fail. Is that a good reason not to try it (assuming you are competent to do so)?

                    Hyperproductivity is defined as at least 4x normal productivity (the best data say normal is 2 Function Points per Developer Month). So, 2x is not there yet. But if you can get to 2x, you can get to 4x.

                    Regards, Joe



                    --- In scrumdevelopment@yahoogroups.com, Ron Jeffries <ronjeffries@...> wrote:
                    >
                    > Hello, Tobias. On Thursday, May 21, 2009, at 6:46:40 PM, you
                    > wrote:
                    >
                    > > I agree with Adam, this "hyper-productivity" measuring is
                    > > mostly a waste of time -- and a way of selling snake oil. 
                    > > 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'm not sure why I think this, not having visited them, but my money
                    > says Jeff's teams really do kick butt. And he does have some
                    > external productivity measures that back that up ...
                    >
                    > Ron Jeffries
                    > www.XProgramming.com
                    > www.xprogramming.com/blog
                    > The lyf so short, the craft so long to lerne. -- Geoffrey Chaucer
                    >
                  • Adam Sroka
                    ... I suspect that is true. And, I didn t read the article the OP referred to. Possibly their analysis was quite informative. I just don t think there is much
                    Message 9 of 22 , May 22, 2009
                    • 0 Attachment
                      On Thu, May 21, 2009 at 6:22 PM, Ron Jeffries <ronjeffries@...> wrote:
                      >
                      >
                      > Hello, Tobias. On Thursday, May 21, 2009, at 6:46:40 PM, you
                      > wrote:
                      >
                      >> I agree with Adam, this "hyper-productivity" measuring is
                      >> mostly a waste of time -- and a way of selling snake oil.
                      >> 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'm not sure why I think this, not having visited them, but my money
                      > says Jeff's teams really do kick butt. And he does have some
                      > external productivity measures that back that up ...
                      >

                      I suspect that is true. And, I didn't read the article the OP referred
                      to. Possibly their analysis was quite informative.

                      I just don't think there is much point in trying to quantify
                      productivity. Even if I could demonstrate and improvement in velocity,
                      what does that mean? Is it likely that if I attempt to double my
                      velocity I will succeed? Does than necessarily mean I will double (or
                      even increase, or even not *decrease*) the value I produce?

                      The following measure is good enough for me:

                      Value produced in iteration one: some.
                      Value produced in iteration two: some more.

                      :-)
                    • Ron Jeffries
                      ... One of the big lessons to be found in the ball-tossing game is that we can improve our work ... get some more ... or /change/ our work ... and get a lot.
                      Message 10 of 22 , May 22, 2009
                      • 0 Attachment
                        Hello, Adam. On Friday, May 22, 2009, at 3:17:49 AM, you wrote:

                        > The following measure is good enough for me:

                        > Value produced in iteration one: some.
                        > Value produced in iteration two: some more.

                        One of the big lessons to be found in the ball-tossing game is that
                        we can improve our work ... get "some more" ... or /change/ our work
                        ... and get a lot.

                        Ron Jeffries
                        www.XProgramming.com
                        www.xprogramming.com/blog
                        A man hears what he wants to hear, and disregards the rest. -- Paul Simon
                      • Vikas Atri
                        Jai/Peter,   Thanks a lot for inputs.Inputs were really valuable and Infact it has helped me to some degree. Let me elaborate you my thoughts, I was trying
                        Message 11 of 22 , May 22, 2009
                        • 0 Attachment

                          Jai/Peter,

                           

                          Thanks a lot for inputs.Inputs were really valuable and Infact it has helped me to some degree.

                          Let me elaborate you my thoughts, I was trying to use CMMI reference at CMMIL3,IPM which has added IPPD (integrated product and process development) steps that enables achieving  a timely collaboration of relevant stakeholders throughout the product lifecycle to better satisfy customer needs

                          Infact, I found it interesting and I was trying to adopt them to our scrum processes mainly sprint planning, execution, and closure processes:

                           

                          Below are the practices mentioned and what is expected after implementing the practice.

                          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)

                           

                          Practice 2:  Establish the Integrated Team Structure

                          Expected:

                          a. Assessments of the product and product architectures, including risk and complexity

                          b. Integrated team structure

                           

                          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

                           

                          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

                           

                          5. Ensure Collaboration among Interfacing Teams

                          Expected: a. Work product ownership agreements

                                      b. Team work plans

                                      c. Commitment lists

                          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.

                           

                          Regards,

                          Vikas




                          From: jaibeer_malik <jaibeer_malik@...>
                          To: scrumdevelopment@yahoogroups.com
                          Sent: Friday, 22 May, 2009 12:03:04 PM
                          Subject: [scrumdevelopment] Re: IPM @CMMIL3

                          Hi Vikas,

                          One of the major things you need to do for the distributed teams is that how efficiently you can handle the communication between the teams. I did a write some time back for the distributed teams to handle typical scrum meetings in case of distributed teams with some overlap time difference and with no overlapping time difference.

                          http://jaibeermalik .wordpress. com/2009/ 03/30/sprint- in-action- typical-vs- distributed- team/

                          This can give you some idea:
                          -how you can break up the stanup into local and distributed stanups.
                          -how you can break the planning meetings into first and second part of planning meetings etc.
                          -how can you share demo updated with other teams
                          -what you can do in terms of communication and knowledge sharing.

                          And to have a local Scrum master can definitely help the team in terms of communication and resolving the impediments more effectively.

                          -Jai

                          --- In scrumdevelopment@ yahoogroups. com, Vikas Atri <vikasait25@ ...> wrote:
                          >
                          > Dear All,
                          > We have recently defined initial draft of scrum processes.I am trying to integrate Specific practices from IPM-Integrated project management (at CMMIL3) with SCRUM Planning.
                          > Problem 1 : The following was the trigger for this thought:
                          > There are teams following scrum cycle at multiple locations (more than 2 ) with only 1 scrum master and product owner.
                          > I found it little strange , as to how is possible for scrum master to manage sprint with teams located at multiple locations
                          > and also stand-up meetings(daily scrum) are really difficult in this scenario.This makes me think that , may be
                          > it will be good idea if we include some practices from IPM at CMMIL3 to ensure integrated teaming..
                          > I am looking at two aspects:
                          > Involving scrum teams (from multiple locations with only one scrum master or may be 2) effectively in sprint planning
                          > Involving scrum teams (from multiple locations with only one scrum master or may be 2) effectively in sprint execution and closure
                          >
                          > Just to share my thought on :
                          > Daily scrums:
                          > Here scrum master sets up daily scrum meeting with the Scrum Team for 10-15 mins.
                          > Typically focus is on:
                          > • What was done yesterday?
                          > • What is planned for today/next working day?
                          > • What are the impediments faced?
                          > • What the status of previously identified impediments?
                          >
                          > Scrum of scrums:
                          > Here scrum master (scrum masters , in case of multiple scrum masters) sets up weekly scrum meeting with PO and update the status
                          > of sprint in terms of:
                          > • What was done last week?
                          > • What is the plan for next week?
                          > • What are the impediments faced
                          >
                          > Problem 2 : When does really the resource allocation takes place in scrum.To my knowledge, scrum is project management methodology.
                          > I have no where found planning for resources (human and non-human).Is it during the release planning or sprint planning.To my knowledge during the release planning the scrum master may get involved the very first time,but I am not sure, if the scrum team is really decided here at this stage.Request someone to guide me on this.
                          >
                          > I need expert advice on whether my thought (in problem 1) is feasible and if yes, has anyone done this earlier and what chalenges are there in doing it.
                          > It will be really great, if anyone amongst you can throw some light on it.I have already referred to couple of websites on agile-scrum, but they do not address my 2 problems.
                          > www.implementingscr um.com
                          > www.mountaingoatsof tware.com
                          > www.scrumalliance. org
                          >
                          > Regards,
                          > Vikas
                          >
                          >
                          >
                          >
                          >
                          > ____________ _________ _________ __
                          > From: Ron Jeffries <ronjeffries@ ....>
                          > To: scrumdevelopment@ yahoogroups. com
                          > Sent: Friday, 22 May, 2009 6:52:19 AM
                          > Subject: Re: [scrumdevelopment] Hyper productive... .
                          >
                          >
                          >
                          >
                          >
                          > Hello, Tobias. On Thursday, May 21, 2009, at 6:46:40 PM, you
                          > wrote:
                          >
                          > > I agree with Adam, this "hyper-productivity " measuring is
                          > > mostly a waste of time -- and a way of selling snake oil. 
                          > > 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'm not sure why I think this, not having visited them, but my money
                          > says Jeff's teams really do kick butt. And he does have some
                          > external productivity measures that back that up ...
                          >
                          > Ron Jeffries
                          > www.XProgramming. com
                          > www.xprogramming. com/blog
                          > The lyf so short, the craft so long to lerne. -- Geoffrey Chaucer
                          >
                          >
                          >
                          >
                          >
                          > Explore and discover exciting holidays and getaways with Yahoo! India Travel http://in.travel. yahoo.com/
                          >



                          Explore your hobbies and interests. Click here to begin.
                        • Petri Heiramo
                          Hi, Some comments, then a story. Comments first. ... Expected: PO has defined and shared the project vision and mission with development team(s) and
                          Message 12 of 22 , May 23, 2009
                          • 0 Attachment
                            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
                          • 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 13 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 14 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 15 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 16 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 17 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 18 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 19 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 20 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 21 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 22 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.