For now let’s simplify the definition of productivity, as the amount of requirements implemented (tested and accepted by the client), for a particular team, in a given time, but with the quality required by the client. Thus, productivity improvement is understood as an increase in the quantity of requirements delivered under the above conditions.
That said, we return to the question that brought us here: May the adoption of a work methodology, by itself, improve team’s productivity?
SCRUM
Let’s start by looking at the agile methodologies and maybe the most used, the Scrum (http://www.scrumguides.org/).
Scrum followers advocate that self-organized teams is one of the most influential factors on motivation and that motivated, they produce more and with more quality. Is it true?
As for quality, I have my doubts that it will be achieved only through these means. It takes more to produce quality software, i.e., no errors on the market. For example, clear requirements are needed for programmers and it is a responsibility of the Product Owner, able to transform into your client‘s wishes requirements.
As for the motivation, I have no doubt that when we transfer some decision making to the teams, it makes them more careful, more attentive and more accountable to the results. On the other hand, the fact that there is no “boss” who distributes tasks and says, or suggests how to do, makes most people think for themselves without afraid to take risks, achieving better results. There is no doubt that self-organized teams become more productive.
There are, however, other factors that may justify an increase in productivity, such as the product increments that are delivered in each sprint. These small increments are ready to be published and used by the customer. Unlike what happens in a Waterfall-like methodology, where there are endless functionalities that are never finished, here are goals that are being fulfilled and bringing the teams closer to the end.
FDD
But not all agile methodologies advocate self-organized teams.
Feature Driven Development (FDD), created by Jeff De Luca, is an agile, model-driven, customer-driven requirements-driven process that allows you to develop software (www.featuredrivendevelopment).
In FDD there are 6 defined roles: Project Manager, Chief Architect, Development Manager, Chief Programmers, Domain Experts and Class Owners.
The latter are Developers who are part of the teams and are guided by the Chief Programmer in the activities of Drawing, Coding, Testing and Documentation, and are specialized in Classes. All planning and estimates are made by the planning team, to which these Developers do not belong.
Productivity does not result from self-organization but from organization and distribution of responsibilities and from collaboration among all in their roles.
Note that all development is done feature-oriented. In each sprint, features are delivered according to defined priorities, and control points are made throughout the project.
The various development teams are rebuilt in each sprint according to the features to be developed, and with the necessary classes to develop these same features. Again, there is work ready at the end of each sprint which motivates the teams to get more in the next sprint.
PMBOK and PRINCE2
If we look now at more conventional project management methodologies we will find some differences.
There are ten areas of project management knowledge in the PMBOK from PMI (https://www.wrike.com/project-management-guide/pmbok/), one of which is Human Resources Management, which involves hiring and managing the project team, assigning roles, professional development and team building.
Another of the areas of knowledge is Risk Management. When a project manager is aware of the risks identified by him or team members and can mitigate them, this contributes to a more secure environment for teams.
Communication Management comprises the dissemination of information between team members and external stakeholders, ensuring that it is understood by all stakeholders. A well-informed team is a team that feels part of the project and does not stop at the mere execution of tasks.
When a team knows the problems, the risks, the plans and the solutions, it feels safe and integrated and this contributes to its motivation and consequent productivity.
In the PRINCE2 methodology (https://www.prince2.com/eur/prince2-methodology), the role of the project manager is not so comprehensive, although in smaller projects, it can assume more functions. But it is also up to the project manager to motivate the team.
In short, there is no evidence that these two methodologies, PMBOK and Prince2, may, by themselves, improve team productivity through motivation. It is necessary for the project manager to develop a relationship with the team, outside the methodology and to build motivational factors.
In these methodologies, the change of requirements during the project is more difficult to manage than in the agile methodologies. The understanding that Developers need to have about the requirements is key to avoiding any kind of rework. Unlike the agile methodologies, the requirements owner does not work close to the Developers which can bring delays or misunderstandings, damaging the productivity of the teams.
When we talk about large projects, involving multiple teams, eventually in different geographies, these methodologies are stronger. Good planning, monitoring and communication are needed here, and these methodologies can do this.
To take away:
Agile methodologies tend to be more productive through motivation, and it is necessary to adapt them to large-scale projects.
Non-agile methodologies achieve better results in large projects since they are usually more complex and too cumbersome for smaller projects.
(picture: pergola in our garden)
Thoughts of an Agile Player 