Remote Customer, Remote Developers and a Project in Crisis

Posted by Vikas Hazrati on Jun 29, 2010

Sections

Process & Practices

Topics

Collaboration ,

Agile Techniques ,

Agile

Tags

Offshoring ,

Distributed Teams

Though collocation is one of the prime recommendations of Agile, more and more projects are executed in a manner in which the teams are distributed. Safari Asad started an interesting discussion on the Scrum Development group to discuss about a project in crisis, which not only had a remote customer but also had remote developers.

Asad, described the situation as it degraded from good to bad to worse. The problems started when the team moved back from the customer site due to budget constraints. According to Asad, since then they have been trying to deliver the software but the customer keeps coming back with a huge list of errors and re-opened defects. Asad mentioned that one of the other big problems in the project was remote development. All his developers were working from home and he was not sure if the assigned bugs were getting resolved in the new code base.

When the customer sends the bug list I send the bugs to developers. The developers solve (or spuriously solve) their bugs and give back the new source to me . I compile it and create a patched version.

Though, it was established during the discussion that the team was either not following Agile or not following it in the right way, Asad wanted to seek suggestions by which he could salvage the project.

Mark suggested that a way to save the current project would be by writing a load of acceptance tests and executing them before making a release to the customer. This would depend a lot on the technical debt in the system but is a perfect way to ensure that the software which is being delivered is of the right quality.

According to Roy Morien, one of the fundamental problems in this situation seemed to be the responsibility of testing software and ensuring that the bugs were solved. If the developers were not responsible then they could send back code which had no guarantee of being 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?

Roy also suggested that Asad should gather the new software, test it and demo it at the customer site to get immediate and valid feedback.

Bachan Anand emphasized on the importance of honest communication. According to him, the team should move ahead now in a positive way if they wanted to save the project.

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.

Pete Ruth outlined a comprehensive strategy to salvage the project. According to Pete, the customer would have to be convinced that the software can be fixed in a quick and cost effective way. He suggested the following list of techniques which have been helpful for him in the past

• Set up a "key user" at the customer site.
• Set up a remote access facility so you can see what's happening with the software at the customer site.
• Consider modifying your software to include special test functions that can be executed via keyboard shortcuts or software switches. This would help in identifying the problems if the remote access is not available
• Consider using remote access software between you and your remote developers
• Consider modularizing your software to isolate and centralize important functions
• Minimize the complexity of your software through code re-use wherever possible

Jeff suggested that blaming everything on remote customers and remote developers is just a way to find excuses. According to him, he has done several projects in distributed mode and those have had excellent results. The real solution is a commitment to succeed by both the team and the organization.

Thus, most members in the discussion did not see distributed development as the problem. Most of them were of the opinion that having a remote client or doing remote development was not an issue. The pains of distributed development were only symptoms of incorrect execution. The key to success in a remote project is to augment the right agile practices with the right tooling and have a commitment to succeed.

1. Back to top

   Agile w/o automated test suite ?

   by Dorel Vaida

   Maybe they are agile in the sense that they are young and have good reflexes, right ?

   Reply

2. Back to top

   The process sounds broken

   by Alex VanLaningham

   I have about 3 years distributed scrum experience at a management level position of such distrubuted teams. I am much closer to a pig than a chicken on these projects, and am very technical and could replace a developer on the team if required. I can say distributed scrum is very difficult and requires the perfect mix of everything to implement it with great success. In my opinion the number one thing is trust, which appears to be lost at the moment. Putting things in place to re-establish trust is crucial. Scrum is built on trust.
   
   The best would be to try and inspire the customer to go sit with the dev team for a while, but that may be difficult, definitely worth asking. From a very limited view point, it sounds like many things are broken in your processes, but without more information I would only be speculating. Again, I say focus on what you can do to re-establish trust, tell the client this is what your goal is. Ask the client what they think you should do, get them involved in solving the problem. Explain the project is very unlikely to be a success without this trust. Good luck.
   
   Alex VanLaningham
   www.forwardvisibility.com

   Reply

• Older >