Is PM too expensive for you? Ex-developer shares his honest opinion why you shouldn't skimp on a PM.

Just to give you an idea of how good software is created, let’s talk about Scrum. In general, it is assumed that software projects are built by mature adults (that’s what you expect from your vendor). You don’t want to throw a few youngsters – yesterday’s graduates – into building a sophisticated insurance or fintech solution. You engage mature experts who have at least 5 years of active programming experience in the same area and know perfectly well what bug tracking means, which task they should take next or prioritize right now, why it’s crucial to ping a message to the QA that they can go on with their testing jobs, etc.

This is how it is supposed to be in Scrum. You do things, then you inform the next person in line to take care of things when you’re done. The QA gives it a look and comes back with some suggestions. The dev fixes the code and deploys it straight away, without even creating a bug report (Because who needs a bug report if we talk about a motivated team of adult people working together on a common goal?!) As you can see, there’s no place for a PM on a Scrum project.

A typical Scrum team includes:

• Product Owner
• Scrum Master
• Developers

A Product Owner approaches the team with new ideas on what should be built and how it should work. Yet how things are built isn’t a PO’s area of responsibility. This is what you hire developers for.

Again, no sign of a PM here. If you run through the above text one more time, pay attention to how mature and motivated the Scrum team members should be. They need no one to tell them what to do. You need a spaceship to fly to the moon? No problem, just give us a sec to think how we can do it. Right before you know it, they start with the drawings, google what types of spaceship engines are out there, and swipe through Amazon looking for the spaceship components…But hey, who’s this guy coming? It’s a Scrum master. He is here to make sure that the team follows the Scrum ceremonies, which are:

• Sprint planning

to create a roadmap for the upcoming sprint

• Daily stand-up

informal gatherings to identify roadblocks and discuss current tasks, goals, and obstacles of each team member

• Sprint review

the Scrum team, Scrum Master, and PO meet with other teams, managers, and executives to share their sprint results

• Sprint retrospective

the development team, the Scrum Master, and the PO discuss what went well (and not so well) during the sprint and what lessons they learned from it

No backlog filling, no scope management, no nothing. Just motivation, facilitation and enablement. Even user stories are created by the PO. Ah, let’s have a look at one for a better comprehension.

A user story created by the PO may sound like that:

As a restaurant administrator, I want to be able to generate an annual report to see my restaurant performance.

The user story gets to the team backlog, and the Scrum team gathers together with the Scrum master to discuss what they need to implement the respective functionality. No instructions on how this is going to be done follows from anywhere, it’s only the team who’s in charge. The Scrum master makes sure that the team does their job and does it well through active communication, face-to-face discussions and knowledge sharing. Besides facilitating the development process, the Scrum master keeps an eye on the team performance metrics. You need those to make accurate performance and team velocity predictions, identify bottlenecks and get fully prepared for Sprint retrospectives.

No PM so far. Where’s the catch?

Well, to start with, not all Scrum teams are equally good. There’s a better way to say it – not all project teams are Scrum teams. Moreover, projects may fall apart when individuals leave, or budgets may overrun, or it may take ages to deliver the system. What if it’s a software designed specifically for the Olympic Games and time is a crucial factor? You cannot release an Olympic Games app after the Olympic Games. Thus, a PM was created, to take care of the projects and align customer’s expectations to reality.

To avoid subjectivity, let’s speak the language of terminology. What is a project? It is a temporal activity with a predefined timeline, resources and scope. Thus, we came close to the Project Management Triangle.

The Project Management Triangle is an easy way to visualize how three project constraints – scope, time and budget – are interrelated. A balanced project is the one where a change in one constraint immediately affects the others in such a way that the quality isn’t impacted. So, the PM is a person who makes sure that the Project Triangle principle is adequately implemented. The truth is, your project shouldn’t even be that huge in order to justify a PM’s involvement. Even with as many as 3 talents onboard, if you want to make sure that the project scope that needs to be done is done within the allocated time and budget, go for a PM.

Yet for many the question remains - Is there a correlation between the number of people on the project and the value that the PM brings? I’m inclined to say no: if you have another look at the Project Management Triangle above, there’s no such thing as a workforce there. However, it is clear that an immature PM won’t be able to handle the scope of work, say, from 20 talents (like in this project), or take care of several projects at once, which is a common thing, if several projects come from one client (see this and this).

