At first glance, it may just seem like some companies are doing marketing gimmicks to differentiate themselves from the competition. Let’s leave marketing aside and focus on actual software development here. Is there really a difference in executing a project with a time zone difference? Let’s take a look. Let’s start from the beginning: requirements. So, Agile says that most of the tedious documentation in requirements is replaced by conversations and verbal explanation and documentation is kept only to a necessary level. Then, what happens to the requirements process when time zones start moving? Agile requires constant communication between the customer and the development team. If you don’t change the processes and documentation, this process would simply slow down. Imagine a situation where you only overlap 2 or 3 hours of the workday with your provider. You do a nice long meeting where everyone “understands” the requirements and everyone leaves the conference happy. You go to sleep. Then a developer at your provider thinks up some obscure scenario that no one had thought of before.
Let’s make it a bit worse: the scenario is actually not that obscure and quite possible to happen and the process that was designed does not support it and becomes basically broken, hindering the business to flow through the system. The team would have to wait until you wake up and go to the office to talk about it and figure out what to do. Not very agile is it? They’ve just had to “stand around” generating loads of questions for you for hours and had to wait an entire day to talk to you. Agile software development project requires truly constant communication between the team and the customer. This would allow the customer to be constantly informed of the progress and decisions that are being made in the project. The efficiency of the entire process relies on this, specifically because of the premise of replacing documentation by communication. One way of solving this is to simply “correct” that premise and document more to “make up” for the lack of communication. This would definitely work for requirements. The process would still be slower and a bit more painful, in the sense that you’re back to writing long requirements documents.
The team would also continue to have to manage the cases where requirements don’t explain what must happen under certain conditions (lack of detail of the requirements). The process would go back to more traditional methods where basically a requirements bug would be reported and then corrected. There are definitely ways of getting through this. The question is not really if one or the other works or not. They both work, just with important differences in the process that you must follow to “make up” for the lack of communication. The question is “Is it really worth it?”. Is the offshore provider so different and so much better than the nearshore provider so as to sacrifice response speed and increase the work your team must do to make sure the hundreds of pages of requirements and documentation are correct and cover all the details of the system? Isn’t it more comfortable to be able to just simply pick up the phone and talk to someone and explain things to them?
You will probably be able to tell them more and have more time to focus on meeting your business objectives and being analytical about your new product than focusing on the details described in a document? If you’d like to know more, contact us. We’d be happy to explain in more detail.
More on Perficient Latin America: With more than 30 years of experience, Perficient Latin America specializes in outsourcing and nearshoring software development projects as well as Team Augmentation. Based in Colombia, Mexico, and the US, Perficient Latin America is an agile SCRUM development shop focused on high-quality services.
