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

Re: [scrumdevelopment] Remote Customer

Expand Messages
  • Bachan Anand
    Hi Asad, Appreciate you reaching out and seeking support and perspective from other . It takes a lot of courage to do that . Yes I have been in similar
    Message 1 of 17 , May 26, 2010
    • 0 Attachment
      Hi Asad,

      Appreciate you reaching out and seeking support and perspective from
      other . It takes a lot of courage to do that .

      Yes I have been in similar situations and what has helped is
      transparency and being open to solutions .

      What would be the solution from your perspective and also from the
      customers perspective . What has happened has happened , the only way
      I could see this solved is to first accept what has happened and then
      look for solution .

      So the first step would be come up with a solution to save this
      project that is acceptable first and foremost to the customer after
      communicating to them clearly the situation the project is in now.

      Would like hear your thoughts on whether that is already done .

      Everyone problem has a solution , don't give up, be open to solutions.


      -Bachan

      On 5/26/10, Asad <safari_asad@...> wrote:
      > Hi Folks,
      >
      > We are working on a project that Customer is on other State. In start of
      > project we worked on Customer site in their state. after Completing 70% or
      > 80% of project we decided to leave customer site Because Customer Couldn't
      > pay our accommodation Cost and we come back to our Office and release
      > software remotely to customer. After Some works we done all requirements of
      > Software and we release the software to customer. Customer after test the
      > software , send a big list of errors and bugs to us.
      >
      > We Solve the bugs and send patched version to customer But customer after
      > test the software ,send a big list of errors and bugs Again . There's a big
      > iterative. Sometimes We Fixed Bug "A" , but Customer say that this Bug still
      > exist on software. or other problems.
      >
      > I think we are in loop . the loop what doesn't has a finish.
      >
      > We Should Done project 2 month ago but the project is continued And it's not
      > finished yet.
      >
      >
      > If you have similar experience , please Guide us .
      >
      >
      > Cheers
      >
      >
    • PeteCRuth@aol.com
      Sounds like you ve got process problems from A to Z. Much of the problems you re experiencing might not have happened at all if you were doing real agile
      Message 2 of 17 , May 26, 2010
      • 0 Attachment
        Sounds like you've got process problems from A to Z. Much of the problems you're experiencing might not have happened at all if you were doing "real" agile development, but you need help getting through the immediate stuff.
         
        You can fix the software, but you've got to convince the customer that you can do it quickly and cost-effectively. Assuming you can do that, here are some things you can do to get back on track. For what it's worth, I've been using these techniques successfully for quite some time, as I'm certain that many members of this group have as well. Nonetheless, here goes:
         
        1. Set up a "key user" at the customer site. This person would be the most knowledgeable user, or the one who can best follow directions. Under the best of circumstances, this user would report problems and implement your solutions. Starting with a single point of contact minimizes distractions; you can always enlarge the contact list later.
         
        2. Set up a remote access facility so you can see what's happening with the software at the customer site. Seeing is believing, anything else is second-hand. You need to see how the software is actually being used. There are a number of very good products that satisfy this need; pick one and implement it. In addition to debugging problems, you can use it to transfer fixes to the software, and for training your key user on updates. This facility can be bi-directional; you can use it to demonstrate fixes and updates on your development version of the software before implementing them on the customer system.
         
        3. Consider modifying your software to include special test functions that can be executed via keyboard shortcuts or software switches. When the chips are down, and the customer is breathing down your neck for a fix, sometimes just being able to verify the code path can be helpful. These are even more important in the absence of a remote access facility. Under the worst of circumstances, if you aren't able to use a remote access product, your key user can execute the tests, print the results and fax them to you, or even read them to you over the phone. You can always take the tests out when you're sure they're not needed. (It's always better to be able to say, "We've run our built-in tests to help us identify the problem", than "We'll put some tests in", etc. after the fact). It's even better to be able to demonstrate this during your initial software demos. Many product developers don't like to bring up potential failure scenarios during the sales cycle, but I'm seeing buyers becoming more and more interested in software support over the years, as  software is getting increasing complex and expensive, and tends to be in place longer than in the past. Customers have a fetish for reliability, and after that, for quick problem identification and resolution. Even today, many developers have a thousand reasons why they don't like to consider anything that might be considered "defensive" development strategies; many of these folks, or their customers, often become my best customers later. Software failures can be extremely disruptive, and can even cause companies to fail. Demonstrating that you're thinking ahead about ways to preserve their investment is becoming more important than ever before. There's not much worse for a developer than having to "buy back" a dissatisfied customer's trust and good will after a bad failure and a botched recovery. You may end up sitting across the table from someone who can't afford to throw you out for your misdeeds for far longer than you'd care to.
         
        4. You should consider using remote access software between you and your remote developers, so that you can verify the operation of the software before they transmit the final version to you. As long as you're doing the final test and integration, they're not necessarily incented to ensure that the software is properly tested. Again, seeing is believing. In the absence of replicating your development environment on your developers' systems, you may have to create a test environment for their systems to properly test their work, but it will pay huge dividends in more reliable software, and save you loads of time.    
         
        5. If you haven't already done so, consider modularizing your software to isolate and centralize important functions, so you don't have to go rooting around the code to find all the places that a specific function is implemented. If you use a particular code block in several places, even with minor conditioning before and/or after execution, consider creating one module for which separate code paths can be selected via parameters. I often use this method as part of the "special tests" mentioned above. This can often be accomplished with only minimal impact on module size, if that is a constraint.   
         
        6. One of the best ways I've found to "head-off" problems in advance is to minimize the complexity of your software through code re-use wherever possible, from simple code fragments to the module level. Make re-use a priority; it pays substantial dividends in development time, reliability and problem identification and debugging. There seems to be some residual resistance to extensive code re-use in many quarters; I urge you to reject this notion. I'd be surprised if more than 25% of any new system I develop is entirely new code, but I'm careful not to go too far afield in the jobs I take on. (For the past 10-15 years, most of my work is upgrades to existing systems, new applications for existing clients, or through referrals by existing clients). When you're just getting started in software development, just about every new line of code you write is a potential problem waiting to bite you in the butt. I've spent a good part of my career fixing and supporting software developed by others, using the methods described above. For my money, if you're not concentrating on eliminating problems by not letting them into the software from the beginning, you might not be understanding your customers and users. 
         
        Product development is difficult, but it can be nearly impossible when you're doing it from a thousand miles away because something broke, or there was some misunderstanding about what it should do or how the customer would use it. The best problems are those that occur long before you've sold to your first customer. because you've already experienced or considered them. You can't identify and fix every conceivable problem up front, but even a minimal amount of work on maintenance and support facilities and strategies up front can be very beneficial.  
         
        That's probably enough (or more than enough) food for thought for now.
         
        Regards,
         
        Pete
         
         
         
        In a message dated 5/26/2010 7:19:07 A.M. Pacific Daylight Time, safari_asad@... writes:
         

        Sure , it's not an agile project .  in first it's agile but in last it's not agile. We Don't have Automate test and it's our Big problem .

        The Customer Doesn't accept our releases and say that I can't test it more . I say that you are not a tester but he say that: "I Can't pay for a bad Software."

        We started other projects and this project being suspended . What we Can do for this project? We are in big problem.

        Safari Asad
        Software Project Manager, Team Leader, Agile And Scrum Coach
        http://sirasad. wordpress. com

        --- On Wed, 5/26/10, woynam <woyna@argonne. com> wrote:

        From: woynam <woyna@argonne. com>
        Subject: [scrumdevelopment] Re: Remote Customer
        To: scrumdevelopment@ yahoogroups. com
        Date: Wednesday, May 26, 2010, 9:46 AM

         


        Are you sure you're doing agile development? If you were, and you had completed 70% to 80% of the project, your customer would have been happy with the software in its state when you left.

        Did you have automated acceptance tests? Did you have working software every iteration? Did the customer review the working software, and provide guidance?

        I find it hard to believe that a team practicing agile development, working with the customer, delivering tested software acceptable to the customer each iteration, would suddenly start producing junk when they got back home.

        The root of the problem must have existed at the customer sight, assuming you're following the same development model back at the home office.

        Mark

        --- In scrumdevelopment@ yahoogroups. com, "Asad" <safari_asad@ ...> wrote:
        >
        > Hi Folks,
        >
        > We are working on a project that Customer is on other State. In start of project we worked on Customer site in their state. after Completing 70% or 80% of project we decided to leave customer site Because Customer Couldn't pay our accommodation Cost and we come back to our Office and release software remotely to customer. After Some works we done all requirements of Software and we release the software to customer. Customer after test the software , send a big list of errors and bugs to us.
        >
        > We Solve the bugs and send patched version to customer But customer after test the software ,send a big list of errors and bugs Again . There's a big iterative. Sometimes We Fixed Bug "A" , but Customer say that this Bug still exist on software. or other problems.
        >
        > I think we are in loop . the loop what doesn't has a finish.
        >
        > We Should Done project 2 month ago but the project is continued And it's not finished yet.
        >
        >
        > If you have similar experience , please Guide us .
        >
        >
        > Cheers
        >


      • Victor Hugo de Oliveira
        I ll give my two cents on this one. Firstly, you need to have a Product Backlog with the remaining items prioritized. In your next delivery, be sure you get
        Message 3 of 17 , May 26, 2010
        • 0 Attachment
          I'll give my two cents on this one.

          Firstly, you need to have a Product Backlog with the remaining items prioritized. In your next delivery, be sure you get the most important ones, and above all, be sure you actually get them. The client must see what you are doing in order to consider something done.

          To be sure of that, there is no way the developers interacting with you through source code is going to work.
          The team needs to work together and talk to the customer. They need to make sure the customer sees the same thing that they do.

          It seems to me that the customer and the team have become too far apart (not only physically).
          Just choose the first item, get the team to communicate within and with the customer and try to solve that one. Be a facilitator to them, not an intermediary.

          Help this helps you.

          Best Regards,
          Victor

          On Wed, May 26, 2010 at 2:34 PM, <PeteCRuth@...> wrote:
           

          Sounds like you've got process problems from A to Z. Much of the problems you're experiencing might not have happened at all if you were doing "real" agile development, but you need help getting through the immediate stuff.
           
          You can fix the software, but you've got to convince the customer that you can do it quickly and cost-effectively. Assuming you can do that, here are some things you can do to get back on track. For what it's worth, I've been using these techniques successfully for quite some time, as I'm certain that many members of this group have as well. Nonetheless, here goes:
           
          1. Set up a "key user" at the customer site. This person would be the most knowledgeable user, or the one who can best follow directions. Under the best of circumstances, this user would report problems and implement your solutions. Starting with a single point of contact minimizes distractions; you can always enlarge the contact list later.
           
          2. Set up a remote access facility so you can see what's happening with the software at the customer site. Seeing is believing, anything else is second-hand. You need to see how the software is actually being used. There are a number of very good products that satisfy this need; pick one and implement it. In addition to debugging problems, you can use it to transfer fixes to the software, and for training your key user on updates. This facility can be bi-directional; you can use it to demonstrate fixes and updates on your development version of the software before implementing them on the customer system.
           
          3. Consider modifying your software to include special test functions that can be executed via keyboard shortcuts or software switches. When the chips are down, and the customer is breathing down your neck for a fix, sometimes just being able to verify the code path can be helpful. These are even more important in the absence of a remote access facility. Under the worst of circumstances, if you aren't able to use a remote access product, your key user can execute the tests, print the results and fax them to you, or even read them to you over the phone. You can always take the tests out when you're sure they're not needed. (It's always better to be able to say, "We've run our built-in tests to help us identify the problem", than "We'll put some tests in", etc. after the fact). It's even better to be able to demonstrate this during your initial software demos. Many product developers don't like to bring up potential failure scenarios during the sales cycle, but I'm seeing buyers becoming more and more interested in software support over the years, as  software is getting increasing complex and expensive, and tends to be in place longer than in the past. Customers have a fetish for reliability, and after that, for quick problem identification and resolution. Even today, many developers have a thousand reasons why they don't like to consider anything that might be considered "defensive" development strategies; many of these folks, or their customers, often become my best customers later. Software failures can be extremely disruptive, and can even cause companies to fail. Demonstrating that you're thinking ahead about ways to preserve their investment is becoming more important than ever before. There's not much worse for a developer than having to "buy back" a dissatisfied customer's trust and good will after a bad failure and a botched recovery. You may end up sitting across the table from someone who can't afford to throw you out for your misdeeds for far longer than you'd care to.
           
          4. You should consider using remote access software between you and your remote developers, so that you can verify the operation of the software before they transmit the final version to you. As long as you're doing the final test and integration, they're not necessarily incented to ensure that the software is properly tested. Again, seeing is believing. In the absence of replicating your development environment on your developers' systems, you may have to create a test environment for their systems to properly test their work, but it will pay huge dividends in more reliable software, and save you loads of time.    
           
          5. If you haven't already done so, consider modularizing your software to isolate and centralize important functions, so you don't have to go rooting around the code to find all the places that a specific function is implemented. If you use a particular code block in several places, even with minor conditioning before and/or after execution, consider creating one module for which separate code paths can be selected via parameters. I often use this method as part of the "special tests" mentioned above. This can often be accomplished with only minimal impact on module size, if that is a constraint.   
           
          6. One of the best ways I've found to "head-off" problems in advance is to minimize the complexity of your software through code re-use wherever possible, from simple code fragments to the module level. Make re-use a priority; it pays substantial dividends in development time, reliability and problem identification and debugging. There seems to be some residual resistance to extensive code re-use in many quarters; I urge you to reject this notion. I'd be surprised if more than 25% of any new system I develop is entirely new code, but I'm careful not to go too far afield in the jobs I take on. (For the past 10-15 years, most of my work is upgrades to existing systems, new applications for existing clients, or through referrals by existing clients). When you're just getting started in software development, just about every new line of code you write is a potential problem waiting to bite you in the butt. I've spent a good part of my career fixing and supporting software developed by others, using the methods described above. For my money, if you're not concentrating on eliminating problems by not letting them into the software from the beginning, you might not be understanding your customers and users. 
           
          Product development is difficult, but it can be nearly impossible when you're doing it from a thousand miles away because something broke, or there was some misunderstanding about what it should do or how the customer would use it. The best problems are those that occur long before you've sold to your first customer. because you've already experienced or considered them. You can't identify and fix every conceivable problem up front, but even a minimal amount of work on maintenance and support facilities and strategies up front can be very beneficial.  
           
          That's probably enough (or more than enough) food for thought for now.
           
          Regards,
           
          Pete
           
           
           
          In a message dated 5/26/2010 7:19:07 A.M. Pacific Daylight Time, safari_asad@... writes:
           

          Sure , it's not an agile project .  in first it's agile but in last it's not agile. We Don't have Automate test and it's our Big problem .


          The Customer Doesn't accept our releases and say that I can't test it more . I say that you are not a tester but he say that: "I Can't pay for a bad Software."

          We started other projects and this project being suspended . What we Can do for this project? We are in big problem.

          Safari Asad
          Software Project Manager, Team Leader, Agile And Scrum Coach
          http://sirasad.wordpress.com

          --- On Wed, 5/26/10, woynam <woyna@...> wrote:

          From: woynam <woyna@...>
          Subject: [scrumdevelopment] Re: Remote Customer
          To: scrumdevelopment@yahoogroups.com
          Date: Wednesday, May 26, 2010, 9:46 AM

           


          Are you sure you're doing agile development? If you were, and you had completed 70% to 80% of the project, your customer would have been happy with the software in its state when you left.

          Did you have automated acceptance tests? Did you have working software every iteration? Did the customer review the working software, and provide guidance?

          I find it hard to believe that a team practicing agile development, working with the customer, delivering tested software acceptable to the customer each iteration, would suddenly start producing junk when they got back home.

          The root of the problem must have existed at the customer sight, assuming you're following the same development model back at the home office.

          Mark

          --- In scrumdevelopment@yahoogroups.com, "Asad" <safari_asad@...> wrote:
          >
          > Hi Folks,
          >
          > We are working on a project that Customer is on other State. In start of project we worked on Customer site in their state. after Completing 70% or 80% of project we decided to leave customer site Because Customer Couldn't pay our accommodation Cost and we come back to our Office and release software remotely to customer. After Some works we done all requirements of Software and we release the software to customer. Customer after test the software , send a big list of errors and bugs to us.
          >
          > We Solve the bugs and send patched version to customer But customer after test the software ,send a big list of errors and bugs Again . There's a big iterative. Sometimes We Fixed Bug "A" , but Customer say that this Bug still exist on software. or other problems.
          >
          > I think we are in loop . the loop what doesn't has a finish.
          >
          > We Should Done project 2 month ago but the project is continued And it's not finished yet.
          >
          >
          > If you have similar experience , please Guide us .
          >
          >
          > Cheers
          >





          --
          Victor Hugo de Oliveira

          Scrum & Agile Blog
          http://csvo.wordpress.com

          Concrete Solutions
          new edition: http://www.concretesolutions.com.br/index_eng/

          +55 21 2240 2030
          +55 11 4119 0449
          R. São José 90, 2121
          20010-020
          Rio de Janeiro, RJ, Brasil
        • Jeff
          Hi, In my view, virtually every situation has a solution. If there is no solution, then there is no problem - it s just fact. Where do you believe you stand
          Message 4 of 17 , May 26, 2010
          • 0 Attachment
            Hi,

            In my view, virtually every situation has a solution. If there is no solution, then there is no problem - it's just fact. Where do you believe you stand in that mix?

            For the most part, I'll skip all the 'should have' theory and just focus on solutions. Except, I must comment on at least this one, where you later write:

            >>We started other projects and this project being suspended . What we Can do for this project? We are in big problem.<<

            Who suspended it, you or the customer, or both? Saying 'this is a big problem' - I am disheartened to see you moving on to other projects. How do you know the next projects will not have the same result? Where is the shared learning? Where is the commitment to the customer? I'm guessing that no matter what you do, this will certainly not turn into a "good customer reference" - but you perhaps have a chance to save some face.

            Your statements of:
            "remote customer - another state" and >>I think my great problem is my Developers . My Developers are home workers. they work in his home
            When Customer send bug list i send the bugs for developers. the developers solve (or spurious solve) their bugs and give back the new source to me . And I Compile it and create a patched version. I think it's our big problem. Can We recovery this project? <<

            All of that are just excuses trying to find the blame. I have done many projects where no one was collocated and I never saw the customer face to face that had excellent results. I am not advocating that approach, but it is not the root cause - although the real problem(s) may be greatly heightened without co-location.

            In another reply, petecruth writes >>As long as you're doing the final test and integration, they're not necessarily incented to ensure that the software is properly tested.<< I have a bigger question - who is testing this end to end before it gets sent to the customer? The process appears broken there as a start - and the definition of "done" is not universally agreed upon. Sure, I don't know the details, but I have seen this so many times from developers who simply do not test. There are probably many more factors, and probably a lot of miscommunication and lack of root cause analysis.

            Solving the problem is going to take commitment, and agreed upon definition of "done". If the different locations are really an issue, remote access may help - or better yet, send one person from your team (or you) to the client site to see firsthand - and be in constant communication with the development team with remote access. It would go along way as commitment in the customer's eyes. You are obviously already way behind schedule and over budget - the only real question is your organization is committed to fixing it (even at additional cost without reimbursement), and if the customer has already given up and lost all faith or not.

            The team must commit - it's that simple. And why are you asking the question here? The question should be posed to the team. And if the team can't figure it out - it was doomed from the start.

            Jeff

            --- In scrumdevelopment@yahoogroups.com, "Asad" <safari_asad@...> wrote:
            >
            > Hi Folks,
            >
            > We are working on a project that Customer is on other State. In start of project we worked on Customer site in their state. after Completing 70% or 80% of project we decided to leave customer site Because Customer Couldn't pay our accommodation Cost and we come back to our Office and release software remotely to customer. After Some works we done all requirements of Software and we release the software to customer. Customer after test the software , send a big list of errors and bugs to us.
            >
            > We Solve the bugs and send patched version to customer But customer after test the software ,send a big list of errors and bugs Again . There's a big iterative. Sometimes We Fixed Bug "A" , but Customer say that this Bug still exist on software. or other problems.
            >
            > I think we are in loop . the loop what doesn't has a finish.
            >
            > We Should Done project 2 month ago but the project is continued And it's not finished yet.
            >
            >
            > If you have similar experience , please Guide us .
            >
            >
            > Cheers
            >
          • Richard Whitten (Cont)
            Hi Asad, As you can see from the responses, you are not using Agile practices, or you would not be here . A possible way through this is to demo the software
            Message 5 of 17 , May 26, 2010
            • 0 Attachment

              Hi Asad,

               

              As you can see from the responses, you are not using Agile practices, or you would not be here . 

               

              A possible way through this is to demo the software in its current state with everyone in attendance (at least in a conference).  This includes developers, QA and the customers.  As you demo the software, document things that do work to the customer’s satisfaction.  Get agreement, preferably in the demo that this is the definitive list of items to fix for customer acceptance of the software.  Then fix the software and test thoroughly before turning over to the customer.  This may get you out of the loop that you are in, unless there are other things going on here.

               

              Rich

               

            • Roy Morien
              It seems to me that the fundamental problem here is who is responsible for testing the software, and ensuring the bugs really are solved? . If not the
              Message 6 of 17 , May 26, 2010
              • 0 Attachment
                It seems to me that the fundamental problem here is 'who is responsible for testing the software, and ensuring the bugs really are solved?'.
                 
                If not the developers, then they will quite happily send you back 'fixed' software that has no guarantee of really being fixed. AND if they do not have the full system available to them, they cannot test to see if their bug-fixes disrupt anything else in the system.
                 
                Is the customer qualified to do that testing, to the point of guaranteeing the correctness of the bug-fixes? Why can they claim that a bugs not fixed, when you think it is fixed?

                If you are responsible for testing, then the developers have no real incentive to ensure they have done the work correctly. They can apparently rely on you to find out, and just need to say 'Damn, I thought that was working. I'll fix it up by tomorrow!". WHen do they get paid for the work of fixing the bug?
                 
                Also, it is certainly a difficult and sub-optimal situation for you to have remote developers. That seems far more problematic to me tan remote users.
                 
                Regards,
                Roy Morien

                To: scrumdevelopment@yahoogroups.com
                From: safari_asad@...
                Date: Wed, 26 May 2010 14:57:18 +0000
                Subject: [scrumdevelopment] Re: Remote Customer

                 
                Thanks Mark

                I use Agile Development in my new projects . but in this project our agile get wrong.

                I have many problem in this project .

                I think my great problem is my Developers . My Developers are home workers. they work in his home .

                When Customer send bug list i send the bugs for developers. the developers solve (or spurious solve) their bugs and give back the new source to me . And I Compile it and create a patched version.

                I think it's our big problem. Can We recovery this project?

                cheers

                --- In scrumdevelopment@yahoogroups.com, "woynam" <woyna@...> wrote:
                >
                >
                > It doesn't sound like you can do much for this project, other than to use it as a learning experience. As you discovered, if you don't have well-defined (automated)acceptance tests, written with the assistance of the customer, then you run the risk of delivering buggy code that's unacceptable to the customer.
                >
                > Are the other projects doing the same thing? If so, then they're likely to fail as well.
                >
                > My suggestion, and I'm sure it'll be backed by others here, is to use agile development.
                >
                > It may be possible to save the current project, but it will involve a lot of test writing, and I'm not sure if you're going to get the OK to do it. You may discover that the amount of technical debt is massive.
                >
                > Again, the way to avoid technical debt is to test early and often, and focus on improving the code base along the way.
                >
                > Mark
                >
                > --- In scrumdevelopment@yahoogroups.com, Asad Safari <safari_asad@> wrote:
                > >
                > > Sure , it's not an agile project .  in first it's agile but in last it's not agile. We Don't have Automate test and it's our Big problem .
                > >
                > > The Customer Doesn't accept our releases and say that I can't test it more . I say that you are not a tester but he say that: "I Can't pay for a bad Software."
                > >
                > > We started other projects and this project being suspended . What we Can do for this project? We are in big problem.
                > >
                > > Safari Asad
                > >
                > > Software Project Manager, Team Leader, Agile And Scrum Coach
                > >
                > > http://sirasad.wordpress.com
                > >
                > > --- On Wed, 5/26/10, woynam <woyna@> wrote:
                > >
                > > From: woynam <woyna@>
                > > Subject: [scrumdevelopment] Re: Remote Customer
                > > To: scrumdevelopment@yahoogroups.com
                > > Date: Wednesday, May 26, 2010, 9:46 AM
                > >
                > >
                > >
                > >
                > >
                > >
                > >
                > >  
                > >
                > >
                > >
                > >
                > >
                > >
                > >
                > >
                > >
                > >
                > >
                > > Are you sure you're doing agile development? If you were, and you had completed 70% to 80% of the project, your customer would have been happy with the software in its state when you left.
                > >
                > >
                > >
                > > Did you have automated acceptance tests? Did you have working software every iteration? Did the customer review the working software, and provide guidance?
                > >
                > >
                > >
                > > I find it hard to believe that a team practicing agile development, working with the customer, delivering tested software acceptable to the customer each iteration, would suddenly start producing junk when they got back home.
                > >
                > >
                > >
                > > The root of the problem must have existed at the customer sight, assuming you're following the same development model back at the home office.
                > >
                > >
                > >
                > > Mark
                > >
                > >
                > >
                > > --- In scrumdevelopment@yahoogroups.com, "Asad" <safari_asad@> wrote:
                > >
                > > >
                > >
                > > > Hi Folks,
                > >
                > > >
                > >
                > > > We are working on a project that Customer is on other State. In start of project we worked on Customer site in their state. after Completing 70% or 80% of project we decided to leave customer site Because Customer Couldn't pay our accommodation Cost and we come back to our Office and release software remotely to customer. After Some works we done all requirements of Software and we release the software to customer. Customer after test the software , send a big list of errors and bugs to us.
                > >
                > > >
                > >
                > > > We Solve the bugs and send patched version to customer But customer after test the software ,send a big list of errors and bugs Again . There's a big iterative. Sometimes We Fixed Bug "A" , but Customer say that this Bug still exist on software. or other problems.
                > >
                > > >
                > >
                > > > I think we are in loop . the loop what doesn't has a finish.
                > >
                > > >
                > >
                > > > We Should Done project 2 month ago but the project is continued And it's not finished yet.
                > >
                > > >
                > >
                > > >
                > >
                > > > If you have similar experience , please Guide us .
                > >
                > > >
                > >
                > > >
                > >
                > > > Cheers
                > >
                > > >
                > >
                >




                Meet local singles online. Browse profiles for FREE!
              • Roy Morien
                Hi Asad, Is there any reason why you can t gather together the new software that has been fixed and hopefully tested properly, and go to the Customer site
                Message 7 of 17 , May 26, 2010
                • 0 Attachment
                  Hi Asad,
                   
                  Is there any reason why you can't gather together the new software that has been 'fixed' and hopefully tested properly, and go to the Customer site and demonstrate it there. This will give you the opportunity to see first hand what is happening, and get immediate feedback from the customer.
                   
                  I was once in this situation where a remote customer was always coming back to me to tell me the still had problems, and new problems cropping up, even though we could not findthe problem in the software. So I actually went to the customer site
                   
                  Interesting situation! Yes, indeed, they had those problems that we couldn't see. So I had to try to track down what was happening and why the difference. ABout 3pm in he afternoon, everything suddenly started to go dim ... te lights dimmed, the airconditioners slowed down ... I could even here the main computer disk unit slow down (yeah, you could often hear the disk in those days).
                   
                  Immediately things started to go wrong with the running software ... bugs happened! I was quite horrieif about this, and asked what the hell just happened? They tol me that a huge machine in a monster open cut coal mine 30 kilometres away just restarted at the beginning of the new work shift. It was so huge (andwas electrically driven) that it temporilly drained the power grid of power ... it happened twice a day every day.
                   
                  So, the solution to the many software bugs was to install power protection. They did, we fixed up the software and especially the broken links in the database, and every thing worked from thereon in.
                   
                  Which also raises nother interesting problem about testing. I call it 'debugging your data', not debugging your code. Crappy data left over from previous testing and previous bugs that cause your perfectly good software to behave erratically. Hours can be spent debugging bug-free code becuase the data is rubbish.
                   
                  Regards,
                  Roy Morien
                   

                  To: scrumdevelopment@yahoogroups.com
                  From: safari_asad@...
                  Date: Wed, 26 May 2010 14:57:18 +0000
                  Subject: [scrumdevelopment] Re: Remote Customer

                   
                  Thanks Mark

                  I use Agile Development in my new projects . but in this project our agile get wrong.

                  I have many problem in this project .

                  I think my great problem is my Developers . My Developers are home workers. they work in his home .

                  When Customer send bug list i send the bugs for developers. the developers solve (or spurious solve) their bugs and give back the new source to me . And I Compile it and create a patched version.

                  I think it's our big problem. Can We recovery this project?

                  cheers

                  --- In scrumdevelopment@yahoogroups.com, "woynam" <woyna@...> wrote:
                  >
                  >
                  > It doesn't sound like you can do much for this project, other than to use it as a learning experience. As you discovered, if you don't have well-defined (automated)acceptance tests, written with the assistance of the customer, then you run the risk of delivering buggy code that's unacceptable to the customer.
                  >
                  > Are the other projects doing the same thing? If so, then they're likely to fail as well.
                  >
                  > My suggestion, and I'm sure it'll be backed by others here, is to use agile development.
                  >
                  > It may be possible to save the current project, but it will involve a lot of test writing, and I'm not sure if you're going to get the OK to do it. You may discover that the amount of technical debt is massive.
                  >
                  > Again, the way to avoid technical debt is to test early and often, and focus on improving the code base along the way.
                  >
                  > Mark
                  >
                  > --- In scrumdevelopment@yahoogroups.com, Asad Safari <safari_asad@> wrote:
                  > >
                  > > Sure , it's not an agile project .  in first it's agile but in last it's not agile. We Don't have Automate test and it's our Big problem .
                  > >
                  > > The Customer Doesn't accept our releases and say that I can't test it more . I say that you are not a tester but he say that: "I Can't pay for a bad Software."
                  > >
                  > > We started other projects and this project being suspended . What we Can do for this project? We are in big problem.
                  > >
                  > > Safari Asad
                  > >
                  > > Software Project Manager, Team Leader, Agile And Scrum Coach
                  > >
                  > > http://sirasad.wordpress.com
                  > >
                  > > --- On Wed, 5/26/10, woynam <woyna@> wrote:
                  > >
                  > > From: woynam <woyna@>
                  > > Subject: [scrumdevelopment] Re: Remote Customer
                  > > To: scrumdevelopment@yahoogroups.com
                  > > Date: Wednesday, May 26, 2010, 9:46 AM
                  > >
                  > >
                  > >
                  > >
                  > >
                  > >
                  > >
                  > >  
                  > >
                  > >
                  > >
                  > >
                  > >
                  > >
                  > >
                  > >
                  > >
                  > >
                  > >
                  > > Are you sure you're doing agile development? If you were, and you had completed 70% to 80% of the project, your customer would have been happy with the software in its state when you left.
                  > >
                  > >
                  > >
                  > > Did you have automated acceptance tests? Did you have working software every iteration? Did the customer review the working software, and provide guidance?
                  > >
                  > >
                  > >
                  > > I find it hard to believe that a team practicing agile development, working with the customer, delivering tested software acceptable to the customer each iteration, would suddenly start producing junk when they got back home.
                  > >
                  > >
                  > >
                  > > The root of the problem must have existed at the customer sight, assuming you're following the same development model back at the home office.
                  > >
                  > >
                  > >
                  > > Mark
                  > >
                  > >
                  > >
                  > > --- In scrumdevelopment@yahoogroups.com, "Asad" <safari_asad@> wrote:
                  > >
                  > > >
                  > >
                  > > > Hi Folks,
                  > >
                  > > >
                  > >
                  > > > We are working on a project that Customer is on other State. In start of project we worked on Customer site in their state. after Completing 70% or 80% of project we decided to leave customer site Because Customer Couldn't pay our accommodation Cost and we come back to our Office and release software remotely to customer. After Some works we done all requirements of Software and we release the software to customer. Customer after test the software , send a big list of errors and bugs to us.
                  > >
                  > > >
                  > >
                  > > > We Solve the bugs and send patched version to customer But customer after test the software ,send a big list of errors and bugs Again . There's a big iterative. Sometimes We Fixed Bug "A" , but Customer say that this Bug still exist on software. or other problems.
                  > >
                  > > >
                  > >
                  > > > I think we are in loop . the loop what doesn't has a finish.
                  > >
                  > > >
                  > >
                  > > > We Should Done project 2 month ago but the project is continued And it's not finished yet.
                  > >
                  > > >
                  > >
                  > > >
                  > >
                  > > > If you have similar experience , please Guide us .
                  > >
                  > > >
                  > >
                  > > >
                  > >
                  > > > Cheers
                  > >
                  > > >
                  > >
                  >




                  Australia's #1 job site If It Exists, You'll Find it on SEEK
                • Asad
                  Thank you to all Friends for good Solutions . I Deiced to Invite customer to our state And Rent a Place for compilation the Developers and customer in our Site
                  Message 8 of 17 , May 27, 2010
                  • 0 Attachment
                    Thank you to all Friends for good Solutions .

                    I Deiced to Invite customer to our state And Rent a Place for compilation the Developers and customer in our Site .

                    In first We Want to Find Worked parts of Software and get Customer Agreement about those Parts. So Find Not Worked or Buged parts of Software.At last , Fix the bugs and delivered the working software to customer in our site .


                    Is this Good Solution ?

                    Cheers
                  • Victor Hugo de Oliveira
                    Asad, if you can get the developers and the customer on the same room, odds are you will greatly increase the communication between them. This is just part of
                    Message 9 of 17 , May 27, 2010
                    • 0 Attachment
                      Asad,

                         if you can get the developers and the customer on the same room, odds are you will greatly increase the communication between them.
                         This is just part of the problem, but I think it is a great starting point for the other issues.

                      Best Regards,
                      Victor 

                      On Thu, May 27, 2010 at 4:23 PM, Asad <safari_asad@...> wrote:
                       

                      Thank you to all Friends for good Solutions .

                      I Deiced to Invite customer to our state And Rent a Place for compilation the Developers and customer in our Site .

                      In first We Want to Find Worked parts of Software and get Customer Agreement about those Parts. So Find Not Worked or Buged parts of Software.At last , Fix the bugs and delivered the working software to customer in our site .

                      Is this Good Solution ?

                      Cheers




                      --
                      Victor Hugo de Oliveira

                      Scrum & Agile Blog
                      http://csvo.wordpress.com

                      Concrete Solutions
                      new edition: http://www.concretesolutions.com.br/index_eng/

                      +55 21 2240 2030
                      +55 11 4119 0449
                      R. São José 90, 2121
                      20010-020
                      Rio de Janeiro, RJ, Brasil
                    • Fabiano Macedo
                      It can work but, you need tell to developers for not talk about soluctions terms, just talk about scenarios and workflows. Fabiano Félix Macedo msn :
                      Message 10 of 17 , May 27, 2010
                      • 0 Attachment
                            It can work but, you need tell to developers for not talk about soluctions terms, just talk about scenarios and workflows.
                         
                        Fabiano Félix Macedo



                        De: Victor Hugo de Oliveira <victor.oliveira@...>
                        Para: scrumdevelopment@yahoogroups.com
                        Enviadas: Quinta-feira, 27 de Maio de 2010 16:42:52
                        Assunto: Re: [scrumdevelopment] Re: Remote Customer

                         

                        Asad,


                           if you can get the developers and the customer on the same room, odds are you will greatly increase the communication between them.
                           This is just part of the problem, but I think it is a great starting point for the other issues.

                        Best Regards,
                        Victor 

                        On Thu, May 27, 2010 at 4:23 PM, Asad <safari_asad@ yahoo.com> wrote:
                         

                        Thank you to all Friends for good Solutions .

                        I Deiced to Invite customer to our state And Rent a Place for compilation the Developers and customer in our Site .

                        In first We Want to Find Worked parts of Software and get Customer Agreement about those Parts. So Find Not Worked or Buged parts of Software.At last , Fix the bugs and delivered the working software to customer in our site .

                        Is this Good Solution ?

                        Cheers




                        --
                        Victor Hugo de Oliveira

                        Scrum & Agile Blog
                        http://csvo. wordpress. com

                        Concrete Solutions
                        new edition: http://www.concrete solutions. com.br/index_ eng/

                        +55 21 2240 2030
                        +55 11 4119 0449
                        R. São José 90, 2121
                        20010-020
                        Rio de Janeiro, RJ, Brasil

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