
Ask HN: What are some good tools for keeping a software project on track? - bnchrch
Hey!  I&#x27;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.<p>Things like:<p>1. Know what each other are working on? (progress&#x2F;blockers)<p>2. Know what is currently deployed to production and staging? (heroku)<p>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.

~~~
jwdunne
Another dark side to tools is that they are a vector for procrastination. You
can convince yourself (or justify at least) that you need a new X and that's
the answer. You'll spend a few hours evaluating various Xs.

You might end up using it for a few days but then you quickly fall back to the
tools you usually use.

I've seen this with email clients, todo apps, project management tools, etc.

~~~
vram22
True. Tools paralysis, like analysis paralysis ...

~~~
jwdunne
Analysis of tools paralysis!

------
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](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](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://zube.io)

[https://www.pivotaltracker.com](https://www.pivotaltracker.com)

[https://basecamp.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).

------
edimaudo
If you want to keep a software project on track, tools are secondary. The most
important things are proper communication, good people management and some
luck.

------
sirrele
1\. ____JIRA __ __ <\------ This is what you are looking for.. 2\. Testrail <3
QA + JIRA 3\. Confluence <3 JIRA 4\. OneNote [Mac's Desktop App > 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!

------
camclay
Basecamp. Have tried Trello, and it's great for concisely scrumming specific
small projects, but Basecamp's won us over with it's ability to manage
multiple concurrent projects.

Project Management (Campfires), ability to set To-Dos, keep track of Docs &
Files, and look at a master schedule is awesome.

You can quickly go from an overview to nitty gritty, and its easy to see what
you and your team have accomplished.

------
a_imho
Individuals and interactions over processes and tools.

~~~
busterarm
Definitely this.

Responsible people who care about the work and have a spine when required are
what keep projects on track.

------
klenwell
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-...](https://workplace.stackexchange.com/questions/32765/what-is-the-
purpose-of-1-on-1-meetings-with-your-direct-leader-boss)

~~~
mpfundstein
Great post. I am in the situation and can confirm that this works. I don't do
the 1-on-1 though but will introduce them soon. It's a great idea.

How involved are yiur developers in the design process? Do they work in a
whole story from a to z or do they get handed over requiremebts, ux and ui and
then only work on the inplementation? I am trying to get a real a to z process
in place, but its quite hard

~~~
klenwell
We have the luxury of having a good UX/UI designer on the team so I am happy
to defer to her on design questions. These should be spec'd out in the Trello
card as a checklist and mockups attached in an easily readable format so that
any questions can get addressed and hashed out in the grooming meetings.

In teams without a designer, I'd recommend picking a well-documented frontend
framework like Bootstrap to establish a baseline and make sure there's a
functional UAT process in place.

As far as getting a process in place, I agree it's challenging. Scrum provides
a great foundation. But as the regular threads on scrum in Hacker News show,
many orgs adopt it without really appreciating how it all fits together and as
a result there's a good amount of well-earned resistance to it. At a previous
company, we initially brought in a consultant for three days of in-house
training. I believe it was money well spent. But we still managed to screw it
up in critical ways.

I think establishing and documenting best practices is important, for both
process and coding. I'm a big fan of checklists and transparency generally. A
lot of my effort goes toward establishing consistency and eliminating
surprises.

There's also the Joel Test, which is another good way to measure dev team
health and smooth out some aspects of the dev process:

[https://www.joelonsoftware.com/2000/08/09/the-joel-
test-12-s...](https://www.joelonsoftware.com/2000/08/09/the-joel-
test-12-steps-to-better-code/)

------
jaequery
unfortunately, there is no one good tool. you'd have to use a combination of
Asana, JIRA, and something like Productplan.

it is quite interesting to see that no one has yet created one that combines
all three in a simple / minimal interface.

------
ajax100
You should check out Standup, it makes it easy to track what everyone in your
team has been working on:

[https://getstandup.com/](https://getstandup.com/)

~~~
sencho
You should have picked www.getupstandup.com as the domain!

------
sAbakumoff
1\. Jira is awesome for it.

------
anotheryou
How do you guys manage large backlogs? Tiny bugs or nuances with low priority
that just accumulate and are a pain to review again because you are not even
sure they are still reproducable.

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

~~~
rabidrat
Is there a way to have a backlog board with github issues?

~~~
PeterisP
Assign them to a milestone 'backlog', and have people filter the view so they
see only the milestone(s) 'we will actually do this'.

------
wheresvic1
If you are looking for something simple I can highly recommend Trello.

It is very flexible - you can label tickets, assign them and you even have git
integration!

------
speedracr
Post-its are hard to beat because they function as a backdrop and everyone
walks by a couple of times per day, whether they want to or not.

For remote teams that run on Slack, give [http://www.slash-
done.com/](http://www.slash-done.com/) a try - a good friend of mine had this
built after missing a simple way of having everyone check in once their tasks
were completed.

------
zwetan
simply look at the tools you can find on Github or similar: issue tracker,
wiki, versioning of release, etc.

------
Walkman
not tools, however these are the best: your brain, your mouth and some things
you can write with. Maybe a computer.

~~~
biot
The computer would certainly help convey the speech and writing to the remote
team.

------
gaius
The only project management tool I've ever seen work effectively - I'm not
even kidding - is a whiteboard with Post-it notes stuck to it. Everything else
is snake oil.

~~~
zwetan
how do you make that work for a "remote team" ?

~~~
dasmoth
Something Trelloesque is the obvious answer, but I'm curious if anyone's tried
whiteboard+webcam.

~~~
gaius
_whiteboard+webcam_

You could call it a trelloscope

~~~
akoncius
holy shit, good name!

------
dreamdu5t
Lines of communication and chain of command are more important than tools. The
only person who should need to know what you're doing is who you report to.
And so on all the way to the top.

Trello, jira, aha, whatever won't help if you don't have clear lines of
communication and a chain of command

------
vermooten
'On track'? Really? Dude it's 2017, not 1997.

