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

Re: Forming an XP dot-com

Expand Messages
  • Keith Richardson
    ... wrote: ... How do you sell the concept that a 40 hour week from employees is better in the long run for investors than a
    Message 1 of 16 , Jan 1, 2001
      --- In extremeprogramming@egroups.com, "Laurent Bossavit"
      <laurent.bossavit@a...> wrote:
      <snip...>
      > One area where I
      > found XP values definitely at odds with typical start-up corporate
      > cultures was the "slow down to speed up" precept.

      How do you sell the concept that a 40 hour week from employees is
      better in the long run for investors than a 50 hour work week?
      Particularly when their other companies are working 60 hour work
      weeks. Any ammunition would help before this comes up!
      Thanks, Keith
    • Ron Jeffries
      ... Well, maybe ... Measure your performance in terms of delivery of features per unit time, at various levels of work effort. Do the overtime mode for a month
      Message 2 of 16 , Jan 1, 2001
        At 11:35 PM 1/1/2001 +0000, it seemed like Keith Richardson wrote:
        >How do you sell the concept that a 40 hour week from employees is
        >better in the long run for investors than a 50 hour work week?
        >Particularly when their other companies are working 60 hour work
        >weeks. Any ammunition would help before this comes up!

        Well, maybe ...
        Measure your performance in terms of delivery of features per unit time, at
        various levels of work effort. Do the overtime mode for a month or so, get
        really tired. Graph velocity Graph illness. Graph hours actually spent
        working and hours spent screwing around. Then take a few days to decompress
        and work reasonable hours. Track the same data. Let us all know what you get.

        Remember, the rule is called 40 hour week (by Kent). C3 called it "no
        overtime" and defined overtime as "time when you don't want to be in the
        office". The rule doesn't mean work 40 hours and go home. It means don't
        work consecutive overtime, because it slows you down. Your facts rule, your
        mileage may vary.

        regards,

        Regards,

        Ronald E Jeffries
        http://www.XProgramming.com
        http://www.objectmentor.com
      • Ron Jeffries
        ... Mr Manager, let s face facts: you get what you measure. If lines of code are good and you measure lines of code,
        Message 3 of 16 , Jan 2, 2001
          At 11:35 PM 1/1/2001 +0000, it seemed like Keith Richardson wrote:
          >How do you sell the concept that a 40 hour week from employees is
          >better in the long run for investors than a 50 hour work week?
          >Particularly when their other companies are working 60 hour work
          >weeks. Any ammunition would help before this comes up!

          <rant target="some unknown manager">

          Mr Manager, let's face facts: you get what you measure. If lines of code
          are good and you measure lines of code, you'll get more lines of code. If
          defects are bad and you measure defects, you'll get fewer defects. And if
          time in the office is good and you measure that, you'll get lots of hours
          in the office.

          Turns out that your customers don't buy hours in the office. They buy
          features. They buy your product because it does things for them, because it
          offers features that provide benefits.

          Therefore, measure your programmers by telling them clearly what features
          you want, and measuring how quickly they get the features done. You'll get
          programmers who focus on quickly delivering features for your product. Now
          wouldn't that be nice?

          There's even another benefit. By tracking how fast the programmers are
          doing features, and asking them how hard the new features you want will be,
          you can predict fairly accurately what you'll have and when you'll have it.
          This actually lets you schedule your releases, and if things change - and
          they will - you can adjust the features you ask for to the speed the team
          is actually going. You can steer what will happen, according to what has
          happened in the past. I call that "management", and it's what XP is all about.

          Measure hours, get hours. Measure features, get features. It's up to you.
          That is all.
          </rant>

          Ronald E Jeffries
          http://www.XProgramming.com
          http://www.objectmentor.com
        • Keith Richardson
          ... code ... code. If ... And if ... hours ... buy ... because it ... features ... You ll get ... product. Now ... are ... will be, ... have it. ... change -
          Message 4 of 16 , Jan 2, 2001
            --- In extremeprogramming@egroups.com, Ron Jeffries
            <ronjeffries@a...> wrote:
            > At 11:35 PM 1/1/2001 +0000, it seemed like Keith Richardson wrote:
            > >How do you sell the concept that a 40 hour week from employees is
            > >better in the long run for investors than a 50 hour work week?
            > >Particularly when their other companies are working 60 hour work
            > >weeks. Any ammunition would help before this comes up!
            >
            > <rant target="some unknown manager">
            >
            > Mr Manager, let's face facts: you get what you measure. If lines of
            code
            > are good and you measure lines of code, you'll get more lines of
            code. If
            > defects are bad and you measure defects, you'll get fewer defects.
            And if
            > time in the office is good and you measure that, you'll get lots of
            hours
            > in the office.
            >
            > Turns out that your customers don't buy hours in the office. They
            buy
            > features. They buy your product because it does things for them,
            because it
            > offers features that provide benefits.
            >
            > Therefore, measure your programmers by telling them clearly what
            features
            > you want, and measuring how quickly they get the features done.
            You'll get
            > programmers who focus on quickly delivering features for your
            product. Now
            > wouldn't that be nice?
            >
            > There's even another benefit. By tracking how fast the programmers
            are
            > doing features, and asking them how hard the new features you want
            will be,
            > you can predict fairly accurately what you'll have and when you'll
            have it.
            > This actually lets you schedule your releases, and if things
            change - and
            > they will - you can adjust the features you ask for to the speed
            the team
            > is actually going. You can steer what will happen, according to
            what has
            > happened in the past. I call that "management", and it's what XP is
            all about.
            >
            > Measure hours, get hours. Measure features, get features. It's up
            to you.
            > That is all.
            > </rant>
            >
            > Ronald E Jeffries
            > http://www.XProgramming.com
            > http://www.objectmentor.com

            This is essentially an answer to another message I have just posted.
            However it is not an answer. Mr. Manager knows that you have a no-
            overtime rule and your staff works a 40 hour week. You have not
            explained why you would not get 10% more features delivered if the
            staff worked 44 hour weeks. The "you get what you measure" argument
            only works if all other factors are unconstrained. It is not
            convincing to say that measuring features while constraining hours
            delivers the maximum numbers of features. e.g. All your arguments
            would hold true if you told your team to work 20 hours each week. You
            would just take twice as long to deliver the functionality.
            Keith Richardson
          • Keith Richardson
            ... wrote: ... to you. ... Another thought... Surely the no-overtime rule implies that you are measuring hours. How else would
            Message 5 of 16 , Jan 2, 2001
              --- In extremeprogramming@egroups.com, Ron Jeffries
              <ronjeffries@a...> wrote:
              <snip...>
              > Measure hours, get hours. Measure features, get features. It's up
              to you.
              > That is all.
              > </rant>
              >
              > Ronald E Jeffries
              > http://www.XProgramming.com
              > http://www.objectmentor.com

              Another thought... Surely the no-overtime rule implies that you are
              measuring hours. How else would anyone know if overtime is being
              worked? There has to me more to this than your simple statement.
              Keith Richardson
            • Ron Jeffries
              ... Actually I will wager a substantial amount of money that in 20 hours you ll get more than half what you do in 40. However, that s not the point. The point
              Message 6 of 16 , Jan 2, 2001
                At 02:36 AM 1/3/2001 +0000, it seemed like Keith Richardson wrote:
                >This is essentially an answer to another message I have just posted.
                >However it is not an answer. Mr. Manager knows that you have a no-
                >overtime rule and your staff works a 40 hour week. You have not
                >explained why you would not get 10% more features delivered if the
                >staff worked 44 hour weeks. The "you get what you measure" argument
                >only works if all other factors are unconstrained. It is not
                >convincing to say that measuring features while constraining hours
                >delivers the maximum numbers of features. e.g. All your arguments
                >would hold true if you told your team to work 20 hours each week. You
                >would just take twice as long to deliver the functionality.

                Actually I will wager a substantial amount of money that in 20 hours you'll
                get more than half what you do in 40. However, that's not the point. The
                point is that you need to know how much you can deliver at various work
                levels - 20, 40, 44, 50, whatever. Once you know that, you know what the
                right thing is. If a team could deliver, week in and week out, more at 60
                hours that at 40, you need another reason not to work 60.

                The real deal is this: you have to work in such a way as to sustain the
                effort. A little overtime won't kill you.

                But as long as you leave hours on the table as something to measure, it
                will always look like more hours is better. You need to know the facts, and
                you have to have the nerve not to let hours be the issue. Get the facts.

                R



                Ronald E Jeffries
                http://www.XProgramming.com
                http://www.objectmentor.com
              • Ron Jeffries
                ... The rule is don t work more than a week of overtime . The NAME of the rule is 40-hour week . The IDEA is to work at a pace you can live with for the long
                Message 7 of 16 , Jan 2, 2001
                  At 02:40 AM 1/3/2001 +0000, it seemed like Keith Richardson wrote:
                  >Another thought... Surely the no-overtime rule implies that you are
                  >measuring hours. How else would anyone know if overtime is being
                  >worked? There has to me more to this than your simple statement.

                  The rule is "don't work more than a week of overtime". The NAME of the rule
                  is "40-hour week". The IDEA is to work at a pace you can live with for the
                  long term.

                  Ronald E Jeffries
                  http://www.XProgramming.com
                  http://www.objectmentor.com
                • J. B. Rainsberger
                  ... corporate ... I am not a manager, but my recent personal experience leads me to say the following: Consider a hot-shot programmer, Joe. [:)] Joe thinks
                  Message 8 of 16 , Jan 3, 2001
                    --- In extremeprogramming@egroups.com, "Keith Richardson"
                    <keith@s...> wrote:
                    > --- In extremeprogramming@egroups.com, "Laurent Bossavit"
                    > <laurent.bossavit@a...> wrote:
                    > <snip...>
                    > > One area where I
                    > > found XP values definitely at odds with typical start-up
                    corporate
                    > > cultures was the "slow down to speed up" precept.
                    >
                    > How do you sell the concept that a 40 hour week from employees is
                    > better in the long run for investors than a 50 hour work week?
                    > Particularly when their other companies are working 60 hour work
                    > weeks. Any ammunition would help before this comes up!

                    I am not a manager, but my recent personal experience leads me to say
                    the following:

                    Consider a hot-shot programmer, Joe. [:)] Joe thinks he's pretty
                    good, but he's new to development and doesn't know any better. He
                    takes a job -- probably his first job -- and becomes the typical hero
                    programmer. He likes the attention and ignores the ridiculous demands
                    on his time and patience for, say, 9 months. After that, he gets
                    tired. He pushes himself through one more release, then finds out
                    that life doesn't have to be that way. Within 18 months after you
                    hire him, Joe is out the door, because he just doesn't want to work
                    another month of 70-hour weeks.

                    This is in stark contrast to middling programmer, Howard. Howard is
                    just happy to have a job. He'll never be the hero, but he's steady.
                    You can give him coding tasks and he's all right, but you doubt his
                    ability to design and he makes the same mistakes over and over.
                    Because he never gets thrust into the forefront, he manages to avoid
                    the long weeks except right before a release. Because he's not a
                    clutch guy, people don't ask him to do everything. He can handle his
                    job and likely sticks around for years.

                    After five years, how many of each kind will you have? Lots of
                    Howards and few Joes, in which case you either have to pay through
                    the nose to hire more Joes, or thrust a Howard or two into the
                    spotlight, where they'll invariably fail.

                    No way to run a business. Better to make sure that the Joes stick
                    around, which they will if you run a development house that doesn't
                    force them to work 100 hours of overtime in a month.

                    So find a way. Hey wait, I heard that XP might be part of the
                    answer....

                    ...and so on.

                    JBR.
                  • kentbeck@csi.com
                    ... Get used to a focused working style, then measure the difference. I talked to a team this morning that did exactly that and measured that they were most
                    Message 9 of 16 , Jan 3, 2001
                      --- In extremeprogramming@egroups.com, "Keith Richardson"
                      <keith@s...> wrote:
                      > How do you sell the concept that a 40 hour week from employees is
                      > better in the long run for investors than a 50 hour work week?
                      > Particularly when their other companies are working 60 hour work
                      > weeks. Any ammunition would help before this comes up!
                      > Thanks, Keith

                      Get used to a focused working style, then measure the difference. I
                      talked to a team this morning that did exactly that and measured that
                      they were most productive around 40.

                      I like Bob Martin's idea. Instead of calling it the 40 hour week,
                      call it the 8 hour burn. The idea is to work so focused and intensely
                      that at 1700 you're obviously good for nothing more than going home
                      and playing with the kids, and on Friday you clearly need a couple of
                      days off. This saves the macho aspect, and even takes it up a notch--
                      could you work so intensely that you had to spend Wednesday's
                      screwing around?

                      Kent
                    • Bob Koss
                      ... And I m here to tell you that it s balls to the wall for those 8 hours! I ve had the opportunity to work with Bob in his home office. The work day started
                      Message 10 of 16 , Jan 13, 2001
                        >
                        > I like Bob Martin's idea. Instead of calling it the 40 hour week,
                        > call it the 8 hour burn. The idea is to work so focused and intensely
                        > that at 1700 you're obviously good for nothing more than going home

                        And I'm here to tell you that it's balls to the wall for those 8 hours!

                        I've had the opportunity to work with Bob in his home office. The work day
                        started at exactly 9am, we usually had a sandwich (standing up) around noon,
                        and by 5pm I was so drained that I wasn't sure that I could drive back to my
                        hotel. I couldn't imagine working more than 40 hours a week at that pace.

                        ----
                        Robert S. Koss, Ph.D. | Training and Mentoring
                        Senior Consultant | Object Oriented Design
                        Object Mentor, Inc. | C++, Java
                        www.objectmentor.com | Extreme Programming
                      Your message has been successfully submitted and would be delivered to recipients shortly.