Ask HN: How do you avoid wasting time on project management?

5 points by jamespaden 4 years ago | 12 comments

I'm shocked by the amount of time development teams spend "managing" projects instead of working on them.

I've been interviewing people for an upcoming software project and it's considered normal for someone (project manager, senior team lead, CTO, whoever) to spend hours every week discussing the plan for the week. Then, of course, the plan changes and they spend more hours moving the plan around.

How do you avoid this kinds of overhead? Any tips or tricks that you've seen work? Does anyone work in an environment where the developers are just trusted to figure out how to complete a project?

mattbrewsbytes 4 years ago |

We break work down into smaller tasks. We don't estimate anything and use Kanban boards to track work. Each column can be prioritized however the PM wants. Due dates are sometimes needed which just changes prioritization.

If there are cross-team dependencies we use feature flags or in cases where we're building something like a new API, agree on the API contract and ship it when ready even if the other team hasn't started. Follow-on items can be created and worked if we need to make changes or if bugs are found after the fact.

We use CI/CD with tests running on every deploy, this allows for deploying anytime and finding when dependencies are broken with new features.

jamespaden 4 years ago | |

Who breaks the work down: you or the PM?

Does the PM ever bother you to get the status of something, or is it always clear from the kanban board? I've seen the "bug the developer for a status update" move a lot in the past.

Agreeing on the API contract seems like a fantastic way to streamline the process!

mattbrewsbytes 4 years ago | | |

The PM breaks down the work and we talk about new items as a team weekly, I (or devs) break down purely engineering work. The board is the status - its in progress, code review or getting tested. There are discussions on things as people work them - that's the small "a" agile practice of "individuals and interactions over processes and tools". Let those minor details get figured out as you work it rather than have everything planned, documented, etc.

nialse 4 years ago |

I’m not sure what your question is. It seems you want to know what management (or project management) is and what it’s good for? That is indeed a good question sometimes and can be quite challenging to figure out coming from a developer background. In general I would say that management exists to make sure the things the customers need (the value) is delivered on time and on budget with the resources available and with the necessary quality. How well management does that varies of course.

jamespaden 4 years ago | |

There's obviously a lot of different project management strategies.

Some companies seem to have project managers assign daily tasks to each developer. The PMs then spend a lot of time defining the tasks and moving the schedule around. They have weekly/daily meetings with other PMs to do cross-project planning.

On the other hand, Basecamp's Shape Up (https://basecamp.com/shapeup) process defines a desired outcome with some clear parameters and a six-week deadline and simply lets the team figure out the rest. There's not a lot of project management happening on a week-by-week basis.

So my question is, what do teams in the middle of those two extremes do? How do teams spend less time on minutia of planning projects and tasks and more time doing?

sharemywin 4 years ago | | |

My 2 cents:

A lot depends on the size and nature of the work. if your project is big enough it needs multiple PMs then there's a lot of time needed for coordination and cross communication.

I do find that asking if a task is 50% done is kind of random and that task should be broken down into something that's more concrete and binary(is it done or not). so it's ok to report 8 of 10 tasks are complete but asking an individual 80% of X is complete is probably not helpful.

daily standups help because it uncovers blockers and helps people admit when their stuck. and can help with redistributing the work.

as for documentation, I feel if you can't commit to documenting what it is you want then it's probably not a priority.

document discovery is a big problem in a large project/org.

you wouldn't write a book without an editor so it's probably good to have a qa person be another set of eyes on what needs to be done.

having a BA/product owner on the business side helps the business own the product and takes alot of the prioritization off of the development side. Having a BA that's done the job using the software helps.

nialse 4 years ago | | |

That is indeed an interesting question. Thanks for clarifying!

afarrell 4 years ago |

Increase the quality of communication between team and thier stakeholders so that there are fewer reasons for the plan to change.

Increase the trustworthiness of the developers' tools, docs, and skills so there are fewer schedule risks.

Decrease the scope of projects relative to the time alotted so there is more slack.