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

Re: [XP] Digest Number 1500

Expand Messages
  • Dave Storrs
    ... This is actually a really interesting point, and one that I hadn t quite managed to articulate for myself before. Quite possibly, the most important of
    Message 1 of 20 , Sep 30, 2001
    • 0 Attachment
      > Message: 25
      > Date: Fri, 28 Sep 2001 17:34:37 -0400
      > From: "Baker, Bram" <bram.baker@...>
      > Subject: RE: XP and COM
      >[snip]
      > done a *lot* of COM (and all/only? in c++). I think XP and COM (and c++)
      > work well together. Your colleagues who are pushing back are just expressing
      > fear, and yet again, XP to the rescue: courage.

      This is actually a really interesting point, and one that I hadn't
      quite managed to articulate for myself before. Quite possibly, the most
      important of the XP virtues is Courage...without Courage, we will not be
      willing to try the new practices, to step away from our old
      "well-it-seems-to-be-good-enough" methods and see what XP can and cannot
      do for us.

      So how do we get our companies to exhibit Courage?

      Think about it. There are multiple reasons why a company does
      not want to exhibit Courage in the XP sense:

      1) As a developer, I am quite ready and willing to try new things
      like XP...for one thing, all of the XP books were written BY developers,
      largely FOR developers, so they are an excellent fit with my cognitive
      process. They are a less good fit with your random PHB's cogproc (pardon
      the neologism)...for that matter, they aren't even necessarily a perfect
      fit with a _NON_-PHed Boss's cogproc, either. At the risk of stating the
      obvious (or of overgeneralizing), developers do not think the same way
      that most people do, and our priorities are not the same. (If anyone
      disagrees with me on this, I will argue the case further, but I'm hardly
      the first person to say it.) I am willing to go along with the books
      because they "ring true" for me. If the bosses don't have that same "of
      course" experience, they will not be need to be rationally convinced,
      which is a more difficult process.

      2) For a second reason, managers are not interested in showing
      Courage about a new process when they have something that they feel more
      or less works...or, at the least, is familiar so they know how to handle
      the problems. Why should they want to learn something new and throw away
      all their experience?

      3) Much of XP goes counter to the "conventional wisdom." How can
      you possibly go faster if you put two programmers on every task? We don't
      have time to write all these tests, just write the d@#n code! What do you
      mean we shouldn't do a design phase--haven't you programmers been telling
      us for thirty years that you need to take time to design things before you
      write them?

      4) Developers see technical problems and apparently arbitrary
      constraints. If they fail to solve their problems, a project fails or is
      shelved. Managers see business problems with economic constraints. If
      they fail to solve their problems, the company fails.


      I know these issues have been raised before on this list, and are
      addressed in the books. I don't think that we've ever put exactly this
      focus on it, which is why I bring it up.

      So, here's the problem: having me tell my boss, "It's ok...just
      show Courage" is not going to help. That's too much like saying "Trust
      me, I know what I'm doing, and I'm prepared to gamble the company on
      it." If he has an ounce of gray matter, he's not going to accept
      that...nor would I think it wise to work for someone who was willing to
      accept it blindly.

      The standard answers to issues like these are listed below, but
      none of them have ever felt very satisfying, so right below them I have
      listed the answer that I would expect from management. Is there anything
      else that anyone can suggest?

      XP: Well, let's try it the new way for a month, measure our progress and
      compare.

      M: What if it doesn't work? Then we've wasted a month...maybe
      more, because you'll have to undo all the stuff you've done. With the
      market the way it is right now, we can't afford that. Just do it the way
      we've been doing it.
      ------------
      XP: Pair Programming makes you produces higher quality code faster,
      because you have another set of eyes catching mistakes the instant they
      are made.

      M: But I've got three projects that need to be worked on NOW, and only
      four programmers. And there's no money to hire more.
      ------------
      XP: Writing lots of unit tests lets us produce higher quality code.

      M: I care less about quality than time to market. The tech market is in
      the toilet right now...if we don't get the next release out before the
      competition, we may fold.

      XP: But the unit tests will give us a speed boost, because they let us
      trap and fix errors faster as we develop and maintain the codebase.

      M: But doesn't it mean that you have to maintain all the code for the
      tests, as well as the codebase?

      XP: Well, yes....

      M: Forget it then. I don't want you maintaining anything other than our
      codebase.
      ------------
      XP: Doing our design incrementally, by way of The Planning Game and the
      unit tests, allows us to be more responsive to your needs. We are always
      working on the highest priority stories, and we can give you a
      better-than-usual estimate of what you will get by a certain date.

      [ok, actually, I can't think of why management would object to this. On
      the other hand, this is the single practice that my boss has been most
      resistant to...and I have yet to understand his reasons for it.]
      ------------
      XP: We try to estimate things in Ideal Days, because it gives us an
      objective standard.

      M: Look, I'm not familiar with these Ideal Days. Why don't we call them
      "Man-Effort Days" instead.

      XP: Well, but Man-Effort Days means something different...it refers to
      calendar days.

      M: But development time is never ideal--you always have to answer the
      phone, or go to meetings, or whatever--so what's the point of using a
      measurement that can't be meaningful? Look, it's very simple...you just
      estimate in Man-Effort Days, and then assume that everyone is working at
      75%, so you build in 25% slack. You don't have to do all this fancy
      stuff.



      Any thoughts, anyone?

      Dave
    • Ron Jeffries
      ... Yeah. Give up. Do our best and wait for the old farts to die off. No, bad idea. I _am_ an old fart! I guess I don t know how to sell the stuff. That s why
      Message 2 of 20 , Sep 30, 2001
      • 0 Attachment
        Around Sunday, September 30, 2001, 1:05:09 PM, Dave Storrs wrote:

        > Any thoughts, anyone?

        Yeah. Give up. Do our best and wait for the old farts to die off. No,
        bad idea. I _am_ an old fart! I guess I don't know how to sell the
        stuff. That's why I'm a techie, not a salesman.

        Ronald E Jeffries
        www.XProgramming.com
        The fact that we know more today, and are more capable today,
        is good news about today, not bad news about yesterday.
      • dstorrs@dstorrs.com
        ... I m not sure if you re (A) joking (B) gently chiding me for giving up (C) castigating me for giving up (D) some combination of the above (E) something
        Message 3 of 20 , Sep 30, 2001
        • 0 Attachment
          --- In extremeprogramming@y..., Ron Jeffries <ronjeffries@a...> wrote:
          > Around Sunday, September 30, 2001, 1:05:09 PM, Dave Storrs wrote:
          >
          > > Any thoughts, anyone?
          >
          > Yeah. Give up. Do our best and wait for the old farts to die off. No,
          > bad idea. I _am_ an old fart! I guess I don't know how to sell the
          > stuff. That's why I'm a techie, not a salesman.
          >
          > Ronald E Jeffries

          I'm not sure if you're

          (A) joking
          (B) gently chiding me for giving up
          (C) castigating me for giving up
          (D) some combination of the above
          (E) something else.

          So which is it? :>

          My post was meant very seriously...I believe that selling the company
          on the idea of Courage would be a sufficient requirement for getting
          them to try full-blown XP. I haven't been able to get them to do that
          yet, and it's been very frustrating...largely because I couldn't
          understand why I couldn't get them to do it. Now I see what the
          problem is, and all I have to do is solve it.

          Certainly talking to the CTO and the other more technically-minded
          managers will help...we share more points of reference. I understand
          that Rome wasn't built in a day and I'll just have to keep at it. But
          I'm *not* a salesman, and I'm asking for specific advice from the
          people who do this for a living...e.g., consultants and coaches. (This
          includes you, Ron, old fart or not. :>)

          So again...any ideas?

          Dave
        • Ron Jeffries
          ... So which is it? : Whichever one works best for you? I can assure you, however, that no one has ever been castigated by me and been unsure whether that
          Message 4 of 20 , Sep 30, 2001
          • 0 Attachment
            Around Sunday, September 30, 2001, 2:36:21 PM, dstorrs@... wrote:

            > --- In extremeprogramming@y..., Ron Jeffries <ronjeffries@a...> wrote:
            >> Around Sunday, September 30, 2001, 1:05:09 PM, Dave Storrs wrote:
            >>
            >> > Any thoughts, anyone?
            >>
            >> Yeah. Give up. Do our best and wait for the old farts to die off. No,
            >> bad idea. I _am_ an old fart! I guess I don't know how to sell the
            >> stuff. That's why I'm a techie, not a salesman.
            >>
            >> Ronald E Jeffries

            > I'm not sure if you're

            > (A) joking
            > (B) gently chiding me for giving up
            > (C) castigating me for giving up
            > (D) some combination of the above
            > (E) something else.

            So which is it? :>>

            Whichever one works best for you? I can assure you, however, that no
            one has ever been castigated by me and been unsure whether that was
            the case. ;->

            > My post was meant very seriously...I believe that selling the company
            > on the idea of Courage would be a sufficient requirement for getting
            > them to try full-blown XP. I haven't been able to get them to do that
            > yet, and it's been very frustrating...largely because I couldn't
            > understand why I couldn't get them to do it. Now I see what the
            > problem is, and all I have to do is solve it.

            Yes. But the problem with the Courage value is that to adopt it you
            have to admit that you don't have it. And to do that, you have to have
            courage. Otherwise, using XP's practices, you tend to gain courage,
            though there's another post here that I have to reply to that suggests
            that isn't guaranteed -- not that we thought it was.

            > Certainly talking to the CTO and the other more technically-minded
            > managers will help...we share more points of reference. I understand
            > that Rome wasn't built in a day and I'll just have to keep at it. But
            > I'm *not* a salesman, and I'm asking for specific advice from the
            > people who do this for a living...e.g., consultants and coaches. (This
            > includes you, Ron, old fart or not. :>)

            Here are the things your guy "said" (or might say) to you, with some
            comments from me. I mean them to be helpful. They'll be brief, in the
            interest of time and space, not because I'm angry or impatient.
            Although I am both.

            > XP: Well, let's try it the new way for a month, measure our progress and
            > compare.
            >
            > M: What if it doesn't work? Then we've wasted a month...maybe
            > more, because you'll have to undo all the stuff you've done. With the
            > market the way it is right now, we can't afford that. Just do it the way
            > we've been doing it.

            This is asking for permission. Better perhaps to ask for forgiveness.
            "The new way" is a very scary phrase. Does the manager know he has a
            problem? What's the problem? Relate the suggested solution to that.

            What does he want? Give him that. Why are you asking anyway?
            > ------------
            > XP: Pair Programming makes you produces higher quality code faster,
            > because you have another set of eyes catching mistakes the instant they
            > are made.
            >
            > M: But I've got three projects that need to be worked on NOW, and only
            > four programmers. And there's no money to hire more.

            Pair programming doesn't reduce productivity. He has the impression
            that it does. Have you tried PP with multiple projects? How often did
            you switch? What happened? Do the programmers want to PP? Do they know
            how?
            > ------------
            > XP: Writing lots of unit tests lets us produce higher quality code.
            >
            > M: I care less about quality than time to market. The tech market is in
            > the toilet right now...if we don't get the next release out before the
            > competition, we may fold.

            Writing unit tests lets you ship code faster because you spend less
            time debugging. Do your programmers know how to write unit tests, or
            are you trying to impose these practices on them? I don't understand
            why, if you programmers want to do these things, you don't just do
            them.

            If the programmers don't know, or don't want to, you may be wasting
            your time getting management support. It probably won't help.
            >
            > XP: But the unit tests will give us a speed boost, because they let us
            > trap and fix errors faster as we develop and maintain the codebase.
            >
            > M: But doesn't it mean that you have to maintain all the code for the
            > tests, as well as the codebase?
            >
            > XP: Well, yes....
            >
            > M: Forget it then. I don't want you maintaining anything other than our
            > codebase.

            I still don't know why you would ask. This isn't a business
            decision. If it makes you go faster, f5g do it. But the answer isn't
            "Well, yes ...", it's "Of course. And writing good tests and
            maintaining them is faster than all the debugging time we do now. For
            example ..."
            > ------------
            > XP: Doing our design incrementally, by way of The Planning Game and the
            > unit tests, allows us to be more responsive to your needs. We are always
            > working on the highest priority stories, and we can give you a
            > better-than-usual estimate of what you will get by a certain date.
            >
            > [ok, actually, I can't think of why management would object to this. On
            > the other hand, this is the single practice that my boss has been most
            > resistant to...and I have yet to understand his reasons for it.]

            A f5g ha! What are his reasons? Why don't you know them? Have you and
            he been talking at each other and not listening? (Not that I've never
            done that maybe more than 800 times a day.)

            Find out why he doesn't want it. Find out what he does want. Figure
            out how to give him that.
            > ------------
            > XP: We try to estimate things in Ideal Days, because it gives us an
            > objective standard.
            >
            > M: Look, I'm not familiar with these Ideal Days. Why don't we call them
            > "Man-Effort Days" instead.

            Stop using Ideal Days. Story is something like: "The time we spend
            working on things is too variable. A feature that takes me one real
            day of work can take me two, three, or more days because of
            interruptions, bug fixes and the fact that you are an a5e. What we CAN
            do is estimate the DIFFICULTY of things in points, and tell you how
            many difficulty points we have been doing each week."

            And why aren't you just giving him the information without talking to
            him about it? Things that slow you down, reducing velocity, will be
            interesting to him if he can do something about them.
            >
            > XP: Well, but Man-Effort Days means something different...it refers to
            > calendar days.
            >
            > M: But development time is never ideal--you always have to answer the
            > phone, or go to meetings, or whatever--so what's the point of using a
            > measurement that can't be meaningful? Look, it's very simple...you just
            > estimate in Man-Effort Days, and then assume that everyone is working at
            > 75%, so you build in 25% slack. You don't have to do all this fancy
            > stuff.

            How's that working? If it's working fine, don't change it. If it
            isn't, then that tells us why we should do better.

            I still say give up. Does everyone on your team, or a critical mass,
            want to do XP? Just start doing what you can, look good, and be ready
            to answer how you're doing it.

            Ronald E Jeffries
            www.XProgramming.com
            Logic is overrated as a system of thought.
          • Dan Palanza
            ... If I imagine system as working model of some kind, with a focus on the word _work_, then, as I perceive logic , its primary mission in thought is not
            Message 5 of 20 , Sep 30, 2001
            • 0 Attachment
              Ronald E Jeffries:

              >Logic is overrated as a system of thought.

              If I imagine 'system' as 'working model' of some kind, with a focus on the
              word _work_, then, as I perceive 'logic', its primary mission in thought is
              not about contributed value in work, it is about expressed meaning in
              communication.

              If that were so, your philosophic expression above might say:

              "Logic is overrated as a language of expression."

              Language, of course, does play a role in getting work done. In fact a
              system without a language is inconceivable to me. And, for that matter, so
              is a language without a system. Making a distinction between system versus
              language, subtle though it may be, would enable a useful clarification of
              tasks: focusing 'system' a person is a software engineer; focusing
              'language' a person is a software author.

              Among carpenters, system versus language is helpful for focusing a
              distinction between work's value driving nails versus expression's meaning
              delivered in what gets nailed.

              This distinction, experience tells, is helpful in many contexts. Romance is
              one other good example.

              Dan
            • Ron Jeffries
              ... I think this pretty much proves my point ... ;- Ronald E Jeffries www.XProgramming.com
              Message 6 of 20 , Sep 30, 2001
              • 0 Attachment
                Around Sunday, September 30, 2001, 8:01:15 PM, Dan Palanza wrote:

                > Ronald E Jeffries:

                >>Logic is overrated as a system of thought.

                > If I imagine 'system' as 'working model' of some kind, with a focus on the
                > word _work_, then, as I perceive 'logic', its primary mission in thought is
                > not about contributed value in work, it is about expressed meaning in
                > communication.

                > If that were so, your philosophic expression above might say:

                > "Logic is overrated as a language of expression."

                > Language, of course, does play a role in getting work done. In fact a
                > system without a language is inconceivable to me. And, for that matter, so
                > is a language without a system. Making a distinction between system versus
                > language, subtle though it may be, would enable a useful clarification of
                > tasks: focusing 'system' a person is a software engineer; focusing
                > 'language' a person is a software author.

                > Among carpenters, system versus language is helpful for focusing a
                > distinction between work's value driving nails versus expression's meaning
                > delivered in what gets nailed.

                > This distinction, experience tells, is helpful in many contexts. Romance is
                > one other good example.

                I think this pretty much proves my point ... ;->

                Ronald E Jeffries
                www.XProgramming.com
              • Dan Palanza
                ... You overrate my intelligence :) Which point? Dan
                Message 7 of 20 , Sep 30, 2001
                • 0 Attachment
                  Ron Jeffries wrote:

                  >I think this pretty much proves my point ... ;->

                  You overrate my intelligence :) Which point?

                  Dan
                • Ron Jeffries
                  ... My point about logic being overrated as a system of thought. Ronald E Jeffries www.XProgramming.com Life tough is. Then die you do. --Yoda
                  Message 8 of 20 , Sep 30, 2001
                  • 0 Attachment
                    Around Sunday, September 30, 2001, 8:24:08 PM, Dan Palanza wrote:

                    > Ron Jeffries wrote:

                    >>I think this pretty much proves my point ... ;->

                    > You overrate my intelligence :) Which point?

                    My point about logic being overrated as a system of thought.

                    Ronald E Jeffries
                    www.XProgramming.com
                    Life tough is. Then die you do. --Yoda
                  • Bryan Dollery
                    Dave Storrs wrote ... Doing XP means a radical business process reengineering. XP affects not only developers but also the business. If your an
                    Message 9 of 20 , Sep 30, 2001
                    • 0 Attachment
                      Dave Storrs wrote
                      <snip>
                      > The standard answers to issues like these are listed below, but
                      > none of them have ever felt very satisfying, so right below them I have
                      > listed the answer that I would expect from management. Is there anything
                      > else that anyone can suggest?
                      <snip>

                      Doing XP means a radical business process reengineering. XP affects not only
                      developers but also the business. If your an internal soft-dev department
                      then your relationship with the business changes, and the business must
                      change to realise the benefits of frequent releases, and to allow SMEs to
                      become part of the development team. If you're a consultancy then you need
                      to change both internal and external processes. The sales team need to
                      change their approach, and what they're selling. Your customers must then
                      change in a similar manner to the internal example.

                      Your arguments would suggest that this isn't your company, and that you
                      don't have the power to just change things. In this case you need to
                      convince a power that this is a good idea. The power in question is probably
                      the big-boss (or end-of-level-baddy, depending on your perspective).

                      I would assume that the person representing the business in your arguments
                      isn't a power. If they were their arguments would have been different.
                      Powers tend to talk about things like Return On Investment (ROI) and
                      business benefits. Your protagonist was concerned with technical issues,
                      like testing, and maintenance, a power is concerned with ROI and TCO.

                      You have reached what I call a glass ceiling. You must break the ceiling,
                      your options are to do it from below, or from above. From below you have to
                      persevere preaching to the deaf. From above you simply bypass the obstacle
                      and attack the problem from a higher level.

                      If your manager won't shift, bypass him. The best place to go is to the
                      big-boss. Coerce him with lower risks, and increased ROI. That'll get him,
                      then he can remove the obstacle.

                      Another technique is to bring in outside help, although this will only work
                      if you have a budget to do such a thing. For some inexplicable reason
                      organisations continue to bring in 'big' consultants to say the same thing
                      as the lower-level staff, just to get the higher levels of the hierarchy to
                      listen.

                      This works on the idea that if you're famous it must be for a good reason.
                      This is not necessarily true, but it can be used to your advantage if you
                      know about it.

                      Anyway, I've just written a paper on this subject. I'm publishing it at
                      Auckland's XP conference next week, and after that I'll put it up on my
                      website. It should be there by the 12th, so if you remember, and are
                      interested, have a look then.

                      Bryan
                      www.ChaosEngineers.co.nz
                    • Ron Jeffries
                      ... Of course Brian neglects to mention that even if you ARE the big boss you can t just change things ... ... This technique will in most cases result
                      Message 10 of 20 , Sep 30, 2001
                      • 0 Attachment
                        Around Sunday, September 30, 2001, 9:02:50 PM, Bryan Dollery wrote:

                        > Your arguments would suggest that this isn't your company, and that you
                        > don't have the power to just change things. In this case you need to
                        > convince a power that this is a good idea. The power in question is probably
                        > the big-boss (or end-of-level-baddy, depending on your perspective).

                        Of course Brian neglects to mention that even if you ARE the big boss
                        you can't just change things ...

                        <snip/>

                        > If your manager won't shift, bypass him. The best place to go is to the
                        > big-boss. Coerce him with lower risks, and increased ROI. That'll get him,
                        > then he can remove the obstacle.

                        This technique will in most cases result in the removing of someone.
                        It won't always be your manager. I'd advise using this with caution.

                        > Another technique is to bring in outside help, although this will only work
                        > if you have a budget to do such a thing. For some inexplicable reason
                        > organisations continue to bring in 'big' consultants to say the same thing
                        > as the lower-level staff, just to get the higher levels of the hierarchy to
                        > listen.

                        There is some merit to this. But if the upper guys didn't ask the
                        question, they probably don't want to hear the answer.

                        Brian is offering some pretty direct advice here. It could work, and
                        it could backfire. From your imaginary Q&A I'm not convinced you have
                        a good handle on what the guys upstairs care about. That's the first
                        step, in my opinion.

                        Ronald E Jeffries
                        www.XProgramming.com
                        It's easier to act your way into a new way of thinking
                        than to think your way into a new way of acting. --Millard Fuller
                      • Bryan Dollery
                        Ron Jaffa-ries wrote Ron, it s Bryan, not Brian ;- ... A big-boss can t just change things. But, change from the top down in a hierarchical organisation is
                        Message 11 of 20 , Sep 30, 2001
                        • 0 Attachment
                          Ron Jaffa-ries wrote

                          Ron, it's Bryan, not Brian ;->

                          >
                          > Around Sunday, September 30, 2001, 9:02:50 PM, Bryan Dollery wrote:
                          >
                          > > Your arguments would suggest that this isn't your company, and that you
                          > > don't have the power to just change things. In this case you need to
                          > > convince a power that this is a good idea. The power in
                          > question is probably
                          > > the big-boss (or end-of-level-baddy, depending on your perspective).
                          >
                          > Of course Brian neglects to mention that even if you ARE the big boss
                          > you can't just change things ...

                          A big-boss can't 'just' change things. But, change from the top down in a
                          hierarchical organisation is a lot easier than change from the bottom up. If
                          you're not in a hierarchical organisation then there is no big-boss role,
                          and therefore no glass-ceiling.

                          > <snip/>
                          >
                          > > If your manager won't shift, bypass him. The best place to go is to the
                          > > big-boss. Coerce him with lower risks, and increased ROI.
                          > That'll get him,
                          > > then he can remove the obstacle.
                          >
                          > This technique will in most cases result in the removing of someone.
                          > It won't always be your manager. I'd advise using this with caution.

                          In my experience this can lead to terrible fallout, think 'Nuclear Winter',
                          and should be avoided at all costs. However, if you are right, if XP will be
                          of benefit to the business, then the risk of discontent has to be weighed
                          against the benefits.

                          Also, Ron is suggesting that the XPer may be the one removed. This isn't
                          such a bad thing if you have met your objectives through your sacrifice. It
                          is unlikely that it will do your career much harm.

                          > > Another technique is to bring in outside help, although this
                          > will only work
                          > > if you have a budget to do such a thing. For some inexplicable reason
                          > > organisations continue to bring in 'big' consultants to say the
                          > same thing
                          > > as the lower-level staff, just to get the higher levels of the
                          > hierarchy to
                          > > listen.
                          >
                          > There is some merit to this. But if the upper guys didn't ask the
                          > question, they probably don't want to hear the answer.

                          I would suggest that they will always be asking about ROI and risk. I
                          suggest that they probably wouldn't know that it was possible to reduce risk
                          and increase return on their soft-dev projects because nobody has told them
                          that it is possible.

                          > Brian is offering some pretty direct advice here. It could work, and
                          > it could backfire. From your imaginary Q&A I'm not convinced you have
                          > a good handle on what the guys upstairs care about. That's the first
                          > step, in my opinion.

                          Very good point. You have to know what the business is trying to achieve in
                          order to sell XP. If your business really doesn't care about time-to-market
                          then the frequent releases will just be an obsticle, not a benefit. If your
                          company doesn't care about quality, then pair-programming, refactoring, TFD
                          etc are all a waste of time. There are plenty of companies that don't care
                          about quality.

                          Its always a good technique to tailor your sales effort to the target. This
                          is why marketing companies pay a fortune for good demographic data, to help
                          them target the right market. You must do the same with XP.

                          In other words, you need to be a businessman, as well as a techy, to sell XP
                          successfully.

                          Bryan
                        • Ron Jeffries
                          ... my humble apologies. Ronald E Jeffries www.XProgramming.com How do I get to XP? Practice, man, practice.
                          Message 12 of 20 , Sep 30, 2001
                          • 0 Attachment
                            Around Sunday, September 30, 2001, 9:52:18 PM, Bryan Dollery wrote:

                            > Ron Jaffa-ries wrote

                            > Ron, it's Bryan, not Brian ;->

                            my humble apologies.

                            Ronald E Jeffries
                            www.XProgramming.com
                            "How do I get to XP?" "Practice, man, practice."
                          • Dale Emery
                            Hi Ron, ... I haven t found that to be true, either for me or for others. The biggest challenge for me is to stay in touch with what I really want, right here,
                            Message 13 of 20 , Oct 1, 2001
                            • 0 Attachment
                              Hi Ron,

                              > But the problem with the Courage value is that to adopt it you
                              > have to admit that you don't have it.

                              I haven't found that to be true, either for me or for others.

                              The biggest challenge for me is to stay in touch with what I really
                              want, right here, right now. When I can do that, I usually act
                              courageously. When I can't, I don't.

                              I often help other people do something courageous. To do that, I
                              focus on helping the person explore what they really want, and
                              (sometimes) what they think would happen if they took a risk. The
                              idea that the person doesn't have courage never comes up.

                              Dale
                            • Dale Emery
                              Hi Dave, ... One person at a time. One courageous act at a time. Start with myself. 1. Do something courageous, in public. This reminds people that they are
                              Message 14 of 20 , Oct 1, 2001
                              • 0 Attachment
                                Hi Dave,

                                > So how do we get our companies to exhibit Courage?

                                One person at a time. One courageous act at a time. Start with
                                myself.

                                1. Do something courageous, in public. This reminds people that they
                                are able to act courageously. It helps if you survive the
                                consequences of your courageous act, but that isn't always necessary.

                                2. Help one person at a time to do at least one courageous thing. My
                                way is to help people find out what they really want in some sticky
                                situation. Often, this is enough to connect the person with their
                                courage. If that doesn't do it, I sometimes ask they expect would
                                happen if they were to speak up (or whatever courageous act). What's
                                the worst thing that could happen? What's the best thing that could
                                happen? What is most likely to happen? Sometimes, the person
                                realizes that even the worst thing that could happen isn't so bad.

                                I highly recommend the wonderful book "The Courageous Messenger," by
                                Kathleen D. Ryan, Daniel K. Oestreich, and George A. Orr III. (San
                                Francisco: Jossey-Bass Publishers, 1996 -- ISBN: 0-7879-0268-3)

                                Dale
                              • Dale Emery
                                Hi Dave, ... Yes. Stop speculating about how the managers would respond. Talk to them, and listen to what they really say. Dale
                                Message 15 of 20 , Oct 1, 2001
                                • 0 Attachment
                                  Hi Dave,

                                  > The standard answers to issues like these are listed below, but
                                  > none of them have ever felt very satisfying, so right below them I
                                  > have listed the answer that I would expect from management. Is
                                  > there anything else that anyone can suggest?

                                  Yes. Stop speculating about how the managers would respond. Talk to
                                  them, and listen to what they really say.

                                  Dale
                                • Christopher Hart
                                  Dave, Don t sell the company on Courage. Courage implies risk, and most people avoid risk. It s better to begin implementing XP practices one by one, gathering
                                  Message 16 of 20 , Oct 1, 2001
                                  • 0 Attachment
                                    Dave,

                                    Don't sell the company on Courage. Courage implies risk, and most people
                                    avoid risk. It's better to begin implementing XP practices one by one,
                                    gathering some metrics for the benefits, and then demonstrating results.
                                    Don't mention XP. After you generate some enthusiasm, describe how you can
                                    get even better results and then do it. Still don't mention XP. After you
                                    change the culture to accept all twelve XP practices as normal, then you can
                                    casually mention XP. Use the Stone Soup story from "The Pragmatic
                                    Programmer." Good luck!

                                    Best Regards,

                                    Chris

                                    Christopher Hart
                                    President & CTO
                                    Hart Edwards Corporation, Inc.
                                    Tel: 303-402-9883 ext 117
                                    Mobile: 720-231-6616

                                    Enterprise and Network Management Solutions

                                    Proprietary and Confidential Correspondence
                                    Copyright (c) 2001 Hart Edwards Corporation, Inc. All rights reserved.


                                    ----- Original Message -----
                                    From: <dstorrs@...>
                                    To: <extremeprogramming@yahoogroups.com>
                                    Sent: Sunday, September 30, 2001 12:36 PM
                                    Subject: Selling the company on Courage (was Re: [XP] Digest Number 1500)


                                    > --- In extremeprogramming@y..., Ron Jeffries <ronjeffries@a...> wrote:
                                    > > Around Sunday, September 30, 2001, 1:05:09 PM, Dave Storrs wrote:
                                    > >
                                    > > > Any thoughts, anyone?
                                    > >
                                    > > Yeah. Give up. Do our best and wait for the old farts to die off. No,
                                    > > bad idea. I _am_ an old fart! I guess I don't know how to sell the
                                    > > stuff. That's why I'm a techie, not a salesman.
                                    > >
                                    > > Ronald E Jeffries
                                    >
                                    > I'm not sure if you're
                                    >
                                    > (A) joking
                                    > (B) gently chiding me for giving up
                                    > (C) castigating me for giving up
                                    > (D) some combination of the above
                                    > (E) something else.
                                    >
                                    > So which is it? :>
                                    >
                                    > My post was meant very seriously...I believe that selling the company
                                    > on the idea of Courage would be a sufficient requirement for getting
                                    > them to try full-blown XP. I haven't been able to get them to do that
                                    > yet, and it's been very frustrating...largely because I couldn't
                                    > understand why I couldn't get them to do it. Now I see what the
                                    > problem is, and all I have to do is solve it.
                                    >
                                    > Certainly talking to the CTO and the other more technically-minded
                                    > managers will help...we share more points of reference. I understand
                                    > that Rome wasn't built in a day and I'll just have to keep at it. But
                                    > I'm *not* a salesman, and I'm asking for specific advice from the
                                    > people who do this for a living...e.g., consultants and coaches. (This
                                    > includes you, Ron, old fart or not. :>)
                                    >
                                    > So again...any ideas?
                                    >
                                    > Dave
                                    >
                                    >
                                    > To Post a message, send it to: extremeprogramming@...
                                    >
                                    > To Unsubscribe, send a blank message to:
                                    extremeprogramming-unsubscribe@...
                                    >
                                    > ad-free courtesy of objectmentor.com
                                    >
                                    > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
                                    >
                                    >
                                    >
                                  • Steve Ropa
                                    ... Darn it! I was halfway through a lengthy reply, and you turn around and boil it down to one paragraph! I would just add that we also need to stop selling
                                    Message 17 of 20 , Oct 1, 2001
                                    • 0 Attachment
                                      > -----Original Message-----
                                      > From: Christopher Hart [mailto:hart@...]
                                      > Sent: Monday, October 01, 2001 10:44 AM
                                      > To: extremeprogramming@yahoogroups.com
                                      > Subject: Re: Selling the company on Courage (was Re: [XP]
                                      > Digest Number
                                      > 1500)
                                      >
                                      >
                                      >
                                      > Dave,
                                      >
                                      > Don't sell the company on Courage. Courage implies risk, and
                                      > most people
                                      > avoid risk. It's better to begin implementing XP practices one by one,
                                      > gathering some metrics for the benefits, and then
                                      > demonstrating results.
                                      > Don't mention XP. After you generate some enthusiasm,
                                      > describe how you can
                                      > get even better results and then do it. Still don't mention
                                      > XP. After you
                                      > change the culture to accept all twelve XP practices as
                                      > normal, then you can
                                      > casually mention XP. Use the Stone Soup story from "The Pragmatic
                                      > Programmer." Good luck!
                                      >
                                      > Best Regards,
                                      >
                                      > Chris
                                      >
                                      > Christopher Hart
                                      > President & CTO
                                      > Hart Edwards Corporation, Inc.
                                      > Tel: 303-402-9883 ext 117
                                      > Mobile: 720-231-6616
                                      >
                                      > Enterprise and Network Management Solutions
                                      >
                                      > Proprietary and Confidential Correspondence
                                      > Copyright (c) 2001 Hart Edwards Corporation, Inc. All rights reserved.
                                      >
                                      Darn it! I was halfway through a lengthy reply, and you turn around and
                                      boil it down to one paragraph! I would just add that we also need to stop
                                      selling management short. Managers generally are more courageous than we
                                      think, they just apply it in different directions. Of course, we know of at
                                      least one President and CTO that had the courage to do XP! ;-)

                                      Steve
                                    • Matthew Davis
                                      ... the ... always ... On ... most ... It may have to do with tax law and capitalizable and uncapitalizable expenses. I won t pretend to understand it
                                      Message 18 of 20 , Oct 1, 2001
                                      • 0 Attachment
                                        --- In extremeprogramming@y..., Dave Storrs <dstorrs@d...> wrote:
                                        > XP: Doing our design incrementally, by way of The Planning Game and
                                        the
                                        > unit tests, allows us to be more responsive to your needs. We are
                                        always
                                        > working on the highest priority stories, and we can give you a
                                        > better-than-usual estimate of what you will get by a certain date.
                                        >
                                        > [ok, actually, I can't think of why management would object to this.
                                        On
                                        > the other hand, this is the single practice that my boss has been
                                        most
                                        > resistant to...and I have yet to understand his reasons for it.]

                                        It may have to do with tax law and "capitalizable" and
                                        "uncapitalizable" expenses. I won't pretend to understand it all, but
                                        I know that my boss has concerns that without a detailed up-front
                                        requirements document, we won't be able to put our dev costs in the
                                        best possible tax situation.

                                        Other possible concerns:

                                        M: You mean I have to take time to meet with you all every two weeks
                                        just to tell you to keep going?

                                        or

                                        M: Every two weeks?! QA is already 3 months behind, they'd all quit
                                        if we started giving them a new release to test every two weeks!
                                        Besides, we already know that a full regression takes 4 weeks to
                                        complete. And no, they can't automate it - I just told you they're
                                        three months behind, they just don't have the time to automate it.

                                        -Matthew
                                        azami@...
                                      • Ron Jeffries
                                        ... P: How often do you open your eyes when you are driving home? Steering a million dollar
                                        Message 19 of 20 , Oct 2, 2001
                                        • 0 Attachment
                                          Around Monday, October 01, 2001, 2:55:37 PM, Matthew Davis wrote:

                                          > M: You mean I have to take time to meet with you all every two weeks
                                          > just to tell you to keep going?

                                          P: How often do you open your eyes when you are driving home? Steering
                                          a <insert how many million dollars this project is worth here> million
                                          dollar project is worth a half day of your time -- or your designated
                                          representative -- every two weeks.

                                          > or

                                          > M: Every two weeks?! QA is already 3 months behind, they'd all quit
                                          > if we started giving them a new release to test every two weeks!
                                          > Besides, we already know that a full regression takes 4 weeks to
                                          > complete. And no, they can't automate it - I just told you they're
                                          > three months behind, they just don't have the time to automate it.

                                          P: It takes us an average of <your number, probably >=3> cycles
                                          through QA to get the code released. In that time, what's our lost
                                          revenue? What are the other opportunity costs of that much delay?

                                          P: We'll write the acceptance tests: we have to anyway, so that we'll
                                          know when we're done and so that we can deliver clean code to QA.
                                          We're trying to get the number of cycles through there as low as we
                                          can.

                                          Ronald E Jeffries
                                          www.XProgramming.com
                                          It's easier to act your way into a new way of thinking
                                          than to think your way into a new way of acting. --Millard Fuller
                                        • Darren Hobbs
                                          ... Absolutely spot on. This is almost exactly the reponse I got when pushing for frequent releases. Along with the our process doesn t allow for frequent
                                          Message 20 of 20 , Oct 3, 2001
                                          • 0 Attachment
                                            --- In extremeprogramming@y..., "Matthew Davis" <azami@s...> wrote:
                                            >
                                            > M: Every two weeks?! QA is already 3 months behind, they'd all
                                            > quit if we started giving them a new release to test every two
                                            > weeks!
                                            > Besides, we already know that a full regression takes 4 weeks to
                                            > complete. And no, they can't automate it - I just told you they're
                                            > three months behind, they just don't have the time to automate it.
                                            >
                                            Absolutely spot on. This is almost exactly the reponse I got when
                                            pushing for frequent releases. Along with the "our process doesn't
                                            allow for frequent releases and all this 'iterative' nonsense so we
                                            won't do it, and we can't change the process because the PHB's have
                                            decreed it so". I _so_ wanted to say, "I see, so what you're saying
                                            is that our software process is more important than the actual
                                            software it is supposed to help us produce?". We were a couple of
                                            floors up next to a big window so I kept my mouth shut.

                                            -Darren
                                          Your message has been successfully submitted and would be delivered to recipients shortly.