- Scott, I think you are right, for large companies, complex product projects, working together is unusual. What we are hoping to do, and it is indeed aMessage 1 of 79 , Mar 1 9:20 AMView SourceScott,I think you are right, for large companies, complex product projects, working together is unusual. What we are hoping to do, and it is indeed a daunting task, is make it common.
Not sure where you got "documents" in what I said - I just said "review". What you do with the customer at the end of an iteration is a review. That's what I'm talking about - the Baseline is a point where everybody looks at the current state of things and provides feedback.
Working together is fine, if you can do it, but for large company, complex product projects, it's unusual. Again, the components develop on different schedules, making it unlikely that everybody is working on the project all the time over the life of the project. Teams will ramp up and down depending on how long their involvement in the project is. And, of course, in most large companies the people are likely to be in different places - silicon designers in a facility that has fabs, hardware people in a facility with bench spaces.
--- In scrumdevelopment@ yahoogroups. com, George Dinwiddie <lists@...> wrote:
> You can do it high-ceremony if you want, communicating though
> It certainly doesn't have to be that way, though. I don'trecommend
> it; it's too easy for things to go off-track but un-noticed.Then those
> baselined documents are just used for apportioningblame.
>ARE separate things, done by different
> scott preece wrote:
> > On the other hand, they
> > people, using differentdesign tools, under different constraints.
> > Concurrent engineeringis important - you want to have all aspects of
> > the project workingclosely together on design, constant
> > communication about thedetails, and regular iterative review (at the
> > Baselines).------------ --------- --------- --------- --------- --------- -
> Yes, but those people don't have to be working separately. That
> "regular iterative review" can be daily, in conversation.
> - George
>* George Dinwiddie * http://blog. gdinwiddie. com
>Software Development http://www.idiacomp uting.com
>Consultant and Coach http://www.agilemar yland.org
>------------ --------- --------- --------- --------- --------- -
- 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, andMessage 79 of 79 , Apr 20, 2010View SourceOn 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.
--- In email@example.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.
> 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