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

Integration with non-XP teams

Expand Messages
  • Nick Korbel
    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
    Message 1 of 14 , Mar 31 6:51 AM
    • 0 Attachment
      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?

      Thanks,
      Nick


      [Non-text portions of this message have been removed]
    • jmilunsky
      I think that s fine. Your team will have it s goals and objectives. And you ll be managing that using Scrum/XP. The issue will come down to the dependencies.
      Message 2 of 14 , Mar 31 12:51 PM
      • 0 Attachment
        I think that's fine. Your team will have it's goals and objectives. And you'll be managing that using Scrum/XP. The issue will come down to the dependencies. Most agile teams are able to sort these dependencies out on the fly. It will most likely take a bit more overhead to ensure that you're in lock-step but it shouldn't prevent you from managing your side of the fence using XP.

        Jack
        www.agilebuddy.com
        blog.agilebuddy.com

        --- In extremeprogramming@yahoogroups.com, Nick Korbel <nkorbel@...> 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?
        >
        > Thanks,
        > Nick
        >
        >
        > [Non-text portions of this message have been removed]
        >
      • davenicolette
        Hi Nick, In similar circumstances in the past, colleagues and I have tried to engage the other groups in the organization in as effective a way as possible.
        Message 3 of 14 , Mar 31 2:23 PM
        • 0 Attachment
          Hi Nick,

          In similar circumstances in the past, colleagues and I have tried to engage the other groups in the organization in as effective a way as possible. What fell out from those efforts was a three-level model of engagement with non-agile groups on which our teams had dependencies.

          The first step was to meet with each of the other groups to explain that we intended to use a different development process than the rest of the organization, and describing how we would be working and on what sort of time scales. Based on the response, we tried to formalize a working relationship with each group.

          In the best case, we found the people in another group were just as frustrated with the status quo as we were, but they weren't in a position to adopt agile methods. These groups usually agreed to interact with our teams in a different way than they did with the traditional groups. For instance, the network services group at one company had a formal procedure for requesting work from them that took a minimum of six weeks. After speaking with us about the way we intended to run our projects, they agreed to turn around work requests from our teams in one week. At the time, we were running two-week iterations, so that sort of responsiveness made it possible for us to defer many network-related decisions until the last responsible moment.

          At the opposite extreme, we found some groups completely adamant about following the existing standard procedures. They were simply uninterested in the value of changing the company's defined process. When our teams had a dependency on one of these groups, we had to shift our last responsible moment for certain decisions back in time so that we could try and request services from the other group early enough to receive the result in time for the iteration in which we needed it. The risk in this case was that the result we received might no longer meet our customer's needs, because the customer had learned more about their needs in the meantime.

          Between the extremes were groups that were willing to try and match up with our normal pace of work, but that could not offer really fast turnaround times for reasons outside our control. In these cases, we did a combination of the two approaches outlined above.

          All three of the above examples deal with the case when one of our agile development teams had a dependency on a non-agile group to provide specialized services such as network configuration, database creation, localization, security, or similar.

          There were also cases in which an agile team was developing a component that was to become part of a larger solution, while non-agile teams were developing other components that had to be integrated prior to deployment. 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. Then we went ahead and started new projects while waiting for the other teams to deliver their components.

          I hope that helps,
          Dave

          --- In extremeprogramming@yahoogroups.com, Nick Korbel <nkorbel@...> 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?
          >
          > Thanks,
          > Nick
          >
          >
          > [Non-text portions of this message have been removed]
          >
        • J. B. Rainsberger
          ... 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
          Message 4 of 14 , Apr 1, 2009
          • 0 Attachment
            On Tue, Mar 31, 2009 at 1:51 PM, Nick Korbel <nkorbel@...> 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
          • Nick Korbel
            Dave, 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
            Message 5 of 14 , Apr 1, 2009
            • 0 Attachment
              Dave,
              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?

              Thanks,
              Nick

              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]
            • Nick Korbel
              Joe, ... We have pretty clear lines of responsibility, so it s always customer/supplier situation with our role defined by the feature. While communication
              Message 6 of 14 , Apr 1, 2009
              • 0 Attachment
                Joe,

                > Do you supply those teams with features? Do they supply you with features?
                > or Do you all build different parts of the same features?
                >

                We have pretty clear lines of responsibility, so it's always
                customer/supplier situation with our role defined by the feature. While
                communication can be difficult at times, our biggest struggle has been on
                the technological side.

                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.
                >
                > 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.
                >

                Your assumptions are dead on here. Any suggestions on how to avoid or deal
                with these situations?

                Thanks,
                Nick


                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]
              • jmilunsky
                Hi Joe, That s a sound response. Thanks for crystalizing this Jack www.agilebuddy.com blog.agilebuddy.com
                Message 7 of 14 , Apr 1, 2009
                • 0 Attachment
                  Hi Joe,

                  That's a sound response. Thanks for crystalizing this

                  Jack
                  www.agilebuddy.com
                  blog.agilebuddy.com

                  --- In extremeprogramming@yahoogroups.com, "J. B. Rainsberger" <jbrains762@...> wrote:
                  >
                  > On Tue, Mar 31, 2009 at 1:51 PM, Nick Korbel <nkorbel@...> 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
                  >
                • davenicolette
                  We can t prevent code from going stale while it waits for other groups to finish their parts of the solution. By keeping our own code as clean as possible, we
                  Message 8 of 14 , Apr 1, 2009
                  • 0 Attachment
                    We can't prevent code from going stale while it waits for other groups to finish their parts of the solution. By keeping our own code as clean as possible, we minimize the impact of differences in the interfaces that come up when other groups finalize their designs. If they won't provide interim versions for us to test against, then we've got no way to know whether our code has gone stale, or how badly. There's no magic bullet.

                    Cheers,
                    Dave

                    --- In extremeprogramming@yahoogroups.com, Nick Korbel <nkorbel@...> wrote:
                    >
                    > Dave,
                    > 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?
                    >
                    > Thanks,
                    > Nick
                    >
                    > 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]
                    >
                  • Tim Ottinger
                    ... Perception altering: The problem isn t that your code went stale waiting for them. Being done first is the culprit? I think not. The problem, rather, is
                    Message 9 of 14 , Apr 1, 2009
                    • 0 Attachment
                      > From: davenicolette <dnicolet@...>
                      >
                      > We can't prevent code from going stale while it waits for other groups to finish
                      > their parts of the solution. By keeping our own code as clean as possible, we
                      > minimize the impact of differences in the interfaces that come up when other
                      > groups finalize their designs. If they won't provide interim versions for us to
                      > test against, then we've got no way to know whether our code has gone stale, or
                      > how badly. There's no magic bullet.

                      Perception altering:

                      The problem isn't that your code went stale waiting for them. Being done first
                      is the culprit? I think not.

                      The problem, rather, is that they didn't provide you feedback as they made
                      changes to their code (finalized their designs). Had they kept you in the
                      loop, there wouldn't be a disconnect.

                      Some would argue that their final design differed from the spec, and that was
                      the problem. I don't buy that, because as-built is always a little different
                      from as-designed due to corrective steering.

                      You are not at fault if they deliver something different than they expected
                      to. The answer, most likely, lies in them keeping you aligned as they make
                      improvements. Maybe by testing early with you.

                      That's just good interface management, not an agile issue per se. One side
                      is always done first unless they get together and drive the two home together.

                      tim
                    • davenicolette
                      Tim, You re right. The solution to the true problem would be to improve the level of communication and collaboration in the organization. It isn t always
                      Message 10 of 14 , Apr 2, 2009
                      • 0 Attachment
                        Tim,

                        You're right. The solution to the true problem would be to improve the level of communication and collaboration in the organization.

                        It isn't always possible to achieve that in the short term. In those cases, we have to do the best thing that is feasible to do.

                        Cheers,
                        Dave

                        --- In extremeprogramming@yahoogroups.com, Tim Ottinger <linux_tim@...> wrote:
                        >
                        >
                        >
                        >
                        >
                        > > From: davenicolette <dnicolet@...>
                        > >
                        > > We can't prevent code from going stale while it waits for other groups to finish
                        > > their parts of the solution. By keeping our own code as clean as possible, we
                        > > minimize the impact of differences in the interfaces that come up when other
                        > > groups finalize their designs. If they won't provide interim versions for us to
                        > > test against, then we've got no way to know whether our code has gone stale, or
                        > > how badly. There's no magic bullet.
                        >
                        > Perception altering:
                        >
                        > The problem isn't that your code went stale waiting for them. Being done first
                        > is the culprit? I think not.
                        >
                        > The problem, rather, is that they didn't provide you feedback as they made
                        > changes to their code (finalized their designs). Had they kept you in the
                        > loop, there wouldn't be a disconnect.
                        >
                        > Some would argue that their final design differed from the spec, and that was
                        > the problem. I don't buy that, because as-built is always a little different
                        > from as-designed due to corrective steering.
                        >
                        > You are not at fault if they deliver something different than they expected
                        > to. The answer, most likely, lies in them keeping you aligned as they make
                        > improvements. Maybe by testing early with you.
                        >
                        > That's just good interface management, not an agile issue per se. One side
                        > is always done first unless they get together and drive the two home together.
                        >
                        > tim
                        >
                      • Olof Bjarnason
                        ... I m thinking; wouldn t modern social communication tool like twitter be one way of keeping in synch? Say, each team has twitter user, and all team members
                        Message 11 of 14 , Apr 2, 2009
                        • 0 Attachment
                          2009/4/2 davenicolette <dnicolet@...>:
                          > Tim,
                          >
                          > You're right. The solution to the true problem would be to improve the level
                          > of communication and collaboration in the organization.
                          >
                          > It isn't always possible to achieve that in the short term. In those cases,
                          > we have to do the best thing that is feasible to do.

                          I'm thinking; wouldn't modern social communication tool like twitter
                          be one way of keeping in synch?

                          Say, each team has twitter user, and all team members can post on that.

                          Then, everyone that is interested in what happens on that team can
                          subscribe to that twitter user.

                          >
                          > Cheers,
                          > Dave
                          >
                          > --- In extremeprogramming@yahoogroups.com, Tim Ottinger <linux_tim@...>
                          > wrote:
                          >>
                          >>
                          >>
                          >>
                          >>
                          >> > From: davenicolette <dnicolet@...>
                          >
                          >> >
                          >> > We can't prevent code from going stale while it waits for other groups
                          >> > to finish
                          >> > their parts of the solution. By keeping our own code as clean as
                          >> > possible, we
                          >> > minimize the impact of differences in the interfaces that come up when
                          >> > other
                          >> > groups finalize their designs. If they won't provide interim versions
                          >> > for us to
                          >> > test against, then we've got no way to know whether our code has gone
                          >> > stale, or
                          >> > how badly. There's no magic bullet.
                          >>
                          >> Perception altering:
                          >>
                          >> The problem isn't that your code went stale waiting for them. Being done
                          >> first
                          >> is the culprit? I think not.
                          >>
                          >> The problem, rather, is that they didn't provide you feedback as they made
                          >> changes to their code (finalized their designs). Had they kept you in the
                          >> loop, there wouldn't be a disconnect.
                          >>
                          >> Some would argue that their final design differed from the spec, and that
                          >> was
                          >> the problem. I don't buy that, because as-built is always a little
                          >> different
                          >> from as-designed due to corrective steering.
                          >>
                          >> You are not at fault if they deliver something different than they
                          >> expected
                          >> to. The answer, most likely, lies in them keeping you aligned as they make
                          >> improvements. Maybe by testing early with you.
                          >>
                          >> That's just good interface management, not an agile issue per se. One side
                          >> is always done first unless they get together and drive the two home
                          >> together.
                          >>
                          >> tim
                          >>
                          >
                          >



                          --
                          Min blogg:
                          http://olofb.wordpress.com
                          [My blog, in Swedish]
                        • Tim Ottinger
                          ... As a bit of social engineering, just make sure that they don t perceive the problem as you being agile, but rather that you were done first. If agile is
                          Message 12 of 14 , Apr 2, 2009
                          • 0 Attachment
                            ----- Original Message ----
                            > From: davenicolette <dnicolet@...>
                            >
                            > You're right. The solution to the true problem would be to improve the level of
                            > communication and collaboration in the organization.
                            >
                            > It isn't always possible to achieve that in the short term. In those cases, we
                            > have to do the best thing that is feasible to do.

                            As a bit of social engineering, just make sure that they don't perceive
                            the problem as you being agile, but rather that you were done first.
                            If agile is the "problem", the solution is to stop it. I've seen it
                            blamed for the wrong things.

                            My most recent reversal was luckily when they blamed it for the right things.
                            With agile, we worked on fewer things at once and followed given priorities.
                            Certain individuals lost the ability to bypass priorities and assign whatever
                            they want done directly to an individual developer. Since they didn't buy the
                            whole lean/agile thing, they eventually reverted. I think that's fine.

                            What I would hate to see is that they perceive your success as failure here.
                            Do some marketing. Make sure they know that you're ahead of the game. It's
                            important insurance.

                            tim
                          • Tim Ottinger
                            ... A lot of places install jabber servers. It can help, if people actually watch it. Some places it s poorly attended and poorly monitored, and helps not at
                            Message 13 of 14 , Apr 2, 2009
                            • 0 Attachment
                              Olof Bjarnason says:
                              > I'm thinking; wouldn't modern social communication tool like twitter
                              > be one way of keeping in synch?
                              >
                              > Say, each team has twitter user, and all team members can post on that.
                              >
                              > Then, everyone that is interested in what happens on that team can
                              > subscribe to that twitter user.


                              A lot of places install jabber servers. It can help, if people actually watch it.
                              Some places it's poorly attended and poorly monitored, and helps not at all.
                              I find that wikis are pretty easy to ignore, even easier than emails.

                              A local skype appeals to me. Messages are persistant enough, immediate enough.

                              Tim Ottinger
                              http://agileinaflash.blogspot.com/
                              http://agileotter.blogspot.com/
                            • Olof Bjarnason
                              ... A group chat channel in skype is another idea, yes. Have you tried twitter/are you using twitter..? I think it is quite good for notifications . A lot
                              Message 14 of 14 , Apr 2, 2009
                              • 0 Attachment
                                2009/4/2 Tim Ottinger <linux_tim@...>:
                                >
                                > Olof Bjarnason says:
                                >> I'm thinking; wouldn't modern social communication tool like twitter
                                >> be one way of keeping in synch?
                                >>
                                >> Say, each team has twitter user, and all team members can post on that.
                                >>
                                >> Then, everyone that is interested in what happens on that team can
                                >> subscribe to that twitter user.
                                >
                                > A lot of places install jabber servers. It can help, if people actually
                                > watch it.
                                > Some places it's poorly attended and poorly monitored, and helps not at all.
                                > I find that wikis are pretty easy to ignore, even easier than emails.
                                >
                                > A local skype appeals to me. Messages are persistant enough, immediate
                                > enough.

                                A group chat channel in skype is another idea, yes.

                                Have you tried twitter/are you using twitter..? I think it is quite
                                good for "notifications". A lot better than mails/blogs/wikis. How
                                well a Skype group channel works out, I don't know. I guess a browser
                                could be embedded with "home page" = your twitter feed, inside the
                                IDE, to facilitate frequent viewing. Or something like that.

                                [ Note: I cannot technically see why twitter is so good for
                                notifications - IME it just is that way .. ]


                                >
                                > Tim Ottinger
                                > http://agileinaflash.blogspot.com/
                                > http://agileotter.blogspot.com/
                                >
                                >



                                --
                                Min blogg:
                                http://olofb.wordpress.com
                                [My blog, in Swedish]
                              Your message has been successfully submitted and would be delivered to recipients shortly.