OK, so you and the rest of your team members have decided you want to “try agile” on your next big project. Maybe you’re getting pressured by management to do something (anything) different to get things out the door quicker or to improve your project success rate, and they think agile is just the thing you (and they) need. Maybe some of your team members have used it on prior projects, in prior lives. Or maybe you’ve been reading about all the benefits others have been reaping and have decided you’re ready to give it a try. You could really use some of those benefits too…
And then you remember: we’re not just a large team, we’re a [globally] distributed team, and one of the basic tenets of agile projects is “small co-located teams”. Can we still make it work? We really need to make it work, but are we doomed before we even start? You know that you are never going to be able to get everyone into the same location for more than a few days every quarter. Even if travel budgets weren’t tight, it’s just not feasible. There are going to be too many of you on this new project, you’re spread out all over, and everyone has commitments at home they need to keep too. Everyone on the project can’t relocate for the next 6, 9, or 12 months while you get this out the door.
Sound familiar? Welcome to the party.
Unless you are one of the very few centrally located teams left on the planet, you’ve most likely been living the life of a distributed or even globally distributed organization, working in several offices, time zones, countries, or maybe even continents for several years now. This is the normal mode of operations for you.
So what are some things you can do when you want to “go agile” on your next big project and you’re a large distributed team?
First of all, it’s been my experience that all the rules for organizing and working in large distributed teams/projects still apply. Ignore them at your peril. And when agile goes global (Part 2), we’ll see that some of the agile processes and tools do need to be tweaked or augmented a bit. There is definitely no “one-size-fits-all”. Implementations will be as varied as their organizations (Part 3). Understanding where you are and how much you want to take on (or can take on) requires some planning, time, resources, and patience to implement, but it’s well worth the effort.
So first off, here are a few things that come to mind for large, distributed teams. I’m sure you have others as well. This is by no means an exhaustive list:
-
Meet face-to-face periodically, particularly at key points in the project
-
Project kick-off and initial planning
-
At major milestones
-
Other crucial points in the project
-
Agile hint: When forming a team, you should co-locate for 2-3 sprints, particularly if you have team members working in other regions or overseas
Again, don’t write this one off. Team building exercises may sound trite, but there is evidence to show that these types of activities do yield real results, especially for distributed teams. Find an exercise/activity that suits your team.
-
Consult a professional if you need assistance
-
Involve your team members, including your introverts, to help plan your events
-
Don’t forget to involve the women in your team to make sure it’s something everyone will be willing to participate in
-
Shared purpose
-
What are we doing and why? Why is this project so critical? What will it mean to our company, our group, and our own futures? What will it mean if we don’t do this well?
-
This is a critical element for success on any project, and even more so for virtual teams
-
Communication plan
-
Who needs to know what, when, via which methods, and how often
-
Make sure you beat this drum early and often
-
One communication mode is not going to be enough (e.g., email); some groups will need to be communicated with face-to-face and even one-on-one, not once but several times
-
Don’t tell a few people something once and expect it to be known throughout the organization
-
You need to tell people what you are doing and when things are expected to happen
-
You need to tell them repeatedly over the course of the project
-
You also need to communicate your results
-
Remember if someone hasn’t heard about something recently the perception can often be:
-
It’s not really real (we can ignore it)
-
It’s not going well (it’s failing, so we can ignore it)
-
We aren’t doing it any more (it’s dead)
-
Create a shared knowledge base
-
Make sure it’s globally accessible and available to everyone
-
Ensure everyone knows about it, knows how to use it, and then actually uses it
-
Make sure it is well organized, if it isn’t this can be a big turn off
-
Organize teams based on your system architecture
-
This is a good practice regardless of what method you are going to use
-
If you don’t organize your teams around architecture, your teaming structure will drive your system architecture (oops!)
-
Consider assigning a system/sub-system/project (once you figure out what they are) to a team whose members are in the same office or same region, if possible, to reduce the number of time zones, cultural issues, etc.
-
Pay attention to team leadership
-
Ensure each team has an identified and strong leader who is good at:
-
Communication up, down, and side-ways
-
Good organizational skills
-
Good listening skills
-
Willing to admit they don’t have all the answers; everyone has something to contribute
-
Has a good handle on the goals and objectives and can keep the team focused
-
Continuous feedback – this is really critical on a virtual team
-
Clear communication of roles and responsibilities, goals and objectives
-
Consistent leadership style
-
Ensure you have the proper environment in place
-
Communication tools
-
Email, phone systems, teleconferencing lines, web conferencing, online chat, video conferencing, online collaboration tools, etc.
-
Ensure everyone has access to all of the above and is trained on how to use them
-
Sufficient bandwidth between locations to get the job done and support your tooling
-
If you don’t have sufficient bandwidth, you may need to invest in more hardware, improve your communication pipes, or invest in other technology like remote server access
-
If you don’t address your bandwidth issues, it can make your tooling perform poorly and look like you have tooling problems when it is in fact your communication pipes that need work
-
Insufficient bandwidth can also negate any efficiency gains you hope to achieve from your tooling deployments, hinder/inhibit adoption of your strategic tooling, and harm team morale
-
Development and Other Tools
-
Ensure everyone has access to the toolset and is trained on how to use them
-
If there are diverse technical skills, or a wide range of expertise, assign mentors or buddies to foster and improve individual knowledge, team cohesion and trust, teamwork, commitment to the project, and overall satisfaction
-
Make sure your mentors and mentees know what is expected, goals and objectives for the mentoring period, agree on duration of the mentoring engagement, etc.
-
Note that the mentees are expected to drive the relationship; if you need to have the mentor driving, then you are really talking about coaching vs. mentoring
Again, the above is not an exhaustive list, but at least gets a few items on the table. What else would you suggest?
Tags: 
global
sparacin
agile
distributed
team