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

Re: [scrumdevelopment] Design vs delivery

Expand Messages
  • George Dinwiddie
    ... When you mention over designing and technical debt together like this, it make me think there s a misunderstanding. Let me describe the way I look at
    Message 1 of 11 , Jun 5, 2009
    • 0 Attachment
      inanc_gumus wrote:
      > Hello,
      >
      > I am a SM, and one of my team members said to me that: 'Even we
      > couldn't delivered our committed stories PO didn't get angry w/us. I
      > think PO might angry in these situations, so we can know where to
      > stop over designing. He should decide whether technical debt is
      > accepted or not. So we can deliver what he wants'.

      When you mention "over designing" and "technical debt" together like
      this, it make me think there's a misunderstanding. Let me describe the
      way I look at these and you can tell me if that's the way you intend, or
      if you mean something else.

      I highly recommend designing for the current functionality, only. That
      doesn't mean that I don't /think/ about what I expect to need in the
      future. I do that all the time. Sometimes it influences the choices I
      make so as to not "paint myself into a corner." I'm careful, however,
      not to add flexibility for the future. I can always add that
      flexibility when I need it.

      Technical debt, to me, means that the code I've written isn't as clear
      and clean as I can make it. Perhaps a method is misnamed, and doesn't
      quite do what its name says it does. Perhaps a method or class is
      taking responsibility for two different things. Perhaps a piece of code
      is operating on multiple levels of abstraction. Perhaps there is
      duplication, either obvious or subtle.

      These are the sorts of things that I want to clean up to reduce
      technical debt.

      > I think, PO should not decide whether the team can have technical
      > debt or not. Especially on design. I think, the team should deliver
      > stories as 'done done', which contains refactored design too.

      Perhaps you could describe an example or two of what you mean by
      refactoring the design.

      > What do you think? Should PO have a word on technical debt especially
      > with design?

      Generally, I think not. When the technology itself is the product, then
      the design may be a legitimate concern of the PO. Otherwise, I think
      the PO should focus on the benefits desired from the design, not the
      features of the design.

      - George

      --
      ----------------------------------------------------------------------
      * George Dinwiddie * http://blog.gdinwiddie.com
      Software Development http://www.idiacomputing.com
      Consultant and Coach http://www.agilemaryland.org
      ----------------------------------------------------------------------
    • 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 2 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 3 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 4 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.