I think project management gets a bad rap among engineers. Yes, it's nonsensical when estimates magically become deadlines and, yes, spending more time reporting status than actually working is an antipattern. I've been there! But though the implementation might be wrong, the intentions are right. Project management is meant to control costs on projects and ensure we'll ship the right things at the right time, typically so we can coordinate their release with other departments.
Here's my approach toward project management. This has tended to work well for small teams of 3-4 engineers on projects that are essentially CRUD apps, so YMMV!
Assign every project a project lead. This person is responsible for the success of the project. I expect them to understand the state of the project, manage stakeholder expectations, and escalate concerns as they arise.
Project leads should be engineers. I've found it's easier for folks to keep their finger on the pulse of a project when they're in the code every day. This enables them to piece together a picture of how things are going just by scanning the other engineers' pull requests and code reviews.
Distribute ownership throughout the team. Delegation helps junior individuals grow and enables senior individuals to scale as leaders. Try to carve out scopes of work into mini-projects and assign project leads to them.
Make those responsible for execution also responsible for planning. The person who's been tasked with a goal is the best person to figure out how they're going to reach it.
Always form a plan. I've found that breaking work down into phases and writing this stuff down forces folks to think more critically about what they're going to do. They spot dependencies and unknowns sooner. They find opportunities to work in parallel. They identify smaller shippable units of value. As Camille Fournier wrote in The Manager's Path: "The plan itself, however accurate it turns out, is less important than spending time on the act of planning." Also, I prefer estimates to be in weeks or some other unit of time instead of intangible units like story points or t-shirt sizes, simply because it's a unit of measurement understood by everyone.
Expect the initial plan to be wrong. Just as the map is not the territory, the plan is not the project. You'll discover more about the project as you work on it, which will affect the plan. Corollary: the product you ship will diverge from the product you spec'ed. If you're working with product-minded engineers, these are signs of a healthy process because...
Expect engineers to be the first to discover the initial plan's flaws. Engineers are on the project's front lines, translating requirements into code and immersing themselves in the resulting UX. They’ll discover usability gaps that weren’t considered during design, requirements that turn out to be unnecessary, and opportunities to ship a leaner MVP sooner. Listen to them when they find problems and suggest changes! Of course, this implies a need to...
Hire product-minded engineers. This is a bit beyond the realm of project management but many of my opinions depend upon the engineers on the team caring more about shipping great products than just writing code. For my project management process to work, the engineers must be able to collaborate effectively with the designers and product managers.
Expect the plan to change frequently. Surprise! The plan won't be wrong just once – it will be wrong again and again. The project management process should make it easy for those executing the plan to continuously adjust it.
Separate project management from status reporting. The purpose of a project tracking system like a project board or issue tracker is to help the engineers execute. If an external audience uses it to monitor progress, you'll start asking the engineers to change how they manage the project to better serve the audience, to the detriment of execution. I've found that there are more effective means of keeping stakeholders in the loop, such as through update emails, demos, or status review sessions, so you can tailor the content to their needs.