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

[bnchrch]

Hey! I'm coming into a new remote team as Technical Lead on Monday and I wanted to know are some good tools that can help us work better together.

Things like:

1. Know what each other are working on? (progress/blockers)

2. Know what is currently deployed to production and staging? (heroku)

3. Keep track of larger goals (milestones)?

[dannysu]

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

I believe the most important task is to teach your team members those project management skills.

Teach them the skills to recognize unexpected events and know to communicate those bad news proactively. For example, an assigned task turned out to be much more difficult or larger scope than previously thought? Communicate. Uncertainty whether things can get done in time? Communicate. Feeling even the slightest uneasy about anything? Communicate.

Understanding of the business goals? You have to teach it and make it clear. You're not gonna have a textbox, type it in and expect the team to just get it. There's a difference between reading something, and understanding something.

Again, tools are "tools". No tool can allow your team to just be in zombie mode and not use their brain to think. Tools are there as an aid, not to fill in a hole in competencies.

Choose whichever tool that works for you. Observe how your team members are doing and teach them the necessary skills as needed.

At my company we've used simple Google doc, Asana, Trello, and now we're on JIRA. They all have pros and cons, but so far JIRA is working out alright and I think better than Trello.

[vram22]

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

[Pica_soO]

The first thing you will get for raising a issue, is a slap over the head for "bringing everybody down" and "not thinking positively".

Many managers view incursions of reality upon there vision as a personal attack.

You are right though, good communication is the best approach.

[BOOSTERHIDROGEN]

Any books about project management skills?

[boffinism]

In my experience, what matters most is good communication. Whatever tool you use, what matter most is making sure your team are diligent about updating it, and about responding to updates by others. If you can get them doing that, then using a spreadsheet or a wall of post-it notes will give you 80% of the benefits of using the most advanced dashboard/kanban/IM tool. If you can't get them doing that, then even the most advanced tools won't save you.

[LrnByTeach]

Bingo.. these 4 things are the crux of the Project Management ..

> In my experience, what matters most is good communication.

> Whatever tool you use, what matter most is making sure your team are diligent about updating it, and about responding to updates by others

> If you can get them doing that, then using a spreadsheet or a wall of post-it notes will give you 80% of the benefits of using the most advanced dashboard/kanban/IM tool.

> If you can't get them doing that, then even the most advanced tools won't save you.

[tootie]

Post-it notes are an absolutely terrible mechanism even for a small colocated team. Trello is barely sufficient. It's a digital task list, not project management. I'm sure everyone is deliberately thumbing their nose at enterprise tools like JIRA, but I consider it absolutely essential. Take the time to learn how to use it. Pick a workflow that works for you and just enforce discipline. It can do release management. Even in an automated way with Jenkins plugins. Pair it with bitbucket and you can create feature branches from the UI for each ticket. You can easily match commits to which feature they were for.

I know there's also a lot of scorn for agile, but the core tenet is really just writing well-defined stories. Make each ticket the smallest possible feature with incremental value than can be built, tested and deployed. Then stack your tickets in priority order. Everything else about the process is for communication and visibility, but if you write your stories well, they are less important.

[ryandrake]

Incomplete problem statement. Project size plays a big role.

A lot of solutions posted so far (post-its, E-mail, whiteboard) work well for 2 person projects, with discipline scale to 20 person projects, are problematic for 200 person projects, and are totally inappropriate for 2000 person projects.

Specialized tools are recommended when projects scale beyond 10-20 people. Formal process helps. You also need to track risks as another poster pointed out. If your project is a part of a larger whole, you need to track dependencies and their schedules (other teams at your company, vendors/suppliers, 3rd party open source dependencies, etc.)

[jcoffland]

200-2000 person projects may be what the big guys do but that does not mean it's a good idea. There's bound to be massive inefficiency with large numbers of developers working on the same project. The resulting software will reflect the complicated political structures required to organize that many people and will suffer greatly for it. Small teams are the most successful at producing quality software in a reasonable time frame regardless of problem complexity.

[wikwocket]

One micro-solution to the "what's deployed right now" problem is to have a health-check url for your app, which includes info like what git commit was used to create the current build, when it was deployed, and some basic application health info.

