How can I effectively manage project tasks?

January 8, 2013 6:42 PM

I'm a senior software developer who has been working as a project manager/project design lead for the past year. Essentially, my role is to manage the tasks involved in developing web applications. What can I do to become more effective? Are there any books on the subject? Help me improve!

A few more details...

We currently use the agile methodology, although we aren't strictly by the book. For the most part, we pump out iterations of code through sprints to clients, then have them test this code in a testing environment before signing off on it to be published live.

What am I looking for? Well, I'm looking for tips of being as effective as I can at managing these tasks, whether it be in estimating timelines, managing developers, dealing with clients, and helping them through testing. What are some good books and websites on the matter that I can learn from?

posted by MMALR to Technology (4 answers total)

Best answer: The Art of Project Management by Steven Berkun.
posted by infinitewindow at 6:57 PM on January 8, 2013 [1 favorite]

Best answer: Yep, that's the one I was coming in to recommend too, except the second edition has a new title, Making Things Happen: Mastering Project Management.
posted by mendel at 7:38 PM on January 8, 2013 [2 favorites]

Here in Silicon Valley and SF, the Pivotal Tracker is the gold standard. There's a lot of online documentation and community forums about how Pivotal Labs uses the agile development method and the tracker - many companies are emulating them.
posted by amaire at 7:58 PM on January 8, 2013

Best answer: Seconding Pivotal.

One angle to consider on your road to improvement is just what you consider your weaknesses to be. What are the pain points in your development process? What are your clients (or devs) unhappy about? Take stock of these things after every sprint, and see what if anything needs to be changed.

I'm not a project manager, but I do work under a very cool project manager. I don't know if the remaining thoughts are super-obvious for someone with some experience but here goes anyway:

What features should we build this sprint?

1. Have your clients tell you what they want, in the knowledge that they won't get everything they want right away
2. Have your developers estimate the cost (in time and money) for those features
3. Go back to your clients and ask them to rank what they want, knowing the costs of those features
4. Go down the list of features requested in the client's order of preference, stopping when the cumulative cost exceeds the capacity of the sprint in time or money

How can we estimate accurately?

1. Get the developers together. For each feature, decide on what criteria would tell you when that feature is "done".
2. For each feature, get the developers to make a list (or better, a tree) of the tasks they expect will be required to get to "done'
3. For each item in that list (or each leaf on that tree), have each developer secretly guess how long it will take.
4. The estimate for a task item starts out as the median of the secret guesses. BUT if you have an outlier that thinks the task might take way longer than the rest of the devs, let them briefly have the floor to explain their reasoning, and see if the consensus of the room changes. If you have an outlier on the low end, unless they're saying "it's already done and tested", you should probably not adjust downward to take them into account.
5. Add the task estimates to arrive at the feature estimate.
6. Do this before you talk to the client about priorities, and definitely before you decide what's going into your sprint! Otherwise, people will fudge estimates to make the sprint seem like it's going to work.

Thoughts on testing

Consider making a spectrum of passing unit, layer, and end-to-end tests part of your criteria for when a feature is done. If code has some unit tests- I'm not talking 100% coverage, but >0% coverage- then when that code participates in larger and larger levels of integration, the tests that exercise those levels will correspondingly be more likely to pass.

Focus your tests on what your team gets wrong the most. Hopefully you're getting error reports from your clients (or if you're hosting everything, your own logs) that you can use to get a sense of the most common problems. Ask your team to include tests that make sure they're not making those common classes of error.
posted by a snickering nuthatch at 11:13 PM on January 8, 2013 [1 favorite]