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

RE: [scrumdevelopment] UX role in Scrum teams

Expand Messages
  • Roy Morien
    I m with you all the way on this one, Pete. Let me recount a story about this situation. I wanted to be put on the list of system providors for a government
    Message 1 of 14 , Aug 1 12:48 AM
    • 0 Attachment
      I'm with you all the way on this one, Pete.
       
      Let me recount a story about this situation.
       
      I wanted to be put on the list of system providors for a government department. They asked me to show them what I could do ... proof of concept (that I knew what I was doing). So I asked them for the specs of a particular, not very large, system that they were putting out for EOI.
       
      Using my prototyping approach and code generators, I developed the system in a week, and took it back to the government department for evaluation. They were quite bewildered at first to see the system already up and running in a pretty complete form. In fact, they almost seemed a bit miffed that I had done it, almost as if I had already been given the nod to develop the system.
       
      Anyway, they looked at the system with interest, and nodded wisely, and seemed to be quite satisfied with my demonstration of competence and ability to deliver. The told me that they would 'be in touch'. I said, half jokingly, OK, if you pay me $10,000 now I will install the system and you can start using it now. This suggestion was met with some rather dubious looks, and I was asked to submit a formal proposal and quote. I did this, at a price of $10,000 with any follow up fees for extras and extensions, although the system basically already met all their specs. I was happy with $10,000 for a week's work.
       
      I didn't get the job! I heard that another contractor had been given the contract, for a price of $35,000. When I enquired about this, I was told that my system did not meet their standards ... the code did not meet their code standards, and because I had told them that there was no need to modify the code, just regenerate it if changes to the database or the user interface occured, I did not meet the contract requirements of providing source code that their programmers could modify.
       
      This happened a long time ago, and the contract price today would probably be 3 times that in today's dollars, so it wasn't a big job ... , although $100,000+ is not to be sneezed at. but the complete ignorance by the IT people then of prototyping, rapid development methods, code generators etc., was amazing. Unfortunately, that situation has not changed a lot in the intervening years.
       
      This was certainly not the only time that I met IT people who completely failed to understand about these things. I have also had the experience of 'prototype' systems being pounced on by enthusiastic users wanting immediate installation and use, and I had to put them off because I knew the system still lacked needed facilities. The users based their enthusiasm on what they could see.
       
      Lessons to be learned and passed on!
       
      Regards,
      Roy Morien

      To: scrumdevelopment@yahoogroups.com
      From: PeteCRuth@...
      Date: Sun, 1 Aug 2010 03:28:35 -0400
      Subject: Re: [scrumdevelopment] UX role in Scrum teams

       
       
       
      In a message dated 7/31/2010 9:55:58 P.M. Pacific Daylight Time, roymorien@hotmail. com writes:
      I see such interface prototypes as almost being an 'on screen' storyboard. I also see it as being very useful for gaining client acceptance, raising client confidence, and giving a very good impression that the project is going ahead knowledgeably ... but be careful that this is not a mirage.
      Back when I started using prototypes and code generators to accelerate the development process, "real" developers complained that I wasn't playing by the rules. Now when I crank out a prototype to help the team visualize a particular approach, "real" developers complain that I'm not playing by agile rules or Scrum rules. The only group that has virtually never complained about my extensive use of prototypes are the actual users of the systems I build.  Of all the tools in my toolbox, prototypes have always been a very effective means of getting to what users really want. Not surprisingly, many of the prototypes find their way into the final code, and that's by design. So whether it's Scrum-but or Scrum-Butt, it works for my clients.
       
      Regards,
       
      Pete


    • PeteCRuth@aol.com
      I ve been down that road many times, Roy. What surprises me is that even now, it still happens fairly often. I ve mentioned before that my best clients are
      Message 2 of 14 , Aug 1 1:20 AM
      • 0 Attachment
        I've been down that road many times, Roy. What surprises me is that even now, it still happens fairly often. I've mentioned before that my best clients are usually either desperate or daring: they're either up against a looming deadline for a custom application system, or they're intrigued by the approach to "building" software in a fraction of the time it usually takes to do it themselves using more traditional methods. Of course, resistance to change is a hallmark of many fields, and software development is no exception. Scrum and other agile methods are good examples of this: while many Scrum practices have been in use for many years, when they got all rolled up into a comprehensive approach, many cried "foul". Go figure!
         
        Regards,
         
        Pete
         
        In a message dated 8/1/2010 12:51:24 A.M. Pacific Daylight Time, roymorien@... writes:
         

        I'm with you all the way on this one, Pete.
         
        Let me recount a story about this situation.
         
        I wanted to be put on the list of system providors for a government department. They asked me to show them what I could do ... proof of concept (that I knew what I was doing). So I asked them for the specs of a particular, not very large, system that they were putting out for EOI.
         
        Using my prototyping approach and code generators, I developed the system in a week, and took it back to the government department for evaluation. They were quite bewildered at first to see the system already up and running in a pretty complete form. In fact, they almost seemed a bit miffed that I had done it, almost as if I had already been given the nod to develop the system.
         
        Anyway, they looked at the system with interest, and nodded wisely, and seemed to be quite satisfied with my demonstration of competence and ability to deliver. The told me that they would 'be in touch'. I said, half jokingly, OK, if you pay me $10,000 now I will install the system and you can start using it now. This suggestion was met with some rather dubious looks, and I was asked to submit a formal proposal and quote. I did this, at a price of $10,000 with any follow up fees for extras and extensions, although the system basically already met all their specs. I was happy with $10,000 for a week's work.
         
        I didn't get the job! I heard that another contractor had been given the contract, for a price of $35,000. When I enquired about this, I was told that my system did not meet their standards ... the code did not meet their code standards, and because I had told them that there was no need to modify the code, just regenerate it if changes to the database or the user interface occured, I did not meet the contract requirements of providing source code that their programmers could modify.
         
        This happened a long time ago, and the contract price today would probably be 3 times that in today's dollars, so it wasn't a big job ... , although $100,000+ is not to be sneezed at. but the complete ignorance by the IT people then of prototyping, rapid development methods, code generators etc., was amazing. Unfortunately, that situation has not changed a lot in the intervening years.
         
        This was certainly not the only time that I met IT people who completely failed to understand about these things. I have also had the experience of 'prototype' systems being pounced on by enthusiastic users wanting immediate installation and use, and I had to put them off because I knew the system still lacked needed facilities. The users based their enthusiasm on what they could see.
         
        Lessons to be learned and passed on!
         
        Regards,
        Roy Morien


        To: scrumdevelopment@ yahoogroups. com
        From: PeteCRuth@aol. com
        Date: Sun, 1 Aug 2010 03:28:35 -0400
        Subject: Re: [scrumdevelopment] UX role in Scrum teams

         
         
         
        In a message dated 7/31/2010 9:55:58 P.M. Pacific Daylight Time, roymorien@hotmail. com writes:
        I see such interface prototypes as almost being an 'on screen' storyboard. I also see it as being very useful for gaining client acceptance, raising client confidence, and giving a very good impression that the project is going ahead knowledgeably ... but be careful that this is not a mirage.
        Back when I started using prototypes and code generators to accelerate the development process, "real" developers complained that I wasn't playing by the rules. Now when I crank out a prototype to help the team visualize a particular approach, "real" developers complain that I'm not playing by agile rules or Scrum rules. The only group that has virtually never complained about my extensive use of prototypes are the actual users of the systems I build.  Of all the tools in my toolbox, prototypes have always been a very effective means of getting to what users really want. Not surprisingly, many of the prototypes find their way into the final code, and that's by design. So whether it's Scrum-but or Scrum-Butt, it works for my clients.
         
        Regards,
         
        Pete


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