You can monitor this for basic uptime monitoring and refer to it to sanity check which version is deployed. We do this at my place and it's super convenient.

[smithkl42]

I've successfully used Pivotal Tracker for my last three startups. It's an opinionated tool whose opinions don't always match mine, but it works well, and I've scaled it to teams up to about 15-20 participants. Beyond that, it seems to get bulky and hard to work with, but I don't know if that's so much a limitation with Pivotal, or with how I've tended to use it.

[blipblop]

I have found that revisiting the same documents during regular meetings works best. First starting at a high-level overview of the projects/milestones/deadlines/customers and then drilling down in the detail.

> Know what each other are working on? (progress/blockers)

a. Gantt chart = Asana + Instagantt

- Instagantt is great. It allows you to create a Gantt chart from multiple Asana projects. I have an Asana project for each customer project with the deadlines/milestones. I also have a project for Ops/Refactoring "projects" (changing ORM, dockerizing, etc.), a project for Releases, and a project for Meetings.

- I use to think Github could do everything but business-folk seem to struggle with it, and Asana is more flexible. Assigning tasks to people in Asana is great.

b. Kanban board = Github + Zube

To actually get things built we work in loose two week sprints. We create Github Issues for tasks we are working on usually keeping them quite broad as usually a lot of details emerge once we start working on them.

We estimate time based on Planning Poker with the goal being to become better at estimating time and scoping tasks.

> Know what is currently deployed to production and staging? (heroku)

I've started keeping details of releases in Asana. Could also use Github Milestones. We feature freeze releases to a branch called `release/0.5.x`, when we ship we use a tag called `release-tag/0.5.0`, and then tag our deploys with `deploy/staging`, `deploy/prod`, or `deploy/<on-premise-customer-name>`.

> Keep track of larger goals (milestones)

We use a Gantt chart is visualise this, and usually some high-level strategy docs in Quip.

[olalonde]

Small team here.

1. We do all of this from Github using issues, milestones and projects. We have a GitHub Slack integration which can also give a feel of what everyone's working on. We also have a meeting every Monday where everyone says what they'll be working on this week.

2. Master branch is always in production. Staging branch is always in staging. We use CircleCI for CI/CD.

3. Milestones in GitHub.

[Thriptic]

Yeah we used to use Jira for a < 10 person team mostly based on my insistence and it ended up being too much tool for our needs. I begrudgingly agreed to switch to GitHub issues and it ended up working very well for us.

[leipert]

We are using Kanban with the help of JIRA. Took it a while to set it up, but the switch from OpenProject & Sprints was totally worth it.

1. How do we know what each other is working on?

All of us (~15 people, 5 of which remote) participate in the daily at 10 o'clock. The daily takes around 15 min and it is focused on the stories and every one has a good overview on what is everyone doing. Other meetings are usually organized in the daily. Typically like

A) "I have this and that problem with X, I would like to talk with B)"

B) "Okay, let's talk after the daily."

C) "I have also interest in this"

Every day the daily is lead by another person. At the end of daily we ask questions regarding if everyone has enough/to much to do, knows what to do and so on.

2. How do we know what is currently deployed to production and staging?

Version numbers ;) And Bamboo deployments.

3. Larger Goals

Big releases every few months with planning directly after each release.

[taprun]

As a former pm, I sure hope you're going to track risks. Things that are (or should be) spotted early need to be tracked and managed.

[foodie_]

I'm honestly surprised no one has said it yet, but you shouldn't be thinking about tools at this stage. You should start on Monday and see what they are using, identify where it's not working and propose a solution.

It's simply to early to think about the solution at this stage.

(With that said I manage a remote team and we use kanban on trello, heroku and slack. We only meet as needed)

[james-skemp]

Second this. More than once I've heard that the best thing a new director can do is learn the current state of things for the first six months. Coming into a team as a new leader and changing things without learning about the team first isn't a good idea. Don't come up with fixes for imaginary, or the wrong, problems.

[astonex]

At my job we use https://clubhouse.io which is basically Trello but with a lot more helpful features

We can see what everyone is working on just by looking at the stories in our 'in development' list which show who picked up that story.

