About a year ago, I took over a small team of 3 developers that was floundering and demoralized. This was not a remote team but I think that's incidental for th

About a year ago, I took over a small team of 3 developers that was floundering and demoralized. This was not a remote team but I think that's incidental for the most part. I admit I'm writing this mainly as a testament to my own experience. But I think it includes some sound advice (a lot of which I collected from Hacker News discussions over the years.) Process is key. Tools should serve the process and the team. First thing I did was to put together a basic scrum process. This had an immediate positive impact that has persisted. Some recommendations: - Respect your team members. Give them the benefit of the doubt. There have been some good threads on HN about the distinction between being a dev and a manager.[0] - Short daily standups: no more than 10 minutes, just the three questions: Did? Doing? Blocks? We do them in-person in the office, but I also do them over email with some of our contractors. - Regular sprints (I like two-week sprints) with focused, structured demo, retrospective, and planning meetings. - Retrospective meetings with developers and product owners that identify pain points but emphasize fixing the process not blaming or fixing individuals. - One-on-one meetings every other week with members of my team and with my manager.[1] - Weekly grooming meetings: product owners and developers together review, size, and prioritize stories. - Projects are managed in Trello: cards are either user stories or defects with acceptance criteria. - Issues are tracked and documented (in Github). I set an example for my team by thoroughly documenting issues and emphasizing best practices. - Developers don't work on anything that doesn't have a Trello card (we have an action item card for small one-off tasks.) - No burndown charts! A lot of these practices I carried over from my previous job, where we used scrum but, because of laziness and laxity on a few points, ended up with a pretty dysfunctional team. My only real innovation was the "No Card/No Work" rule. I think it's essential. It both stops managers and stakeholders from derailing the process. And it provides a record and reference for the team's accomplishments. Coming into an existing team, I made sure I was flexible and accommodating in implementing the new process. But this is the one point on which I told my manager I needed to be firm. We agreed to leave a little bit of room in each sprint for any urgent stories that might come up. It's worked out well. Finally, my managers support and respect the process. Commitment was one of the keywords that was emphasized when I was first trained in Agile Scrum and I appreciate the significance of it now. Without the investment and commitment of management, this would probably all be futile. For larger goals, we created an Epic board that my manager likes to use with senior management. Trello is great because it visually reinforces the reality that priorities are a queue and if you push some urgent new job to the top, everything else in line is going to get pushed down and delayed. It's funny how easy it is for people on high or under stress to ignore that basic law of nature. [0] https://news.ycombinator.com/item?id=3407643 https://news.ycombinator.com/item?id=3407643 [1] https://workplace.stackexchange.com/questions/32765/what-is-the-purpose-of-1-on-1-meetings-with-your-direct-leader-boss https://workplace.stackexchange.com/questions/32765/what-is-...