Agile Boston has offered me a slot to do a presentation about Distributed Agile on July 29. When I get a chance to talk to groups working on agile methodologies, I mention distributed teams, since most software teams ARE distributed anyway. Traditional agile methodologies don't recommend distributed teams, but we can remove that bug. Organizer Dan Mezick of New Technology Solutions Inc. sent me a list of questions to get the audience started. He's been following the issue for a long time, and it's a great set of questions, so I share it with you below.
Dan: You founded Assembla to develop software for clients, using remote teams. Right?
Andy: We founded Assembla to explore the best way to use "inspired by open source" distributed teams to accelerate commercial software development. From the beginning this included doing rapid application development for clients, mostly startups trying to get to market quickly, and working on our own tools.
Did you use remote teams from the beginning? Or ease into it?
I started using distributed teams in 1999 to find the best talent for my last startup, an enterprise software company called PowerSteering Software. We made a study of ways to manage them effectively. So, by the time that we started ramping up Assembla, we were already committed.
Tell us some of the challenges of using remote teams. Language, time zone, issues etc.
The biggest challenge is making someone feel like part of the team. That's very important for motivation and productivity. We show an "activity stream" in our application that allows a new team member to see what everyone else is doing, in real time. And, we don't have test or beginner tasks. We treat everyone like a professional from the beginning.
Time zones can be a challenge for people who work in India or Indonesia. But, it hasn't been a big issue for us. We write down our tasks in tickets. In most cases, we can find a time for a daily chat that works for everyone, and we ingrain the habit by sticking to it.
Language can be another issue for a global team. We communicate mostly in writing, and we use English. The universe of developers who are good English writers is considerably bigger than the universe of good English speakers.
I wrote about Assembla and remote teams in 2003 in a COMPUTERWORLD article: Outsourcing 2.0: Collaborative Development
It's now 2009...and a lot of what I said in that article came to pass...everyone uses remote teams now. So, in 2009, what makes a really good remote team?
That article was right on. In your article you wrote about a very important idea, the idea of "collaborative" or "peer to peer" organization. We call this the "single global team" idea. It's a lot different than traditional outsourcing, where you have Team A in one place, and Team B in another place, and you throw stuff over the wall. In a single global team, there is no wall, and you can distribute work more efficiently. Every team member should be ready to take on an important task.
So what makes a really good remote team? Really good developers. The quality and productivity of the individuals is hugely important in software. And, if the team is good and starts to succeed, that success is very motivating. Some people say that motivation causes high productivity, but I think it is more likely that high productivity causes motivation. That's why we emphasize doing global recruiting, with trials.
With co-located agile teams, intimacy between team members is generated (in part) as a function of proximity. Are remote teams intimate? If not, what holds them together?
Remote teams work a full day together, every day. They share their work in real time through code repositories and other online systems. They chat. They post pictures of their babies. We have some people that work in our little office in Needham, Massachusetts, but often it's hard for me to tell if they are in the office, or working at home. Kids growing up these days feel very social and intimate when they are at home alone working the Facebook newsfeed. Ironically, technology is not making distributed teams more like co-located teams, it is making everyone else more like distributed teams.
Early in the Assembla genesis, you use the tagline 'inspired by open source'. Tell us about that idea.
We look to open source teams as a source of tools and techniques for managing distributed teams. They have decades of experience with hundreds of thousands of developers, and the successful projects are tightly managed. For example, they do competitive trials. To get on the committing team, you have to submit good code. In commercial projects, we need to add scheduling, so we adopted an agile process with fixed release dates - basically, Scrum. We also work on a lot of Web 2.0 projects. I define Web 2.0 as a product strategy built around release early, release often. We learned to strip down the initial releases into a minimal useful product that we could get to customers fast, and build on incrementally. So, our "distributed agile" methodology is a mashup of open source, agile, and Web 2.0.
Later, you built tools on top of open-source stacks, to help manage remote projects. Tell us about that early work building collaborative tools. What year did you start?
We started building Assembla.com at the beginning of 2006. Initially, we built on popular open source applications like Trac and subversion, because we wanted to integrate people quickly, and those are tools that a lot of people understand. We've added a lot since then.
Now you sell collaborative toolsets on a subscription basis. Do you still complete software projects for a fee, or is Assmebla 100% tools now?
We still do consulting and fee-based software development. However, we are investing heavily in our products.
You have a list of 6 things to do and NOT do. 'Estimating' is something in the NOT list. Excuse me? Please explain.
To increase productivity, you have to produce the same output with less work. Estimating is a lot of work, and if you can cut it out, you produce more. If you put your work in priority order, and you always work on the most important things, then your estimate is not going to change your workplan. In this case, you can skip the estimate.
You say NO concalls. Huh? Seriously, explain yourself.
Conference calls is another one of the six things to skip. We sometimes get called in to work on projects that have NOT been able to get to a release, and statistically, the more time they spend on conference calls, the worse these situations are. Conference calls are a sign of management problems. If someone comes to me and says "I worked on a project with daily conference calls, and it was great," I will reconsider. So far, it hasn't happened.
You say that a history of building software from scratch is highly correlated with success on a remote team. Explain that one.
Statistically, this one question, "Tell me about a piece of software that you designed and built by yourself" is a terrific predictor of success. I think there are two reasons. First, it's important for distributed team members to be able to solve problems independently. But, more fundamentally, good programmers build software because they want to, and sooner or later, they do it solo. Not-so-good programmers build software because their team leader tells them they should.
Say I have a really productive remote team. What group-level factors are at play?
First, discipline and habit. The team needs to be reliable, and get onto a daily schedule, and a schedule for releases or "iterations". Second, raw talent. Our wonderful and prescient management direction comes a distant third.
Is a good remote team simply a set of productive and willing individuals who agree to a set of ground rules....or something more? Do remote teams have any social cohesion whatsoever? What goes on at the group level-- if anything-- except software construction?
I like to think that by focusing on the work from the beginning, we get more productive by cutting out social orientation and maneuvering. If the work is successful, people feel rewarded. There is a lot of research on team dynamics that shows teams will work effectively together, even if the team members don't like each other, as long as they share a goal and are moving toward it. However, any team is a society of people. They want to know that everyone is pulling his weight, and they need to learn the best way to communicate with each team member.
Tell me about the process of selecting a candidate as a team member.
We look at the resume, price, and availability, and if we like a candidate, we offer a two week trial contract, and ask him/her to start work. We don't interview, because interviews are misleading compared to actual work, and just as expensive as trials if you count all the delays setting them up.
We do trials on our own product development, where we can manage some unpredictability, or we do it at the beginning of a new project. At the beginning of a project, nobody knows what to do, so you lose nothing by throwing in some extra team members, some of whom may be outstanding.
After you select a team member, what is the orientation process beyond selecting them? What do you tell them to expect? What do you promise? What do they promise?
How detailed are your ground rules? How important is it to clearly do you define the boundaries, authority, role and tasks of each team member?
What documents (if any) are used to communicate these understandings?
We ask team members to sign a standard contract that covers details about how they will get paid, and and minimum and maximum hours per week. I think it's important to establish our authority as managers by paying promptly for everything, even the initial trials. We communicate that the project is going to be tightly managed. We also get an assignment of IP and other legal details so that clients will have everything they need when they deal with investors.
Then there is the technical integration. We always write a wiki page called "Setup Development". They should follow the instructions on that page, set up a development environment, join our chat, and grab some tickets. If there is a problem with the instructions and they need to ask some questions, then their first task is to fix the Setup Development instructions. If it is a big, complicated system we can give them some learning time where they just work on bug fixes, but in general, we are looking for folks who can figure out complexity.
We use the pull system, where teammates pull tasks that they think they can complete from our list of tasks or "tickets". This saves work for the project manager (instant higher productivity), and it gives us a good match of skills to tasks. We have one-on-one discussions to ask people to commit to the hard tasks. And, we ask for a daily "standup" or "scrum" report - an online form that takes 2 minutes to fill out and lists "What I did", "What I will do", and "What I need."l
The ticket list is maintained by someone called a "technical lead". The tech lead writes many of the tickets, clarifies them, and answers questions. This is an extremely important role, and it is not the same as a project manager or scrum master. It's a player-coach who works on the code. We're a programming operation, and we believe that we get a lot of efficiencies out of flattening the project management structure and putting a technical person in a lead role.
You are on the team until you are off the team. We let team members pick their own tasks. If they don't deliver at the level that we need, they might need to leave the team.
In your writing on your blog, you seem to imply that a remote Scrum team can be as productive or MORE productive than a co-located team. Explain how and why.
It can be more productive because you don't waste time traveling or commuting, and you have access to some of the best talent available globally.
Why should I attend your presentation at Agile Boston on July 29?
I will quickly run through a lot of things we learned from experience. Even if you don't agree with the whole thing, you will probably get something you can use immediately with your own team.