How do you track what you and your team are working on day-to-day?

Question

I'm struggling with how to keep track of what myself and people on my team actually do each day. I get a good broad picture by going over completed cards each week and stand-ups help a bit, but I feel like I don't have a good handle on the day-to-day workings of my team. Cards will stay in progress for days on end without an update at the daily stand-up, and some engineers are my team aren't the most communicative.

I've thought about implementing some sort of daily record that everyone fills out (via a mailing list or a shared google doc) but this seems fairly cumbersome and manual.

Monitoring GitHub activity does an ok job but can be a little bit overwhelming with how many emails it sends out everyday. I've thought about trying to build a digest system for it, but don't have the time to spare.

What strategies have you implemented to stay on top of what your team is doing everyday so that you can measure work on "in progress" tasks?

Answer 1

I talk to them.

Technology cannot solve social problems. You have short morning standups. What did you do yesterday? What will you do today? Any impediments?

If something sounds fishy (or I'm curious), I stop and ask questions: "You were working on XYZ yesterday, how'd that turn out?". This forces people to pay attention, and to actually know what's going on. It also keeps you the team lead in the loop (and paying attention, and knowing actually what's going on). This needs to be on time, and short (10 minutes max). Anything else and people won't "shelve" work. They'll stop and wait for the standup and then take time to get started again. Some will do that anyways, but it's largely unavoidable.

Then I stop by everyone's desk in the afternoon. Not every afternoon (though it might be more than every afternoon for new people), not at the same time, but around the same time (so it's both informal, and regular). "Any problems? Any impediments?"

You'll be surprised how often you'll encounter problems when people are one on one.

If people have no problems, great; get back to work. If they don't have problems all week? Problem. You're not challenging them enough, or they're not opening up. Ask how XYZ (that they mentioned in standup) is going. Make them explain things.

This isn't micromanagement. You're not telling them how to do their jobs. You're not babysitting them. You're there to remove impediments from their day to day life. You need information to do that. As long as you keep your team out of meetings, and project managers out of their cubes, then one person stopping by to help once a day isn't going to cause them grief. But all these interactions need to come from the "I am here to help you" vein.

Another thing I will do is review changesets (by myself, informally). I can then see how frequently people check in, how large their changesets are, how that matches what they reported, how often they re-do things, how many bugfixes they have, and so on. A work item changing status to "done" is nearly meaningless. Look at the code. Does it seem done?

note: One extremely serious side point: how big is your team? Is it more than 7 people? Of course you won't be able to keep track of everything going on if your team is too big.

Answer 2

Don't micro-manage your developers!

Productive software development requires long stretches of concentrated mental effort. It's not realistic to expect them to produce constant output. If you begin measuring them on a daily basis, they will restructure their work so that they always produce some discernible artifacts for you to see each day. That may or may not have a positive impact on your software quality. It will almost certainly have a negative impact on your developers' efficiency.

Answer 3

As Robert Harvey suggests, don't micro manage your team. Give the team some prioritized tasks with concrete business value and let your team figure out best how to deliver this business value.

If the team delivers business value, then you should be happy. How they go about making sure that they deliver the requested features should be up to them.

However:

Cards will stay in progress for days on end without an update at the daily stand-up

This could indicate that there is a deficiency in the process.

It could be the team that is not really functioning as a team, and not stepping in to help each other out when they are stuck. It could also be the communication with the business. The tasks are too big, so it becomes difficult to figure out what is needed. Specifications are not clear.

It could also be that there is no real problem at all. Maybe the team just works fine with cards representing major pieces of work that takes days to complete, and maybe the team is working fine to achieve this.

I think that it is valid to use the retrospective as a platform for expressing your concern. Sometimes it's a good thing to receive observations from the outside.

But let the team figure out if there is a problem, and what is the cause of this. And be ready to accept that perhaps you need to adjust the way that tasks are delivered to the team.

Remember that the daily stand up is a tool for the team to help them organize the work; it is NOT a tool for managers to keep track on what the team is doing.

Answer 4

'Push messaging' not 'pull messaging'

A developer will often get to one of the following states that matter to you:

1. Yaaay, I did X !
2. I'm working on X, but it looks like it will take a prolonged time...
3. I'm stuck on problem Y, am researching it but might need advice;
4. I'm blocked because I'm waiting for A,B and C.

Ideally, you want to have a reasonably up-to-date information on these statuses without disrupting actual productivity. Constant "Are we there yet?" is counterproductive, but it may be that you can do something useful for states 2-4, so you need to get informed about them.

What will work is a culture of 'push messaging', preferably in an automated way. You may not need to look at the whole commit-log, but you can make a "dashboard" where you see the latest commit or the latest solved ticket (for bugs or features) of every teammember. For the rest of the situations, you can get them to e-mail you proactively with such updates (hopefully they are more rare than commits) or go and ask them if you're not seeing continuous progress on whatever dashboard - if you have an internal agreement that getting stuck needs to be raised (it might be that some feature isn't needed if it turns out that it costs 80 hours not 8 hours), then either they'll keep you up to date or get bothered by you.

Alternatively, you may make a culture of something like https://idonethis.com/ daily reports going out to the whole team - this will ensure that others are on the same page as well.

Answer 5

An alternative to some of the other answers (communication focused) is that perhaps the tasks on your note cards can be broken up into smaller pieces which you would then be able to get feedback on sooner.

With smaller pieces the team feels like they are accomplishing something every day which should reflect in the stand-up.

