I have used many different methods to manage outsourced development teams over the years. I have had the most success with a Agile development process called SCRUM. The reason the Agile development process is successful is it is an iterative or reactive process. This blog will document the process I follow when working with outsourced development teams and demonstrated how it is reactive.
Here are the definitions of the terms:
Road Map. This is the plan or schedule that you wish to accomplish. The road map will consist of high level features to be added and approximate dates for them to be delivered for a product. Knowing when something is due helps you define the sprints you need to accomplish to achieve the road map goals. You do not have to have a road map, but without a road map you are basically working on the most urgent items.
Backlog. The product backlog contains all of the new features, bugs, engineering tasks, etc. that need to be done for a product. These need to be organized into a set that you want to accomplish for a sprint called the Sprint Backlog. This sets the basic theme for the work to be accomplished, however, remember this is an agile or iterative software development process so if priorities change this allows you to change up the work as needed. One of the best ways to write backlog items is via User Stories. I will write a blog later about how to write backlog items.
Product Owners. You MUST designate product owners. This is the person or team who is responsible for the success and failure of the sprint and ultimately the road map. Responsibilities of a Product Owner consist of:
- Product Management. This role understands the requirements of the sprint from a customers perspective and/or how it will integrate with a current product. Typically the product manager has written the backlog items for the new features.
- Develop Management /Project Management. This role understands how to manage the engineers expertise and time within the sprint’s dates.
- Technical Leaders. This role understands the current architecture of the product that the sprint applies to and answers questions and enforces engineering standards for the work in the sprint.
Sprint. This is a set of backlog items and can be from 1 week to 6 weeks depending on how you want to run your development process. I prefer shorter sprints, so I typically run 1 to 2 week sprints. It really just depends on the type of software product. Typically, I do a sprint review meeting the day before the sprint where you describe the goals and review the processes to be followed. I also move the sprint into a code lock down a few days before the sprint releases so that testing and bugs get all fixed by the time the sprint is scheduled to be complete.
SCRUM. This is an everyday meeting with the team including product owners and engineers who are working on the sprint. You may do several different meetings per day if your engineers are working on different aspects of the sprint and do not need to collaborate. This optimizes the time of the engineers. These meetings are referred to as stand up meetings because they are supposed to be 15 minutes or less so some people have the meetings standing up so it keeps it short. In this meeting you do the following:
- Engineers describe what they accomplished the day before. This can included a demo so Product Owners can see the progress.
- Product Owner review works items with the engineers that will be accomplished for the next day.
- Question/Answer. At this time Engineers can ask questions about new items or currently in progress items. Product Owners can also ask questions to engineers.
Integration. It is important to do regular integrations into your test site. This makes sure that the build of the code is not broken as well as making sure that one engineer does not break a feature for another engineer. This also allows the testing teams to quickly test features so bugs get reported quickly in the cycle.
For this process to work I follow the following steps:
Communication. Develop the process you will use to communicate. This will consist of the following mechanisms:
- Chat: You need to use a program that you can quickly chat with like Skype, Google Talk, etc. This allows you to quickly turn around questions as well as share files and text.
- Voice: The outsourced employees are typically in a different country so need an application where you can talk without them having to call a long distance or international phone number. Skype, Google Talk, etc. are free services that work great for voice calls.
- Desktop Sharing: Some times you need to share screens so you can see the progress on a feature or show them something. Skype is a great tool for screen sharing.
- Bug/Feature Tracking: You need to have a mechanism for tracking your features or backlog items as well as bugs and tasks. If you are using .net I recommend visualstudio.com. Other programs I have used are Trac, Github, etc.
- Overlapping work schedules. Insist that outsourced team members have overlapping schedules with your local teams. If you only are working when the other team is sleeping you can not do SCRUM meetings. Note, it takes 24 hours for items to get turned around(at least) if you do not have overlap. I typically insist on at least 4 hours of overlap a day.
Enable open communication throughout the sprint. Engineers should be encouraged to ask questions whenever they need to. Since these engineers are outsourced make sure they understand their assignments before they are done for the day so that in the morning they will be able to work without getting stuck. The Product Owners need to make sure the outsourced engineers understand their tasks. The one thing that will kill your schedules is if you get in in the morning and either the engineers did not do the work because they did not understand the backlog item or they did it wrong.
Step 1. Before the sprint begins have the sprint backlog ready. You do not have to have full details for each backlog items but you should have the general gist of all changes. You do not have to do a sprint of only one feature it can be a set of features.
Step 2. Define the dates for the sprint and times for SCRUMs. Include code freeze and release dates.
Step 3. Form your teams. Make sure you have a Product Owner. Define what other software development resources you need and put them on the teams you need. You may have 1 or more engineers on a team. I recommend keeping the teams small, under 5 engineers.
Step 4. Be ready for stand ups. They must start on time and finish on time. Product Owners have your product backlogs items ready. If you have a team of Product Owners I recommend quick meetings before the SCRUM so you are all on the same page when the SCRUM starts.
Step 5. Have daily SCRUMs. This is the most important part of the process. This will let the product owners know if the sprint is on schedule an this allows you to be agile. Remember this process is designed to be reactive. Sometimes with all of the planning you do you miss something major that comes up during your SCRUM sessions. This may affect the road map so you have to determine if the reaction is worth the potential schedule impact.
Step 6. Do daily or at least bi-weekly integrations of the changes into your test environment.
I have been doing this for many years and this helps me as a Product Owner have a great feel of not only how we are doing in relationship to the roadmap but I also get to know the strengths and weaknesses of my teams. This helps me do the evaluations on the team members as well so I can help the weak links. If you follow this process you will get your software development projects done with the highest quality.
At Rabota Source we will help you guild a outsourced development team for a faction of the cost.