Will agile methods make project division superfluous in the long term, or is that even already the case? Because the absence of a project manager can also have advantages - at least that's what Anna Zarudzka at dev-insider.de
thinks. It goes without saying that projects and project management belong inseparably together. Or is it not? Anna Zarudzka wants to provide approaches to question this premise. In the following, we summarize her theses for you.
Most companies in software development use a manager for every project as a matter of course. At the same time, many of these companies use the agile project approach Scrum and set up their work structures as Scrum envisions: with development teams, with a Scrum Master and a Product Owner. Doesn't that mean that the need for a project manager is ultimately eliminated? Anna Zarudzka is convinced that teams without a superior project manager can work even more efficiently and better together with the Scrum system. Better results are achieved, also or precisely because there is no single person responsible for the success of the project.
To shed light on how this works, it's worth taking a look at the classic role of the project manager. Project managers deal with project planning and goal definition, monitor the schedule, assign tasks, manage the resources a project has available, and play a role in motivating staff. Without question, these are essential tasks. But Anna Zarudzka is convinced that these tasks can be distributed differently and, consequently, in a Scrum team there is no need to appoint a superior project manager. She wants to get away from the idea that one person is responsible for managing a project and that is exactly the idea behind Scrum and other agile methods. Hierarchies are being dismantled and traditional methods are being reconsidered.
Traditional systems are based on the following assumptions:
- The project plan is more or less stable (if it has been prepared well).
- The project plan is better the more detailed it is.
- Customers are involved in the processes at the beginning and at the end of the project (and only then).
- If the schedule is met, the project is a success.
- There are human resources that need to be managed.
In contrast, there is the alternative: the agile approach. There are many different agile methods, and Anna Zarudzka considers a mix of the Lean-Startup-Build-Measure-Learn approach and Scrum to be ideal. She works with two-week intervals in development work.
So now, if the project manager fails, his tasks have to pass to other people in the team, at least many of the tasks. But this is easily possible through Scrum. The development team has all the expertise and the experience and can therefore work out the distribution of tasks (resource management) among themselves. The Scrum Master supports the team so that the Scrum process runs as efficiently as possible. The product owner represents the interests of the customers or stakeholders. The schedule takes a back seat because it is not set at the beginning and then adhered to, but changes daily and is also adapted by the people who are directly involved in the topic, in the team. The iterative process demands it.
In traditional management, the project manager communicates his project vision to the team. This vision changes only slightly during the course of the project. In Scrum, it is the case that the entire team participates in the development of this vision. At the same time, this vision can change significantly during the various project phases. While in classic project management the project manager evaluates the success of a project, in Scrum this is also done by the team itself. Everything becomes more flexible and fluid. For example, a product owner can completely redefine the goal in the middle of the project and the entire team then takes a new direction. Time management is also the responsibility of the Scrum team itself. The schedule is no longer the sacred cow, which may not be touched, but becomes in Scrum a flexible and constantly moving document. Often it is even the case that the Scrum team plans on a very short-term basis, namely only for the next sprint, i.e. in very short periods of time. After that, there is a re-evaluation and further planning. Regular reviews play an important role here, but also within the team and not by an outside third party. Communication and information are essential in Scrum and - how could it be otherwise - are also in the hands of the Scrum team. If you look at all these differences, it becomes clear why Anna Zarudzka claims that agile methods make a project manager virtually obsolete. Of course, this can only be taken to mean that the role of the manager is simply different than it was a few years ago. The people who were once project managers are now Scrum managers or product owners or work in Scrum teams. They are not becoming redundant, but are finding themselves in new roles.
In a Scrum project, a paradigm shift in the middle of the project does not mean a disaster, but is commonplace. Scrum teams are designed to deal with continuous change in requirements. This is exactly the reason why Scrum is so well suited for projects in software development, while the classical methods are nowadays only used for classic projects such as in the construction industry. But even here, agile methods are making inroads, even if a construction project naturally cannot switch from a kindergarten to a hospital in the middle of construction.