By now we all know that countless software teams all across the world are making the shift to Agile. Agile has helped teams deliver big projects in short bursts, and provide business value to clients, fast, and consistently for over a decade now.
As more and more teams adopt Agile though, we must look for ways to make Agile projects successful for all types of teams.
Originally Agile methodologies were created for small collocated teams working together to deliver their products. The reality now is that Agile is being adopted by teams that are distributed. In some cases these teams work with the onsite-offshore model. In other cases the entire team is distributed with team members being in different cities, countries and even time zones. In such teams it becomes essential to have a water tight collaboration strategy put in place to ensure that teams can work efficiently, sprint after sprint.
Here are 6 things I always put into place before I start any Agile project with a distributed team.
1. An inception phase/project discovery phase : This is basically a 2-3 week intensive workshop that you have with the client and all the stakeholders involved to talk about what you will be building in the coming weeks and months. For this phase I would recommend travelling to the client location and spending as much time as you can trying to understand the product, its value proposition, requirements, timelines, budgets etc. If you cannot travel to the client location, ask them for as much information before this phase begins, and then spend the next 2-3 weeks speaking with them on a daily basis about the project, the goal, their vision and their end users.
2. An Initial Story list and release plan: After the discovery or inception phase, you should have an initial list of stories/product roadmap you will be building in the next few months. Remember, this list doesn’t have to be perfect, it doesn’t have to have ALL of the stories you will be building and not all the details of each story needs to be fleshed out. Having said that though, the team needs to have a high level idea of the roadmap ahead and what is the end goal they are trying to reach, and story list/product backlog helps them do that. Keep in mind though that this story will change over a period of time and your clients and team need to understand that. At this time you should also have some high level estimates and a tentative release plan so that your customer knows when to expect the various features you need to build.
3. Collaboration plan: Before you start the project, you should have a good idea of who the stakeholders are and involve them in the release plan. You need to make sure your project has a product owner, who has enough time to spend with your team. You also should know if there are any other subject matter experts(SMEs) you should be speaking with them on a regular basis to ensure you get inputs from the right people when you need it. Remember, you likely are not in the same office as them. So set expectations with them that they will need to be part of sprint planning meetings, retrospectives etc, probably at odd hours. Send them recurring calendar invites for the next few months so they can plan better.
4. Collaboration tools: I cannot stress how important this is. I have seen countless teams where everything is great from the get go, but the team fails to set up the right infrastructure to help a distributed team work well together. Share a communication plan with everyone first, and take care of the following:
● Make sure everyone has an awesome broadband connection and wifi. This is a distributed team and being able to be ‘online’ is key.
● Set up the team calendar(Google calendar is super easy, but use whatever works for you). In that team calendar set up recurring stand up reminders, sprint planning meetings, retrospectives, tech huddles, showcases and demos etc. Set invites to the entire team.
● Setup file sharing folders on Google drive, Dropbox, Box, Drop mark,Invision etc. Make sure everyone has access to the appropriate folders. Discourage e-mailing files, resources, links etc. You do not want to be on the last day of the sprint, looking for a mock up or assets your UI dev needs.
● Set up a team wall. I don’t care what unicorn telepathic powers your team members have, you have got to do this. Trello is super simple to set up. JIRA is a little more complicated, but super powerful. Mingle is great as well. Whatever you are using, make sure you have a team wall, product backlog and sprints set up in the tool before the project starts.
5. A sprint/iteration 0: So sprint/iteration 0 is typically the first sprint that the team does before starting actual dev work. Usually, this should happen while part of the team is going through the discovery phase with the client. The rest of the team sets up various environments, does research into tools they want to try, sets up databases, sets up their machines etc. This is called iteration 0 because all the tasks that are done in this sprint are mostly not technical and need to be done before the project starts anyway. Once the tasks are done, the team can start work on actual functional stories and start delivering value on day one of sprint 1.
6. A staffing plan: Cross functional teams are key to the success of any Agile team. Once you have a good idea of the timelines and backlogs for your product, it is time to come up with a staffing plan for your time. Think about how many people you will need for your team and if they can work in parallel with each other without blocking each other. Once you know that, decide when they can start working with the team. Usually, it is better to ramp up the team slowly instead of getting everyone started on the same day, but do what works for you.
Now that you have carried out all the above 6 steps, you are on your way to start sprint 1 of your project and have ensured that you have done everything you can at this point to ensure your team is motivated, and clear about what to expect in the next few months, no matter where they are located!