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

Re: [XP] Metaphors Required: Sustainable Pace (and other practices) and Startups

Expand Messages
  • Steve Freeman
    ... If your team is pairing, then a coding session is like taking a hard exam. It s not routine work, and if it is then that work should be automated. One
    Message 1 of 20 , Apr 10 8:34 AM
    • 0 Attachment
      On 7 Apr 2011, at 19:54, Peter Bell wrote:
      > What I *am* getting push back on is the idea of sustainable pace. Idea X, after all, is the one true idea that will change the world. The founder has decided to give up sleep until 2015 to build the next big thing. They're paying (what seems to them like) crazy salaries for Rails developers with experience, and they want to get everything they can out of their investment.
      >
      > There is both the fallacy of "if only we pushed them harder they'd deliver more" and the "if only they stayed 16 hours a day we'd be done in half the time". I'm looking for metaphors, research, suggestions, blog postings, whatever that supports the idea of sustainable pace in the early days of a start-up. Much of what I use elsewhere gets countered with the "yeah, but they are established so they can afford to take a little longer".

      If your team is pairing, then a coding session is like taking a hard exam. It's not routine work, and if it is then that work should be automated. One option might be to have them actually pair for a session and see what the work is like. The other thing is to look for occasions where people screwed up through tiredness and make sure that comes up in the retrospectives.

      Meanwhile, I have a hard-enough time getting the developers to take breaks...

      S.

      Steve Freeman
      http://www.growing-object-oriented-software.com
    • Kay
      Hi, Steve, Failing frequently, which happens when one is tired and not doing one s best, as in the case of having to produce less than quality work can build
      Message 2 of 20 , May 20, 2011
      • 0 Attachment
        Hi, Steve,

        Failing frequently, which happens when one is tired and not doing one's best, as in the case of having to produce less than quality work can build up to a consciousness of failure. This can reduce effectiveness not only in the present but into the future if it is not corrected.

        Success builds on success. Another reason for sustainable pace.

        Kay Pentecost

        --- In extremeprogramming@yahoogroups.com, Steven Gordon <sgordonphd@...> wrote:
        >
        > A couple of useful metaphors where it is well know that being greedy is
        > counterproductive:
        >
        > * Server utilization - it is well known that letting utilization go above
        > 80% increases wait time, yet one would naively think that getting more work
        > out of the servers would make the work go faster.
        >
        > * Freeway entrance ramp meters - those traffic lights at the ends of freeway
        > entrance ramps increase effective freeway capacity during rush hours even
        > though they reduce the number of vehicles using the freeway at any given
        > time.
        >
        > Of course, the real reason is that software development is knowledge work,
        > not rote labor. Tire people make mistakes that will later cost more time
        > than was saved. Just redoing the work is usually not enough. Not only is
        > there the additional work of detecting and finding the erroneous work, but
        > other work based on that erroneous work may also have to be redone.
        >
        > SteveG
        >
        >
        >
        > On Thu, Apr 7, 2011 at 11:54 AM, Peter Bell <lists@...> wrote:
        >
        > >
        > >
        > > I'm finding myself doing an increasing amount of consulting with early
        > > stage start ups. Often the tech teams are either inexperienced or I'm
        > > actually tasked with some part of the recruiting process to build a team
        > > around some code I've delivered for the client.
        > >
        > > One of the challenge I run into with the people starting businesses is that
        > > they don't know much about best practices for managing software teams (why
        > > would they - that's one of the reasons they bring me in).
        > >
        > > My question relates primarily to sustainable pace. Strangely enough I'm not
        > > having a hard time selling (some) pairing. I have no issue selling TDD or
        > > building some time into each story to do refactoring. I get a lot of
        > > pushback initially on not interrupting scrums, but once we get into a
        > > process and get the management educated that goes away.
        > >
        > > What I *am* getting push back on is the idea of sustainable pace. Idea X,
        > > after all, is the one true idea that will change the world. The founder has
        > > decided to give up sleep until 2015 to build the next big thing. They're
        > > paying (what seems to them like) crazy salaries for Rails developers with
        > > experience, and they want to get everything they can out of their
        > > investment.
        > >
        > > There is both the fallacy of "if only we pushed them harder they'd deliver
        > > more" and the "if only they stayed 16 hours a day we'd be done in half the
        > > time". I'm looking for metaphors, research, suggestions, blog postings,
        > > whatever that supports the idea of sustainable pace in the early days of a
        > > start-up. Much of what I use elsewhere gets countered with the "yeah, but
        > > they are established so they can afford to take a little longer".
        > >
        > > Any thoughts or suggestions much appreciated.
        > >
        > > Best Wishes,
        > > Peter
        > >
        > >
        > >
        >
        >
        > [Non-text portions of this message have been removed]
        >
      • Kay
        And to respond to my own post: Great quote from Chad Fowler s _The Passionate Programmer_: So, I learned from this that people can significantly improve or
        Message 3 of 20 , May 20, 2011
        • 0 Attachment
          And to respond to my own post:

          Great quote from Chad Fowler's _The Passionate Programmer_: "So, I learned from this that people can significantly improve or regress
          in skill, purely based on who they are performing with. And, prolonged
          experience with a group can have a lasting impact on one's
          ability to perform."

          --- In extremeprogramming@yahoogroups.com, "Kay" <tranzpupy@...> wrote:
          >
          > Hi, Steve,
          >
          > Failing frequently, which happens when one is tired and not doing one's best, as in the case of having to produce less than quality work can build up to a consciousness of failure. This can reduce effectiveness not only in the present but into the future if it is not corrected.
          >
          > Success builds on success. Another reason for sustainable pace.
          >
          > Kay Pentecost
          >
          > --- In extremeprogramming@yahoogroups.com, Steven Gordon <sgordonphd@> wrote:
          > >
          > > A couple of useful metaphors where it is well know that being greedy is
          > > counterproductive:
          > >
          > > * Server utilization - it is well known that letting utilization go above
          > > 80% increases wait time, yet one would naively think that getting more work
          > > out of the servers would make the work go faster.
          > >
          > > * Freeway entrance ramp meters - those traffic lights at the ends of freeway
          > > entrance ramps increase effective freeway capacity during rush hours even
          > > though they reduce the number of vehicles using the freeway at any given
          > > time.
          > >
          > > Of course, the real reason is that software development is knowledge work,
          > > not rote labor. Tire people make mistakes that will later cost more time
          > > than was saved. Just redoing the work is usually not enough. Not only is
          > > there the additional work of detecting and finding the erroneous work, but
          > > other work based on that erroneous work may also have to be redone.
          > >
          > > SteveG
          > >
          > >
          > >
          > > On Thu, Apr 7, 2011 at 11:54 AM, Peter Bell <lists@> wrote:
          > >
          > > >
          > > >
          > > > I'm finding myself doing an increasing amount of consulting with early
          > > > stage start ups. Often the tech teams are either inexperienced or I'm
          > > > actually tasked with some part of the recruiting process to build a team
          > > > around some code I've delivered for the client.
          > > >
          > > > One of the challenge I run into with the people starting businesses is that
          > > > they don't know much about best practices for managing software teams (why
          > > > would they - that's one of the reasons they bring me in).
          > > >
          > > > My question relates primarily to sustainable pace. Strangely enough I'm not
          > > > having a hard time selling (some) pairing. I have no issue selling TDD or
          > > > building some time into each story to do refactoring. I get a lot of
          > > > pushback initially on not interrupting scrums, but once we get into a
          > > > process and get the management educated that goes away.
          > > >
          > > > What I *am* getting push back on is the idea of sustainable pace. Idea X,
          > > > after all, is the one true idea that will change the world. The founder has
          > > > decided to give up sleep until 2015 to build the next big thing. They're
          > > > paying (what seems to them like) crazy salaries for Rails developers with
          > > > experience, and they want to get everything they can out of their
          > > > investment.
          > > >
          > > > There is both the fallacy of "if only we pushed them harder they'd deliver
          > > > more" and the "if only they stayed 16 hours a day we'd be done in half the
          > > > time". I'm looking for metaphors, research, suggestions, blog postings,
          > > > whatever that supports the idea of sustainable pace in the early days of a
          > > > start-up. Much of what I use elsewhere gets countered with the "yeah, but
          > > > they are established so they can afford to take a little longer".
          > > >
          > > > Any thoughts or suggestions much appreciated.
          > > >
          > > > Best Wishes,
          > > > Peter
          > > >
          > > >
          > > >
          > >
          > >
          > > [Non-text portions of this message have been removed]
          > >
          >
        Your message has been successfully submitted and would be delivered to recipients shortly.