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

Re: Remote Customer

Expand Messages
  • Asad
    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
    Message 1 of 17 , May 26, 2010
    • 0 Attachment
      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
      > >
      > > >
      > >
      >
    • Peter Stevens (calendar)
      Hi Mark, I m skeptical that engineering practices are the place to start (although you will need to go there quickly!) - usually getting the people talking
      Message 2 of 17 , May 26, 2010
      • 0 Attachment
        Hi Mark,

        I'm skeptical that engineering practices are the place to start (although you will need to go there quickly!) - usually getting the people talking (and listening!) to each other is top priority. See: SavingProjects in Crisis.

        Cheers,

        Peter

        On 26.05.10 16:26, woynam 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


        -- 
        Peter Stevens, CSM, CSPO, CSP
        www.scrum-breakfast.com
        tel: +41 44 586 6450 
        
      • 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 3 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 4 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 5 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 6 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 7 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 8 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 9 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 10 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 11 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 12 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.