hard to do a crash course in one post not knowing size of the team, schedule, methodology etc - but generally:

• you need a priv repo to share code of course. With proper user/group permissions, on top of that sign proper paperwork with devs before giving them access to the repo (your new startup client will thank you later)

• daily calls are good... but make them quick ones ie:

  • what a dev did yesterday
  • what is he/she going to do today
  • what blockages they face

• weekly calls (Friday eve to close the week, Monday morning to plan) - are good if you need to react on changes

• slack can be too distracting - especially for devs who need to stay in the flow

• Trello / Asana - are good to plan and track work

• depends on team size / schedule - you can try things like this weekdone.com/development-team…

• Regarding project management - have a look at Kanban - and this video by Eric Brechner an Xbox development manager is gold www.youtube.com/watch?v=CKWvm…

• mistakes? biggest f-ups happen when there is

  • lack of communication... when no one knows priorities and goals (short and long terms) - and do what THEY think is the most important
  • mess in code/documentation/project... - it's all good when there is 2 - 5 devs - but when you expect to get 20, 50 etc - some proper procedures need to be implemented
  • saying YES to too many things by lead developer / management (if something takes 3 weeks to develop and you promise to deliver it in 1 week - it's doable but there is some cost and Karma will get back to you in the future :P)

Here's a workflow that I've used on dev teams from 2 to 10 people:

• Mondays: weekly planning meetings to set goals & discuss things (30 minutes max)
• Log tasks to Trello in proper columns (Backlog / This Week / In Progress / Review / Deployed)
• Once you're working on something, assign the card to yourself on Trello and move it to the In Progress column.
• Push your code to GitHub and open a PR when you're ready for review or for hand-off to another developer.
• Customize your labels in GitHub and use them well. Make one red label for WIP — DON'T MERGE and tag your PRs that are not ready to avoid confusion. I liked having a Ready for front-end, Ready for back-end, and Help needed! label for hand-offs.
• Daily: very quick standups over video/audio call. I mean quick, 10-15 minutes max. Try to limit the agenda to 3 minutes per person. Discuss what you've done the previous day (same day if timezone diff) and what you're working on today. Keep other conversations or follow-ups to Slack DMs or channels.
• Have another Trello board for ideas that are not priorities in the next 3 or 4+ weeks to keep your focus clear on the main dev board. Move those to the main board if you decide to work on them.
• Push often and rebase often. Nothing's worse than having to resolve conflicts for an hour or more.
• Use feature toggles in production, if possible, that don't require deploys to turn them on/off.

Be honest, be humble, don't be afraid to be wrong. Talk with your team and collaborate on ideas, solutions, and implementation. If you're a manager know when to have final say on things and when to let other people take some things over. Don't have cocky underestimates because then the roadmap falls apart and everyone is disappointed.

@PatskyPat @pugson @getaclue Wow!!

So much great stuff here guys. Incredibly helpful.

Interesting hearing the same things crop up again and again. eg. Trellow / QUICK daily calls / enforce style

Love Tags on Github Idea as well. And hearing your whole Trello task management is something I think I'll copy exactly as you explained Pugson :):)

@patskyPay, I'm will check out that you tube video when I'm on the train on Monday. Looks promising :)

Alex, when you say "measure", what exactly do you mean? Are you talking about a productivity metric?

My only follow up question would be, I expect there to only be 3/4 of us. And I also expect the standard of ability to vary a lot. Any advice on how to working with people of very different ability levels?