Re: Where did I miss the point?
- Lovely - thank you, Pablo.
--- In email@example.com, "Pablo Emanuel"
> here's my 2 cents. I've been working for the last several years as an
> project manager, and all of my projects where done for payingcustomers, so
> scope X time X cost controlling is the bread-and-butter of my job.I've done
> some waterfall projects in the beginning, but I've switched toiterative
> development as soon as I knew RUP, circa 2000-2001.agile
> There are some key points IMHO. First of all, there's a great risk in
> projects of biasing the scope to one specific stakeholder. In everyproject,
> there are a multitude of stakeholders, whose needs must be addressedby the
> project's deliverables and by the project itself. In a traditionalwaterfall
> model, those stakeholders' needs are protected by the project managervia
> the approved (and usually carved in stone) requirements document andproject
> plan. In agile methodologies, there are clearly two categories ofproject,
> stakeholders - the ones that have a voice (in Scrum, that would be the
> product owner and the team), and the ones that don't. If, in your
> that's representative enough, perfect. If it's not, beware!first) is
> The second key point (that, in fact, is a particular case of the
> that one of the key stakeholders in every project is the sponsor - thebe two
> person who's paying the bill (in a contracting scenario, there would
> sponsors - one in the client and one in the supplier - negotiatingstakeholder
> which fraction of the bill would be payed by each part). This
> does have his own needs, and those are the needs that made the projectto be
> done. Healthy projects don't come out of the blue, but from a businesscase;
> and the business case states that the project is worthwhile given thatsome
> constraints (usually cash-flow related - hence involving costs andrevenues
> in time - which, ultimately, reflects in scope, cost, time andquality)
> happen. The business case MUST have a voice, it should be hanging onthe
> wall during the whole project. RUP, for instance, addresses this issuevia
> the vision document, that states why the project has been done, whichwere
> the alternatives and why they have not been chosen, etc. Assume forinstance
> that the business had 2 alternatives for a e-commerce solution, butchose
> one of them because the long-term plan was to move the solution to themake
> Microsoft Azure cloud, and that option was more compatible and would
> the transition simpler. That should drive all the decisions made inthe
> project. A more prosaic and common scenario is when the project onlyis
> economically viable if it costs under X thousand dollars.analysis.
> The third point, related to the first two, is the marginal return
> Iterative development has a great consequence - it gives you many moreall or
> go-no-go options. In a traditional waterfall model either you have it
> you've got nothing. If you choose to stop the project at any point butthe
> very end, you got all the costs and none of the benefits. In iterativeiteration.
> approaches, you should do the go-no-go question at every single
> That means that someone with the go-no-go power should be involved inevery
> single iteration.teams
> My feeling is that some (probably most) of the agile methodologies and
> tend to overlook to some degree the three points above. The sad partis that
> iterative, change-welcoming methodologies enable these points to becovered
> in ways that traditional waterfall approaches never could.iteration
> One approach that worked for me is to have more formal monthly
> assessments, where more stakeholders and the sponsor(s) are involved.So, in
> each of these assessments, we review the new plan (i.e., the newschedule,
> the new scope, the new costs), than decide which part of the scopestill
> makes sense, which part to prioritize (next one or to iterations),which
> fraction of the new costs will be payed by which sponsor, and evenwhether
> the project should move to transition and closing.that
> Best regards,
> Pablo Emanuel
> 2008/12/28 aacockburn acockburn@...
> > Hi, Flavio,
> > First of all, judging from what is written there, it seems you me
> > you did a fabulous job on your first agile project. Please patyourself
> > (ves) on your back(s). From where you started to where you got lookscan
> > great as far as I can see. The problems you describe are those that
> > affect any group of people.trickier.
> > Second - I don't think content vs functionality is the problem or
> > question for you. The question, to my mind, is considerably
> > I'll wait and see what others offer, but personally, I'm seeing thisas
> > a core issue for agile projects to address. Maybe I'm just in a darkresult of
> > tunnel this week and someone else will suggest something that I'm
> > "obviously" overlooking.
> > The matter is balancing cost and benefit on a micro-basis. The
> > not having the balance is "feature-fiddling" or undetected scopecreep.
> > Normally, or in the olden days, (for some definition of "normally"
> > "olden days"), there have been a couple of factors to stop thefeature
> > fiddling or undetected scope creep.to
> > * On a fixed-price, fixed-scope project, the contractor has so much
> > lose by humoring the sponsor's extra requests that there is anatural
> > counterbalance to those requests.adjustments
> > * On a project with a tight delivery deadline (most projects :), the
> > time factor itself provides a counterbalance to those requests.
> > * In "conventional" projects, the sponsor is away from the scene of
> > action, and so there is a Product Manager/Owner person present, who
> > arm-wrestles with the tech lead over what new features or
> > can get made in the time and money available. Their argumentsprovide
> > the counterbalance to those requests.and
> > But if the sponsor has a little more time and a little more money,
> > doesn't mind making changes to get a better result, then there areno
> > natural counterbalances to those requests, and it seems to me thatthe
> > sponsor can easily get caught in a state where he/she OKs a bunch ofto
> > requests that individually are small and good, but collectively do
> > something bad to the time or budget.
> > What seems to me to be a possible antidote is to arrange for someone
> > play devil's advocate on changes - that is, someone plays "time xmoney
> > x scope" auditor in those discussions so that the sponsor reallysees
> > the costs of the change requests more firstname.lastname@example.org<scrumdevelopment%40yahoogroups.com>,
> > I look forward to seeing what others think.
> > Alistair
> > --- In
> > "Flávio Steffens de Castro"the
> > flavio.steffens@ wrote:
> > >
> > > Hello fellows,
> > >
> > > Im trying to use some agile concepts in my work, to check the best
> > practices
> > > that I can use without fear. The first one that I tried to use was
> > > "deliverables concepts". Since my work was in a website for aclient,
> > Ietc.
> > > tried to divide the website in contents. Something like this:
> > >
> > > 1st iteraction: home section
> > > 2nd iteration: institutional section
> > > 3rd iteraction: energy section
> > > 4th iteraction: "interaction" section (contact us, work with us,
> > allsince
> > > the sections with user interaction)
> > >
> > > The idea was great. I told the client that this will be better
> > theySo,
> > > could approve the iteractions and the content without any problem.
> > inthe
> > > every iteraction we will have an information architecture study,
> > design
> > > study, development and deploy for the client.
> > >
> > > The execution wasnt very good...
> > >
> > > First because the team told me that are better for them to make
> > > architeture of all the site in the beginning and then approve withthe
> > > client. Then, do all the design and approve with the client. Andafter
> > that,me
> > > the development could be in iteraction... but the developers told
> > thatvery
> > > they prefer to build all the website directly... without "section"
> > > iteractions.
> > >
> > > Well, we tried to make the iteractions... even with the team not
> > > confortable.IA
> > >
> > > We finished the home (1st) and the client love to see it done (not
> > orthe
> > > design). We finished it on time.
> > >
> > > Then, all the other sections became late. That wasnt very nice. We
> > failed on
> > > the schedule about 2 or 3 days for each iteraction.
> > >
> > > But besides that, with the client being more closer, he understood
> > > reasons and also helped us to avoid more late states. Mostlybecause
> > heNew
> > > realized that we were late because of his suggestions for each
> > section.
> > > Yeah, I couldn't protect the team from changes during the sprints.
> > > sections arises, contents changed a lot, images and animationsbecame
> > moreearlier
> > > complex than planned. Of course that all this impact in our
> > plan.should
> > > "Respond to changes" was very strong here... maybe not as is
> > be.things
> > >
> > > What I can say now that we finished the work: I made a lot of
> > in thegood
> > > wrong way... and I will try to learn why that happened. But as a
> > point,he
> > > the collaboration with the client make the work more visible! And
> > > understood the late! Because he saw the website being doing duringthe
> > time.needed to
> > > He understood that he made a lot of changes (well, in fact I
> > > remind him a lot about the changes). But even with the late, inthe
> > finalto
> > > the client really LOVED our work. Loved the website and appeared
> > love thewe
> > > relation between us, during the process. And for me, this is a
> > conquest.
> > >
> > > I can say that the client didnt really make HIS job. For example,
> > > delivered the "institutional section" and he aproves it. But inthe
> > end ofalso
> > > the project, he decided to change some contents , pictures and
> > create ameans
> > > sub-section in this one... that should already be approved! That
> > thatshould
> > > we needed to stop our current work to maintain a section that
> > beI
> > > reviewed and approved by the client.
> > >
> > > Well... I only wanted to write a little about this experience that
> > had.the
> > > And try to learn something from you. Where do you think I missed
> > point?
> > > How could I improve?
> > >
> > > Sorry for the long text... night time, just want to write without
> > think too
> > > much :)
> > >
> > > Best wishes
> > >
> > > _____________________
> > > Flavio Steffens de Castro
> > >