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

36322Re: [scrumdevelopment] Flaccid Scrum ...

Expand Messages
  • Robin Dymond
    Feb 1, 2009
      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.

      Robin Dymond.

      On Fri, Jan 30, 2009 at 6:46 PM, George Dinwiddie <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

      * George Dinwiddie * http://blog.gdinwiddie.com
      Software Development http://www.idiacomputing.com
      Consultant and Coach http://www.agilemaryland.org

      Robin Dymond, CST
      Managing Partner, Innovel, LLC.
      (804) 239-4329
    • Show all 30 messages in this topic