Remote Customer, Remote Developers and a Project in Crisis
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.
Agile w/o automated test suite ?
The process sounds broken
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.