StarterSquad (SSQ) is an internationally distributed community. Each member of a SSQ team may work from a different city, country and time-zone. Team members often work across 4-5 different time-zones in a single SSQ team.
This is a new and innovative team structure which required a custom process.
Three years ago when we started, we decided to cut our toolbox down to the bare essentials. Since then, StarterSquad’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 for teams to follow:
- 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 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 self-explanatory. However the rest of the practices are explained below.
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.
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.
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.
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 this post you got a peek at the process evolution in StarterSquad. 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.