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

A Practical Question

Expand Messages
  • David A Barrett
    I have a situation that I m hoping the list can help me with. We re a small team (4 people) doing development work for internal business units. Of necessity,
    Message 1 of 10 , Oct 29, 2004
      I have a situation that I'm hoping the list can help me with.

      We're a small team (4 people) doing development work for internal business
      units. Of necessity, each of our Scrums need to address a number of
      different projects and one-off items for a variety of departments. We do
      our best to keep the departments focused on strategic goals, and we find
      that this is working very well.

      Here's the problem. We've got a project coming down the pipe that we've
      known about for some time. This project involves outside business partners
      and has been mired in contract negotiations, internal executive approval
      process and the like for some time now. We have an idea of the scope of
      the project, but only restricted access to necessary outside technical
      resources until the contracts are signed. We're reluctant (refuse) to
      start work on this project prior to final approval, even if we could start
      now (which we probably couldn't). Our current Sprint ends November 12th.
      We are likely to find out that project has a formal go ahead sometime next
      week, and they would like to be in a position to do some restricted
      implementation by December 1st.

      The quantity of work feels do-able in that time (possibly). It doesn't
      feel do-able in the time from November 15th to December 1st. We don't want
      Scrum to become a "bondage and discipline" methodology that gets in the way
      of IT being an "enabler" of business initiatives. On the other hand, we
      are extremely happy with the results we get from Scrum and like idea of
      being able to say, "We have a system, it works, and if you want our help
      you'll need to play by our rules". We don't want to jettison the
      methodology this time, because that sends the message that we're willing to
      jettison the methodology and the business unit involved will keep bringing
      up projects in the future that won't fit into our Sprint schedule.

      In the course, Ken paints this as a rather black and white picture. If the
      customers start to get silly and messing around with the process, you call
      a Premature Termination of Sprint, nobody gets anything and you start all
      over. In our mixed bag Sprints, though, this would penalize the other
      internal business units.

      So, the question: How can I handle this situation, get the work done by
      December 1, and still preserve some adherence to Scrum principles?


      Dave Barrett,
      Lawyers' Professional Indemnity Company
    • mike.dwyer1@comcast.net
      David: Are you running this project or does the contract include the vendor providing the project management? I ask because if the vendor is running the
      Message 2 of 10 , Oct 29, 2004
        David:
        Are you running this project or does the contract include the vendor providing the project management?
         
        I ask because if the vendor is running the project then you need to establish explicit interface rules that allow you to manage your area.
         
         
        --
        Mike Dwyer

        "I Keep six faithful serving-men
        Who serve me well and true:
        Their names are What and Where and When
        And How and Why and Who." - Kipling
         
        -------------- Original message --------------

        >
        >
        >
        >
        >
        > I have a situation that I'm hoping the list can help me with.
        >
        > We're a small team (4 people) doing development work for internal business
        > units. Of necessity, each of our Scrums need to address a number of
        > different projects and one-off items for a variety of departments. We do
        > our best to keep the departments focused on strategic goals, and we find
        > that this is working very well.
        >
        > Here's the problem. We've got a project coming down the pipe that we've
        > known about for some time. This project involves outside business partners
        > and has been mired in contract negotiations, internal executive approval
        > process and the like for some time now. We have an idea of the scope of
        > the project, but only restricted access to necessary outside technical
        > resources until the contracts are signed. We're reluctant (refuse) to
        > start work on this project prior to final approval, even if we could start
        > now (which we probably couldn't). Our current Sprint ends November 12th.
        > We are likely to find out that project has a formal go ahead sometime next
        > week, and they would like to be in a position to do some restricted
        > implementation by December 1st.
        >
        > The quantity of work feels do-able in that time (possibly). It doesn't
        > feel do-able in the time from November 15th to December 1st. We don't want
        > Scrum to become a "bondage and discipline" methodology that gets in the way
        > of IT being an "enabler" of business initiatives. On the other hand, we
        > are extremely happy with the results we get from Scrum and like idea of
        > being able to say, "We have a system, it works, and if you want our help
        > you'll need to play by our rules". We don't want to jettison the
        > methodology this time, because that sends the message that we're willing to
        > jettison the methodology and the business unit involved will keep bringing
        > up projects in the future that won't fit into our Sprint schedule.
        >
        > In the course, Ken paints this as a rather black and white picture. If the
        > customers start to get silly and messing around with the process, you call
        > a Premature Termination of Sprint, nobody gets anything and you start all
        > over. In our mixed bag Sprints, though, this would penalize the other
        > internal business units.
        >
        > So, the question: How can I handle this situation, get the work done by
        > December 1, and still preserve some adherence to Scrum principles?
        >
        >
        > Dave Barrett,
        > Lawyers' Professional Indemnity Company
        >
        >
        >
        > ------------------------ Yahoo! Groups Sponsor --------------------~-->
        > $9.95 domain names from Yahoo!. Register anything.
        > http://us.click.yahoo.com/J8kdrA/y20IAA/yQLSAA/9EfwlB/TM
        > --------------------------------------------------------------------~->
        >
        > To Post a message, send it to: scrumdevelopment@...
        > To Unsubscribe, send a blank message to:
        > scrumdevelopment-unsubscribe@...
        > Yahoo! Groups Links
        >
        > <*> To visit your group on the web, go to:
        > http://groups.yahoo.com/group/scrumdevelopment/
        >
        > <*> To unsubscribe from this group, send an email to:
        > scrumdevelopment-unsubscribe@yahoogroups.com
        >
        > <*> Your use of Yahoo! Groups is subject to:
        > http://docs.yahoo.com/info/terms/
        >
        >
        >
        >
      • Mike Cohn
        Can the team, ScrumMaster and Product get together and agree to an early termination of the current sprint with some delivered functionality? That is, some of
        Message 3 of 10 , Oct 29, 2004
          Can the team, ScrumMaster and Product get together and agree to an early
          termination of the current sprint with some delivered functionality? That
          is, some of what is done is salvageable either immediately or with a day or
          two (or more) of work. If you spent a day or two wrapping up, couldn't you
          then start a new sprint that delivered the new project with perhaps some of
          the currently planned features that would get dropped?

          --Mike Cohn
          Author of User Stories Applied for Agile Software Development
          www.mountaingoatsoftware.com
          www.userstories.com

          -----Original Message-----
          From: David A Barrett [mailto:dave.barrett@...]
          Sent: Friday, October 29, 2004 7:19 AM
          To: scrumdevelopment@yahoogroups.com
          Subject: [scrumdevelopment] A Practical Question






          I have a situation that I'm hoping the list can help me with.

          We're a small team (4 people) doing development work for internal business
          units. Of necessity, each of our Scrums need to address a number of
          different projects and one-off items for a variety of departments. We do
          our best to keep the departments focused on strategic goals, and we find
          that this is working very well.

          Here's the problem. We've got a project coming down the pipe that we've
          known about for some time. This project involves outside business partners
          and has been mired in contract negotiations, internal executive approval
          process and the like for some time now. We have an idea of the scope of
          the project, but only restricted access to necessary outside technical
          resources until the contracts are signed. We're reluctant (refuse) to
          start work on this project prior to final approval, even if we could start
          now (which we probably couldn't). Our current Sprint ends November 12th.
          We are likely to find out that project has a formal go ahead sometime next
          week, and they would like to be in a position to do some restricted
          implementation by December 1st.

          The quantity of work feels do-able in that time (possibly). It doesn't
          feel do-able in the time from November 15th to December 1st. We don't want
          Scrum to become a "bondage and discipline" methodology that gets in the way
          of IT being an "enabler" of business initiatives. On the other hand, we
          are extremely happy with the results we get from Scrum and like idea of
          being able to say, "We have a system, it works, and if you want our help
          you'll need to play by our rules". We don't want to jettison the
          methodology this time, because that sends the message that we're willing to
          jettison the methodology and the business unit involved will keep bringing
          up projects in the future that won't fit into our Sprint schedule.

          In the course, Ken paints this as a rather black and white picture. If the
          customers start to get silly and messing around with the process, you call
          a Premature Termination of Sprint, nobody gets anything and you start all
          over. In our mixed bag Sprints, though, this would penalize the other
          internal business units.

          So, the question: How can I handle this situation, get the work done by
          December 1, and still preserve some adherence to Scrum principles?


          Dave Barrett,
          Lawyers' Professional Indemnity Company




          To Post a message, send it to: scrumdevelopment@...
          To Unsubscribe, send a blank message to:
          scrumdevelopment-unsubscribe@...
          Yahoo! Groups Links
        • Boris Gloger
          On Fri, 29 Oct 2004 09:19:05 -0400, David A Barrett ... [...] ... [...] ... Hi Dave, I have no out of the box advice for you, and I do not see how to solve
          Message 4 of 10 , Oct 30, 2004
            On Fri, 29 Oct 2004 09:19:05 -0400, David A Barrett
            <dave.barrett@...> wrote:
            >
            >
            > I have a situation that I'm hoping the list can help me with.
            >
            [...]

            >
            > Here's the problem. We've got a project coming down the pipe that we've
            > known about for some time. This project involves outside business partners
            > and has been mired in contract negotiations, internal executive approval
            > process and the like for some time now. We have an idea of the scope of
            > the project, but only restricted access to necessary outside technical
            > resources until the contracts are signed. We're reluctant (refuse) to
            > start work on this project prior to final approval, even if we could start
            > now (which we probably couldn't). Our current Sprint ends November 12th.
            > We are likely to find out that project has a formal go ahead sometime next
            > week, and they would like to be in a position to do some restricted
            > implementation by December 1st.
            >
            > The quantity of work feels do-able in that time (possibly). It doesn't
            > feel do-able in the time from November 15th to December 1st.

            [...]
            >
            > So, the question: How can I handle this situation, get the work done by
            > December 1, and still preserve some adherence to Scrum principles?
            >
            > Dave Barrett,

            Hi Dave,

            I have no out of the box advice for you, and I do not see how to solve
            that problem on a simple way. What i doubt is, that the siutation is
            so tight as you describe it. I mean, if the project did not start so
            far, who defined that it needed to be ready by 1st of December? I mean
            - the development team start to think about the amount of work, that
            is able to deliver in the Sprint Planning. There was not Sprint
            Planning, who did create this feeling that it is possible to deliver?

            At the moment there is not project, as I understand, right? So lets
            say you get the approval for running the project next week, lets say
            on Thursday. Nobody will start on Friday. So you might start on Monday
            the 8th, right?

            If you really able to start on the 8th that would make me wonder. Are
            all interfaces to outside partners defined? Are the responsibiliies
            clear? I mean in a traditional project management world you would need
            at least a week to set up the environment, right?

            Why do you not start the project, but you do not waste the effort of
            your team. You could set up the environment, talk to your partners
            about the way you want to work with them and you could define the
            necessary meetings for the week after the 12th. So you would not spent
            the time of your team, besides your own time and you could define with
            your customer on the 15th what they will get on the 1st of Dec. Maybe
            only 80 % but - well that is all you can deliver.

            Or you go the way that Mike suggestes - ask you business, what is more
            important. The old project finished in the right way with deliverables
            or waste everything and start now - without an approval?

            The point is - you have to make clear - it is not the process which is
            responsible for what happens, but the nonsens to non-start a project
            with a clear defined end before starting the project.

            boris
          • Hubert Smits
            Hello David, Without knowing much about your company, and the way Scrum is implemented I would have a question/assessment: Is your management a full part of
            Message 5 of 10 , Oct 30, 2004
              Hello David,

              Without knowing much about your company, and the way Scrum is
              implemented I would have a question/assessment:

              Is your management a full part of the Scrum implementation? In other
              words, do they prioritise backlogs and decide which business values
              are to be delivered in any sprint.

              My assessment is that they are not, as you seem to be dealing with the
              priority question.

              I would only halt the current sprint if I feel that the business value
              of the newer contract exceeds the business value of the current
              sprint. But when proposing that to the management I would also make it
              clear that the work done in the current sprint will deliver no
              business value. Let the management make the choice: halt now, destroy
              the invested money and deliver the new contract in a sprint. Or
              complete the current sprint, then plan the next one. That next one has
              two options: either run a full sprint, with a full delivery, and
              deliver by 15 Dec. Or run one or two 2-week sprints. Delivering value
              by Dec 1st, albeit not the full value.

              This is the black and white option that Ken pictures, true. The reason
              for doing this is to make the management fully aware of their
              responsibilities. You are pulling them into Scrum. It is too easy for
              them to leave you with the decision problem. You'll never get it right
              (either your current customers get value and the next ones don't, or
              vice versa), you take the blame, and they get on with playing golf.

              The long and short: your management has to take on the
              responsibilities that they own: make business decisions.

              Just my 2p, remember that I can only assess, not assert, as I don't
              know you, your company or projects.

              Success with the process,

              Hubert

              On Fri, 29 Oct 2004 09:19:05 -0400, David A Barrett
              <dave.barrett@...> wrote:
              >
              >
              > I have a situation that I'm hoping the list can help me with.
              >
              > We're a small team (4 people) doing development work for internal business
              > units. Of necessity, each of our Scrums need to address a number of
              > different projects and one-off items for a variety of departments. We do
              > our best to keep the departments focused on strategic goals, and we find
              > that this is working very well.
              >
              > Here's the problem. We've got a project coming down the pipe that we've
              > known about for some time. This project involves outside business partners
              > and has been mired in contract negotiations, internal executive approval
              > process and the like for some time now. We have an idea of the scope of
              > the project, but only restricted access to necessary outside technical
              > resources until the contracts are signed. We're reluctant (refuse) to
              > start work on this project prior to final approval, even if we could start
              > now (which we probably couldn't). Our current Sprint ends November 12th.
              > We are likely to find out that project has a formal go ahead sometime next
              > week, and they would like to be in a position to do some restricted
              > implementation by December 1st.
              >
              > The quantity of work feels do-able in that time (possibly). It doesn't
              > feel do-able in the time from November 15th to December 1st. We don't want
              > Scrum to become a "bondage and discipline" methodology that gets in the way
              > of IT being an "enabler" of business initiatives. On the other hand, we
              > are extremely happy with the results we get from Scrum and like idea of
              > being able to say, "We have a system, it works, and if you want our help
              > you'll need to play by our rules". We don't want to jettison the
              > methodology this time, because that sends the message that we're willing to
              > jettison the methodology and the business unit involved will keep bringing
              > up projects in the future that won't fit into our Sprint schedule.
              >
              > In the course, Ken paints this as a rather black and white picture. If the
              > customers start to get silly and messing around with the process, you call
              > a Premature Termination of Sprint, nobody gets anything and you start all
              > over. In our mixed bag Sprints, though, this would penalize the other
              > internal business units.
              >
              > So, the question: How can I handle this situation, get the work done by
              > December 1, and still preserve some adherence to Scrum principles?
              >
              > Dave Barrett,
              > Lawyers' Professional Indemnity Company
              >
              >
              > To Post a message, send it to: scrumdevelopment@...
              > To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...
              > Yahoo! Groups Links
              >
              >
              >
              >
              >
            • David A Barrett
              First of all, thank you for all the suggestions and replies. After our Scrum on Friday, I laid the situation out for the team. There was no doubt in their
              Message 6 of 10 , Nov 1 11:32 AM
                First of all, thank you for all the suggestions and replies.

                After our Scrum on Friday, I laid the situation out for the team. There
                was no doubt in their minds; give management the option of terminating the
                current Sprint in order to start on the new project right away. To be
                honest, we smelled this coming, and we made an effort to unofficially
                divide the current Sprint into two parts. Halfway through, we have fair
                number of Sprint Backlog items completed (or close enough ) so that would
                could deploy them, another bunch of Sprint Backlog items that haven't been
                touched at all and only a very few items were we've invested any
                significant amount of time but aren't yet completed.

                We're supplying senior management with a list of what's been done, and what
                will not be delivered if we terminate the Sprint tomorrow. We're going to
                have a meeting shortly to get our minds wrapped around what this new
                project will take to complete, and based on that we'll build some time
                estimates and let senior management know how much (if any) of the dropped
                items can be added to the new Sprint.

                We like this approach, because it makes it brutally obvious the impact of
                this kind of "planning" on the part of one business unit has on all of the
                others. Personally, I've always viewed the "Premature Terminate of Sprint"
                to be a bit of a big stick to use, and a little bit confrontational. On
                the other hand, the team is fully booked, and the senior management need
                the opportunity to tell us what the priorities are.

                I thought Boris's answer was interesting for a number of reasons:

                >If you really able to start on the 8th that would make me wonder. Are
                >all interfaces to outside partners defined? Are the responsibiliies
                >clear? I mean in a traditional project management world you would need
                >at least a week to set up the environment, right?

                You know, I could have a programmers up and running tomorrow on this if I
                wanted. Yeah, I don't know all of the details about anything, but I do
                know that I'm going to need to add a few files to my database; I've got XML
                transfers involved, so I'll need to build a handler for them; I've got to
                send some flat files out to a third party, I can get someone started on a
                program to build that. There's lots of other stuff that we could start
                right away. In all of these cases, I don't have enough information to
                finish, but I do have enough information to start with very little chance
                that the programmers would go significantly astray before we had the
                details they needed at hand.

                What I can do, is to sit down with the team and go over the entire business
                scenario with them, and share as much as I know about what the business
                units involved are concerned about, what the business partners are looking
                for and so on. Thusly informed, I hope, they'll be able to make superior
                decisions about how to design stuff, when to design and build stuff and
                where to ask for more information.

                I've noticed that with brand new systems like this, the biggest hurdle is
                the inability of the users to visualize the solution during the
                specifications phase. One of the things I like about Agile is that you can
                almost throw that aways, sit the programmers down with the users, cut some
                code and show them what you've done so they can see it and comment.

                Dave Barrett,
                Lawyers' Professional Indemnity Company
              • Boris Gloger
                Hi Dave, ... On Mon, 1 Nov 2004 14:32:09 -0500, David A Barrett ... [...] ... [...] thanks for quoting me and I would love to see your team working - obviously
                Message 7 of 10 , Nov 2 12:46 AM
                  Hi Dave, ...

                  On Mon, 1 Nov 2004 14:32:09 -0500, David A Barrett
                  <dave.barrett@...> wrote:
                  >
                  >
                  > First of all, thank you for all the suggestions and replies.
                  >
                  [...]

                  >
                  > I thought Boris's answer was interesting for a number of reasons:
                  >
                  > >If you really able to start on the 8th that would make me wonder. Are
                  > >all interfaces to outside partners defined? Are the responsibiliies
                  > >clear? I mean in a traditional project management world you would need
                  > >at least a week to set up the environment, right?
                  >
                  > You know, I could have a programmers up and running tomorrow on this if I
                  > wanted. Yeah, I don't know all of the details about anything, but I do
                  > know that I'm going to need to add a few files to my database; I've got XML
                  > transfers involved, so I'll need to build a handler for them; I've got to
                  > send some flat files out to a third party, I can get someone started on a
                  > program to build that. There's lots of other stuff that we could start
                  > right away. In all of these cases, I don't have enough information to
                  > finish, but I do have enough information to start with very little chance
                  > that the programmers would go significantly astray before we had the
                  > details they needed at hand.
                  >
                  > What I can do, is to sit down with the team and go over the entire business
                  > scenario with them, and share as much as I know about what the business
                  > units involved are concerned about, what the business partners are looking
                  > for and so on. Thusly informed, I hope, they'll be able to make superior
                  > decisions about how to design stuff, when to design and build stuff and
                  > where to ask for more information.
                  >
                  [...]

                  thanks for quoting me and I would love to see your team working -
                  obviously your team is in a very good shape - to phrase it in this
                  way. But you answer makes me wonder again. Where is the customer? That
                  you could sit with your team to get this project running I have no
                  doubt. But is this your role?

                  Dave I do not want to agrue for the sake of arguing - my concern is
                  that I got the feeling from you explainations that the business is not
                  really engaged. It sounds as that they demand something from you
                  without doing their own part.

                  But this is only a feeling, based on some sentences and I am sitting
                  thousends of miles away and have not real insight - so feel free to
                  ignore this mail :))

                  Boris
                • David A Barrett
                  ... That s a darned good question. Where IS the customer, and is he fully engaged? This project has two business units involved. One is a product department,
                  Message 8 of 10 , Nov 3 6:57 AM
                    Boris wrote:

                    >But you answer makes me wonder again. Where is the customer? That
                    >you could sit with your team to get this project running I have no
                    >doubt. But is this your role?
                    >
                    >Dave I do not want to agrue for the sake of arguing - my concern is
                    >that I got the feeling from you explainations that the business is not
                    >really engaged. It sounds as that they demand something from you
                    >without doing their own part.

                    That's a darned good question. Where IS the customer, and is he fully
                    engaged?

                    This project has two business units involved. One is a product department,
                    and the other is the finance department. The driver is the product
                    department, but the nature of the project is such that the bulk of the
                    responsibility for day to day operation falls on the finance department.
                    The project can be described in about 10 minutes, and the bulk of the work
                    will be building controls to make sure that the data communication works
                    properly, and that the finance people can track the beans properly and
                    reconcile the numbers in a timely manner. One of the outside business
                    partners is concerned that the system is secure and fiddle-proof at our
                    end. The other outside business partner just wants it to happen.

                    The bottom line is that any experienced software developer could tell the
                    various customers what they should want on this particular project. Is the
                    Finance Department fully engaged? Nah. Does that matter? Not really.
                    Our relationship with the finance department is such that they trust us not
                    build a system which won't give them the controls they need, and at this
                    point in time they don't have enough of a feel for how it will work to
                    start giving input into what controls they want. Also, the Controller's
                    office is right next door to mine and enough informal conversations will
                    take place over the next month to keep things on track.

                    All of this puts the IT department in the middle of the situation. Is that
                    bad? Not really, its part of our perceived value to the company; that we
                    can step out of the pure "developer" box and be involved in the business
                    decisions behind the requirements for the software when we have to.

                    As to my role? My role is make it happen. Period.

                    Dave Barrett,
                    Lawyers' Professional Indemnity Company
                  • mike.dwyer1@comcast.net
                    It sounds like you are going to be both the project guy and the product owner guy . It also sounds like their has been a lot of trust build up between you
                    Message 9 of 10 , Nov 3 1:46 PM
                      It sounds like you are going to be both the 'project guy' and the 'product owner guy'.  It also sounds like their has been a lot of trust build up between you and the folks that write the checks for this project.
                       
                      One of the truly great things about the methodology is that at no time is the check writer out of touch with what is going on.  If you feel that the informal conversation level is going to keep them in control and you out of the middle - go for it.  If not then keep in mind how many OH NO's it takes to trash a thousand attaboys.
                       
                      --
                      Mike Dwyer

                      "I Keep six faithful serving-men
                      Who serve me well and true:
                      Their names are What and Where and When
                      And How and Why and Who." - Kipling
                       
                      -------------- Original message --------------

                      >
                      >
                      >
                      >
                      >
                      > Boris wrote:
                      >
                      > >But you answer makes me wonder again. Where is the customer? That
                      > >you could sit with your team to get this project running I have no
                      > >doubt. But is this your role?
                      > >
                      > >Dave I do not want to agrue for the sake of arguing - my concern is
                      > >that I got the feeling from you explainations that the business is not
                      > >really engaged. It sounds as that they demand something from you
                      > >without doing their own part.
                      >
                      > That's a darned good question. Where IS the customer, and is he fully
                      > engaged?
                      >
                      > This project has two business units involved. One is a product department,
                      > and the other is the finance department. The driver is the product
                      > department, but the nature of the project is such that the bulk of the
                      > responsibility for day to day operation falls on the finance department.
                      > The project can be described in about 10 minutes, and the bulk of the work
                      > will be building controls to make sure that the data communication works
                      > properly, and that the finance people can track the beans properly and
                      > reconcile the numbers in a timely manner. One of the outside business
                      > partners is concerned that the system is secure and fiddle-proof at our
                      > end. The other outside business partner just wants it to happen.
                      >
                      > The bottom line is that any experienced software developer could tell the
                      > various customers what they should want on this particular project. Is the
                      > Finance Department fully engaged? Nah. Does that matter? Not really.
                      > Our relationship with the finance department is such that they trust us not
                      > build a system which won't give them the controls they need, and at this
                      > point in time they don't have enough of a feel for how it will work to
                      > start giving input into what controls they want. Also, the Controller's
                      > office is right next door to mine and enough informal conversations will
                      > take place over the next month to keep things on track.
                      >
                      > All of this puts the IT department in the middle of the situation. Is that
                      > bad? Not really, its part of our perceived value to the company; that we
                      > can step out of the pure "developer" box and be involved in the business
                      > decisions behind the requirements for the software when we have to.
                      >
                      > As to my role? My role is make it happen. Period.
                      >
                      > Dave Barrett,
                      > Lawyers' Professional Indemnity Company
                      >
                      >
                      >
                      > ------------------------ Yahoo! Groups Sponsor --------------------~-->
                      > $9.95 domain names from Yahoo!. Register anything.
                      > http://us.click.yahoo.com/J8kdrA/y20IAA/yQLSAA/9EfwlB/TM
                      > --------------------------------------------------------------------~->
                      >
                      > To Post a message, send it to: scrumdevelopment@...
                      > To Unsubscribe, send a blank message to:
                      > scrumdevelopment-unsubscribe@...
                      > Yahoo! Groups Links
                      >
                      > <*> To visit your group on the web, go to:
                      > http://groups.yahoo.com/group/scrumdevelopment/
                      >
                      > <*> To unsubscribe from this group, send an email to:
                      > scrumdevelopment-unsubscribe@yahoogroups.com
                      >
                      > <*> Your use of Yahoo! Groups is subject to:
                      > http://docs.yahoo.com/info/terms/
                      >
                      >
                      >
                      >
                    • David A Barrett
                      ... owner guy . Hmmmm. More like the product custodian guy . Once the Finance people get their hands on it, and can understand it, they ll start to assume
                      Message 10 of 10 , Nov 4 7:11 AM
                        >It sounds like you are going to be both the 'project guy' and the 'product
                        owner guy'.

                        Hmmmm. More like the "product custodian guy". Once the Finance people
                        get their hands on it, and can understand it, they'll start to assume an
                        ownership role.

                        Dave Barrett,
                        Lawyers' Professional Indemnity Company
                      Your message has been successfully submitted and would be delivered to recipients shortly.