We can also group stories into epics and milestones to track progress towards larger goals

[ilaksh]

Depends on the type of project. For small projects it mainly is about engagement and communication. They have to actually be around doing work and also have time set aside to communicate. They have to actually use the communication tools effectively. A lot of people actually are bad at online communication so you have to correct or work around that. If you are doing online everyone needs to be good at whatever online communication, or trying hard to be. And if most people are using Github issues for example, some people can't be doing their own thing on Skype if they overlap with the stuff on Github. Github. A chat tool with history. Phone calls or Skype or any voice tool. Make sure people are available for a minimum amount of time every day or few days to discuss things freely. For me I think it is counter-productive and just stressful to dump a big to-do list in any tool. Concentrate on the most important tasks for that week or two is how I do it.

[perlgeek]

Most modern software development methodologies have elements to address your point 1. For example Scrum has daily standups that specifically inform every attendant about progress and blockers. Kanban mandates that you visualize your workflow with a board.

Tracking the larger goals is often not well formalized, but I like this podcast episode about levels of planning in agile projects: http://deliveritcast.com/ep33-always-be-planning. It's often included in frameworks for scaling scrum, like SAFE of scrum of scrums.

2. is a purely technical problem. If I remember correctly, stuff deployed to heroku corresponds to git branches, so it should be pretty easy to create some visualization about what's deployed right now from looking at git repos. I could be wrong here.

[eikenberry]

I've worked on several remote teams and for keeping up with each other the best combo I've found is a daily chat based standup, optionally with a standup-bot. Along with a ticket tracking systems with an in-progress state + a dashboard layout that includes your teams in-progress stuff.

For example my dashboard I has a 2 column layout, on the left top is my in-progress stuff and down the left side is the other team members in progress stuff. On the right top is my assigned tasks and below is monitored tasks. This layout is useful to me for tracking my work and I get to stay aware what the others are working on. It helps a lot to keep tickets small in scope, so you can rotate them fairly often.

Of course what works depends on the nature of your teams work. Anyways, just some ideas.

[batbomb]

We have a stand up bot (geekbot). Coupled with a jira bot that posts-back ticket information if tickets are mentioned in the stand up, it makes for a good experience.

[ksikka]

For 1 and 3, it's the process that matters more than the tool. One process I found effective is maintaining a spreadsheet of tasks and a spreadsheet of larger milestones, updated in periodic meetings.

For the task spreadsheet, you can have a twice-a-week stand up where everyone goes around and updates their own tasks on a google sheet in turn.

For the milestone spreadsheet, a period between one month and one quarter works well.

Although meetings are often eschewed by software engineers, they really do help to keep projects on track.

Also appoint someone to be in charge of tracking the "health" of various milestones, red = needs course correction, orange = at risk, green = on track, etc.

[dasmoth]

1. Know what each other are working on? (progress/blockers)

The closest thing I've seen to a nice solution to this is to e-mail a brief report of what you've been up to to the manager at the end of the week, who collates into a summary at the start of the following week. Lightweight, avoids superfluous detail (because the coordinator can edit it out), and not so fine-grained that individuals can't sit on a problem for a day or two while thinking it over if that's their preferred style.

Obviously, this doesn't preclude talking about individual issues during the week! But daily check-ins force this too quickly in my view.

[msupr]

I'm pretty surprised to see so many people recommending post it notes or a whiteboard. Even if you aren't remote, people are going to have sick days or WFH days and "can you take a picture of the whiteboard for me" requests are nonsensical.

Start with Trello. You can easily bend Trello to work with any productivity/PM system. Easy to get started and easy to evolve your process over time. Lots of great examples of how people are using it and some cool plugins to extend it.

#1 is extremely easy to implement in Trello. #3 is definitely possible but takes some time and buy in.

[billdybas]

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

[laktek]

Let me answer those with what we are currently doing in our remote startup:

1) Team members have to reply to a thread on "What are you working on?" at the end of the day. This keeps everyone informed of progress and blockers.

2) We use the CI dashboard to answer this (any changes to the master branch are auto-deployed to staging, and then staging is manually promoted to production.)

3) We use a Gantt chart to track high-level milestones (usually we go through it once a week to see where we are at).