Re: [scrumdevelopment] Design vs delivery
- inanc_gumus wrote:
> Hello,When you mention "over designing" and "technical debt" together like
> 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'.
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
> I think, PO should not decide whether the team can have technicalPerhaps you could describe an example or two of what you mean by
> debt or not. Especially on design. I think, the team should deliver
> stories as 'done done', which contains refactored design too.
refactoring the design.
> What do you think? Should PO have a word on technical debt especiallyGenerally, I think not. When the technology itself is the product, then
> with design?
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 Dinwiddie * http://blog.gdinwiddie.com
Software Development http://www.idiacomputing.com
Consultant and Coach http://www.agilemaryland.org
- 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.