Asked

How should a proper dev team work together?

Doing some work for a new startup making a payment app. I've got to build the development team and map out how they should work together.

I've always worked solo before.
Would be really grateful for for a crash course on how a proper dev team works.

Private/Public GitHub Repo to share code?
Daily Calls / Slack Channel ?

What mistakes do you see all the time?
Any general / specific tips much appreciated.

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 https://weekdone.com/development-team-reporting

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

  • 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.

Nothing crazy to add to what others have added but to me it always comes down to communication and scope. As the lead you need to have the big picture and know how to break it down and delegate... but this is the tricky part... be open to the strengths and weaknesses of your team and adjust. It is tricky because although you probably shouldn't micromanage you need to guide and provide business value to whoever pays your bills. And finally measure. Since its a new team, begin the collecting whatever metrics make sense to you and come back in 30 days and set it as a baseline. It is tricky because its important to set some kind of structure as the lead from the beginning. It is much harder to do this down the line. Be open to adjustment but don't forget your goals.

oh and for code make sure to have some kind of type safety or standard ... I know its not a popular opinion among this community / small teams but it really helps in the real world. However, this also depends on the experience of the team. If it is taking too much time for people to adjust... might want to reconsider. If it was my team I would enforce.

@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?

Sign in to answer 😃