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

Re: Who is the Product Owner?

Expand Messages
  • Roman Pichler
    Hi Jalilnejad, For commercial products, the product owner is typically a customer representative, such as a product manager or marketer. An actual customer
    Message 1 of 12 , Mar 3, 2011
    • 0 Attachment
      Hi Jalilnejad,

      For commercial products, the product owner is typically a customer representative, such as a product manager or marketer. An actual customer tends to assume the role when the product is being developed for a specific organization, for instance, an external client who requires a new data warehouse solution or an internal client (e.g., the marketing department) asking for a web site update. I have worked with customers, users, business line managers, product managers, project managers, business analysts, and architects who filled the product owner role well in the given circumstances.

      Whoever plays the product owner role should own the product and should be responsible for its success.

      You can find out more by reading my book "Agile Product Management with Scrum" and my blog: allthingsproductowner.com 

      Best regards,
      Roman

      --- In scrumdevelopment@yahoogroups.com, "M.Jalilnejad" <M.Jalilnezhad@...> wrote:
      >
      > Hello,
      > I have read the book "scrum and xp from the trenches" and some questions
      > arose in my head. I will ask one of them occasionally
      >
      > Who is the product Owner? is he an employee of our company? or he is from
      > the customer's? is he a customer on-site?
      > what i realized that is his responsibilities/roles relates to the customer.
      > So he should be determined by stakeholders
      > Roman Pichler wrote in his
      > article<http://www.scrumalliance.org/articles/44-being-an-effective-product-owner>
      > :
      > *"The product owner is required to closely collaborate with the team on an
      > ongoing basis and to guide and direct the team (e.g., by actively managing
      > the product backlog, answering questions when they arise, providing
      > feedback, and signing off work results.)"
      > *
      > Notice me if I'm wrong.
      >
      >
      > Regards
      > Jalilnejad,
      >
    • Michael James
      ... Yes. I was on a team that had breakthroughs because the customer finally took over the PO role. Before then, scope was growing out of control and there
      Message 2 of 12 , Mar 3, 2011
      • 0 Attachment
        On Mar 3, 2011, at 7:01 AM, Alan Dayley wrote:

        > In my opinion, it should be someone who understands the customers. Even better, the actual customer.

        Yes. I was on a team that had breakthroughs because the customer finally took over the PO role. Before then, scope was growing out of control and there was no way we'd ever release. Get the real PO with the product vision, not some intermediate proxy.

        --mj
        http://ScrumReferenceCard.com
      • Charles Bradley - Scrum Coach CSM PSM I
        ... This usually brings up an interesting conundrum though. Often times, the Customer PO cannot commit to a full time commitment with the dev team. Maybe
        Message 3 of 12 , Mar 3, 2011
        • 0 Attachment
          > we'd ever release.  Get the real PO with the product vision, not some intermediate proxy.
           
          This usually brings up an interesting conundrum though.

          Often times, the "Customer PO" cannot commit to a full time commitment with the dev team.  Maybe their time commitment is something like 20%.  The good news is you have the real customer with the real vision.  The bad news is you have them only rarely, so they become a bottleneck pretty quickly.  Also, if they're new to Scrum or your requirements gathering techniques, that can also be bad news.

          OTOH, if you have a "Proxy PO", usually that is a full time commitment with the dev team, and usually the Proxy PO comes from a development background, or at least a requirements background.  The good news is you have someone full time supporting and collaborating with the dev team.  The other good news is that these proxies usually understanding requirements gathering and hopefully Scrum too.  The bad news is that the Proxy PO can create lots of waste if they don't do a good job of collaborating with the real customers/stakeholders to ascertain the real vision and priorities.

          Still others say somethign like "Well, if you can't get someone from the user/customer community to commit to being a full time PO, then the project should be defunded and/or deprioritized."  Not everyone buys into that view.

          I don't find the optimum solution to always be so black and white as "always get the customer if you can."  (I realize that is not exactly what Michael was saying.)

          I think the obvious great PO is someone from the user/customer community, committed 100%, and at least fairly well trained on Scrum and/or requirement gathering techniques (or maybe dev team members can assist with the requirements gathering).  I just find that to be a rare specimen in my experiences.

          -------
          Charles Bradley, CSM, PSM I
          Experienced Scrum Coach
          My blog: http://scrumcrazy.wordpress.com/



          From: Michael James <mj4scrum@...>
          To: scrumdevelopment@yahoogroups.com
          Sent: Thu, March 3, 2011 10:22:53 AM
          Subject: Re: [scrumdevelopment] Who is the Product Owner?


          On Mar 3, 2011, at 7:01 AM, Alan Dayley wrote:

          > In my opinion, it should be someone who understands the customers.  Even better, the actual customer.

          Yes.  I was on a team that had breakthroughs because the customer finally took over the PO role.  Before then, scope was growing out of control and there was no way we'd ever release.  Get the real PO with the product vision, not some intermediate proxy.

          --mj
          http://ScrumReferenceCard.com

          ------------------------------------

          To Post a message, send it to:  scrumdevelopment@...
          To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...! Groups Links

          <*> To visit your group on the web, go to:
              http://groups.yahoo.com/group/scrumdevelopment/

          <*> Your email settings:
              Individual Email | Traditional

          <*> To change settings online go to:
              http://groups.yahoo.com/group/scrumdevelopment/join
              (Yahoo! ID required)

          <*> To change settings via email:
              scrumdevelopment-digest@yahoogroups.com
              scrumdevelopment-fullfeatured@yahoogroups.com

          <*> 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/

        • M.Jalilnejad
          Thanks all, Very great. I got the answer. I surprised. I didn t expect to get the answer so soon. It shows that I selected the right place to ask Let me
          Message 4 of 12 , Mar 4, 2011
          • 0 Attachment
            Thanks all,
            Very great. I got the answer. I surprised. I didn't expect to get the answer so soon. It shows that I selected the right place to ask
            Let me summarize. The ideal PO is a "Customer PO" with real vision , full time commitment and Scrum awareness. But a good enough "Proxy PO" with full time availability and development background is also fine.
            In think personal characteristics of a PO is somewhat/sometimes influential. (It seems so clear to say ;) )


            Regards
            Jalilnejad,

            On Thu, Mar 3, 2011 at 9:12 PM, Charles Bradley - Scrum Coach CSM PSM I <chuck..> wrote:
             

            > we'd ever release.  Get the real PO with the product vision, not some intermediate proxy.
             
            This usually brings up an interesting conundrum though.

            Often times, the "Customer PO" cannot commit to a full time commitment with the dev team.  Maybe their time commitment is something like 20%.  The good news is you have the real customer with the real vision.  The bad news is you have them only rarely, so they become a bottleneck pretty quickly.  Also, if they're new to Scrum or your requirements gathering techniques, that can also be bad news.

            OTOH, if you have a "Proxy PO", usually that is a full time commitment with the dev team, and usually the Proxy PO comes from a development background, or at least a requirements background.  The good news is you have someone full time supporting and collaborating with the dev team.  The other good news is that these proxies usually understanding requirements gathering and hopefully Scrum too.  The bad news is that the Proxy PO can create lots of waste if they don't do a good job of collaborating with the real customers/stakeholders to ascertain the real vision and priorities.

            Still others say somethign like "Well, if you can't get someone from the user/customer community to commit to being a full time PO, then the project should be defunded and/or deprioritized."  Not everyone buys into that view.

            I don't find the optimum solution to always be so black and white as "always get the customer if you can."  (I realize that is not exactly what Michael was saying.)

            I think the obvious great PO is someone from the user/customer community, committed 100%, and at least fairly well trained on Scrum and/or requirement gathering techniques (or maybe dev team members can assist with the requirements gathering).  I just find that to be a rare specimen in my experiences.

            -------
            Charles Bradley, CSM, PSM I
            Experienced Scrum Coach
            My blog: http://scrumcrazy.wordpress.com/



          • Dan Rawsthorne
            Yes, but remember that this PO (or Proxy) must be empowered and accountable for the prioritizations he/she makes. This is the most important thing - the rest
            Message 5 of 12 , Mar 4, 2011
            • 0 Attachment
              Yes, but remember that this PO (or Proxy) must be empowered and accountable for the prioritizations he/she makes. This is the most important thing - the rest is just nice-to-have.
              Dan  ;-)

              On 3/4/2011 4:52 AM, M.Jalilnejad wrote:  
              Thanks all,
              Very great. I got the answer. I surprised. I didn't expect to get the answer so soon. It shows that I selected the right place to ask
              Let me summarize. The ideal PO is a "Customer PO" with real vision , full time commitment and Scrum awareness. But a good enough "Proxy PO" with full time availability and development background is also fine.
              In think personal characteristics of a PO is somewhat/sometimes influential. (It seems so clear to say ;) )


              Regards
              Jalilnejad,

              On Thu, Mar 3, 2011 at 9:12 PM, Charles Bradley - Scrum Coach CSM PSM I <chuck..> wrote:
               
              > we'd ever release.  Get the real PO with the product vision, not some intermediate proxy.
               
              This usually brings up an interesting conundrum though.

              Often times, the "Customer PO" cannot commit to a full time commitment with the dev team.  Maybe their time commitment is something like 20%.  The good news is you have the real customer with the real vision.  The bad news is you have them only rarely, so they become a bottleneck pretty quickly.  Also, if they're new to Scrum or your requirements gathering techniques, that can also be bad news.

              OTOH, if you have a "Proxy PO", usually that is a full time commitment with the dev team, and usually the Proxy PO comes from a development background, or at least a requirements background.  The good news is you have someone full time supporting and collaborating with the dev team.  The other good news is that these proxies usually understanding requirements gathering and hopefully Scrum too.  The bad news is that the Proxy PO can create lots of waste if they don't do a good job of collaborating with the real customers/stakeholders to ascertain the real vision and priorities.

              Still others say somethign like "Well, if you can't get someone from the user/customer community to commit to being a full time PO, then the project should be defunded and/or deprioritized."  Not everyone buys into that view.

              I don't find the optimum solution to always be so black and white as "always get the customer if you can."  (I realize that is not exactly what Michael was saying.)

              I think the obvious great PO is someone from the user/customer community, committed 100%, and at least fairly well trained on Scrum and/or requirement gathering techniques (or maybe dev team members can assist with the requirements gathering).  I just find that to be a rare specimen in my experiences.

              -------
              Charles Bradley, CSM, PSM I
              Experienced Scrum Coach
              My blog: http://scrumcrazy.wordpress.com/



            • alex.armstrong
              Jalilnejad, Just don t lose sight of the goal: delivering value with your product. You have to have a PO. Beyond that, the more people that stand between the
              Message 6 of 12 , Mar 4, 2011
              • 0 Attachment
                Jalilnejad,

                Just don't lose sight of the goal: delivering value with your product. You have to have a PO. Beyond that, the more people that stand between the customers and the developers, the more chances there are for delays and miscommunications.

                Alex

                --- In scrumdevelopment@yahoogroups.com, Dan Rawsthorne <dan.rawsthorne@...> wrote:
                >
                > Yes, but remember that this PO (or Proxy) must be empowered and
                > accountable for the prioritizations he/she makes. This is the most
                > important thing - the rest is just nice-to-have.
                > Dan ;-)
                >
                > On 3/4/2011 4:52 AM, M.Jalilnejad wrote:
                > > Thanks all,
                > > Very great. I got the answer. I surprised. I didn't expect to get the
                > > answer so soon. It shows that I selected the right place to ask
                > > Let me summarize. The /ideal /PO is a "Customer PO" with /real vision/
                > > , full time commitment and Scrum awareness. But a /good enough /"Proxy
                > > PO" with full time availability and development background is also fine.
                > > In think personal characteristics of a PO is somewhat/sometimes
                > > influential. (It seems so clear to say ;) )
                > >
                > >
                > > Regards
                > > Jalilnejad,
                > >
                > > On Thu, Mar 3, 2011 at 9:12 PM, Charles Bradley - Scrum Coach CSM PSM
                > > I <chuck..> wrote:
                > >
                > > > we'd ever release. Get the real PO with the product vision, not
                > > some intermediate proxy.
                > >
                > > This usually brings up an interesting conundrum though.
                > >
                > > Often times, the "Customer PO" cannot commit to a full time
                > > commitment with the dev team. Maybe their time commitment is
                > > something like 20%. The good news is you have the real customer
                > > with the real vision. The bad news is you have them only rarely,
                > > so they become a bottleneck pretty quickly. Also, if they're new
                > > to Scrum or your requirements gathering techniques, that can also
                > > be bad news.
                > >
                > > OTOH, if you have a "Proxy PO", usually that is a full time
                > > commitment with the dev team, and usually the Proxy PO comes from
                > > a development background, or at least a requirements background.
                > > The good news is you have someone full time supporting and
                > > collaborating with the dev team. The other good news is that
                > > these proxies usually understanding requirements gathering and
                > > hopefully Scrum too. The bad news is that the Proxy PO can create
                > > lots of waste if they don't do a good job of collaborating with
                > > the real customers/stakeholders to ascertain the real vision and
                > > priorities.
                > >
                > > Still others say somethign like "Well, if you can't get someone
                > > from the user/customer community to commit to being a full time
                > > PO, then the project should be defunded and/or deprioritized."
                > > Not everyone buys into that view.
                > >
                > > I don't find the optimum solution to always be so black and white
                > > as "always get the customer if you can." (I realize that is not
                > > exactly what Michael was saying.)
                > >
                > > I think the obvious great PO is someone from the user/customer
                > > community, committed 100%, and at least fairly well trained on
                > > Scrum and/or requirement gathering techniques (or maybe dev team
                > > members can assist with the requirements gathering). I just find
                > > that to be a rare specimen in my experiences.
                > >
                > > -------
                > > Charles Bradley, CSM, PSM I
                > > Experienced Scrum Coach
                > > My blog: http://scrumcrazy.wordpress.com/
                > >
                > >
                > >
                > >
                >
              • Peter Stevens (cal)
                On 04.03.11 13:52, M.Jalilnejad wrote:   But a good enough Proxy PO with full time availability and development background is also fine. ,_._,___ If you
                Message 7 of 12 , Mar 5, 2011
                • 0 Attachment
                  On 04.03.11 13:52, M.Jalilnejad wrote:
                   

                  But a good enough "Proxy PO" with full time availability and development background is also fine.
                  ,_._,___

                  If you have a proxy PO, the question I always ask is 'how done is done'?

                  Acceptance is not something one can really outsource, because you are the only person who can decide whether you have gotten what you wanted for your money.

                  So a proxy PO provide by a supplier (or the development group of a large organization) cannot truly speak for the customer. More subtly, if the PO comes from the customer or 'business', the development team has an ally in the customer organization. The can change the dynamic of doneness decisions dramatically.

                  Cheers,

                  Peter

                  -- 
                  Peter Stevens, Partner 
                  DasScrumTeam GmbH 
                  
                  direct: +41 44 586 6450 
                  cell:   +41 79 422 6722
                  skype:  peterstev
                  
                  blog:   http://scrum-breakfast.com
                  
                  My New Email Address: peter.stevens@...
                  Please update your address book. Thanks!
                  
                • Chuck B
                  Jalilnejad, ... I would add a couple more traits for the Proxy PO: * Has excellent communication skills, most notably the ability to collaborate with the real
                  Message 8 of 12 , Mar 5, 2011
                  • 0 Attachment
                    Jalilnejad,

                    > But a good enough "Proxy PO" with full time availability and development background is also fine.

                    I would add a couple more traits for the Proxy PO:
                    • Has excellent communication skills, most notably the ability to collaborate with the real customers/stakeholders to ascertain the real vision and priorities.
                    • Has a background in good requirements techniques.
                    • Has a significant amount of Scrum knowledge, significantly moreso than a typical "Customer PO" would have.  Preferably someone certified as a PO.
                    Roman's book has some good sections in his book(http://bit.ly/gJliYy) on qualities of a good PO(see chapter 1).  Mike Cohn also covers some tradeoffs for different kinds of "User Proxies" in his book(http://bit.ly/gQGHz6) too.  Cohn comes at it from a different angle, but many of the same tradeoffs apply.

                    Said another way:

                    If you listed the top 10 qualities(in order of preference) of a good PO, here is what I would go for:
                    You can assume that #1 would be that the PO is a major user(or business user, business owner) in the system and is fully empowered to make vision decisions, and
                    You can assume that #2 would be that the PO spends 70%+ of their time with the dev team.

                    Customer Proxy:  Has #1, has 2-3 of the other top 10 qualities, but will probably have to be taught many of the other qualities.
                    Proxy PO:  Since they don't have #1, they need to have #2, and they need to be solid in 5-7 of the other top qualities to make up for the fact that they don't have quality #1.

                    -------
                    Charles Bradley, CSM, PSM I
                    Experienced Scrum Coach
                    My blog: http://scrumcrazy.wordpress.com/



                    From: M.Jalilnejad <M.Jalilnezhad@...>
                    To: scrumdevelopment@yahoogroups.com
                    Sent: Fri, March 4, 2011 5:52:50 AM
                    Subject: Re: [scrumdevelopment] Who is the Product Owner?



                    Thanks all,
                    Very great. I got the answer. I surprised. I didn't expect to get the answer so soon. It shows that I selected the right place to ask
                    Let me summarize. The ideal PO is a "Customer PO" with real vision , full time commitment and Scrum awareness. But a good enough "Proxy PO" with full time availability and development background is also fine.
                    In think personal characteristics of a PO is somewhat/sometimes influential. (It seems so clear to say ;) )


                    Regards
                    Jalilnejad,

                    On Thu, Mar 3, 2011 at 9:12 PM, Charles Bradley - Scrum Coach CSM PSM I <chuck..> wrote:
                     

                    > we'd ever release.  Get the real PO with the product vision, not some intermediate proxy.
                     
                    This usually brings up an interesting conundrum though.

                    Often times, the "Customer PO" cannot commit to a full time commitment with the dev team.  Maybe their time commitment is something like 20%.  The good news is you have the real customer with the real vision.  The bad news is you have them only rarely, so they become a bottleneck pretty quickly.  Also, if they're new to Scrum or your requirements gathering techniques, that can also be bad news.

                    OTOH, if you have a "Proxy PO", usually that is a full time commitment with the dev team, and usually the Proxy PO comes from a development background, or at least a requirements background.  The good news is you have someone full time supporting and collaborating with the dev team.  The other good news is that these proxies usually understanding requirements gathering and hopefully Scrum too.  The bad news is that the Proxy PO can create lots of waste if they don't do a good job of collaborating with the real customers/stakeholders to ascertain the real vision and priorities.

                    Still others say somethign like "Well, if you can't get someone from the user/customer community to commit to being a full time PO, then the project should be defunded and/or deprioritized."  Not everyone buys into that view.

                    I don't find the optimum solution to always be so black and white as "always get the customer if you can."  (I realize that is not exactly what Michael was saying.)

                    I think the obvious great PO is someone from the user/customer community, committed 100%, and at least fairly well trained on Scrum and/or requirement gathering techniques (or maybe dev team members can assist with the requirements gathering).  I just find that to be a rare specimen in my experiences.

                    -------
                    Charles Bradley, CSM, PSM I
                    Experienced Scrum Coach
                    My blog: http://scrumcrazy.wordpress.com/





                  • Charles Bradley - Scrum Coach CSM PSM I
                    Peter, I think you re really referring to acceptance more than done -- see my other post just a few minutes ago regarding that. ... I agree with you in
                    Message 9 of 12 , Mar 5, 2011
                    • 0 Attachment
                      Peter,

                      I think you're really referring to "acceptance" more than "done" -- see my other post just a few minutes ago regarding that.

                      > Acceptance is not something one can really outsource, because you
                      are the only person who can decide whether you have gotten what you wanted for your money.
                       
                      I agree with you in principle, but, in Scrum, if someone has been chosen to be the PO, whether they come from the customer side or the dev side, that PO does decide PBI/Story acceptance. 

                      So maybe what I'm saying is that, in Scrum, "PO Acceptance" must be decided by the PO.

                      "Customer Acceptance" (where this is defined to be something like "acceptance by the most powerful business stakeholder") is a different matter altogether.  In some ways, I agree with you that PO Acceptance doesn't equal Customer Acceptance.  In other ways, I disagree that you can't outsource "Customer Acceptance."  You can absolutely do this, it's just that your mileage may vary widely.

                      In Scrum, I think it's really important that a Scrum team keeps their "eye on the ball" when it comes to PO Acceptance, and this is why I always recommend that the PO Acceptance be obtained as soon as a story is complete, and that the PO *lead* the Sprint Review.  The Sprint Review is generally where you find out, among other things, what the difference is between PO Acceptance and Customer Acceptance, which is why the Sprint Review is so important.  If you get into a situation where you end up deciding whether a Story has been accepted or not by what (non PO) customers say at the Sprint Review, then you'll generally have stories that carry over and carry over and carry over and are difficult to get "accepted."

                      I'm in the process of writing an article about the user story lifecycle (I essentially say that a User Story can proceed through different "levels", or phases).  Here is a pertinent snippet(be sure and see the 2nd paragraph):

                      <snip>
                      In the Acceptance level, the main goal is to get the PO to agree and accept the User Story's functionality as complete and correct, as judged against the User Story's Acceptance Tests.  Like many things in Scrum, this too is a collaboration, but since the Product Owner is responsible for product vision, the decision is ultimately up to them.
                      Acceptance technically can only really happen when a complete potentially shippable product increment is available for release(release need not happen for acceptance to occur, though).  Having said that, many teams do acceptance in two steps.  One step is a more informal acceptance by the Product Owner during the sprint, as soon as the story is completely implemented.  If the Product Owner approves, they are then basically saying, "Ok, I agree that this story appears to be complete and correct, and assuming it still appears complete and correct in the final integrated potentially shippable increment, I'll give my final acceptance at that time."  In other words, the Product Owner has to verify that the story works correctly once integrated with the rest of the stories implemented that sprint.  This second step is at the end of the sprint, once the entire increment(including all implemented stories for the sprint) is fully integrated, tested, and available for release.  The second step usually happens just before the Sprint Review, but could happen earlier than that if the increment is delivered early.

                      One thing you might want to note about this level is that I do not ever say anything about acceptance happening during or just after a Sprint Review.  Acceptance occurs between two parties and two parties only:  The Product Owner and the dev team.  This acceptance should occur *prior* to the Sprint Review.  There are a couple of reasons for doing acceptance before the Sprint Review.  First, the Product Owner should be leading the Sprint Review (assisted by other members of the Scrum Team if the PO so desires).  It's difficult for them to lead the Sprint Review and be analyzing the stories for acceptance at the same time.  Second, the acceptance scrutiny given by the Product Owner to the Sprint increment will allow the Product Owner to speak intelligently at the Sprint Review about the implemented functionality, including any known bugs or interesting bits of behavior.  Thirdly, you don't want to get into a situation where the Non Scrum Team(NST) stakeholders have a direct impact on acceptance.  If the NST stakeholders have feedback about how the stories are delivered or what changes should occur, that feedback should be communicated to the Product Owner as new User Stories that will go on the backlog.  It is perfectly fine, though, if a collaboration happens *at or after* the Sprint Review about these new User Stories (that might or might not be changes to the just delivered functionality).  Further, the Product Owner has the ability, if they so desire, to prioritize those "follow on" stories right up to the top of the backlog, and introduce them at the soon to be had Sprint Planning Meeting for the very next sprint.  Hopefully this late entering story situation will become fairly rare over time, but we have to remain agile and be accepting of late breaking changes.
                      </snip>



                      -------
                      Charles Bradley, CSM, PSM I
                      Experienced Scrum Coach
                      My blog: http://scrumcrazy.wordpress.com/



                      From: Peter Stevens (cal) <peterstev@...>
                      To: scrumdevelopment@yahoogroups.com
                      Sent: Sat, March 5, 2011 3:10:24 AM
                      Subject: Re: [scrumdevelopment] Who is the Product Owner?



                      On 04.03.11 13:52, M.Jalilnejad wrote:
                       

                      But a good enough "Proxy PO" with full time availability and development background is also fine.
                      ,_._,___

                      If you have a proxy PO, the question I always ask is 'how done is done'?

                      Acceptance is not something one can really outsource, because you are the only person who can decide whether you have gotten what you wanted for your money.

                      So a proxy PO provide by a supplier (or the development group of a large organization) cannot truly speak for the customer. More subtly, if the PO comes from the customer or 'business', the development team has an ally in the customer organization. The can change the dynamic of doneness decisions dramatically.

                      Cheers,

                      Peter

                      -- 
                      Peter Stevens, Partner
                      DasScrumTeam GmbH

                      direct: +41 44 586 6450
                      cell: +41 79 422 6722
                      skype: peterstev

                      blog: http://scrum-breakfast.com

                      My New Email Address: peter.stevens@... Please update your address book. Thanks!


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