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

Re: [scrumdevelopment] Bob Schatz in Mechelen: The Sprint Review is for the End-User.

Expand Messages
  • Mark Saffell
    Your are not listening, shut - up and listen to your customer! If the customer cannot afford what they want asist them with what they need. Hmm? Who said that?
    Message 1 of 62 , Mar 3, 2008
    • 0 Attachment
      Your are not listening, shut - up and listen to your customer! If the customer cannot afford what they want asist them with what they need.
      Hmm? Who said that? "You can't alway get what you want, but sometimes you get what you need". 
      - Mark A Saffell 

      Peter Bell <pbell@...> wrote:
      And you would seriously replicate Ebay for $1500??? Man. I though I was pretty good at delivering business value quickly, but THAT is impressive :->


      On 3/3/08 7:54 AM, "Mark Saffell" <masaffell@yahoo. com> wrote:


       
       

      Ok, send them over.
        
      In this care or your customer. I would build them a 1500.00 website. If they don't like it we'll work with them to build what they want.
        
      Do you sport a 5.00 hair cut?
        
      -Mark A Saffell

      Peter Bell <pbell@freshstartsof tware.com> wrote:
        

        
      In that case Mark, I have some customers for you :->

      They believe that rich, complex web applications are trivial, that you should just be able to intuit what they want (they are too busy to actually talk about what they want – but it’s an auction system – you know, like Ebay – just look at Ebay, give them that and then they’ll tell you what they need different). Best news is they have a $1500 budget for the site (including project management, a new logo, look and feel, programming, and some content population and training), but what with the price of offshored programmers in Russia no reason why you shouldn’t be able to get the project done for their big trade show week after next – right?

      The customer is NOT always right, in so many ways. They often ask for specific implementations when they want an underlying outcome, they often ask for contractual terms that would not be in their best interest, and as human beings, they are subject to the same foibles as the rest of us.

      Successful businesses help their customers to become more successful, but it’s not just about “the customer is right”.

      Best Wishes,
      Peter


      On 3/2/08 6:40 PM, "Mark Saffell" <masaffell@yahoo. com> wrote:

        


      What is the number one rule of business?
        
      1. The customer is always right? Right?
        
      If the customer is always right, then we need to find a way to make them happy. We never say no to a customer, we work on theri schedule. We do what ever it takes to make them happy.
        
      Who pays the bills? You? Me?, no the customer. If the customer is not happy then the customer finds happeness somewhere else.
        
       If the customer does not what to come ove, then you go to the cusomer, couse if you don't I will. Therefor your customer becomes my customer.
        
       
        
      Thank you,
        
      Mark A Saffell

      Boris Gloger <boris.gloger@ gmail.com> wrote:
        
        
      Hi,

      I had the pleasure to run a class together with Bob Schatz in Mechelen
      this week. We had a full house, a lot of fun and a lot of very good
      questions. One answer of Bob I will always remember:

      The Sprint Review is for the End-User. Not for the Product Owner not
      for the Management. You need to have him there.

      I strongly support this statement because I believe we need to talk in
      Scrum about 6 roles:

      The User, the Customer, the Manager, Product Owner, Team and
      ScrumMaster.

      We are this week in Oslo. Bob will be in Europe soon - check our
      website: www.sprint-it. de

      Cheers

      Boris


      Scrum - Produkte zuverlässig und schnell entwickeln
      http://www.hanser. de/buch.asp? isbn=978- 3-446-41495- 2&area=Computer <http://www.hanser. de/buch.asp? isbn=978- 3-446-41495- 2&amp;area=Computer>


      You've been invited to view an album on .Mac Web Gallery.



      Bob Schatz in Mechelen

      I published an album to my .Mac Web Gallery that I'd like to share
      with you. To check it out, click View Album.





      If you are unable to access this page, please copy and paste the URL
      below into your browser.
      http://gallery. mac.com/borisglo ger/100182



        
        

       Never miss a thing.   Make Yahoo your homepage. <http://us.rd. yahoo.com/ evt=51438/ *http://www. yahoo.com/ r/hs>
       
          

        


        

      Looking for last minute shopping deals?  Find them fast with Yahoo! Search. <http://us.rd. yahoo.com/ evt=51734/ *http://tools. search.yahoo. com/newsearch/ category. php?category= shopping>
       
          



      Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now.

    • David A Barrett
      ... There are elements of Scrum (and Agile in general) that address the interaction of the Team with the End Users. The approach that we use, which I believe
      Message 62 of 62 , Mar 10, 2008
      • 0 Attachment
        >OK, the poor pigs and chickens have had their time. Instead of
        >interpreting Boris' post in a 0/1 perspective, I would like to extract
        >the valuable information and try to fit it into the Scrum framework.

        There are elements of Scrum (and Agile in general) that address the
        interaction of the Team with the End Users. The approach that we use,
        which I believe is essentially what Ken describes in the book, is that the
        programmers sit down with the actual users and discuss what they need. I
        believe that in a large part, this is what items 1 & 3 of the Agile
        Manifesto are talking about.

        From that perspective, we treat the End Users as "resources" and not Team
        members. It would be different if they were on the project full time,
        however.

        We also do the same thing with our web developer. He spends most of his
        time doing content changes and independant development. When we need him
        to do some work on something more involved and related to core systems, we
        usually only need a day or two of his time. So the Team's BA takes
        responsbility for his involvement, makes sure that he understands what's
        needed of him, and reports on his progress at the daily stand-up meeting.

        I think the biggest point to keep in mind is that you want to keep all of
        the distractions away from the Team if you can. This were the SM really
        earns his paycheck. If there are issues with the PO not talking to the End
        Users, or taking the project in the wrong direction, or whatever, then it
        really is up to the SM to be on top of those things and sort them out. The
        Team may notice them first, in which case I would expect them to be raised
        as impediments at a scrum, and then the SM is supposed to take it from
        there and stop it from further distracting the Team.

        So as far as implementing Scrum goes, I'd pretty much lay it all on the SM.
        He's the one who's supposed to understand how it all fits together, and
        he's the one that the Team needs to count on to make sure that it is, in
        fact, fitting together properly. The idea is to make sure that the needs
        of the chickens are looked after, but at the same time keep them from
        distracting the Team.

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