Dotdee’s Daily Deliveries — a study in remote tech management

Image for post
Image for post
Saigon skyline

Dotdee Digital is an outsourcing company run by a team of Western project managers/tech leads and Vietnamese developers who offer remote developer teams for Android/iOS/Python projects at very competitive prizes.

All team members work on-line from home and live in Vietnam and Cambodia. IRL meet-ups occurs on a monthly/bi-monthly basis with all team members. The Western tech leads come with strong developer backgrounds but have for various reasons branched out into tech project management. They can do hands-on coding and de-bugging if required but will rather focus on the SaaS project management resource tools and manage estimation and planning, resource allocation, reporting and all communication with the client. The Vietnamese developers take care of all coding. Read more Vietnam’s IT talent here.

So how do Dotdee go about in their daily work? Here is a brief story-line on how we manage our teams from day-to-day using Agile methodologies where applicable and the Builder GitHub strategy to keep a steady productivity flow.

CASE SCENARIO:

A team of Android, Back-End and UI/UX design devs, all from Saigon and one Western project lead based in Phnom Penh, have been working since eight months on a large-scale Android app, best described as a location-centric social environment with a high degree of user privacy-enhancing tool implementations.

We have been using Teamwork Projects for team objectives and business processes and Skype for communication. The tech leads are all living/working on the ground in Vietnam or Cambodia and can therefore off-load all time-zone and communications quirks for clients in Europe or the US.

Agile approach:

· Readily admit customer collaboration

· Being able to quickly respond to change

· Prioritize customer oriented product back-logs

· Focus on creating short-time, interesting tasks for devs

· Focus on producing working software from every developer task iteration

Agile approach in practice:

· A product backlog (Feature Request Task list) is featured

· This back log is incrementally feeding a Scrum backlog (Production Task list) in small prioritized chunks

· No Sprint is planned per se, though the devs are working off a Sprint backlog. Normal turn-around for this kind of delivery are no more than 5 working days. After 5 days the Scrum Backlog should be ready to be populated with new chunks unless critically impractical

· Any discovered issues are populating a dedicated Bug Task List that also is fed on demand into the Scrum backlog in prioritized chunks.

· Any reported and reproduced bugs should be assigned as soon as possible after a developer has finished a task

· Efforts are made to minimize work-in-progress duration during these 5-day time-spans

· The project lead measure the individual developers lead-times during this time-span

· A daily meeting is held every morning at 9 AM with the team where the day’s activities are set up

· A one-to-one catch-up between project lead and each dev (5–10 min) is conducted daily at around 1.30 pm

· A close-of- business meet-up is held every day at 5.30 pm with the entire team. At this point the devs have to share their screens and demo what they achieved during the day

· All devs have to commit and push to the Master repo at the latest after evening meet-up

· Every Friday the close-of- business meet-up also include a review of the week passed

· Releases are built daily and goes out to all stakeholders

GitHub Build procedure:

· The project lead, here called the Builder, has sole ownership of a Master Repo

· Developers branch Master Repo and clone their branches to their local machines

· After the developer has made their changes/additions, they should branch again from the Master Repo and confirm that things still work as expected. Any conflicts have to be solved by the dev at this point.

· If everything works, developer should push to their branch and submit a pull request to the Builder

· Builder should pull the developer’s branch and test to see if things work.

· If everything is ok, then the Builder merges the changes to the Master Repo.

  • The developer should by then have received a commit notification to verify that his code was pushed to Master Repo by Builder and now have to make sure he is in sync with the project. Same goes for the other devs so that everybody is in sync.

· Pull request deadlines are set by Builder and obligatory as to give ample time for testing, building and time-zone considerations.

· Previous builds manually backed up (include all GIT folders) and archived as a .zip

· Build is executed and released to stakeholders on a daily basis

This procedure works well, also when bringing in freelancers.

Conclusion

The above processes worked well. Over eight months the lead-times, translated into task/day, improved steadily. Two of our Android devs closed 386 tasks of working software in 32 weeks.

Without being overly dependent on Agile methods it proved possible to cherry-pick bits that fit the project and the developers. It has also proved a huge advantage to have Western ex-devs as project leads/project managers. Get more insights at https://dotdee.digital

Written by

Founder of Dotdee Digital, an outsourcing company run by a team of Western and Vietnamese developers. Android, iOS, Python, ReactJS. https://dotdee.digital

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store