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

RE: [scrumdevelopment] Re: Baselining and Scrum

Expand Messages
  • Roy Morien
    What exactly are these deltas that you refer to? Is a new requirement that arises out of a product demonstration a delta ? Is a change to exisitng code a
    Message 1 of 79 , Mar 1, 2010
    • 0 Attachment
      What exactly are these 'deltas' that you refer to? Is a new requirement that arises out of a product demonstration a 'delta'? Is a change to exisitng code a 'delta'? I don't quite understand. I also don't quite understand how you would quantify 'deltas'. 
       
      I sort of get the idea that many of these terms, and suggested practices, are reminiscent of scientfic management, almost Taylorism. Or are these terms being used to try to give some 'substance' to development practices?
       
      Regards,
      Roy Morien
       

      To: scrumdevelopment@yahoogroups.com
      From: john_hermann@...
      Date: Mon, 1 Mar 2010 01:25:42 +0000
      Subject: [scrumdevelopment] Re: Baselining and Scrum

       


      Yes, baselining seems to be fairly non-agile, and rooted in traditional PM. It exists mostly for logistics (vs. development) projects, where a lot can be known up-front, and hence there is little "excuse" to deviate from plan. When you do deviate, management wants to see the deltas of "actuals" from plan/"baseline" , to see what went "wrong", to create indexes, to make predictions, etc. Such deltas are checked frequently to make sure that the output is not going off track, or out of budget, or off schedule.

      In Scrum, such a delta comparison occurs when comparing velocity sprint to sprint, and making predictions about what can be accomplished in the next sprint based on the previous one(s). Since sprints are short, the "check" occurs frequently enough, and since sprints are ideally "atomic" in scope, no deviations from "baseline" should occur intra-sprint. (There are always exceptions.) So I agree with whoever it was who said earlier that Scrum already takes care of the needs of baselining.

      Also, as has been mentioned elsewhere, a performing team will eventually stabilize into a fairly regular velocity. Perhaps story points can even be eliminated, thus counting only the number of stories themselves. If the team changes, or has not stabilized, then the "baselining" of Scrum helps keep things organized.

      -johnny

      --- In scrumdevelopment@ yahoogroups. com, Monde Hans <monde.hans@ ...> wrote:
      >
      > Baselining to done for Control and Configuration management.
      > Like tracking all the variances from the plan and Change Management.
      > Agile does not have this.
      >
      > M.
      >
      > On Tue, Feb 23, 2010 at 2:53 PM, <sharmila.patwardha n@...> wrote:
      >
      > >
      > >
      > > I some how disagree that baselining does not welcome changes..... ...
      > > Baselining is only about knowing what needs to be done and in case of
      > > changes which all places it would impact
      > >
      > >
      > >
      > > Best regards,
      > >
      > > *Sharmila Patwardhan*, Sr. Q&P Consultant
      > > *Tieto*
      > >
      > >
      > > ------------ --------- ---------
      > > *From:* scrumdevelopment@ yahoogroups. com [mailto:
      > > scrumdevelopment@ yahoogroups. com] *On Behalf Of *Ron Jeffries
      > > *Sent:* Tuesday, February 23, 2010 17:48
      > >
      > > *To:* scrumdevelopment@ yahoogroups. com
      > > *Subject:* Re: [scrumdevelopment] Re: Baselining and Scrum
      > >
      > >
      > >
      > > Hello, sharmila. On Monday, February 22, 2010, at 10:35:10 PM,
      > >
      > > you wrote:
      > >
      > > > Another thing about baselining was if the stories have a scope
      > > > change as per the baseline, in a time and material kind of
      > > > contract the customer has to agree to pay the additional cost or
      > > > bare the consequences of the change.
      > >
      > > Baselining assumes that change is bad. Agile assumes that change is
      > > good.
      > >
      > > Ron Jeffries
      > > www.XProgramming. com
      > > www.xprogramming. com/blog
      > > The lyf so short, the craft so long to lerne. -- Geoffrey Chaucer
      > >
      > >
      > >
      >
      >
      >
      > --
      > I keep six honest serving-men (They taught me all I knew); Their names are
      > What and Why and When And How and Where and Who.
      >




      Browse profiles for free! View photos of singles in your area.
    • woynam
      On top of that, the project is measured against the plan. It s assumed that the plan is handed down from the Almighty on High, i.e. the Project Manager, and
      Message 79 of 79 , Apr 20, 2010
      • 0 Attachment
        On top of that, the project is measured against the plan. It's assumed that the plan is handed down from the Almighty on High, i.e. the Project Manager, and must therefore be correct. Any deviation from the plan *must* be the fault of the team, and not the plan.

        How about if we turn it around? I'm going to invent a new metric that measures the worthlessness of the plan. The more the project deviates from the plan, the more shit we'll heap on the PM.

        Now, I just need a catchy name.

        Mark

        --- In scrumdevelopment@yahoogroups.com, Alan Dayley <alandd@...> wrote:
        >
        > In my simplistic opinion, a project has earned zero value until the end
        > customer starts using it. Therefore, it does not matter to earned value how
        > much "requirements gathering, planning, work breakdown, estimates, etc." is
        > performed or how long doing all that takes. If the customer doesn't have
        > some sort of usable product in his hands, earned value is zero.
        >
        > This is not the definition of "planned value" or "earned value" followed in
        > the article you cite.
        >
        > There is value in a measure that can tell when a project is not progressing
        > as expected. And the whole concept of EVM attempts to provide that measure.
        > And it probably works if you could know everything up front. I don't see
        > how it is anything but an artifact of "big design up front" and a world
        > built on the fantasy that change can be controlled.
        >
        > Alan
        >
        > On Mon, Apr 19, 2010 at 5:09 PM, john_hermann <john_hermann@...>wrote:
        >
        > >
        > >
        > > Hi folks,
        > >
        > > I was referring to baselining as used in traditional PM, in particular
        > > "planned value" in Earned Value Management (EVM) from days of olde. :-)
        > >
        > > See http://en.wikipedia.org/wiki/Earned_value_management
        > > <snip>
        > > Earned value management (EVM) is a project management technique for
        > > measuring project progress in an objective manner. EVM has the ability to
        > > combine measurements of scope, schedule, and cost in a single integrated
        > > system. When properly applied, EVM provides an early warning of performance
        > > problems. Additionally, EVM promises to improve the definition of project
        > > scope, prevent scope creep, communicate objective progress to stakeholders,
        > > and keep the project team focused on achieving progress.
        > > </snip>
        > >
        > > It is pretty heavy, and works well on projects that have a lot of info
        > > upfront, e.g., requirements gathering, planning, work breakdown, estimates,
        > > etc. So not very agile-friendly.
        > >
        > > However, an agile version has been proposed. See "Monitoring Scrum Projects
        > > with AgileEVM and Earned Business Value (EBV) Metrics", Dan Rawsthorne
        > >
        > > http://www.danube.com/system/files/WP_AgileEVM_and_Earned_Business_Value_Metrics.pdf
        > >
        > > -johnny
        > >
        > >
        > >
        >
      Your message has been successfully submitted and would be delivered to recipients shortly.