Ask HN: What are some good tools for keeping a software project on track?

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

[1] https://workplace.stackexchange.com/questions/32765/what-is-...

I echo others: effective communication and a motivated team are more important than any tool.

I would add that visibility into what everyone else is working on is also super helpful to avoid stepping on other's toes or duplicating work.

Once you've got communication down, you might find one of these tools useful:

https://zube.io

https://www.pivotaltracker.com

https://basecamp.com

>Tools don't keep projects on track. Communication skills and project management skills keep projects on track.

Great comment.

Good methods are more important than tools, to keep projects on track. As in, methods of doing things, not OOP methods.

Tools, while they can be useful (though no panacea), are secondary, and also, some tools bind you into fixed ways of doing things, which may be a hindrance at times.

Honest answer:

> How do you guys manage large backlogs?

Try not to.

If PMs insist on logging ideas or keeping rejected projects i have a backlog board where ideas can have several stages. They can go from "spark of an idea" to "concrete details" there. In reality they go there to die

> Tiny bugs or nuances with low priority.

If they come from customers have a customer care person aggregate them and present a summary weekly or two weekly. Don't look at single events unless they seem important.

> …that just accumulate and are a pain to review again because you are not even sure they are still reproducable.

If they can't be reproduce remove it.

Important stuff will pop up by itself.

1. JIRA Window's :( ] 5. Slack + Git + JIRA + Screen Sharing + Emojis - Video Calls 6. SourceTree [Use when no one is looking] 7. MySQL Workbench Crashes When Mad | Hard to let go . . . . . . Write some damn scripts and automate it already!