29 August, 2019
Hi, my name is Marcin and I’m a Project Manager (“Hi Marcin” audible in the distance…). This article is mainly addressed to developers, QA engineers, DevOps and designers from software development companies who, there’s no need to sugar-coat it, love to hate me and my fellow PMs. Working with us is, best-case scenario, a pain in the… neck. Or, worst-case scenario, tortures and crimes against humanity. However, I would like to introduce you to the PM’s side of the story and show you what challenges we face every day. Why does your Project Manager suck? Let’s find out!
Many of you, dear developers, think that project managers waste your time and boss/babysit you around. All the time we’re: managing (while you know better what to do), coordinating (geez, it will be ready when it’s ready!), monitoring (you just love when people stand over your shoulder when you try to work, don’t you). What does all this useless nonsense really mean?
Well, it basically means that someone needs to shield you from the clients (and vice versa).
In your eyes, our duties might seem like some counter-productive mumbo jumbo but let me tell you something – we do more for the successful software development projects than meets the eye. So, today I’m going to address the five most popular whines… I mean issues, I’ve heard from software developers throughout my career.
1. Why do I have to take care of tasks’ status? I’ll do that at the end of the sprint.
Believe it or not, maintaining order in a chosen task management tool (such as Jira or Trello) can significantly improve the performance of the entire team. First of all, everyone will save a lot of time. Imagine a situation where each member of the 10-person team wouldn’t update their statuses in Jira. Effect? Nobody knows at what stage the rest of the team is with a given sprint or whether a colleague sitting next to you is doing the task they supposed to.
Secondly, imagine the project manager or (let’s make it even worse) the client enters the board to check how the sprint delivery is going and sees that a few days before the end of the sprint most tasks are still “in progress” or in the “to do” status and absolutely nothing is delivered. Heads will roll… Fortunately, not yours but you will feel consequences too – that kind of negligence will cause a lot of pressure and your favourite notorious questions: “Where are you with this task?”, “Why do you do several tasks at once?”, “When will this be finished?”, yadda, yadda, yadda.
I find no pleasure in asking those questions myself but clients are always in grave fear that the project won’t be delivered on time. That’s why I must devote hours to determine the current state of the sprint. And you are forced to update the status anyway – so, maybe it’s better to do it on a daily basis than at the end of the sprint when it’s really taking a long moment to remember and write down what you did or didn’t do.
Finally, I often hear the sentence: “Well, it went to the QA and I don’t know what happened with it”. If everybody updated the statuses, you would know, QA would know, I would know and the client would know. Also, annoying questions magically disappear! Simple as that.
2. What’s all the fuss with time logging? Done means done.
Money is seriously at stake here. When software companies are outsourcing developers’ work, they settle accounts with an external customer that ALWAYS wants a report including logged hours. Why? They want to compare them with timesheet – a document which is the basis for issuing invoices. And guess what happens if the numbers don’t match? Before you know it, the client is making phone calls, writing emails and sending post pigeons to project managers asking for an immediate explanation why they were charged for so many hours, when they can see in the management tool that the developers weren’t working that long. At this point, it’s too late to log those overdue hours in Jira because it will look suspicious.
Take my word for it – you don’t want to be in a situation where you have to explain to the entire management of your company that the client doesn’t want to pay for the work already done. That’s why we are trying to make sure that the whole team, without exceptions, always log their time.
It’s not a way to control whether you’re slacking off. It’s a way to prove to our clients that we’re NOT slacking off. And everybody wants to be paid for the jobs they’ve done.
3. I did the task as it was described. The fact it doesn’t make sense is not my fault.
Well, technically it’s not your fault. But the blind performance of senseless tasks is not a way to go (and certainly won’t help you being promoted). And YET AGAIN will trigger a time-wasting avalanche of questions from PM, whose only concern is to protect the entire team. After all, it won’t be you explaining to the client that a given task was already described and approved and that’s exactly what developers did.
The solution is really easy – you see something weird? Just raise an issue in advance.
In most cases, this situation occurs when Refinement Backlog isn’t done quite well – why? Because PM only has two hands and no time to teach the team how to do it. Because there’s a general I-have-no-time issue among developers. Because of pressuring deadlines. Because of constant changes in the project. Because the task wasn’t described correctly nor verified during Planning. Go ahead, pick your reason.
All aforementioned cases are very bad practice in the long run. I promise to tell you more about the correct course of Refinement and Planning in another article, but for now, let’s return to the topic.
So what would PM expect from a developer in a situation where the to-be-coded task doesn’t make sense for some reason? Firstly, remember that you’re not alone with this – you should mention the problematic task during a Daily and ask the team to discuss it. Two (or more) heads are better than one and believe me, together you’ll find a solution quickly. After determining what is wrong and how to fix it without ruining the rest of the project, you should talk to the PM and propose a new version of the task. After the re-estimation and client’s approval, you can return to work.
By communicating problems, you significantly relieve PM and won’t cause frustration of the client who will be aware that their project is fully controlled by the responsible team. And you will be able to become a developer who has a direct impact on the project’s shape, show your maturity and use your professional experience in practice.
4. No can do. Someone else must first complete their task and make that little change I need.
a.k.a. the problem of task granulation on the development side.
Have you ever wondered why you decompose the scope of work to the smallest sensible element? The process of decomposition will also appear in the next article, but for now, I’ll try to explain in general – doing too many things at once just doesn’t work. Imagine a situation in which several developers need a simple change in the code, otherwise it will be a blocker for all of them. Instead of making a branch with this small change and merging it as soon as possible, developers often come up with a brilliant idea that someone will do it when the opportunity occurs.
That creates two problems. Firstly, we don’t know when and who exactly will finish this task (let alone the mandatory tests performed by the QA team). With good luck, if there are no errors, this task can be completed quite efficiently, but other developers will have to wait patiently to start their own tasks (wasting valuable time, anyone?). Secondly, the client will definitely ask: “This small change has a task that has no coverage in branches, so how could it be done?”, followed by: “How much did this change will cost us, since there is no logged time because there is no branch?”. From a developer’s perspective, these questions may seem stupid, but I guarantee you that these are real-life examples. This is not what the business expects from us.
Business isn’t familiar with software development, but it needs simple tools to determine whether the implementation of a given functionality has paid off. And since we create the code and are accounted for it, the client wants to see the effects in the form of branches and commits pinned to tasks in Jira.
Between these two parties, there’s a conflicted project manager, who completely understands both the arguments of developers and the character of the business, and must choose the lesser evil. Unfortunately for you, most of the times it is developers who are going to be told off to follow the established rules, properly manage the repository and the division of work. Business is business…
5. Why does my PM constantly organise meetings? Planning, daily, refinement, retro, review… I waste the time that I could otherwise spend on writing code (or browsing funny cats).
Yes, you could devote your time to coding but (everyone likes a good “but”, right? 😉) do you know exactly what to do or will you rather hit the client or PM with a whole list of questions as soon as you see your tasks for the day? All these meetings have their specific purpose – to facilitate your work when you turn on the computer, put on your headphones on and enter the Matrix to cut off from the surrounding world.
Those meetings are the opportunity for the team to plan work so that each and every one of you can sit down and, without any interruptions, continuously write code, test it, etc.
Examples? Here you go:
- Refinement – understanding customer’s business requirements. You should ask the client all the questions you need (if they are present in a meeting) or write down a list of questions that will be forwarded to them.
- Planning – choosing tasks for the sprint and listing technical sub-tasks that are required to finish everything on time in a sprint without wondering how something should be done during subsequent implementation.
- Daily – updating team knowledge about where you are with delivering a sprint
- Retro – recapping what went wrong in the previous sprint and what can be done to improve the situation
- Review – providing the client with what was done in the last sprint
When do these meetings make no sense? When they are badly run.
If the whole team really focuses on the value of the meeting, you will get over with it very quickly, will be able to return to your duties sooner and be more satisfied with the work you’ve done. Therefore, if you think that you are wasting time on meetings, it means that they are badly run and/or you don’t pay attention and/or you aren’t needed there.
The one to bring the balance to the force
The role of project managers isn’t being the most important people in the room – we just have to be the most responsible ones. Designers want trendy effects, developers want faster loading, QAs want everything to perform smoothly, the client wants everything done for yesterday, the CEO reviews every penny. And we just want everyone to work and prosper in peace.
Although sometimes it may seem that project managers are making your life more difficult, as you can see from these five examples, their behaviour is usually justified by care for both developers and the project itself. I hope that this will allow you to be more forgiving to your PMs and to get more involved during the meetings (which will also be super beneficial for you). Remember that technical knowledge in this profession is not everything – soft skills are equally important.
So the next time you think your PM sucks, think about whether they do it for you.