Recently I have been working on an outsource/remote project on a software solution consisting of both web and mobile parts. As I am always interested in outsource projects, any experience on it is important for me. So I am trying to document my experience on this project in an almost none technical perspective.
- In this sample project we had project management but it was not enough. Not complying sprint patterns was a main issue. New issues were adding to current sprints without noticing that this reduces planning effects.
- A similar issue was losing focus by working tasks outsides of current sprint.
- In some cases, there were tasks which resolved with only 0.5 hour and there were tasks were resolved with about 12 hours. I mean tasks were not broken into same pieces. Some of them were actually more than 1 tasks and some of them could be simply merged with other tasks.
- Too many changes in requirements really caused delays and was hard to apply. I know in agile environments, changes are normal, but I mean too many changes. Consider too many changes in database table structures that caused many other changes in back-end and even APIs.
- This project had enough amounts of documents from first day. But in some parts this was not clear enough. Documentation problem was getting more problematic as project was growing and new people was adding to the project. It was better that question/answers by team members be added to the documentation but it was not. Documentation could be more up-to-date and be more structured.
- I forced to implement soft delete in the system tables but after a while I realized that we were not really needing it. All in all that customer wanted was logging record changes. I am not sure that call it bad communication or letting product owner to take technical decisions.
- Not using full featured ALM tools was causing negative impact on productivity. Having a tool to publish latest versions automatically based on each git push could help us having more up-to-date test server.
- Not all team members were comfortable with written culture of remote working environments. In a team spread in several cities, it was important that any activity logged in Jira, Slack, Emails, … Any member should be able to have information about other works and tasks. This is more important when team members common time are not very large.
- As a team that works in different time zones with different work schedules we had a bad problem that was long wait time between actions. Member A books a bug in bug tracking system, hours or even 1 day later member B want to resolve the bug but need more info, he adds comments but member B see it 1 day later and it is going on. You see resolving a bug can take several days. One of members A or B could have solved this bug with higher problem solving skills. Member A could be able to understand the possible bug by trying more inputs and putting system in more states. And member B could be more successful by thinking on the behalf of A and try to solve the issue with less round trips.
- Team organization was not so ideal. Breaking team to web part and mobile part caused tracking issues harder. We could be more agile if 2 parts was able to run other parts code by themselves. But when in a small team, works are passed via test servers not in source code, then more time is needed to test an even small task.
I believe that this kind of issues have almost 3 roots. Cultural differences that forces us to have different impressions of team roles. For example, from scrum master or back-end developer. Another root is not putting enough time for controlling the team and take actions on weaknesses. And last one in my point of view is that the team has not worked with each other before this. A team needs time to reach its full power. Team members need time to get acquainted which each other.