Compared to product management, project management is more tactical. It is as vital as keeping the strategic vision for your product. Even if your development team consists of only one person, you still need to make sure that all requirements are understood and deadlines are met. Of course, in the team where three co-founders who know each other for years, sit in one room and have the same understanding of the features and user stories there’s not much to manage. However, when you start the project with a fresh team (even if it’s you and a developer), you have a different context, which often leads to misunderstanding.
Communication is key
Most of the problems in software development are people problems that come from not understanding each other. It's the number one problem a project manager should address, especially when working with developers. Most of the engineers are introverted people who rarely share their problems. They rarely argue about the tasks they have been assigned and tend to do what they were asked to even the effort is not worth it. Because of that, you need to proactively ask developers about what they are doing on a regular basis.
Daily standups
SCRUM methodology, which is based on agile principles, introduced the concept of daily standups. Developers hate daily standups because typically they’re a waste of time for them — all a developer does is talks about his progress and impediments, then listens to other team members. Despite the hatred by developers, daily standups are invaluable for a project with a freshly assembled team. Only by using daily standups you as a manager can learn who’s doing what and figure out what problems your subordinates encounter. Without standups, you can easily find out that a developer has spent the whole sprint on a simple issue that was estimated to take a day max. All because she was fixing a bug that she thought was important. For you, the manager, it's evident that the bug wasn’t critical and could be left alone, but for a developer, it was something that was necessary to complete the user story.
Work time overlap
If you are hiring remote developers, it’s essential to have a decent work time overlap between them and you as a manager. Working at the same time allows you to address issues and questions as they arise, instead of learning about them in the morning only to realize that developers were moving in the wrong direction or were just idle waiting for your response. If you can, try to create a schedule where the first four work hours of your developers overlap with your schedule. It's the time when most of the questions arise.
Conflicts
If you have more than one developer or a developer and a designer on your team you need to pay attention to conflicts. Conflicts are typical when you have professionals working together — sometimes they have different approaches or different point of views on the problem at hand. As long as conflicts don’t become personal, there’s nothing to worry about. You need to spot conflicts and resolve them as someone who has the authority to make decisions. It’s important to listen to both sides and make your best judgment. Don’t worry if the problem is technical — most technical problems can be explained in layman terms, and failure to do so might be just lack of arguments.
Micromanagement
Project management is a leadership role. As any leader, you typically have two ways of managing your subordinates. You can be an authoritarian manager requiring them to consult with you on any decision they make under the fear of being blamed for wrong decision or failure. Alternatively, you can become a leader who believes in the team and allows everyone to make their own choices, accepting mistakes and failures as part of the learning process. I recommend keeping away from the micromanagement. After all, you need to hire people who are smarter than you and do everything possible to make their work more comfortable and more efficient. Micromanagement takes a lot of time and energy and rarely yields good results (except for critical situations).
Sprint retrospectives
A sprint is a fixed period used for planning in agile projects. Typically you would have a roadmap that consists of user stories arranged by priority. A typical sprint would be a two-week period where the team’s goal is to implement the set of most important user stories to the point where they are usable to users. After the sprint ends, you need to recap what has been done and what the team has learned. Often clarity about requirements and their implementation comes after the sprint finishes, so it’s important to capture it and refine the roadmap or update the requirements.
Organize the process with Kanban
The key to managing the project well is organizing it properly. One of the most comprehensive ways to do it these days is by using a Kanban board. A Kanban board consists of several ‘lanes’ with the cards attached to them. Each lane represents a state while each card represents a user story your team needs to implement. You can use any number of states, but the three most typical ones are ‘planned,’ ‘in progress’ and ‘completed.’ You start a sprint by marking all user stories as ‘planned’ and then move to ‘in progress’ after developer started working on it.
The Kanban board is a great way to get an overview of who does what and what is the state of the current sprint. You can use either a drawing board with post-it notes as cards or one of the kanban-based project management tools out there. My favorite tool is Trello — it’s free, and you can use it for virtually any project and process you can imagine.
Managing software projects is an art. The topic is so big that you can’t even fit everything in a separate book. However, in a nutshell, the process is quite simple — make sure that you work in sprints, make sure that requirements are understood, ask developers about their progress daily (at least in the beginning of the project) and organize the project visually with the Kanban board. By following these simple rules, you will be able to get pretty far, learning all of the little details during the process.