Ask HN: How to organize a distributed design team?

Trello?

I'd try working with a very strict system like Scrum, but you've got a pain point with the dailies. You could try "formalizing" dailies by having everyone writing down their progress on tasks. However, your Scrum Master would be very busy checking in with everyone to keep track.

How big is the team? Have you considered turning them into smaller timezone based teams, and doing short sprints? They'd all share the PO and Scrum Master so you'll have a pilot view .

Much of the problems with distributed teams is behavioural IMO. We work in a global team and I repeatedly see my local colleagues having to attend late calls to accommodate for the team in another timezone. I constantly tell them to refuse such meeting requests and force the team in the other region to change their practices to deal with any global issues first thing in the morning such as email queries, meetings, requests, etc. Instead, they come in, grab coffees, leisurely waste time clearing out their inbox and it's noon before you know it. If they devised a simple method of scanning mails from the other region first and then reply/meet immediately, it's make everyone's lives easier.

Do you have slack (or some other chat)? Might help a lot. And don't have chat "meetings" or anything. Just talk as things come up as if everyone was available 24/7. @ relevant people if pressure is needed. Also try to not have conversations offline so that there is a real global team rather than 2 teams communicating internally and then communicating externally whatever they think is important.

Whatever it will end up in I hope you'll get to a common understanding of communication principles and obvious signs of tasks to be dealt with. For us (team of 9) a 'relay race' worked the best so several calls had been made between who were awake and we used a shared platform to discuss, annotate and see through the order together with the client.

Contemporary software development team management practices work because they are fundamentally people centric. As soon as the schedule becomes the goal...and to me this is what an emphasis on "difficulties iterating quickly" begins to imply...then the process begins sliding toward infinite defects methodology. [1]

Different techniques work for different situations. Classic XP isn't really defined in terms that lend themselves to distributed teams. It's hard to make Scrum practical across nine time zones while still focusing on people.

What may make sense is choose a unit of iteration that makes sense for the specific team. There are alternatives to the Sprint [2] as the basic unit. There is no silver bullet.

Good luck.

[1] As described by Spolsky. http://www.joelonsoftware.com/articles/fog0000000043.html

[2] e.g. the feature in feature driven development. http://www.agilemodeling.com/essays/fdd.htm