Apart from keeping an eye on the time, scope and budget, a PM is the main Point of Contact for the client and a chief coordinator on the project speaking on behalf of the client to the team, and on behalf of the team – to the client. If there exists a person who knows exactly what is done on your project, what’s not, and why – this is a PM. 

Yet another benefit from engaging a PM is that he/she is a key project enabler. If someone on a team (say, a newcomer) or the whole team lacks access to the resources they need to proceed with their work, the PM steps in. As a matter of fact, PMs at Symfa use a comprehensive risk matrix throughout the project to proactively identify and settle the risks that may affect timely project delivery (see below).

Let’s add some clarity with a few examples. If for some reason a team in question cannot have their CI done timely, it is the PM who will make it possible (Usually by escalating the issue to the Head of DevOps and fighting for the company’s resources, if necessary.)

Or else, the release scope is unrealistic and the PM informs all the parties concerned about that well beforehand (a heavy burden to carry, I should say). PM also initiates a change of the release scope/team composition/project resources (not too much of a relief for a client, either). Thus, all too often the PM is a carrier of bad news.

Back to the good part – a good PM will leave no stone unturned until he/she enables the team to do their work as expected so that no one has to bring the bad news to the client. Be it a PO, Heads of Departments, Customer, CEO of a Customer - if this is what it takes, a PM will reach out to them all. At the same time, reaching out to the customer’s CEO is considered the biggest failure for the PM, for it is the subtle art of Escalation that PMs should master to be the true enabler for their team.

Last but not least, PM is a team’s megaphone. You surely have a friend or know a friend of a friend who never says a thing. Like, life’s breaking apart, everything’s around burning, but they may act as if nothing is actually happening. Yep, that is exactly how each second engineer behaves under normal conditions. Which doesn’t make a PM’s job anywhere easier.

I might as well have gone without this last point, as it is more about the psychology of team building, not software development, but… Have you ever thought how quickly a good team is formed? Is it a game of chances to find a good team with the great synergy of hard and soft skills, or is it something that can be grown and nurtured in time? I’d say both. Yet different team building approaches specify 4 to 9 roles that make for a well-functioning team. I’ll place here five, according to Peter Honey:

• LEADER: Ensures that the team has clear objectives and that all members are engaged in achieving them. 
• CHALLENGER: Questions the effectiveness of current methods and drives for better results. 
• DOER: Encourages progress and takes on practical tasks to achieve objectives. 
• THINKER: Generates new ideas and evaluates those proposed by others. 
• SUPPORTER: Eases tension and promotes harmony among team members.

With talents constantly moving from company to company and project to project, and given that an average project lasts 6 to 8 months, the chances are thin that those talents can even find their role within a team, let alone play it to the best of their abilities. Without some help, of course. In this case, a PM facilitates team building process by promoting more active engagement from the individuals which under normal conditions – like many of us – are pretty reluctant to accept new people in their environment and show their true personality.

What’s more, those individuals won’t start working as a team from the beginning. Various sources state that it may take from 4 to 6 months for a group of people to actually start working as a team. From my one experience, it may take even longer, subject to different circumstances.

There is no place for a PM in Scrum. Just like there is no place for Scrum in most outsourcing projects. This is due to various reasons: clients don’t wish to overpay for Scrum Master on the project, or the ceremonies the value of which they don’t really understand, or simply because the rates for a team of motivated mature engineers are too high for them. One more reason is the project longevity, which in some cases never reaches the 4-6 months threshold required for the team to form.

Well, PM seems like an option. The one who digs deep into the project, not simply works with the project requirements, but manages the client's expectations and aligns them to the reality. 

From my humble experience, a PM brings more value when engaged full-time on a team of five or more talents. At Symfa we also offer a PM with BA skills as an efficient alternative. It boosts involvement and disrupts existing connections to enable an active flow of ideas. Otherwise, project knowledge is spread in small portions across individuals and not shared efficiently. 

Yeah, I personally like the way it sounds: you get a watchdog, professional organizer, babysitter, and a cheerleader all in one person. Only it destroys the beautiful idea of a self-motivated team of mature individuals. THE team who might even get you to the moon, if only there was a chance. But those are just the cherished dreams of a former software engineer, and who am I to stand in the client's way?

Read more articles from this series:

• Things Clients Skimp on During Custom Software Development Projects: Quality Assurance

Coming soon:

• Clients Skimping the BA part: This is what a BA has to say on the matter.