I'm shocked by the amount of time development teams spend "managing" projects instead of working on them.<p>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.<p>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?
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.<p>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.<p>We use CI/CD with tests running on every deploy, this allows for deploying anytime and finding when dependencies are broken with new features.
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.
Increase the quality of communication between team and thier stakeholders so that there are fewer reasons for the plan to change.<p>Increase the trustworthiness of the developers' tools, docs, and skills so there are fewer schedule risks.<p>Decrease the scope of projects relative to the time alotted so there is more slack.