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

149648Re: [XP] Integration with non-XP teams

Expand Messages
  • Nick Korbel
    Apr 1, 2009
    • 0 Attachment
      I really appreciate your input. The experiences you described are very
      similar to what we're dealing with.

      In these cases, the best we could do was to deploy our code into a
      > QA/staging environment with interfaces to the other components mocked out.

      This is a great suggestion. I mean, we mock out code dependencies every day
      so this is not much of a change for us.

      When doing this I assume you're still in the same boat of typically being in
      a deployable state before your dependencies. How have you prevented your
      code from growing stale? For example, with a recent feature we cut a
      branch, built and tested what we could, but have since been sitting on it
      waiting until everyone is ready to deploy.

      Some obvious approaches would be to delay working on what we're responsible
      for until the dependencies are in place, making the feature configurable, or
      just sucking it up and maintaining the branch while we wait. I understand
      there is no blanket answer because each situation is unique, but what has
      worked for people in the past?


      On Wed, Apr 1, 2009 at 6:35 AM, J. B. Rainsberger <jbrains762@...>wrote:

      > On Tue, Mar 31, 2009 at 1:51 PM, Nick Korbel <nkorbel@...<nkorbel%40gmail.com>>
      > wrote:
      > > I'm in a situation where there are a few separate software teams at my
      > > company focusing on different areas of business. Of them, my team is the
      > > only one practicing XP. There are increasing business needs for projects
      > > that span more than one of these teams.
      > >
      > > The problem we've run into is that we are trying to build the side that
      > we
      > > are responsible for in incremental pieces while the side that we need to
      > > integrate with is not.
      > >
      > > How have people handled these types of projects before? What kind of
      > > approaches to development, testing and project management have succeeded?
      > > What pitfalls should we avoid?
      > Do you supply those teams with features? Do they supply you with
      > features? or Do you all build different parts of the same features?
      > If you supply them with features, then I expect your worst problem to
      > be a lack of feedback from your customer(s) about what you deliver. In
      > this case, you might need to find ways to involve your customer(s)
      > more. What probably happens is that under pressure you guess more
      > about what they want than perhaps you should, and that works some of
      > the time and fails the rest of the time. Please do not use this as a
      > way to blackmail your customer(s) into becoming involved.
      > If they supply you with features, then you can insulate yourself from
      > them with interfaces. Be clear with them about what behavior you need,
      > then wraps their code in your own interfaces using the Adapter
      > pattern. In this case, you might find it frustrating to get them to
      > deliver the interfaces you want. What probably happens is that you
      > simulate the behavior you expect from them, but find it hard at times
      > to write the Adapter from your code to theirs. Please do not use this
      > as a way to berate your suppliers into paying attention.
      > If you all build different parts of the same features, then I wish you
      > the best of luck. Communicate more, negotiate more, and pray. (It
      > can't hurt.)
      > Take care.
      > --
      > J. B. (Joe) Rainsberger :: http://www.jbrains.ca
      > Your guide to software craftsmanship
      > JUnit Recipes: Practical Methods for Programmer Testing
      > 2005 Gordon Pask Award for contribution Agile Software Practice

      [Non-text portions of this message have been removed]
    • Show all 14 messages in this topic