Guide for Project Managers working with development teams

There are certain things project managers must keep in consideration when working with a team of developers that will greatly facilitate the work of both stakeholder groups. 

Project managers and developers - these are two totally different stakeholder groups, which nevertheless have to work together and find common ground in order to deliver a project in a way that meets both the objectives of the business and other stakeholders.

I spoke with Ivana, our super capable project manager, who was happy to talk about her efficient process of juggling multiple development teams and client-side stakeholders, and offer some tips and tricks on successfully tackling it all. 

Read on if you’d like to step up your project management game and impress upper management with streamlined operations. 

 

1. To you, what’s the most important thing when working with a team of developers?

Number one would be providing them with an optimal working environment, where they feel safe and a part of the team. In order to do that, you basically need to be a mindreader; you need to have empathy and be able to connect people to achieve certain goals. 

Because of this, a project manager needs to be honest, direct and a good listener. Diplomacy is key: you need to be a team player who knows how to motivate your team and is calm under pressure. 

 

 

2. What is the thing you’d least want to happen when working with a team of developers?

Being without internet or electricity for a longer period of time - everything else is somehow bearable. As a project manager, you’re in the middle of the stakeholders, project owners and CEOs on the one hand, and the development team on the other hand. 

It’s important to keep the balance between them. You’re in the middle of it all, occupied from all sides, but you need to be able to safeguard your team and provide an environment in which they can be most productive and produce the maximum output. 

 

3. Can you describe your typical daily tasks and activities?

I’m more of an early bird, so I start in the morning by checking my to-do list and prioritizing my tasks for the day. After that we usually have stand-ups and other meetings, after which I go through and complete my daily tasks.

At the end of the day, I usually talk with developers and do a quick personal retrospective and prepare for the next day. I try to find out what went wrong and where I performed well that day, so I can optimize for the following day. 

 

4. How do you facilitate communication amongst team members and with external stakeholders?

We have planned standup meetings and other meetings that follow the agile methodology in project management. There are predetermined maximum durations for different types of meetings, e.g. 10 minutes for a daily, up to 4 hours for a retrospective, and up to 8 for a sprint planning. 

All communication must go through a single channel, and all team members must have access to that channel. For example, we use Slack and create channels for specific projects, so that all team members are kept up to date and able to follow. 

Also very important is the documentation - in addition to a good team, a project’s success depends hugely on how well prepared the documentation is. The documentation is the core of everything; it happens more often that a project underperforms due to poor communication rather than due to a lack of skill.

 

5. How do you resolve a conflict within the team or across different teams working on the project?

Well, I do my best to prevent conflict, to act as a mediator and take preventative measures rather than a curative approach. It’s important that the team feels as one, that all team members are involved in the communication. So, as a project manager, it’s also vital that you aim to reduce distractions as much as possible. 

One of the worst things is when a stakeholder bypasses project hierarchy and gives developers additional work without consulting you first. This disrupts their workflow and causes them to skip certain tasks. Additionally, as soon as you skip someone, the entire system of keeping everyone up to date breaks down. 

On the other hand, a small, healthy conflict is actually a welcome thing, it can be an indication of a well-organized and functioning team. There’s enough psychological safety within the team for members to exchange opinions without worrying about how they will be accepted. 

If everyone is always too friendly and supportive, someone may not even argue with a certain point and instead just agree on the basis of friendship rather than the value of that point. So, if a conflict is done in a healthy way, it can even be beneficial to the team and its work. 

 

6. What do you do if something goes wrong with the project? How do you mitigate this (especially if the mistake wasn’t spotted immediately, but further down the line)?

I have a story here. During flight training, pilots are told to always sit on their hands when the plane starts to descend, so that they don’t panic and start frantically pressing buttons. 

I’m a big proponent of that when something goes wrong, it’s better to take a few minutes to think it through and then react - still, the reaction then needs to be quick, so that you don’t fall (in the pilot example). 

