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

Re: [scrumdevelopment] Re: Design vs delivery

Expand Messages
  • Ron Jeffries
    Hello, inanc_gumus. On Friday, June 5, 2009, at 8:26:41 AM, you ... Maybe with a little more pressure, the PO can get them to kill themselves. That would be
    Message 1 of 11 , Jun 5, 2009
    • 0 Attachment
      Hello, inanc_gumus. On Friday, June 5, 2009, at 8:26:41 AM, you
      wrote:

      > hello Roy,
      > --- In scrumdevelopment@yahoogroups.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.

      Maybe with a little more pressure, the PO can get them to kill
      themselves. That would be more efficient.

      Ron Jeffries
      www.XProgramming.com
      www.xprogramming.com/blog
      If not now, when? -- The Talmud
    • Michael James
      ... 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
      Message 2 of 11 , Jun 5, 2009
      • 0 Attachment
        On Jun 5, 2009, at 6:51 AM, George Dinwiddie wrote:

        > Michael James wrote:
        >> 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.

        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.


        --mj
        .
        . 5-page illustrated summary of Scrum: http://tinyurl.com/dkyqjs
        . An example checklist for serious ScrumMasters: http://tinyurl.com/cvdwor
        .
      • Paul Oldfield
        (responding to Michael, George) ... I ve never measured it, but I would think that design for future needs would increase the cost in any case, never mind how
        Message 3 of 11 , Jun 6, 2009
        • 0 Attachment
          (responding to Michael, George)

          > > Not /anything/. Neglected refactoring, yes. Designing for future
          > > 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.

          I've never measured it, but I would think that design for
          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.

          Paul Oldfield
          Capgemini
        Your message has been successfully submitted and would be delivered to recipients shortly.