The drawback is these separate cards will likely rely a lot on each other. A team which is able to communicate very easily with each other is beneficial here, or pieces may not combine as well as they should. You may also need to hold some of the cards back if you need certain things done first.

That being said, people will still get stuck or find out a task is much more challenging than they, or you, anticipated from time to time. This is why it is still helpful to discuss issues openly in the stand-up where others can offer advice without judging the person having troubles.

To answer the issue of micro-management as some of the other answers have brought up: even though people will accomplish small tasks each day it will take a broader view of their accomplished work to get a sense how much each person is actually getting done, rather than judging them by their daily accomplishments.

I suggest this because I work on a team of 8, where communication is very easy and people are very approachable. We are given tasks that are never expected to take longer than two days worth of work. Sometimes these tasks are closely related and we need to keep each other updated on how we each go about our own piece. We are each responsible for reporting what we've accomplished every two weeks to our manager.

---

After reading the question again, I realize you may be asking this as a team member, not as a leader, and so you may not have control over your tasks.

1. You could suggest to your leader to break up the tasks more
2. If your work is getting blocked or depends on work by another team member, feel free to check with them on it and take a different task if you need to.

Answer 6

First of all you need to analyze yourself in terms of your time and skills. If you are a technical person with some previous hands-on experience things may different from those in case you are just a manager (not with strong technical knowledge on what your developers are actually working on) who only needs to make sure that deadlines are met.

The common point in both the cases is that you need to be able to facilitate your team and create a feeling that you trust them. You are not judging their performance but are trying to be empathetic and helpful in making their experience fun and easy.

Now assume that you are just a manager as i said above, in that case even if some developer is really facing some serious development related problem you may not be able to help her/him. The actual problem can be time consuming and will demand concentration as well. Further assuming that the developer is really sincere to his/her job and paying full time (even extra time ) to resolving that problem but unfortunately still not able to solve it. And in such a situation (when your are not even able to understand the problem fully) you keep on asking about the issue by taking progress everyday and even informally twice a day. The result would be extreme frustration and disturbance for the developer. Whether its an app for gathering daily progress or its just daily standup meeting both can be frustrating.

On the other hand, keeping all the other factors same, just assume that you have strong technical background and have worked on the same technologies in the past. In this case, taking daily progress or having standup meetings is really helpful. Developers will surely trust you and your expertise and will be comfortable in discussing the big challenge they are facing. You'll provide some suggestions which can be helpful or even if they are not directly helpful they'll help in providing some alternative approaches.

However, in any case daily standup meetings must create a sense of you being a team member not a head/lead/manager. Unless your team members consider you at the same level as they are, they won't be able to communicate their concerns/suggestions/problems/feedback etc.
Another point to be considered is the size of your team and the time you have for managing them, before thinking of using some automated progress tracking software or increasing your interaction. You need to make sure that whatever concerns have been raised by your team, you are able to resolve them asap. A major demotivating factor for a team member is that their concerns/suggestions/feedback is not taken seriously or is not valued. Knowing the daily progress is important but only in case you are fully involved in the team work. If you are involved in some side businesses as well, don't try to interact more with your team. Think of a situation in which your team's response is overwhelming and they are submitting their tasks well before time, raising concerns and queries but you are unable to provide timely feedback and reviews. In such a situation, your influence as a team lead will be greatly reduced

Answer 7

Create and make good use of various IM chat rooms for the various configurations. Some may be broad like @engineers and some may be specific such as @newFeatureA

Consider making daily standup include a review of in-flight tickets.

Use a open environment that supports collaboration and make sure that QE and the primary product owner sit in the middle of the developers. You'll overhear a lot and get an idea from seeing screens around you.

As Robert points out, above all don't be seen to be micro-managing (note the use of 'be seen', i.e. regardless of your actual intent).

Ultimately we track what is accomplished over time and see what our velocity is from that. Focusing on during-the-day progress is counter-productive as people will become demoralized and/or leave.

Answer 8

I'm surprised that no one here has yet mentioned "followed" or "starred" repository messaging built into systems like GitHub or BitBucket.

Our technical stakeholders (project leads, development and support managers) all follow our issue and commit update histories on their relevant projects. We have a small team (15 FTE + contractors), but this seems to work for us to

No one is measured on any of these things, but in addition to weekly status reports from the PM's, this gives a daily view into the project to at least keep everyone aware of what areas are being worked on so no one goes without visibility.

It's also helped to increase transparency across developers and contractors and our business liaisons which helps everyone be accountable to their deliverables schedules.

When combined with RSS feeds associated with specific repositories or across our entire organization, we've been able to limit emails (where wanted) and offer a similar set of data in real-time and in summary via RSS readers. For some users this is Outlook so it's basically email for them, though slightly different, but for other users they use a full-fledged RSS client with all the extra filtering they need to customize it to their exact needs.

We ran into similar concerns about email volume at first, but our end-users came up with the RSS system without the Engineering Org having to do much besides suggest clients for those not using Outlook. Worked for us, again around 20-30 FTE + Contractors throughout the year across multiple offices and time zones. YMMV, obviously.

Answer 9

This is a very marginal addition (and it isn't programmer specific), but I've had good success with Asana in recent projects.

For integration with existing online collaboration tools, look no further than Slack. It's built around a chatroom, but it serves as a fairly minimalist hub for other tools including Asana, GitHub, and Bitbucket. It has a decent collection of these "integrations," both pre-made and community-made, using the API that of course allows you to build your own.