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

Forming an XP dot-com

Expand Messages
  • Keith Richardson
    I am in the final stages of putting together a dot-com company providing specialized supply-chain solutions that will be based in Florida. After 20 years of
    Message 1 of 16 , Dec 29, 2000
      I am in the final stages of putting together a dot-com company
      providing specialized supply-chain solutions that will be based in
      Florida. After 20 years of software development, XP seems to address
      the problems or requirements change and the corresponding quality
      problems that frequently plague projects. This is particularly
      important in the dot-com environment where rapid change is the norm.

      How practical is it for someone without XP experience to build an XP-
      based team? What is the best way for someone (myself) without an XP
      history to find the right people and verify that they have the
      necessary background? Comments or advice from anyone who has put
      together an XP team from scratch will be appreciated.

      Also, anyone with exceptional J2EE/WebLogic/EJB experience who wants
      the excitement and potential of a start-up in Florida (escape the
      cold!) should feel free to contact me.

      Keith Richardson
    • Bob Koss
      ... Everyone had to start someplace. Even Kent didn t have XP experience before he invented XP ;-) The real question is, how much risk are you willing to take
      Message 2 of 16 , Dec 29, 2000
        >
        > How practical is it for someone without XP experience to build an XP-
        > based team?

        Everyone had to start someplace. Even Kent didn't have XP experience before
        he invented XP ;-)

        The real question is, how much risk are you willing to take in this area?


        > What is the best way for someone (myself) without an XP
        > history to find the right people and verify that they have the
        > necessary background?

        Pair programming. You will discover the personality, team spirit, and what
        they know, all at the same time.


        ----
        Robert S. Koss, Ph.D. | Training and Mentoring
        Senior Consultant | Object Oriented Design
        Object Mentor, Inc. | C++, Java
        www.objectmentor.com | Extreme Programming
      • Keith Richardson
        ... XP- ... experience before ... area? That s an interesting way of putting it and raises a new question... What are the risks from introducing XP in a
        Message 3 of 16 , Dec 29, 2000
          --- In extremeprogramming@egroups.com, "Bob Koss" <koss@o...> wrote:
          > >
          > > How practical is it for someone without XP experience to build an
          XP-
          > > based team?
          >
          > Everyone had to start someplace. Even Kent didn't have XP
          experience before
          > he invented XP ;-)
          >
          > The real question is, how much risk are you willing to take in this
          area?

          That's an interesting way of putting it and raises a new question...
          What are the risks from introducing XP in a start-up environment?
          What can go wrong and what should I be looking out for?
          Keith Richardson
        • Laurent Bossavit
          ... There s this notion that investors want to see all employees in a start-up doing lots of overtime. I m not sure how true that actually is, but myth or
          Message 4 of 16 , Dec 29, 2000
            > That's an interesting way of putting it and raises a new
            > question... What are the risks from introducing XP in a start-up
            > environment? What can go wrong and what should I be looking out
            > for?

            There's this notion that investors want to see all employees in a
            start-up doing lots of overtime. I'm not sure how true that actually
            is, but myth or fact, it was an important factor in management's
            attitude in the 3-4 start-ups I was involved with. One area where I
            found XP values definitely at odds with typical start-up corporate
            cultures was the "slow down to speed up" precept.


            ========================================
            A successful technology creates problems
            that only it can solve.
            ========================================
            Laurent Bossavit - Software Architect
            >>> laurent.bossavit@... <<<
            >>> 06 68 15 11 44 <<<
            >> ICQ#39281367 <<
            Agence Bless http://www.agencebless.com/
            ========================================
          • Bob Koss
            ... In many ways, introducing XP in a new company has advantages. You get to make it clear when you hire people that this is the way things are done. How are
            Message 5 of 16 , Dec 29, 2000
              > What are the risks from introducing XP in a start-up environment?
              > What can go wrong and what should I be looking out for?
              > Keith Richardson


              In many ways, introducing XP in a new company has advantages. You get to
              make it clear when you hire people that this is the way things are done.

              How are your new employees going to learn about XP? Are you going to teach
              them or are you just going to give them copies of all of the books?

              How are they going to learn Test First Programming? That's a strange way of
              thinking, until you get hooked on it.

              Who is going to see to it that the programmers abide by the practices of XP
              until the practices become second nature? You? Will you have time to do this
              and run a company?

              The points I've made above aren't any different in a start-up than they are
              in an established organization.

              Good luck, and please keep us posted on your progress.

              ----
              Robert S. Koss, Ph.D. | Training and Mentoring
              Senior Consultant | Object Oriented Design
              Object Mentor, Inc. | C++, Java
              www.objectmentor.com | Extreme Programming
            • Jean-Marc Heneman
              You may want to hire a coach to better learn/teach your new team members: Ward, Ron, Kent or one of the object mentors! (By the way, hire one new person at a
              Message 6 of 16 , Dec 29, 2000
                You may want to hire a coach to better learn/teach your new team
                members: Ward, Ron, Kent or one of the object mentors!
                (By the way, hire one new person at a time, and have him/her really
                well get the XP philosophy/values/practices before hiring the next
                one.).

                Be sure the potential hire experienced and feel confortable with most
                of the XP practices (mostly/mainly pair-programming).

                You can also send your newly hired by 2 to the XP immersions.
                (Begin by yourself!)

                Books will give you a good idea but 2 people at a whiteboard/at a
                keyboard will give you the true experience!

                Jean-Marc

                --- In extremeprogramming@egroups.com, "Keith Richardson" <keith@s...>
                wrote:
                ...
                >
                > How practical is it for someone without XP experience to build an
                XP-
                > based team? What is the best way for someone (myself) without an XP
                > history to find the right people and verify that they have the
                > necessary background? Comments or advice from anyone who has put
                > together an XP team from scratch will be appreciated.
                >
                ...
                > Keith Richardson
              • 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 7 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 8 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 9 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 10 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 11 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 12 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 13 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 14 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 15 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 16 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.