Re: [scrumdevelopment] Re: Design vs delivery
- Hello, inanc_gumus. On Friday, June 5, 2009, at 8:26:41 AM, you
> hello Roy,Maybe with a little more pressure, the PO can get them to kill
> --- In email@example.com, Roy Morien <roymorien@...>
>> I am troubled by your statements about the PO being angry about the situation. Having an environment where people can get angry, and thus put stress on others is not a good environment to work in.
> This is what one of the team member said to me. I think he is
> thinking that if PO would apply a pressure on the team, then the
> team would deliver more stories. They can spend less time thinking
> on design. And postponing refactoring it to later sprints.
themselves. That would be more efficient.
If not now, when? -- The Talmud
- On Jun 5, 2009, at 6:51 AM, George Dinwiddie wrote:
> Michael James wrote:I'm pretty sure we're saying the same thing. My experience of designing
>> One nit.... Wouldn't technical debt include anything that raises the
>> cost of future change, including neglected refactoring?
> Not /anything/. Neglected refactoring, yes. Designing for future
> needs, no.
for future needs (which aren't well understood) has been an *increase*
in the cost of future change.
. 5-page illustrated summary of Scrum: http://tinyurl.com/dkyqjs
. An example checklist for serious ScrumMasters: http://tinyurl.com/cvdwor
- (responding to Michael, George)
> > Not /anything/. Neglected refactoring, yes. Designing for futureI've never measured it, but I would think that design for
> > needs, no.
> I'm pretty sure we're saying the same thing. My experience of
> designing for future needs (which aren't well understood) has
> been an *increase* in the cost of future change.
future needs would increase the cost in any case, never mind
how well the needs are understood; never mind how sure we
are that the future requirements will eventually become
current requirements. There would be more to maintain and
there would be time spent on something not immediately
giving return on investment, so delaying RoI.
I would take any drive to design for future needs as an
indicator that the team lacks confidence in their ability
to cope with the future needs once they become current.
Perhaps that lack of confidence is something worth addressing.