The dark side of agile development 4/5: Why hire a project manager when you can burn out by yourself? | eMan

The dark side of agile development 4/5: Why hire a project manager when you can burn out by yourself?

The role of project manager is often taken lightly. In software development, people look at it like it’s a rack of lollipops in a diabetologist’s waiting room. In today's episode we will explain that this is just wrong. A good project manager will save your project from doom.

In SCRUM we have a list of clearly defined roles:


Product Owner owns the product being developed. They clearly define the vision, priorities and order of tasks, and business logic.

ScrumMaster eliminates problems, mediates conflicts, motivates developers, and safeguards the peace at work. They also monitor compliance with the process and its necessary changes.

Development team (QA, UI, Devs) takes care of individual tasks and develops the product.

Project manager: brews coffee at home.


In SCRUM, the project manager is often forgotten. The PM, over the course of the project, measures using only abstract benchmarks, story points, which express the difficulty of completing the individual parts of each sprint. But where is the direct link to finance?

Suddenly, we realize there is no project manager keeping an eye on a budget that is ever-shrinking.


Let me show you this with an example of agile planning: we need to create Element A. Each team individually estimates its intensity and, finally, we all agree on three SPs (story points). But this is not a very hard currency (such as MD (manday rate) or headcost). Only the product manager understands the actual cost of the three story points, and he/she puts the challenge of the task into context with the client’s budget, thus avoiding financial problems related to spending too much effort on minor issues.


But having a project manager is not enough. You also need to clarify their position with respect to the others in the team, especially ProductOwner and ScrumMaster. Their roles overlap to some extent, and it is important that they respect each other.


Suffice to say, Agile is not all wine and roses. Next time we will bring you the last episode, in which I will ask myself if this is worth all the trouble.

Dmytro Trofymchuk
Division Director