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

36324Re: [scrumdevelopment] Flaccid Scrum ...

Expand Messages
  • George Dinwiddie
    Feb 1, 2009
      Hi, Robin,

      Re-reading Martin Fowler's posting, then I think it's overstating the
      case to say he's blaming Scrum for technical debt. Surely the team's
      technical practices don't worsen just because they're doing Scrum.

      The situation he describes, an improvement in software development
      [implied in the article] followed by a slowdown [specifically
      mentioned], is a case of the technical issues being more visible because
      they're no longer hidden in other issues. I certainly agree with you there.

      - George

      Robin Dymond wrote:
      > I think Martin raises some good points, and cose to respond to the blog
      > with a blog.
      > I also think he missed the point of visibility by blaming Scrum for
      > technical debt, when Scrum actually made the debt visible.
      > http://www.innovel.net/?page_id=13
      >
      > cheers,
      > Robin Dymond.
      >
      > On Fri, Jan 30, 2009 at 6:46 PM, George Dinwiddie
      > <lists@... <mailto:lists@...>> wrote:
      >
      > Kane Mar wrote:
      > > I personally think that he makes a good point, and his article is
      > a timely reminder that good
      > > engineering practices (Continuous Integration, TDD and
      > Refactoring) are all very important.
      > >
      > > Anyway, here's the article:
      > http://martinfowler.com/bliki/FlaccidScrum.html
      >
      > Agreed, and thanks for the pointer.
      >
      > In my experience, most organizations have much room to improve both
      > their project management and their technical engineering practice.
      > Those that start with Scrum seem to improve their project management
      > practice enough that the deficiencies in their technical engineering
      > practice become more painfully obvious.
      >
      > The answer is simple and obvious--improve the technical engineering
      > practice. The way to do that is not so easy, however.
      >
      > For example, Tim Walker suggests "Attention to technical excellence and
      > hiring motivated people are required for it to be successful." As true
      > as this is, it's no way for an organization to get from where it is
      > to a
      > desired state of being able to reliably create desired functionality in
      > their software.
      >
      > People cannot suddenly be attentive to technical excellence. They must
      > slowly acquire the awareness and deeper understanding that they
      > lack, or
      > they would already be attentive. Hiring motivated people suggests that
      > those doing the hiring will suddenly be able to understand what sort of
      > motivation is required, how to discern it in candidates, and follow
      > through with this criteria in preference to the criteria they've
      > been using.
      >
      > And what would you do with the people you have now? Those that are
      > presumably not motivated toward technical excellence? Fire them all and
      > replace them? This is the HR equivalent to the total rewrite of a
      > legacy application, and it has some of the same problems. There is a
      > lot of domain knowledge hidden in there--knowledge that would be
      > difficult to find written down anywhere. The new must achieve the
      > competency of the old before it can begin to surpass it--until then, no
      > benefit is seen. The new will be starting in the same context as the
      > old, and therefore is likely to produce something with a similar
      > organization (or lack thereof).
      >
      > The bottom line is that the developers have to learn to /recognize/
      > what
      > is "better," they have to learn how to /do/ it, and the cultural
      > context
      > in which they work has to change such that it really is important
      > enough
      > to have happen. Depending on where you start, that's a lot to change
      > all at once. It can take a lot of time and energy.

      --
      ----------------------------------------------------------------------
      * George Dinwiddie * http://blog.gdinwiddie.com
      Software Development http://www.idiacomputing.com
      Consultant and Coach http://www.agilemaryland.org
      ----------------------------------------------------------------------
    • Show all 30 messages in this topic