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

Re: [scrumdevelopment] Re: Increasing Sustainable Pace

Expand Messages
  • George Dinwiddie
    ... You might consider strategies other than more hours then. Do not assume that those who are suspicious of more hours as a strategy for speeding up
    Message 1 of 32 , Apr 13, 2008
      henrikjernevad wrote:
      > And I also want to point out, that the question I try raise is not
      > "how do I make those other lazy bastards work faster", but "how can I
      > make my team, myself included, work at the top of our capacity without
      > risking the health of our people or the project."

      You might consider strategies other than "more hours" then. Do not
      assume that those who are suspicious of "more hours" as a strategy for
      speeding up development have "given up" and "quit trying."

      You might consider bringing it up with the team, and letting them
      discuss it. Not only will the appropriate approaches vary from context
      to context and team to team, but also from team member to team member.
      Better, bring in a skilled retrospectives facilitator to bring it up
      with the team. Little will be gained if the team discusses it in a
      meeting lead with a particular outcome in mind.

      Increasing hours is, in my experience, the least fruitful way to get
      more done in the software development field. It's a choice that fits
      H.L. Mencken's description of "simple, obvious, and wrong." As Alistair
      Cockburn has so delightfully described, people are non-linear systems.
      Expecting a linear relationship between input (more hours) and output
      (quicker accomplishment) is misguided. Like storing items by throwing
      them up into the air, it works only for short periods of time.

      If you think of the development team as a system composed on non-linear
      components, you can apply systems thinking to good advantage. If you
      do, you'll quickly realize that making decisions based on the input to
      the system (e.g. number of hours worked) will not work nearly so well as
      basing it on the output. Monitoring the pace at which the system is
      produced as you try different things might be more fruitful for you. I
      caution you not to overlook other outputs that you probably desire, such
      as producing the right system (for some definition of right, which you
      should clearly understand). I suggest Jerry Weinberg's book, Quality
      Software Management, Vol. 1: Systems Thinking, on this topic.

      - George

      * George Dinwiddie * http://blog.gdinwiddie.com
      Software Development http://www.idiacomputing.com
      Consultant and Coach http://www.agilemaryland.org
    • henrikjernevad
      ... Thanks for noticing. ;-) That was the main thought I had when I wrote the blog post as well. Unfortunately, however, I don t think it came across all too
      Message 32 of 32 , Apr 13, 2008
        --- In scrumdevelopment@yahoogroups.com, "Joseph Little"
        <jhlittle@...> wrote:

        > Within your post is a great idea: that we should never be satisfied
        > with what we have accomplished. And should always be looking at
        > ways to get better.

        Thanks for noticing. ;-) That was the main thought I had when I wrote
        the blog post as well. Unfortunately, however, I don't think it came
        across all too well.

        > However, in my view you are stuck on one mode of measurement that is
        > not terribly relevant: number of hours worked.

        I believe you are right (as are most others who've commented in this
        thread). Number of hours isn't *the* best metric. It's unclear if it
        is good metric at all. Anyhow, it's the wrong place to start.

        > There are lots of associated issues (technical debt, motivation,
        > etc), but that's too much for a post here.

        It is those associated issues I was hoping to discuss here. As I wrote
        in the article, I believe motivation and discipline are two of the
        main factors in this equation. In retrospect, I regret mentioning
        working hours. I believe the main idea is very much valid without a
        specific reference to hours.
      Your message has been successfully submitted and would be delivered to recipients shortly.