Developers are motivated

The lack of motivation at work is historically related to low income, absences, delays, boredom, frustration, dissatisfaction, and inefficiency among workers (MOTTA, 1991).

When looking for factors to influence the motivation of Developers, we should take into account that human beings are complex by nature and, as such, are constantly influenced by their needs, desires, aspirations, preferences, problems, frustrations and all sorts of emotions. Human beings, therefore, have good moments and bad moments when carrying out their work.

In any team, work motivation is essential to generating commitment from its members to the value being generated and the quality of the product of their work. Motivation can also help maintain stability in the composition of the team, leading to a lower turnover of personnel and helping to prevent the loss of knowledge and pace of work acquired.

The Agile Principles explicitly identify the environment, support and trust needed to perform work as essential to an individual’s motivation. Another factor that can be understood as a motivator – and also mentioned in the Agile Principles – is the existence of a sustainable work pace in which the practice of overtime and forced acceleration of the work is avoided, for example, because of a possible delay in an expected release.

As a motivating leader, the Scrum Master also influences the motivation of the Developers, facilitating their self-organization and encouraging them in self-observation, self-evaluation and self-reinforcement (see The leader of a self-managed team, in How is the Scrum Master?, in the chapter Scrum Master).

Below I highlight some theories about motivation at work that bring relevant motivational factors to teams. I begin with Motivation 3.0 (PINK, 2009), the most recent and aligned with our work, and then continue with some of the more classic and recognized theories (Goal-Setting Theory, Job Characteristics Theory and ERC Theory) based on my master’s thesis from years ago (ARMONY, 2010).

Motivation 3.0

Daniel Pink, in his 2009 book Drive: The Surprising Truth about What Motivates Us, shares the results of studies that show that worker motivation can function in very different ways to what we imagine.

When a job requires only basic, mechanical skills, such as a series of steps with a single result, bonuses work as expected: the more you pay, the better the performance. But when the work requires cognitive skills, decision-making or creativity, even minimally, a higher reward surprisingly leads to poorer performance (ARIELY, 2008).

The best way to use money is to pay enough so that money is no longer a problem, and the worker begins to think about the work itself. After that, the main motivators are autonomy, mastery, and purpose:

Autonomy: the natural desire to direct our own work and own lives. While control can lead to greater compliance, autonomy leads to greater engagement.
Mastery: the desire to become better and better at something that matters to us.
Purpose: the urge to do work that is connected to something meaningful, to serve something greater than ourselves. Part of that is understanding why we do our work and being able to recognize what our contribution is.

From these, Pink defines what he calls Motivation 3.0. According to this new paradigm, intrinsic motivation is much more important than extrinsic motivation to increase work performance and satisfaction.

It is interesting to see how Scrum connects well to these three elements. Autonomy is directly present in the work of self-managed teams. Mastery is stimulated by continuous improvement, a fundamental factor of Scrum and emphasized in the Agile Principle continuous attention to technical excellence and good design enhances agility. It is also stimulated in cross-functional teams, where the Developers end up learning from each other. And the purpose is always clear when we implement something end-to-end in short cycles that aims to generate value for customers and users. This focus on purpose is reinforced by frequent feedback, continuous releases and the value goals established as part of the work, such as the Sprint Goal and Product Goal.

Scrum is designed for exactly this kind of work – creative work. According to this theory, autonomy, mastery, and purpose are therefore seen as the main motivating elements for Developers.

Goal-Setting Theory

According to this theory, the setting of challenging, clear and achievable goals, the commitment to those goals and the availability of feedback showing progress in the realization of those goals are powerful motivational mechanisms (LOCKE, 1996), both for individuals and groups (LOCKE; LATHAM, 2006).

We can understand the goals in Scrum as the Sprint Goal, established for each cycle, and the Product Goal. Additionally, we can define intermediate goals, such as those for releases.

The Agile Principle working software is the primary measure of progress (which we can adapt to working product) tells us that the main feedback on the Developers’ progress towards their goals are those provided by customers and other stakeholders about the implemented Increments of the product, in addition to the metrics collected on the real use of the product by its users.

Work Burndown or Burnup Charts also provide visual feedback on the Developers’ work (see the chapter Burndown and Burnup: monitoring work). However, contrary to what this theory advocates, they indicate progress in fulfilling a plan (the Sprint Backlog) more than progress in realizing goals.

Job Characteristics Theory

According to this theory, individuals can be motivated in their work if they perceive the work as rewarding or important, if they believe they are directly responsible for their results and are able to determine whether or not those results were satisfactory (HACKMAN et al., 1975).

To reach these psychological states, however, it is important that certain characteristics be present in the individual’s work. The first is that the person needs a variety of skills and knowledge to perform their work, which naturally occurs in a cross-functional team. Another characteristic is executing an entire and identifiable part of the work from beginning to end, an important feature of Scrum where in each Sprint the Developers produce done and end-to-end features.

The individual should also perceive their work as having a significant impact on the lives or work of others. The usage metrics resulting from frequent releases and the feedback from the Sprint Review meetings, which feed back into the work, added to the self-regulation among the Developers, give them a sense of their own effectiveness and performance, another necessary characteristic. Finally, autonomy in carrying out the work, another of these characteristics, is natural in a self-managed team.

ERC Theory

According to his theory, human beings are motivated by three categories of needs that should be satisfied, ordered as follows: existence, relatedness, and growth (ALDERFER, 1969; ALDERFER et al., 1974).

We can characterize as the existence needs of the Developers the basic conditions of their work, such as salaries paid on time, an adequate work environment, sufficient infrastructure, and respectful working relationships.

Relatedness needs can be met by the intense communication and good relationships between the Developers, which lead to the sharing of relevant thoughts and feelings.

And growth needs can be fulfilled by the prospect of personal development, the possibility of using creativity in their work and problem-solving, being productive and completing relevant tasks.

ERC Theory is an evolution of Maslow’s Hierarchy of Needs.

Discussion: individual evaluations and rewards?

Evaluations concerning work performed and the corresponding rewards, when directed at the individual, encourage that person to work, above all, as an individual. By rewarding individual workers, what we are encouraging is competition among them rather than collaboration to achieve common goals (HACKMAN, 1987). And this competition is not necessarily for the best work, but often greater visibility vis-à-vis the manager who will be judging. For example, when we define bonuses based on the individual contribution of each Developer in a Scrum Team, each member then has an incentive to work to the detriment of the others, minimizing collaboration and, as a result, reducing the effectiveness of the team as a whole.

However, when directed to the team, the evaluations and rewards can encourage its members to work as a true unit that jointly works towards a common goal. For this reason, there is a widespread preference for agile teams to be evaluated and rewarded as a whole, rather than on the basis of individual contributions.

Nevertheless, we have seen some cross-evaluation approaches between Developers working very well. According to these, the individual members evaluate their colleagues based on parameters established by the team itself. The set of evaluations thus performed can then serve as a basis for the reward system, which can also be added to or crossed with an external evaluation of the set.

In my company, we’ve used Merit Money as part of our bonus system. This is a collaborative Management 3.0 bonus system that encourages support and recognition among team members, focusing on actions and behaviors that contribute to the improvement of the team as a whole (MARINHO, 2018). With Merit Money, behaviors like collaboration, communication, ability to give and receive feedback, focus, etc. are evaluated by peers. Note, however, that individual results are not evaluated. These, it is believed, are achieved together and are consequences of the desired behaviors.