It’s better to take a second to take a few deep breaths and then react, rather than reacting quickly and then reacting quickly to your quick reaction. It’s similar with a project manager - think first, then react, while keeping in mind that the moment for consideration shouldn’t last a whole week or something.

If you spot a mistake quickly, you can typically solve it faster. If you need to do a complete refactoring, the general message to all stakeholders is “Honesty is always the best policy to practice”, especially for bigger things or during the end of projects. 

It’s key that they are aware of it and that you provide them with data as to why something went wrong, and of course give them new timeframes. The sooner you do it, the better it is. Fail fast and optimize. 

 

 

7. How frequently do you check up on team members working on specific tasks or parts of the project? How do you guarantee timely delivery?

We usually work within agile frameworks, where we plan sprints with estimates, which are mostly either in time or in story points. These estimates are essential to planning sprints and achieving sprint goals. 

There typically isn’t really any daily checking in the strict sense of the word. You just check if everything is within the planned scope; if it is, you try not to interfere, but if things start to drag, then you try to talk to the team and find out if someone has specific problems with something. 

The catch is, the longer a team works on a certain project, the more accurate the developers’ estimates become. It’s vital that you find the bottleneck in the framework of project management, then follow the flow of retrospective, adapt and apply. 

As for guaranteeing timely delivery, I try to minimize the context switching, so, not constantly giving developers new tasks, but instead allowing them to finish their main ones before unloading new work on them. 

I personally have to do a lot of holding back to not go to them whenever I need something urgent. It would just reduce focus and quality, while putting additional pressure on the developers. 

 

8. How do you keep stakeholders aligned?

Here I have another real-life example. At a previous job we had a stakeholder who always wanted to be involved and change stuff. So we had to distract him by constantly giving him new versions of the application to test, which allowed him to feel as a part of the team, and he stopped getting involved in everything.

It’s also very important that everyone understands the relations within the team, that a stakeholder has to go through you to reach a developer, and vice-versa, of course.

This is why tools that allow stakeholders to participate (e.g. design systems) are gaining in popularity. But you need to take care that they don’t get too involved and micromanage everything - that’s why they hired you, after all.

It’s crucial that stakeholders are familiar with your project management framework; that they know the difference between waterfall and agile, and which one you use. Then they understand the process better and can follow more easily, they feel more a part of the team and its work. In the end, it is their project.

 

9. What (project management) tools would you recommend to project managers in this position?

At first glance, they all serve pretty much the same purpose. It’s only when you use a tool for a longer time that you start noticing things that are bothering you or that are difficult to do with that particular tool - I think you can find both of these in pretty much all the better-known tools.

At Agiledrop, we have a really well structured process for onboarding new developers, and we rely largely on Teamwork. We basically follow the same high-level of practice both in the management of external projects as well as in recruiting new employees and integrating them into our workflow and culture.

Our clients typically use JIRA, Asana or Trello, and we adapt to whichever system they’re most comfortable working with. Personally, I like JIRA best, as it also has Confluence and Git integration.

 

10. How does the project management of developers differ when you have an in-house team as opposed to a remote team? Is there anything specific that you need to be mindful of with a remote team? 

The thing I’d like to highlight here is that an advantage with an in-house team are the coffee maker chats, where you have those casual conversations about a project while you’re waiting for your coffee. However, it often happens that these discussions don’t get documented and thus ideas never get realized. 

With remote work, it’s really extremely important that you have good documentation of everything, and then to also have a single communication channel and to keep all team members informed. 

And when you have good documentation due to the remote nature of the work, it’s much easier to bring new people into the project, because everything is documented somewhere - it has to be, because of the very nature of the project. 

So, to me, there’s no big difference between in-house and remote project management, except for missing out on coffee maker talks. But, as I said, they often go undocumented and forgotten anyway. The documentation itself is then an advantage that remote work has over in-house work; since good documentation is necessary, we’re forced to be more proficient. 

 

Ivana and three developers at an AgileSport - being able to relax together is also a sign of a good team