Fully Distributed Teams: Squads’ development solution 

Squads is an internationally distributed community. Each member of a team may work from a different city, country and time-zone. Team members often work across 4-5 different time-zones in a single team.

At the time we introduced this, it was a new and innovative team structure which required a custom process. There are some tricky problems associated with distributed work, that when solved well, actually improve productivity over office work.

Back years ago when we started, we decided to cut our toolbox down to the bare essentials. Since then, Squad’s simple development process has evolved. The strength of the process is not in its features, but in the features we’ve left out.

We anchored three principles into the organization inviting teams to follow them:

• Teams hold a weekly retrospective.

• Teams review progress with the client each week.

• Teams set expectations up front.

Setting expectations up front introduces accountability and weekly iteration review with the client squeezes excess air out of the process. 

Any non-essential practices (waste) become evident when showing progress. As a result, fluff meets resistance from the team. Weekly retrospectives help to speed up the learning curve.

Mentioned above are just a few of the sizable practices of XP, Kanban and SCRUM. I ignore the rest, unless they come up in a retrospective.

The most successful teams have evolved the following practices:

• Pair as much as possible.

• No stand up meetings.

• Estimations are optional.

Pairing importance is almost self-explanatory (and I wrote extensively about the practice more than a decade ago, so to keep myself entertained I’ll skip over it for now). If you want us to add some background on pairing let us know! The rest of the practices are a bit more controversial, so they are explained below.

No Standups

As team members work from different time zones, it’s difficult to find one convenient time for a standup meeting. We experimented with many different ideas but they didn’t work. Eventually, we stopped having standups altogether. This was gold.

How do we exchange information without synchronous team communication?

Answer: we align through asynchronous handover of the information.

How do we monitor and adjust the iteration plan on daily basis? 

Answer: our feedback cycle is fast with short (weekly) iterations. So even if we slip, we don’t slide off course. Also we work out loud and pair a lot, which gives even faster than daily feedback loops.

You should not underestimate how much time is wasted by standup meetings. The added benefit of working out loud and communicating asynchronously is that usually information gets indexed under a url or in another searchable form. This is great if we need to jog our memory on something.

Optional Estimates

Just before starting with a client we go over the full project from a bird's eye view. Some teams do estimations in advance, but this is not typical to do in detail. 

Predicting the future of a creative process isn’t an exact science. There is no need to waste time pretending we can estimate the whole project. If a client wants more precision, we do a technical feasibility scan or a risk assessment. When the client is comfortable that we can achieve the desired result, we focus on the goal for the first week.

In many processes such as SCRUM estimation is an essential part of planning. We ignore detailed estimation because it is mostly a waste of time. The best time to calculate an ETA is when you are already enroute. Similarly, the best time to estimate the time of completion is is when you’ve already started coding a feature. 

Of course at some point it may be useful to have some idea of the complexity and timelines around a feature. If that issue presents itself, we estimate to the precision needed to make a business decision, but no more. It would surprise you how much time we save by avoiding estimations like this.

Conclusion

In this post you got a peek at the process evolution in Squads. The process works well for distributed teams. We answered some questions, but there are still more to be answered in future posts. Some examples:

• How do we work with multiple time-zones?

• How does overall communication happen with internationally distributed team members?

• What challenges do we face working with fully distributed teams? 

If you also have any unanswered questions, please write to us. We’d love to answer them.