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

XP in non xp environment?

Expand Messages
  • Michael Brunton-Spall
    Ok based on some of the discussions in the newbie thread, and some other comments here and there, I thought I d ask this fairly newbie type question. If one is
    Message 1 of 21 , Jan 31, 2005
    • 0 Attachment
      Ok based on some of the discussions in the newbie thread, and some other
      comments here and there, I thought I'd ask this fairly newbie type
      question.

      If one is working in an organisation that is firmly anti-xp, what
      practices of XP are possible to do in a skunk works type manner. I.e.
      stealthily apply them by oneself without requiring management approval.
      Which practices can we definitely not do? (Customer on site, Planning
      Game spring to mind).
      Given that many of the processes work best when applied together, what
      problems are caused by the lack of the above in the development process.

      Some possible issues may include the following...
      <these are not a reflection of my place of work, but are merely
      suggestions> (that should avoid me being fired if my emails are
      monitored!)
      Micro-managing managers, are you allowed to perform any techniques that
      are not *approved* techniques
      Restrictive corporate policies, for example, unable to install any
      software of choice on dev machines (this one is true here, the fight to
      get cppunit in was hard!)
      Code sharing, (yes that can be a problem, take cppunit for example,
      programmers who don't have it installed can't compile my programs
      without linking errors)
      Non-supportive peers,

      I'm sure there's more, but I'm out of ideas now, just thought I'd toss
      this off, and see what comes in.

      Mib
      Software Engineer



      [Non-text portions of this message have been removed]
    • Brandon Campbell
      Michael, I tried to answer your questions below. No new information than what I posted on the newbie thread. On Mon, 31 Jan 2005 15:29:36 -0000, Michael
      Message 2 of 21 , Jan 31, 2005
      • 0 Attachment
        Michael,

        I tried to answer your questions below. No new information than what
        I posted on the newbie thread.

        On Mon, 31 Jan 2005 15:29:36 -0000, Michael Brunton-Spall
        <mib@...> wrote:
        >
        > Ok based on some of the discussions in the newbie thread, and some other
        > comments here and there, I thought I'd ask this fairly newbie type
        > question.
        >
        > If one is working in an organisation that is firmly anti-xp, what
        > practices of XP are possible to do in a skunk works type manner. I.e.
        > stealthily apply them by oneself without requiring management approval.
        > Which practices can we definitely not do? (Customer on site, Planning
        > Game spring to mind).
        > Given that many of the processes work best when applied together, what
        > problems are caused by the lack of the above in the development process.
        >
        > Some possible issues may include the following...
        > <these are not a reflection of my place of work, but are merely
        > suggestions> (that should avoid me being fired if my emails are
        > monitored!)
        > Micro-managing managers, are you allowed to perform any techniques that
        > are not *approved* techniques

        Writing requirements/user stories on 3x5 cards, unit tests completly
        separate from the main codebase. Creatively pair with others, ie
        fixing problems, sharing information/knowledge

        > Restrictive corporate policies, for example, unable to install any
        > software of choice on dev machines (this one is true here, the fight to
        > get cppunit in was hard!)


        > Code sharing, (yes that can be a problem, take cppunit for example,
        > programmers who don't have it installed can't compile my programs
        > without linking errors)

        keep unit test in a separate codebase, this may not apply since I am
        not a C++ programmer I'm unsure.

        > Non-supportive peers,

        Ignore them
        --
        Brandon Campbell
      • Steve Berczuk
        Here are some thoughts based on the times I ve introduced practices that XP uses... Note the way that I phrased that... You can get benefit from using some of
        Message 3 of 21 , Jan 31, 2005
        • 0 Attachment
          Here are some thoughts based on the times I've introduced practices
          that XP uses... Note the way that I phrased that... You can get
          benefit from using some of the practices that comprise XP without
          claiming to use XP, which may be a way to overcome resistance...

          Also, you might want to check out the book "Fearless Change" by Mary
          Lynn Manns and Linda Rising... also Weinberg's "Becoming a Technical
          Leader" is a great book that will address many of your issues.

          Note: realize that if the organization is really broken, you might
          want to just find another place to work.

          But assuming that you want to change things...

          On Mon, 31 Jan 2005 15:29:36 -0000, Michael Brunton-Spall
          <mib@...> wrote:
          > If one is working in an organisation that is firmly anti-xp, what
          > practices of XP are possible to do in a skunk works type manner. I.e.
          > stealthily apply them by oneself without requiring management approval.
          > Which practices can we definitely not do? (Customer on site, Planning
          > Game spring to mind).

          Unit testing is the easiest thing to add in some sense, since you can
          do it yourself. Granted the bigger win happens when everyone RUNS (if
          not writes) tests, but at least if you have your unit tests you can
          better identify what changed since you last updated. Also good testing
          may require "architecture -- in the small anyway-- changes.

          Stories are also a key thing, but they are harder to do on your own.
          You need the collaboration of someone who "owns" the project
          requirements. One thing to try is to take requirements/tasks and take
          the approach of "I wasn't sure if I understood you. Is this (Story
          card) what you meant. If you come across someone who says "You don't
          need to understand, just code" see the Note above.

          Also frequent integrations. Do integration builds your self, and
          update your workspace often.

          > Given that many of the processes work best when applied together, what
          > problems are caused by the lack of the above in the development process.

          Well, you won't be doing XP, but you will be doing good practices,
          which is what XP is in a sense: A set of good, development practices
          working together in the context of a set of values.

          > Some possible issues may include the following...
          > <these are not a reflection of my place of work, but are merely
          > suggestions> (that should avoid me being fired if my emails are
          > monitored!)
          > Micro-managing managers, are you allowed to perform any techniques that
          > are not *approved* techniques

          Try to ignore them. If your output improves then what's the difference
          how you work?

          > Restrictive corporate policies, for example, unable to install any
          > software of choice on dev machines (this one is true here, the fight to
          > get cppunit in was hard!)

          one can argue that cpp unit isn't an install, but just code you are
          adding to a project. are you saying that getting permission to check
          in code is hard?

          > Code sharing, (yes that can be a problem, take cppunit for example,
          > programmers who don't have it installed can't compile my programs
          > without linking errors)
          see above question about checking in (third party) code. I initially
          thought that you mean t collective ownership, but that can be tricky
          to encourage on your own.

          > Non-supportive peers,

          What support do you need? How about this approach. Write Tests,
          Integrate often, demonstrate an ability to get YOUR work done quickly.
          People should start to be curious and want to try what you are doing..


          Steve


          --
          Steve Berczuk | steve@... | http://www.berczuk.com
          SCM Patterns: Effective Teamwork, Practical Integration
          www.scmpatterns.com
        • Ron Jeffries
          Hi again, Michael, I ll see if I can get the ball rolling. ... IMO, there s no such thing as definitely can or definitely cannot. We have heard of cases where
          Message 4 of 21 , Feb 1, 2005
          • 0 Attachment
            Hi again, Michael,

            I'll see if I can get the ball rolling.

            On Monday, January 31, 2005, at 10:29:36 AM, Michael Brunton-Spall wrote:

            > Ok based on some of the discussions in the newbie thread, and some other
            > comments here and there, I thought I'd ask this fairly newbie type
            > question.

            > If one is working in an organisation that is firmly anti-xp, what
            > practices of XP are possible to do in a skunk works type manner. I.e.
            > stealthily apply them by oneself without requiring management approval.
            > Which practices can we definitely not do? (Customer on site, Planning
            > Game spring to mind).

            IMO, there's no such thing as definitely can or definitely cannot.
            We have heard of cases where management denied programmers the right
            to write tests. That said, I'll just comment on a few practices,
            some that you mentioned and some that you didn't.

            Programmer testing can usually be done and can usually be improved
            beyond what we're currently doing. Almost certain to pay off, easy
            to use independently, or as a group, usually without approval.

            Talking to customers is often possible even if they're not on
            site, and a good relationship with them will pay off. One wants to
            avoid the appearance of "going around" management.

            I could imagine a team using iterations internally even if the
            organization didn't know what was going on. They might get
            together every Monday and plan what to do for the week. They could
            perhaps share their work in a pairing kind of say, they could
            integrate frequently, and focus on small, completely done
            deliverables, even if these were subsets of the bigger features
            that had been requested. I could imagine such a team producing
            status reports saying things like "To aid the flow of development,
            we have broken down the Baking feature in Spec 125.43 into three
            technical components, Cookies, Cake, and Bread. Cookies is working
            now and we expect Cake to be finished next week, and Bread the
            week after."

            I could imagine carrying cards around with me with features on
            them and pulling them out whenever planning matters arose. Imagine
            the power of being able to say

            "Baking is estimated to require three weeks, and the Broiling
            effort is expected to take two. If we're to demonstrate both
            Baking and Broiling at the show in four weeks, we'll need to
            trim one or both of those requirements a bit. We're suggesting
            dropping Chocolate Chip and Flame-broiled Herring. That should
            do the job, although we think that Salmon Cake is a bit at risk
            as well. We're open to changing what we drop at your discretion
            and we can provide estimates for the time for each sub-feature."

            Those are examples that come to mind. Each situation may vary but I
            think that much benefit can be had by working from the inside out.
            Please raise specific questions for us to talk about more deeply.

            > Given that many of the processes work best when applied together, what
            > problems are caused by the lack of the above in the development process.

            Refactoring without tests is hard. That's the one that I fear most.

            > Some possible issues may include the following...
            > <these are not a reflection of my place of work, but are merely
            > suggestions> (that should avoid me being fired if my emails are
            > monitored!)
            > Micro-managing managers, are you allowed to perform any techniques that
            > are not *approved* techniques
            > Restrictive corporate policies, for example, unable to install any
            > software of choice on dev machines (this one is true here, the fight to
            > get cppunit in was hard!)
            > Code sharing, (yes that can be a problem, take cppunit for example,
            > programmers who don't have it installed can't compile my programs
            > without linking errors)
            > Non-supportive peers,

            All of these are issues. I'd think that you could break up your
            programs or define some macros that would solve the compilation
            issue.

            Again, let's talk about some specifics.

            Ron Jeffries
            www.XProgramming.com
            The main reason that testing at the end of a development cycle finds
            problems is not that problems were put in near the end, it is that
            testing was put off until then.
          • SirGilligan
            I work in the situation where the team/company is phasic in approach. I came from a company that was agile. I do this one thing and try to do it consistently:
            Message 5 of 21 , Feb 1, 2005
            • 0 Attachment
              I work in the situation where the team/company is phasic in approach.
              I came from a company that was agile.

              I do this one thing and try to do it consistently: Test First.

              I write unit tests for my code. I sometimes write a little code and
              then a little test, I sometimes write a little test and then a little
              code. I am trying to do the latter more than the other.

              Before I check my code in I run my tests.

              What I can not do as a whole:
              Sit Together
              Energized Work
              Pair Programming (because the others a busy, but walk throughs can
              happen)
              Stories (we have formal docs because of the process)
              Weekly Cycle (but I hear we are going to weekly reflections)
              Quarterly Cycle
              Ten Minute Build
              Continuous Integration


              What I do when I can:
              Whole Team
              Informative Workspace (In my Cube)
              Slack
              Incremental Design

              Geoff
            • Michael Brunton-Spall
              Thanks all for the responses, I wasn t asking in terms of a specific question that I wanted answering (although some of the features of my workplace are
              Message 6 of 21 , Feb 1, 2005
              • 0 Attachment
                Thanks all for the responses,

                I wasn't asking in terms of a specific question that I wanted answering
                (although some of the features of my workplace are represented in some
                minor way by the problems I described, but I'm working on that!)
                I was originally asking because when I first got interested in XP, after
                reading the white book and some others, I got the impression that one
                could only "do XP" if one was working on a project and the whole team
                was involved.
                However in many organisations, developers are not free to try to do
                anything they please, and the limits on freedoms obviously vary a great
                deal.

                I was hoping to start a discussion about what practices can be
                implemented under the radar of management oversight, and what advantages
                or disadvantages that may have.

                I was obviously interested in which practices can be done subtly, and
                which are simply not able to be done without management interaction.

                Obviously, from the responses I've had there are a number of
                assumptions,
                Firstly that the person wishing to implement the practices is a senior
                developer or responsible for architectural changes.
                Secondly, people have assumed in some cases that it's a single
                developer, Ron suggested that a team could do it as well.

                Hmm, thinking through the issue, I'll pop off a couple of possible
                configurations and see what people think would be appropriate in each
                circumstance.
                I'll repeat these are not my work situation, my work situation is unique
                in it's own way, this is for my intellectual stimulation and possibly to
                help any newbies who might be in situations like this...

                1) Bob starts at his first computing job as a graduate, He studied XP
                and agile methods at university, and is excited to start practicing them
                at his new workplace.
                On his first day he asks who he'll be pairing with to met by blank
                stares from the rest of the team, he's shown his single cubicle and
                given some simple programming tasks to do.
                Over the next few weeks/months he realizes that the development
                environment is not agile in any form, the development environment is
                fairly small (5 - 10 developers) and most developers work on projects by
                themselves, owning their project and being fiercely protective.
                The language of choice is Java, all built in an IDE, not using Ant,
                jUnit or anything like that.
                He approaches his boss to suggest trialling agile methods, shows people
                his copy of the White book, but nobody seems interested. His managers
                are not against the idea however, and say that he can approach his own
                development in any way he wishes.
                Customer interaction is minimal, requirements are tossed "over the wall"
                at the developers, and the finished programs are "tossed over the wall"
                to the release department.
                If you were in his position how would you approach introducing XP and
                why would you choose that method?

                2) Sharon (lets not be sexist), has recently left a nice XP practicing
                development company and started a new job in a large development
                company. The company does not practice XP at all.
                Sharon enquires about introducing XP to the management and is met with
                fierce resistance (the standard XP Refactored arguments). She
                approaches the developers on her team who seem interested in the idea.
                The development project is a .NET web based system.
                Jim on the development team is responsible for gathering requirements
                from the customers and seems excited by the idea of trying XP.

                3) (lets do a really hard one) Karl has started in development, he is
                pro-XP, and is hoping for an XP team. He meets the team who do not do
                XP at all, and are fiercely resistant to change.
                Karl meets the management and finds that they are also highly resistant
                to change and "value cowardice" (to paraphrase Ron), they do not
                encourage changing code that does not need to be changed and outline a
                number of rules and regulations to prevent unnecessary code changes from
                being made to Karl.
                Development is done in C++, and the build environment is locked to
                changes by programmers (no installation of 3rd party libraries, no extra
                applications, no internet access).
                The team around Karl are not pro-XP, in fact because of the value placed
                on cowardice they are highly resistant to change and highly critical of
                anything new, lunch times often consist of ridiculing the latest
                methods.

                Ok, I know those are a bit rubbish as possibilities, but my imagination
                is tired today! Also I know that in Karls case certainly I think my
                response would be quit, but I think there are certainly times when one
                needs to do a job even though one doesn't enjoy it.

                So what would various people do in those cases, what are the best ways
                of bringing XP in, and are there times when it is actually inadvisable
                to try to introduce XP at all, but instead to bite the bullet and simply
                do as the rest of the team does?

                I guess in terms of evangelising XP, in what ways is best to demonstrate
                the business value of XP? Is it wise to show that your development
                produces less defects or is faster than your teams (possible to cause
                resentment), are third party examples better? (I've heard the response
                "but we have a unique development environment" more than a few times!)

                Mib
                Software Engineer


                > -----Original Message-----
                > From: Ron Jeffries [mailto:ronjeffries@...]
                > Sent: 01 February 2005 13:08
                > To: extremeprogramming@yahoogroups.com
                > Subject: Re: [XP] XP in non xp environment?
                >
                >
                >
                > Hi again, Michael,
                >
                > I'll see if I can get the ball rolling.
                >
                > On Monday, January 31, 2005, at 10:29:36 AM, Michael
                > Brunton-Spall wrote:
                >
                > > Ok based on some of the discussions in the newbie thread,
                > and some other
                > > comments here and there, I thought I'd ask this fairly newbie type
                > > question.
                >
                > > If one is working in an organisation that is firmly anti-xp, what
                > > practices of XP are possible to do in a skunk works type
                > manner. I.e.
                > > stealthily apply them by oneself without requiring
                > management approval.
                > > Which practices can we definitely not do? (Customer on
                > site, Planning
                > > Game spring to mind).
                >
                > IMO, there's no such thing as definitely can or definitely cannot.
                > We have heard of cases where management denied programmers the right
                > to write tests. That said, I'll just comment on a few practices,
                > some that you mentioned and some that you didn't.
                >
                > Programmer testing can usually be done and can usually be improved
                > beyond what we're currently doing. Almost certain to pay off, easy
                > to use independently, or as a group, usually without approval.
                >
                > Talking to customers is often possible even if they're not on
                > site, and a good relationship with them will pay off. One wants to
                > avoid the appearance of "going around" management.
                >
                > I could imagine a team using iterations internally even if the
                > organization didn't know what was going on. They might get
                > together every Monday and plan what to do for the week. They could
                > perhaps share their work in a pairing kind of say, they could
                > integrate frequently, and focus on small, completely done
                > deliverables, even if these were subsets of the bigger features
                > that had been requested. I could imagine such a team producing
                > status reports saying things like "To aid the flow of development,
                > we have broken down the Baking feature in Spec 125.43 into three
                > technical components, Cookies, Cake, and Bread. Cookies is working
                > now and we expect Cake to be finished next week, and Bread the
                > week after."
                >
                > I could imagine carrying cards around with me with features on
                > them and pulling them out whenever planning matters arose. Imagine
                > the power of being able to say
                >
                > "Baking is estimated to require three weeks, and the Broiling
                > effort is expected to take two. If we're to demonstrate both
                > Baking and Broiling at the show in four weeks, we'll need to
                > trim one or both of those requirements a bit. We're suggesting
                > dropping Chocolate Chip and Flame-broiled Herring. That should
                > do the job, although we think that Salmon Cake is a bit at risk
                > as well. We're open to changing what we drop at your discretion
                > and we can provide estimates for the time for each sub-feature."
                >
                > Those are examples that come to mind. Each situation may vary but I
                > think that much benefit can be had by working from the inside out.
                > Please raise specific questions for us to talk about more deeply.
                >
                > > Given that many of the processes work best when applied
                > together, what
                > > problems are caused by the lack of the above in the
                > development process.
                >
                > Refactoring without tests is hard. That's the one that I fear most.
                >
                > > Some possible issues may include the following...
                > > <these are not a reflection of my place of work, but are merely
                > > suggestions> (that should avoid me being fired if my emails are
                > > monitored!)
                > > Micro-managing managers, are you allowed to perform any
                > techniques that
                > > are not *approved* techniques
                > > Restrictive corporate policies, for example, unable to install any
                > > software of choice on dev machines (this one is true here,
                > the fight to
                > > get cppunit in was hard!)
                > > Code sharing, (yes that can be a problem, take cppunit for example,
                > > programmers who don't have it installed can't compile my programs
                > > without linking errors)
                > > Non-supportive peers,
                >
                > All of these are issues. I'd think that you could break up your
                > programs or define some macros that would solve the compilation
                > issue.
                >
                > Again, let's talk about some specifics.
                >
                > Ron Jeffries
                > www.XProgramming.com
                > The main reason that testing at the end of a development cycle finds
                > problems is not that problems were put in near the end, it is that
                > testing was put off until then.
                >
                >
                >
                >
                > To Post a message, send it to: extremeprogramming@...
                >
                > To Unsubscribe, send a blank message to:
                > extremeprogramming-unsubscribe@...
                >
                > ad-free courtesy of objectmentor.com
                > Yahoo! Groups Links
                >
                >
                >
                >
                >
                >
                >
                >
              • yahoogroups@jhrothjr.com
                From: Michael Brunton-Spall To: extremeprogramming@yahoogroups.com
                Message 7 of 21 , Feb 1, 2005
                • 0 Attachment
                  From: "Michael Brunton-Spall"
                  <mib.at.ecmsys.co.uk@...>
                  To: "extremeprogramming@yahoogroups.com"
                  <extremeprogramming.at.yahoogroups.com@...>
                  Sent: Tuesday, February 01, 2005 8:12 AM
                  Subject: RE: [XP] XP in non xp environment?


                  >
                  > Thanks all for the responses,
                  >
                  > I wasn't asking in terms of a specific question that I wanted answering
                  > (although some of the features of my workplace are represented in some
                  > minor way by the problems I described, but I'm working on that!)
                  > I was originally asking because when I first got interested in XP, after
                  > reading the white book and some others, I got the impression that one
                  > could only "do XP" if one was working on a project and the whole team
                  > was involved.

                  ...

                  > I was obviously interested in which practices can be done subtly, and
                  > which are simply not able to be done without management interaction.
                  >
                  > Obviously, from the responses I've had there are a number of
                  > assumptions,
                  > Firstly that the person wishing to implement the practices is a senior
                  > developer or responsible for architectural changes.
                  > Secondly, people have assumed in some cases that it's a single
                  > developer, Ron suggested that a team could do it as well.
                  >
                  > Hmm, thinking through the issue, I'll pop off a couple of possible
                  > configurations and see what people think would be appropriate in each
                  > circumstance.

                  ...

                  > 1) Bob starts at his first computing job as a graduate, He studied XP
                  > and agile methods at university, and is excited to start practicing them
                  > at his new workplace.
                  > On his first day he asks who he'll be pairing with to met by blank
                  > stares from the rest of the team, he's shown his single cubicle and
                  > given some simple programming tasks to do.

                  One nitpick - on an XP team, you don't pair with someone
                  all the time, you pair with everyone over the course of a week
                  or so.

                  > Over the next few weeks/months he realizes that the development
                  > environment is not agile in any form, the development environment is
                  > fairly small (5 - 10 developers) and most developers work on projects by
                  > themselves, owning their project and being fiercely protective.
                  > The language of choice is Java, all built in an IDE, not using Ant,
                  > jUnit or anything like that.
                  > He approaches his boss to suggest trialling agile methods, shows people
                  > his copy of the White book, but nobody seems interested. His managers
                  > are not against the idea however, and say that he can approach his own
                  > development in any way he wishes.
                  > Customer interaction is minimal, requirements are tossed "over the wall"
                  > at the developers, and the finished programs are "tossed over the wall"
                  > to the release department.
                  > If you were in his position how would you approach introducing XP and
                  > why would you choose that method?

                  If I can do anything? Bring in a copy of JUnit and FIT (the batch version,
                  from fit.c2.com, not the Fitnesse version from www.fitnesse.org) and
                  have at it. The reason for the disclaimer is that "do anything" most
                  likely doesn't extend to installing FitNesse.

                  Take the requirements, break them into stories, write acceptance
                  tests for the stories using the same tool the analysts use for the
                  requirements (e.g. Word, etc.) This is important!

                  Use the FIT tests as a basis for discussion with the analysts when
                  you're clarifying the requirements. If you're diplomatic (don't mention
                  XP), you may get a delightful surprise when they pick up on it,
                  and they may even pull up Word and add stuff to your tests!

                  Implement story by story using JUnit and TDD.

                  Do your status reports story by story, but _not_ using the
                  term story. Just say you're breaking the project into parts,
                  one or two sentences per part, and will do them in the
                  given order. If the analysts come on board, they may ask
                  you to change the order. Do it.

                  Keep a copy of the FIT tests and the unit tests somewhere
                  safe. In the standard repository if possible, somewhere
                  private if not. They're worth gold when the defect reports
                  come back, and they will come back: no junior programmer
                  is capable of writing defect free code, and darn few
                  real seniors.

                  Keep a running copy availible at all times of what you've
                  done to date for demonstrations. That's your bottom
                  line fallback.

                  If you're working on existing programs, get a copy of
                  "Working Effectively With Legacy Code" by Michael
                  Feathers.

                  > 2) Sharon (lets not be sexist), has recently left a nice XP practicing
                  > development company and started a new job in a large development
                  > company. The company does not practice XP at all.
                  > Sharon enquires about introducing XP to the management and is met with
                  > fierce resistance (the standard XP Refactored arguments). She
                  > approaches the developers on her team who seem interested in the idea.
                  > The development project is a .NET web based system.
                  > Jim on the development team is responsible for gathering requirements
                  > from the customers and seems excited by the idea of trying XP.

                  Find out what the team will accept, and go slow. Jim may well
                  be able to introduce some variant of the planning game, and
                  may also be able to introduce using FIT as a requirements
                  documentation technique.

                  If there are already team practices in place, it may be
                  harder to do the software construction practices than
                  in the code and fix shop in the first example. On the
                  other hand, if most of the team is receptive, you can
                  introduce iterations and most of the software construction
                  techniques as long as you keep a light touch, and lead
                  by example.

                  > 3) (lets do a really hard one) Karl has started in development, he is
                  > pro-XP, and is hoping for an XP team. He meets the team who do not do
                  > XP at all, and are fiercely resistant to change.
                  > Karl meets the management and finds that they are also highly resistant
                  > to change and "value cowardice" (to paraphrase Ron), they do not
                  > encourage changing code that does not need to be changed and outline a
                  > number of rules and regulations to prevent unnecessary code changes from
                  > being made to Karl.
                  > Development is done in C++, and the build environment is locked to
                  > changes by programmers (no installation of 3rd party libraries, no extra
                  > applications, no internet access).
                  > The team around Karl are not pro-XP, in fact because of the value placed
                  > on cowardice they are highly resistant to change and highly critical of
                  > anything new, lunch times often consist of ridiculing the latest
                  > methods.

                  Find another job with another company.

                  > Ok, I know those are a bit rubbish as possibilities, but my imagination
                  > is tired today! Also I know that in Karls case certainly I think my
                  > response would be quit, but I think there are certainly times when one
                  > needs to do a job even though one doesn't enjoy it.

                  Worst case? You can build your own versions of xUnit and FIT. Use
                  some time at home to look at them. The second part of Kent Beck's
                  TDD by Example shows doing a primitive version of PyUnit. A thorough
                  examination of FIT will bend your mind: Ward is a wizard programmer.

                  > So what would various people do in those cases, what are the best ways
                  > of bringing XP in, and are there times when it is actually inadvisable
                  > to try to introduce XP at all, but instead to bite the bullet and simply
                  > do as the rest of the team does?
                  >
                  > I guess in terms of evangelising XP, in what ways is best to demonstrate
                  > the business value of XP? Is it wise to show that your development
                  > produces less defects or is faster than your teams (possible to cause
                  > resentment), are third party examples better? (I've heard the response
                  > "but we have a unique development environment" more than a few times!)

                  The best first step in any organizational change process is to
                  find out how change already happens, and then figure out
                  how to turn that crank.

                  John Roth
                  >
                  > Mib
                  > Software Engineer
                • Brandon Campbell
                  On Tue, 1 Feb 2005 14:12:17 -0000, Michael Brunton-Spall ... This is the situation that I have seen the most of (5 organizations since 1999). In my experience
                  Message 8 of 21 , Feb 1, 2005
                  • 0 Attachment
                    On Tue, 1 Feb 2005 14:12:17 -0000, Michael Brunton-Spall
                    <mib@...> wrote:
                    >
                    > Thanks all for the responses,
                    >

                    > 1) Bob starts at his first computing job as a graduate, He studied XP
                    > and agile methods at university, and is excited to start practicing them
                    > at his new workplace.
                    > On his first day he asks who he'll be pairing with to met by blank
                    > stares from the rest of the team, he's shown his single cubicle and
                    > given some simple programming tasks to do.
                    > Over the next few weeks/months he realizes that the development
                    > environment is not agile in any form, the development environment is
                    > fairly small (5 - 10 developers) and most developers work on projects by
                    > themselves, owning their project and being fiercely protective.
                    > The language of choice is Java, all built in an IDE, not using Ant,
                    > jUnit or anything like that.
                    > He approaches his boss to suggest trialling agile methods, shows people
                    > his copy of the White book, but nobody seems interested. His managers
                    > are not against the idea however, and say that he can approach his own
                    > development in any way he wishes.
                    > Customer interaction is minimal, requirements are tossed "over the wall"
                    > at the developers, and the finished programs are "tossed over the wall"
                    > to the release department.
                    > If you were in his position how would you approach introducing XP and
                    > why would you choose that method?
                    >

                    This is the situation that I have seen the most of (5 organizations
                    since 1999). In my experience this is one of the best non-XP
                    environments because there is a possibility for change. As Bob works
                    on his projects he starts to get the customer more involved, asking
                    detailed questions about the requirements, writing stories down on
                    cards which he posts on his cubicle wall. He begins his projects
                    using TDD and delivers a release to the customer for review and
                    comments, adjusting the remaining stories, or adding more if needed,
                    to incorporate the feedback.

                    Since the matter of tools is essentially left up to Bob, he creates an
                    ant script that checks out his code as well as all dependent items
                    from the team's repository, builds his projects and runs his tests.
                    He runs this script frequently, or continuously if he sets up
                    cruisecontrol. When code from another developer causes his tests to
                    fail, he must carefully approach the other developer and 'pair' with
                    the other developer to help him find and correct the problem. Maybe
                    at this point show other developer how unit testing could be used to
                    test code before it gets checked in.

                    As Bob has the opportunity to work with other customers as he gets
                    assigned other projects, the customers expectations are higher, since
                    they had more opportunity for feedback and the system meets more of
                    their needs than the systems built by the other developers.

                    The other developers, as well as Bob's supervisor notices that Bob
                    spends less time fixing defects and more time completing user
                    requirements.

                    In organizations I have been in people seem to be under the impression
                    that XP is almost cult-like and XP evangelists are continually trying
                    to convert others. I think that in organizations like the one above
                    it is not the XP 'missionary' that is going to convert the other
                    programmers, but the XPer that shows his peers by his examples and by
                    using small 'teaching moments' that the principles and practices of XP
                    can create help the team create higher quality software, that meets
                    the needs of their customers.

                    --
                    Brandon Campbell
                  • Ron Jeffries
                    ... I certainly hope I didn t say that. If I did, I m sorry now. Ron Jeffries www.XProgramming.com You can observe a lot by watching. --Yogi Berra
                    Message 9 of 21 , Feb 1, 2005
                    • 0 Attachment
                      On Tuesday, February 1, 2005, at 9:12:17 AM, Michael Brunton-Spall wrote:

                      > "value cowardice" (to paraphrase Ron)

                      I certainly hope I didn't say that. If I did, I'm sorry now.

                      Ron Jeffries
                      www.XProgramming.com
                      You can observe a lot by watching. --Yogi Berra
                    • Robert Watkins
                      ... It s great that you do this. However, because you are the only person doing it, please remember to run the tests whenever you check out your code as well;
                      Message 10 of 21 , Feb 1, 2005
                      • 0 Attachment
                        SirGilligan wrote:
                        >
                        > I do this one thing and try to do it consistently: Test First.
                        >
                        > I write unit tests for my code. I sometimes write a little code and
                        > then a little test, I sometimes write a little test and then a little
                        > code. I am trying to do the latter more than the other.

                        It's great that you do this. However, because you are the only person doing
                        it, please remember to run the tests whenever you check out your code as
                        well; someone may have changed something that your tests depend on. Also,
                        look for _other_ people tinkering with your tests.

                        > Before I check my code in I run my tests.
                        >
                        > What I can not do as a whole:
                        > Sit Together
                        > Energized Work
                        > Pair Programming (because the others a busy, but walk throughs can
                        > happen)
                        > Stories (we have formal docs because of the process)
                        > Weekly Cycle (but I hear we are going to weekly reflections)
                        > Quarterly Cycle
                        > Ten Minute Build
                        > Continuous Integration

                        Let's tackle this list. There are parts of this list that you can do.

                        You, and you alone, can do Energized Work on your own part. You can
                        structure your workload so that you don't work excessive overtime, and you
                        can structure your private life to give you plenty of R&R. It's also your
                        responsibility to come into work enthused and energized. This may be a
                        dangerous practice if your work culture is one of excessive overtime, however.

                        You can start informal pairing by making yourself available for pairing.
                        Listen for other people asking (possibly non-verbally) for help, and offer
                        it to them. Over time, start asking for help back. From this process,
                        informal pairing can evolve.

                        You can tackle a weekly cycle for yourself. It's not hard: determine, at
                        the start of the week, what you are going to do for the rest of the week.
                        Do it. At the end, reflect on what you did. If your boss overrides your
                        plan, point out to him or her the impact on what you had planned to do.

                        The ten-minute build problem is interesting. You may be able to tackle
                        this, you may not. What you probably can do is analyse why your build takes
                        as long as it does, then start campaiging for it. However... I would
                        defer this one until you've tackled continuous integration.

                        You can easily start a continuous integration bandwagon. This environment
                        is tailored made for an automated build system, such as CruiseControl.
                        Install an instance on your own machine. If the build process is too
                        draining to run during the day, run it only at night. Get the "BUILD
                        FAILED" notices spreading around the team, so that people know that the
                        build is in a bad state. Take it from there. That's how I introduced CI
                        into my workplace, two jobs back.

                        Should you do these things right now? Maybe not. You indicated that there
                        are things that you already do when you can. Promoting change, especially
                        in an apathetic environment, is a slow process (as I found out in my
                        previous job). If you take on too much at once, it can easily burn you out.

                        Robert.

                        --
                        "Software is too expensive to build cheaply"
                        Robert Watkins http://twasink.net/ robertdw@...
                      • Robert Watkins
                        ... Reading the source code for FIT made me realise how many of my programming techniques are utterly defensive in nature. My mind kept screaming Unsafe!
                        Message 11 of 21 , Feb 1, 2005
                        • 0 Attachment
                          yahoogroups@... wrote:
                          > A thorough
                          > examination of FIT will bend your mind: Ward is a wizard programmer.

                          Reading the source code for FIT made me realise how many of my programming
                          techniques are utterly defensive in nature. My mind kept screaming "Unsafe!
                          Unsafe!" Writing code in that particular style scares me because I know _I_
                          would screw it up. Maybe one day I can take my training wheels off too... ;)
                          --
                          "Software is too expensive to build cheaply"
                          Robert Watkins http://twasink.net/ robertdw@...
                        • Michael Brunton-Spall
                          Apologies Ron, I looked back and in the OT -Same stupid arguments, and old methodologies thread, Kent and Charles were talking about it, and it stuck in my
                          Message 12 of 21 , Feb 2, 2005
                          • 0 Attachment
                            Apologies Ron,
                            I looked back and in the 'OT -Same "stupid" arguments, and old
                            methodologies' thread, Kent and Charles were talking about it, and it
                            stuck in my mind, but I guess it must have stuck in my mind as the sort
                            of thing you would say... :)

                            The bit in question was...
                            Charles Said:
                            > Kent Beck wrote:
                            > > Charles,
                            > >
                            > > Few people would say in public that their software development
                            process
                            > > valued cowardice, secrecy, complexity, isolation, and elitism. Most
                            of my
                            > > clients will admit that at least some subset of these are their de
                            facto
                            > > values, however. The ones where no one will admit that their values
                            are
                            > > messed up are the ones where I don't last long.
                            > I think you're saying that few places admit they *reward*
                            > cowardice, secrecy, etc, but in fact they do.
                            <snip>
                            > In the absence of some countering payoff, cowardice *is* rewarded,
                            > although I bet those places would say they reward "caution", or that
                            > they "don't like to take unneeded risks."

                            That was what I was referring to with the value cowardice, which I
                            thought was a very good way of putting the fact that some companies seem
                            to state that they are Cautious or don't take unneeded risks, and are in
                            fact valuing cowardice.

                            Anyway, sorry for attributing it to you Ron, no offence intended

                            Mib
                            Software Engineer


                            > -----Original Message-----
                            > From: Ron Jeffries [mailto:ronjeffries@...]
                            > Sent: 01 February 2005 20:55
                            > To: extremeprogramming@yahoogroups.com
                            > Subject: Re: [XP] XP in non xp environment?
                            >
                            >
                            >
                            > On Tuesday, February 1, 2005, at 9:12:17 AM, Michael
                            > Brunton-Spall wrote:
                            >
                            > > "value cowardice" (to paraphrase Ron)
                            >
                            > I certainly hope I didn't say that. If I did, I'm sorry now.
                            >
                            > Ron Jeffries
                            > www.XProgramming.com
                            > You can observe a lot by watching. --Yogi Berra
                            >
                            >
                            >
                            >
                            > To Post a message, send it to: extremeprogramming@...
                            >
                            > To Unsubscribe, send a blank message to:
                            > extremeprogramming-unsubscribe@...
                            >
                            > ad-free courtesy of objectmentor.com
                            > Yahoo! Groups Links
                            >
                            >
                            >
                            >
                            >
                            >
                            >
                            >
                          • J. B. Rainsberger
                            ... When I worked at IBM, I did what some call XP for One. This is an outline of what I did: * weekly cycle During the status meeting I presented what I
                            Message 13 of 21 , Feb 4, 2005
                            • 0 Attachment
                              Michael Brunton-Spall wrote:

                              > I was hoping to start a discussion about what practices can be
                              > implemented under the radar of management oversight, and what advantages
                              > or disadvantages that may have.
                              >
                              > I was obviously interested in which practices can be done subtly, and
                              > which are simply not able to be done without management interaction.

                              When I worked at IBM, I did what some call XP for One. This is an
                              outline of what I did:

                              * weekly cycle

                              During the status meeting I presented what I achieved in the
                              just-finished iteration. After the meeting I spent an hour in the
                              afternoon talking my customer (who was internal) about what I could do
                              in the coming few weeks. We went over priorities and risks and settled
                              on what to do for the coming week. I would put this information into a
                              spreadsheet and send a copy to my manager. I broke down features small
                              enough that each could be done in 1-2 days.

                              * test-driven development with domain-driven design

                              Since I was a team of one, it was easy to carve out my section of the
                              design and test-drive new features. Integrating with the rest of the
                              product presented challenges, and I wrote about them. ("Use your
                              singletons wisely" came out of that project.) I was able to drive the
                              design from the domain outward, adding persistence last. (Better
                              Software, April 2004, feature article.)

                              (For me, TDD includes Refactoring, in case you're wondering where that
                              went.)

                              * continuous integration

                              I committed code on average every half day. I had to write additional
                              integration tests to make this safe, but then, the requirements for
                              committing code were lax. (If it built, that's all that mattered; and
                              working in Visual Age for Java, you always knew whether it built.)

                              * informative workspace

                              Anyone who wanted to know how I was doing could read my cubicle door,
                              which included a burndown chart and which stories were in plan for the
                              next few weeks.

                              * on-site customer

                              I was fortunate in that I was writing code for another programmer, so I
                              had an on-site customer. He was quite active, answering questions
                              relatively quickly and willing to spend an hour per week planning with
                              me. Our relationship was quite good.

                              I was able to do all this without changing the way I interacted with
                              management:

                              * I still reported status like anyone else, and my reports were based
                              on projections of actual data, rather than gut feelings

                              * I followed the rules for committing code, and even worked with the
                              build team to increase the effectiveness of their automation

                              * I attended meetings and participated, but reported at the end of the
                              week how much time I spent away from writing code and how that affected
                              my schedule

                              My immediate manager appreciated what I was doing and was happy to be
                              involved on a more day-to-day basis, because she felt she was working
                              with me, rather than babysitting me. I certainly liked that.

                              Had I not had an on-site customer, I would likely have done a poorer job
                              of delivering the right features, but I think I would have done a good
                              job at delivering working features. In that environment, working code
                              was enough to stand out.

                              I hope this helps.
                              --
                              J. B. (Joe) Rainsberger
                              Diaspar Software Services
                              http://www.diasparsoftware.com
                              Author, JUnit Recipes: Practical Methods for Programmer Testing
                            • Kent Beck
                              Michael, What is your anti-XP organization in favor of? Could you apply XP to give it more of that? Kent Beck Three Rivers ... From: Michael Brunton-Spall
                              Message 14 of 21 , Feb 8, 2005
                              • 0 Attachment
                                Michael,

                                What is your anti-XP organization in favor of? Could you apply XP to give it
                                more of that?

                                Kent Beck
                                Three Rivers

                                -----Original Message-----
                                From: Michael Brunton-Spall [mailto:mib@...]
                                Sent: Monday, January 31, 2005 7:30 AM
                                To: extremeprogramming@yahoogroups.com
                                Subject: [XP] XP in non xp environment?


                                Ok based on some of the discussions in the newbie thread, and some other
                                comments here and there, I thought I'd ask this fairly newbie type
                                question.

                                If one is working in an organisation that is firmly anti-xp, what
                                practices of XP are possible to do in a skunk works type manner. I.e.
                                stealthily apply them by oneself without requiring management approval.
                                Which practices can we definitely not do? (Customer on site, Planning
                                Game spring to mind).
                                Given that many of the processes work best when applied together, what
                                problems are caused by the lack of the above in the development process.

                                Some possible issues may include the following...
                                <these are not a reflection of my place of work, but are merely
                                suggestions> (that should avoid me being fired if my emails are
                                monitored!)
                                Micro-managing managers, are you allowed to perform any techniques that
                                are not *approved* techniques
                                Restrictive corporate policies, for example, unable to install any
                                software of choice on dev machines (this one is true here, the fight to
                                get cppunit in was hard!)
                                Code sharing, (yes that can be a problem, take cppunit for example,
                                programmers who don't have it installed can't compile my programs
                                without linking errors)
                                Non-supportive peers,

                                I'm sure there's more, but I'm out of ideas now, just thought I'd toss
                                this off, and see what comes in.

                                Mib
                                Software Engineer



                                [Non-text portions of this message have been removed]



                                To Post a message, send it to: extremeprogramming@...

                                To Unsubscribe, send a blank message to:
                                extremeprogramming-unsubscribe@...

                                ad-free courtesy of objectmentor.com
                                Yahoo! Groups Links
                              • Tony Nassar
                                Accordingly, it seems like a skunk works is the wrong starting point; that pretty much implies going behind someone s back. If you do indeed have a manager who
                                Message 15 of 21 , Feb 9, 2005
                                • 0 Attachment
                                  Accordingly, it seems like a skunk works is the wrong starting point;
                                  that pretty much implies going behind someone's back. If you do indeed
                                  have a manager who paranoically looks over your shoulder and forbids you
                                  even to use JUnit, well, then you've got problems, but that scenario
                                  seems pretty unlikely. I've faced a lot of these obstacles, too, MBS, so
                                  I don't dismiss them. I had to be patient, and pick my battles sensibly,
                                  which is not to say that I won them all. The proof, for the manager, was
                                  in the pudding (i.e., an error-free and properly performant
                                  deliverable); he didn't care about my "XP is great" spiel, which I was
                                  unqualified to deliver anyway. Yes, *I'd* have done better work if
                                  everyone on this site had been test-infected, but they weren't; c'est la
                                  vie for a contractor. One thing is certain: I couldn't go into a
                                  customer site hoping to practice stealth there; one has to resist the
                                  temptation to regard a customer in that fashion.

                                  Kent Beck wrote:

                                  >Michael,
                                  >
                                  >What is your anti-XP organization in favor of? Could you apply XP to give it
                                  >more of that?
                                  >
                                  >Kent Beck
                                  >Three Rivers
                                  >
                                  >-----Original Message-----
                                  >From: Michael Brunton-Spall [mailto:mib@...]
                                  >
                                  >Ok based on some of the discussions in the newbie thread, and some other
                                  >comments here and there, I thought I'd ask this fairly newbie type
                                  >question.
                                  >
                                  >If one is working in an organisation that is firmly anti-xp, what
                                  >practices of XP are possible to do in a skunk works type manner. I.e.
                                  >stealthily apply them by oneself without requiring management approval.
                                  >Which practices can we definitely not do? (Customer on site, Planning
                                  >Game spring to mind).
                                  >Given that many of the processes work best when applied together, what
                                  >problems are caused by the lack of the above in the development process.
                                  >
                                  >Some possible issues may include the following...
                                  ><these are not a reflection of my place of work, but are merely
                                  >suggestions> (that should avoid me being fired if my emails are
                                  >monitored!)
                                  >Micro-managing managers, are you allowed to perform any techniques that
                                  >are not *approved* techniques
                                  >Restrictive corporate policies, for example, unable to install any
                                  >software of choice on dev machines (this one is true here, the fight to
                                  >get cppunit in was hard!)
                                  >
                                  >
                                • Michael Brunton-Spall
                                  Thanks for the responses, I m not sure I understood that last post however Tony, You say that implementing XP in a stealthy manner is probably not a good
                                  Message 16 of 21 , Feb 9, 2005
                                  • 0 Attachment
                                    Thanks for the responses,

                                    I'm not sure I understood that last post however Tony,

                                    You say that implementing XP in a stealthy manner is probably not a good
                                    start, a point which I think everybody would agree with, ideally, one
                                    can convince the company to allow XP to be performed freely by everybody
                                    on the team. This is obviously better as it enables the free
                                    information flow in the team, ensures that the development process is
                                    supported and so on.

                                    However there are cases whereby one may not be allowed to do that, it is
                                    in those cases that I am interested.

                                    You then said that the proof was in the pudding, i.e. error free and
                                    properly performing software, I don't understand how if your manager is
                                    opposed to the idea of practicing XP, how you can prove that it works
                                    without performing XP by stealth.

                                    The two possibilities that spring to mind are,
                                    1) You argued for say, the introduction of nUnit (for any value of
                                    n), the manager agreed, and you demonstrated that business improvement
                                    of implementing a single practice of xp.
                                    2) Your manager agreed to allow you to develop in any way you
                                    wished, and you were able to develop the system according to XP
                                    principles wherever possible.

                                    I agree that both are very valid ways of slowly introducing XP to an
                                    environment where people may be opposed to XP by name, but don't truly
                                    understand it, and so wont notice if you introduce the practices one at
                                    a time, or if your organisation is willing to allow developers or teams
                                    of developers to use whatever method of development they wish providing
                                    they meet the organisation requirements, (i.e. status meeting twice a
                                    month or something).

                                    The area I was interested in was exploring all the different ways of
                                    bringing XP in, especially in adverse conditions so to speak.

                                    With regard to my personal development conditions, I have given up hope
                                    of convincing my development organisation that XP is of any use. I am
                                    in a junior development position, and we program mainly in C++. Suffice
                                    to say that the organisation will not accept XP, or agile methods as a
                                    possible development methodology.
                                    I am not and have not been asking Questions on here for my works
                                    benefit, instead for my own elucidation and personal development. So
                                    consider them abstract questions, or thought experiments for now :)

                                    (ah, funny mood today, just wrote 3 paragraphs of badness about my work
                                    then deleted it realising that a) you lot don't care, and b) it's
                                    probably not ethical to complain about my place of work via my company
                                    email address to a global audience!)


                                    Mib
                                    Software Engineer


                                    > -----Original Message-----
                                    > From: Tony Nassar [mailto:tony.nassar@...]
                                    > Sent: 09 February 2005 15:44
                                    > To: extremeprogramming@yahoogroups.com
                                    > Subject: Re: [XP] XP in non xp environment?
                                    >
                                    >
                                    >
                                    > Accordingly, it seems like a skunk works is the wrong starting point;
                                    > that pretty much implies going behind someone's back. If you
                                    > do indeed
                                    > have a manager who paranoically looks over your shoulder and
                                    > forbids you
                                    > even to use JUnit, well, then you've got problems, but that scenario
                                    > seems pretty unlikely. I've faced a lot of these obstacles,
                                    > too, MBS, so
                                    > I don't dismiss them. I had to be patient, and pick my
                                    > battles sensibly,
                                    > which is not to say that I won them all. The proof, for the
                                    > manager, was
                                    > in the pudding (i.e., an error-free and properly performant
                                    > deliverable); he didn't care about my "XP is great" spiel,
                                    > which I was
                                    > unqualified to deliver anyway. Yes, *I'd* have done better work if
                                    > everyone on this site had been test-infected, but they
                                    > weren't; c'est la
                                    > vie for a contractor. One thing is certain: I couldn't go into a
                                    > customer site hoping to practice stealth there; one has to resist the
                                    > temptation to regard a customer in that fashion.
                                    >
                                    > Kent Beck wrote:
                                    >
                                    > >Michael,
                                    > >
                                    > >What is your anti-XP organization in favor of? Could you
                                    > apply XP to give it
                                    > >more of that?
                                    > >
                                    > >Kent Beck
                                    > >Three Rivers
                                    > >
                                    > >-----Original Message-----
                                    > >From: Michael Brunton-Spall [mailto:mib@...]
                                    > >
                                    > >Ok based on some of the discussions in the newbie thread,
                                    > and some other
                                    > >comments here and there, I thought I'd ask this fairly newbie type
                                    > >question.
                                    > >
                                    > >If one is working in an organisation that is firmly anti-xp, what
                                    > >practices of XP are possible to do in a skunk works type
                                    > manner. I.e.
                                    > >stealthily apply them by oneself without requiring
                                    > management approval.
                                    > >Which practices can we definitely not do? (Customer on
                                    > site, Planning
                                    > >Game spring to mind).
                                    > >Given that many of the processes work best when applied
                                    > together, what
                                    > >problems are caused by the lack of the above in the
                                    > development process.
                                    > >
                                    > >Some possible issues may include the following...
                                    > ><these are not a reflection of my place of work, but are merely
                                    > >suggestions> (that should avoid me being fired if my emails are
                                    > >monitored!)
                                    > >Micro-managing managers, are you allowed to perform any
                                    > techniques that
                                    > >are not *approved* techniques
                                    > >Restrictive corporate policies, for example, unable to install any
                                    > >software of choice on dev machines (this one is true here,
                                    > the fight to
                                    > >get cppunit in was hard!)
                                    > >
                                    > >
                                    >
                                    >
                                    >
                                    > To Post a message, send it to: extremeprogramming@...
                                    >
                                    > To Unsubscribe, send a blank message to:
                                    > extremeprogramming-unsubscribe@...
                                    >
                                    > ad-free courtesy of objectmentor.com
                                    > Yahoo! Groups Links
                                    >
                                    >
                                    >
                                    >
                                    >
                                    >
                                    >
                                    >
                                  • banshee858
                                    ... Good move. I got fired for doing the same thing. While getting fired was a bad thing , it ended up being good since I learned how much BS I can tolerate
                                    Message 17 of 21 , Feb 9, 2005
                                    • 0 Attachment
                                      >
                                      > (ah, funny mood today, just wrote 3 paragraphs of badness about my
                                      > work then deleted it realising that a) you lot don't care, and b) it's
                                      > probably not ethical to complain about my place of work via my company
                                      > email address to a global audience!)
                                      >
                                      Good move. I got fired for doing the same thing. While getting fired
                                      was a "bad thing", it ended up being good since I learned how much BS
                                      I can tolerate before it is time to move on.

                                      Carlton
                                    • Dakshinamurthy Karra
                                      On Wed, 9 Feb 2005 16:39:06 -0000, Michael Brunton-Spall ... XP is much more than *some* set of practices - though the practices are important. You can still
                                      Message 18 of 21 , Feb 9, 2005
                                      • 0 Attachment
                                        On Wed, 9 Feb 2005 16:39:06 -0000, Michael Brunton-Spall
                                        <mib@...> wrote:
                                        > With regard to my personal development conditions, I have given up hope
                                        > of convincing my development organisation that XP is of any use. I am
                                        > in a junior development position, and we program mainly in C++. Suffice
                                        > to say that the organisation will not accept XP, or agile methods as a
                                        > possible development methodology.
                                        XP is much more than *some* set of practices - though the practices
                                        are important. You can still practice XP and get the benifits from
                                        whatever practices that you can follow.
                                        1. Did you look at cppunit/cxxunit (both hosted on sf.net) for UT
                                        frameworks. It is nice to practice TDD and it might not clash with
                                        anything your manager wants. You don't need to check-in the UTs into
                                        the source safe if it is not possible.
                                        2. You can intereact more with the tester/customer (whichever role is
                                        available) to ensure that what you develop is more useful.
                                        All said and done, the context provides you a set of practices that
                                        you can follow without disrupting current team practices.

                                        Good luck.

                                        Thanks and Regards
                                        KD
                                        --
                                        Dakshinamurthy Karra
                                        CTO, Subex Systems Ltd.(http://www.subexsystems.com)
                                      • Kent Beck
                                        Michael, Giving up hope of changing others sounds like a positive step. Now you can focus on what you can change about how you work. I encourage you not to
                                        Message 19 of 21 , Feb 11, 2005
                                        • 0 Attachment
                                          Michael,

                                          Giving up hope of changing others sounds like a positive step. Now you can
                                          focus on what you can change about how you work. I encourage you not to
                                          treat this as an abstract or academic exercise, but to try to put what you
                                          learn here to work at work. The feedback will help you learn faster.

                                          Kent Beck
                                          Three Rivers Institute

                                          -----Original Message-----
                                          From: Michael Brunton-Spall [mailto:mib@...]
                                          Sent: Wednesday, February 09, 2005 8:39 AM
                                          To: extremeprogramming@yahoogroups.com
                                          Subject: RE: [XP] XP in non xp environment?

                                          With regard to my personal development conditions, I have given up hope
                                          of convincing my development organisation that XP is of any use. I am
                                          in a junior development position, and we program mainly in C++. Suffice
                                          to say that the organisation will not accept XP, or agile methods as a
                                          possible development methodology.
                                          I am not and have not been asking Questions on here for my works
                                          benefit, instead for my own elucidation and personal development. So
                                          consider them abstract questions, or thought experiments for now :)
                                        • Shane Mingins
                                          Michael I have just finished a book called Fearless Change - Patterns for Introducing New Ideas by Manns & Rising. You may find the patterns of use if you
                                          Message 20 of 21 , Feb 11, 2005
                                          • 0 Attachment
                                            Michael

                                            I have just finished a book called Fearless Change -
                                            Patterns for Introducing New Ideas by Manns & Rising.

                                            You may find the patterns of use if you would like to
                                            instigate change in your organisation.

                                            For example:

                                            Just Do It - use the new idea in your own work to
                                            discover its benefits and limitations.

                                            Good luck
                                            Shane


                                            --- Kent Beck <kentb@...> wrote:

                                            >
                                            > Michael,
                                            >
                                            > Giving up hope of changing others sounds like a
                                            > positive step. Now you can
                                            > focus on what you can change about how you work. I
                                            > encourage you not to
                                            > treat this as an abstract or academic exercise, but
                                            > to try to put what you
                                            > learn here to work at work. The feedback will help
                                            > you learn faster.
                                            >
                                            > Kent Beck
                                            > Three Rivers Institute
                                            >
                                            > -----Original Message-----
                                            > From: Michael Brunton-Spall
                                            > [mailto:mib@...]
                                            > Sent: Wednesday, February 09, 2005 8:39 AM
                                            > To: extremeprogramming@yahoogroups.com
                                            > Subject: RE: [XP] XP in non xp environment?
                                            >
                                            > With regard to my personal development conditions, I
                                            > have given up hope
                                            > of convincing my development organisation that XP is
                                            > of any use. I am
                                            > in a junior development position, and we program
                                            > mainly in C++. Suffice
                                            > to say that the organisation will not accept XP, or
                                            > agile methods as a
                                            > possible development methodology.
                                            > I am not and have not been asking Questions on here
                                            > for my works
                                            > benefit, instead for my own elucidation and personal
                                            > development. So
                                            > consider them abstract questions, or thought
                                            > experiments for now :)
                                            >


                                            =====

                                            Shane Mingins

                                            shanemingins@...

                                            please remove clothes before emailing




                                            __________________________________
                                            Do you Yahoo!?
                                            The all-new My Yahoo! - Get yours free!
                                            http://my.yahoo.com
                                          • Devin Mullins
                                            Michael, 1. Why are others having linking errors with your unit tested code? Can t they just not compile & link the unit tests? 2. Stealthy can bite you in the
                                            Message 21 of 21 , Feb 12, 2005
                                            • 0 Attachment
                                              Michael,

                                              1. Why are others having linking errors with your unit tested code?
                                              Can't they just not compile & link the unit tests?

                                              2. Stealthy can bite you in the butt if your manager finds out. Instead,
                                              tell your boss, "Unit tests are the only way I have of producing
                                              error-free and speedy code, plus they have the added bonus of
                                              encouraging my code to be cheaper to reuse and maintain in the future
                                              (i.e. service-oriented, if you're looking for a buzz word)." Don't speak
                                              for the whole team; just speak for you. Notice two things:
                                              a)you said explicitly that if you don't use unit tests, you WILL
                                              introduce errors and the code will perform suboptimally. Mentally, your
                                              boss is going to have to decide to introduce errors and slowness if he
                                              decides against unit tests for you, and that's something his conscience
                                              is less likely to do.
                                              b)You used the word "cheaper." That's a word a manager can get behind.
                                              Now, if you don't succeed at convincing, you really have no option but
                                              to produce buggy and slow code, like the manager asked. If you
                                              originally argued this in email, then you'll have something with which
                                              to CYA if it really is discovered to be buggy and slow. I know from
                                              similar experience that my boss would say, "Hey, I appreciate you being
                                              proactive about the success of our product. Is this something other
                                              people could use?" but YMMV. You're a better judge of your own
                                              corporation's culture.

                                              3. The nice thing about XP is that you can implement most of the
                                              practices one at a time. When you pair program, you don't have to call
                                              it by name. Just say, "Hey, Jeff, I'm a little uncertain about this
                                              change. When you get a second, could you help me out here? I'd really
                                              appreciate a second set of eyes on this one."

                                              Hope that helps,
                                              Devin

                                              Kent Beck wrote:

                                              >Michael,
                                              >
                                              >What is your anti-XP organization in favor of? Could you apply XP to give it
                                              >more of that?
                                              >
                                              >Kent Beck
                                              >Three Rivers
                                              >
                                              >-----Original Message-----
                                              >From: Michael Brunton-Spall [mailto:mib@...]
                                              >Sent: Monday, January 31, 2005 7:30 AM
                                              >To: extremeprogramming@yahoogroups.com
                                              >Subject: [XP] XP in non xp environment?
                                              >
                                              >
                                              >Ok based on some of the discussions in the newbie thread, and some other
                                              >comments here and there, I thought I'd ask this fairly newbie type
                                              >question.
                                              >
                                              >If one is working in an organisation that is firmly anti-xp, what
                                              >practices of XP are possible to do in a skunk works type manner. I.e.
                                              >stealthily apply them by oneself without requiring management approval.
                                              >Which practices can we definitely not do? (Customer on site, Planning
                                              >Game spring to mind).
                                              >Given that many of the processes work best when applied together, what
                                              >problems are caused by the lack of the above in the development process.
                                              >
                                              >Some possible issues may include the following...
                                              ><these are not a reflection of my place of work, but are merely
                                              >suggestions> (that should avoid me being fired if my emails are
                                              >monitored!)
                                              >Micro-managing managers, are you allowed to perform any techniques that
                                              >are not *approved* techniques
                                              >Restrictive corporate policies, for example, unable to install any
                                              >software of choice on dev machines (this one is true here, the fight to
                                              >get cppunit in was hard!)
                                              >Code sharing, (yes that can be a problem, take cppunit for example,
                                              >programmers who don't have it installed can't compile my programs
                                              >without linking errors)
                                              >Non-supportive peers,
                                              >
                                              >I'm sure there's more, but I'm out of ideas now, just thought I'd toss
                                              >this off, and see what comes in.
                                              >
                                              >Mib
                                              >Software Engineer
                                              >
                                              >
                                            Your message has been successfully submitted and would be delivered to recipients shortly.