Agile methodologies dominate IT. As the world is long and wide, people are training to be product owners and scrum masters. Traditional approaches to IT projects are in retreat. Instead of schedules, burndown charts and kanban boards reign today. Classic waterfall is criticized for its inflexibility - sluggish response to change and low team commitment results in notorious overruns of schedule, budget and customer dissatisfaction. PMP, or Project Management Professional certification, run by the US-based Project Management Institute, is associated by many with precisely the traditional cascading approach to IT projects. Yet in today's world, project managers are no longer needed, but scrum masters, right?
Not really. The following text explains how misunderstanding the role of a project manager and the assumptions of PMP certification can lead to the above erroneous conclusions. We will write about what a project manager does and what a scrum master does not do, and what the Project Management Body of Knowledge (the substantive basis for PMP) really is. I invite you to read it!
Isn't Scrum a cure-all?
The IT department of a certain medium-sized pharmaceutical company decided to switch to agile software development. A scrum master and a product owner were hired to represent the business. The company decided to expand its CRM system internally. The product owner got to work, interviewing business units and preparing a backlog of user stories according to his understanding of the needs.
Work on the project progressed smoothly, and everyone was happy with the transition to an agile model. The scrum master correctly led the daily meetings, planning, retrospectives. The product owner reviewed new functionality and managed the backlog on an ongoing basis. He was able to focus on this, as he was not torn away from the day-to-day operational work of the business departments. The director of the sales department was also happy because no one was pulling his people away from current tasks. This was especially important for him, as it was the last quarter of the accounting year - the sales department was working up a sweat to achieve annual goals.
When the new accounting year arrived, the sales department took a breather. Its director longed to see what the IT department had produced for him so far, and was very disappointed. Unfortunately, it turned out that the hired product owner did not understand the business needs well. The functionality produced corresponded to the product owner's vision, but this vision did not coincide with the actual requirements of the sales department. The project was a failure and the work had to be started from scratch....
Project management is key
The above fictional story illustrates what can happen if a company focuses only on scrum methodology, forgetting the actual management of the project, including stakeholders, communication and risks. The scrum master did his job properly. His scrum team encountered no major obstacles. The product owner also performed his duties according to the scrum process. So who was at fault? It could be said that the product owner should have asked the sales department itself for additional verification of new functionality on an ongoing basis. Actually, however, the problem was more global - there was a lack of real involvement of a key stakeholder - the director of the sales department. No one paid attention to the obvious risks arising from the fact that the product owner was a newly hired person, external to the department he was supposed to represent. Project management was lacking.
Let's repeat: the chief task of the scrum master is to take care of the scrum process, organize and oversee the conduct of meetings (daily scrum, retrospectives, sprint planning, etc.), the proper use of tools (kanban board). Yes, his task is also to protect the scrum team from external factors and remove obstacles, but the scrum master and scrum in general is focused on the software development stage itself, not on achieving the business goal.
It is this aspect that is crucial here. Undeniably, programming is the essence and the biggest part of modern IT, but an IT project happens to be a much broader concept. Before the scrum team starts work, you need to gather stakeholders and make sure that the goal, high-level requirements and business case are known and accepted by key people. Then, define the solution architecture framework, milestones, and make a decision: outsourcing or in-house human resources. Finally: appoint a product owner, scrum master and scrum team members, and sometimes organize their co-location in one place. And it is the project manager who coordinates all these activities. If the development team comes from outside the company, the project manager additionally participates in the procurement process, collecting technical input to the request for proposals, and coordinates the substantive evaluation of the bids.
It is only after all these steps that the scrum team can begin work.
The following overview shows the key differences between project management and software development management according to agile methodologies:
So we can see that the role of the project manager and the very concept of project management is somehow a more general category than agile software development. From the project point of view, programming is one area/work package (work package), but not the only one. And this is the broad project management focus of the Project Management Body of Knowledge. It is a set of best practices created by the American Project Management Institute. Very importantly, and sometimes confusingly, PMBoK does not dictate how a project should be executed - it does not say in any way to do it agile, cascade or hybrid. It states that the delivery model should be tailored to the needs of the project.
PMBoK does not dictate how a project should be implemented. It states that the execution model should be tailored to the needs of the project.
PMBoK defines 49 project management processes. These are de facto activities that should be performed by the project manager. Some are one-time (e.g., creating a project charter), some are recurring (e.g., quality control), and some are continuous (e.g., monitoring risks). The PMBoK classifies these 49 processes into 10 knowledge areas (including risk, scope, time, cost, quality, resources, communication) but also into 5 processes: initiation, planning, execution, monitoring and control, closure. And it is perhaps the division into these 5 groups of processes that can confuse and give the impression of cascading (first initiation, then planning, then implementation, which is in some contradiction with the agile approach, where planning is intertwined with implementation). This is a misinterpretation! The 5 groups of processes mentioned are separated only because of their logical assignment. However, the PMBoK in no way suggests that all planning must be completed before execution can begin. More - PMBoK explicitly says that the process groups have the right to intermingle and overlap. And it is the project manager's job to select the right set of activities, appropriate to the type of project.
Now that we know that classic project management does not contradict the agile approach, it is worth asking ourselves - is it worth aspiring to PMP certification? If you are a scrum master, work for a company of a few people, develop your own product on a continuous rather than project basis, or have a team working on a contract basis, and you want to stay in such an area of specialization, then exploring project management makes no sense for you. However, if you work for an organization that runs projects where the production of programming is only part of a larger whole, and you are interested in a management career, then learning good project management practices may be the right way to go, in which case you might be interested in training courses that will help you earn your PMP certification. Check out our training on this topic
