A few weeks ago, I finished conducting a series of video retrospectives with several POP team members who recently completed Agile/Scrum projects. The goal of these one-on-one interviews was to elicit the kinds of critical insights that can only be discovered through in-the-trenches experience. By video recording the conversations, it allowed me to quickly distribute these Agile learnings to the larger agency in easy-to-digest bites.
It was great listening to the team talk about their Scrum experiences, but what struck me the most was the universal belief among the people I talked to that Agile projects were more fun and motivating than Waterfall projects. I wouldn’t have considered this a pattern if the people I interviewed had all worked on the same project. But the team members I spoke with worked on a variety of different projects, ranging from e-commerce sites, to mobile apps, to frontend-focused work. Furthermore, the participants came from different departments, including design, development, project management and QA. Yet despite these differences, it was clear that everyone I talked to shared one thing in common: they all had a much higher level of satisfaction and motivation when working on Agile projects. So for me the big question was: Why? What was it about Agile that fostered greater motivation and better performance than a typical Waterfall project?
Money certainly didn’t have anything to do with it. None of the team members I spoke with were compensated any more or less based on their participation on an Agile project. But the fact that money wasn’t the answer didn’t come as a surprise. Decades of research has debunked the myth that money motivates employees, despite corporate America’s obsession with performance-based pay. So if not money then, what?
The truth is that there isn’t any one aspect of Scrum that increases motivation. But when you dig into the research behind employee motivation it becomes pretty clear that there are several aspects of Scrum that do. To better understand why, let’s dive into the research.
1. Setting Goals
One of the most powerful motivators for employees is simply setting clear goals. According to Stephen Robbins, professor and author of The Essentials of Organizational Behavior, the research is definitive—setting goals works: “Considerable evidence supports goal-setting theory. This theory states that intentions—expressed as goals—can be a major source of work motivation. We can say with a considerable degree of confidence that specific goals lead to increased performance; that difficult goals, when accepted, result in higher performance than easy goals; and that feedback leads to higher performance than no feedback.” Fortunately, we’ve already been told that setting actionable goals is good, which is why managers focus on goal-setting during the annual employee review process. But this isn’t enough. Clear and challenging project-based goals occur more frequently and are usually more tangible and satisfying than amorphous yearly career goals. So having employees work on Scrum projects throughout the year can help bolster morale in between the reviews.
Scrum projects establish clear goals in three ways. First, a well-defined Product Vision sets high-level goals for the team to achieve. More than just a goal, the Product Vision should establish an overarching purpose for the team. Second, goals for the upcoming Sprint are clearly defined in the Sprint Backlog. Anyone who has been on a Scrum team knows how focused the team gets on completing these items during the Sprint. Third, immediate goals are set in the daily Scrum, when each team members says what he or she is going to work on that day.
Waterfall projects, by comparison, tend to rely on schedules rather than goals. In a Waterfall project, Project Managers use a Gantt chart (or something similar) to direct team member activities by establishing the duration of course-grain tasks. This tends to cause the team to a focus on booking time rather than completing tasks. The Sprint Backlog, in contrast, includes very fine-grained tasks that are team-member specific. As a result, Scrum teams tend to focus on completing tasks rather than booking time, which leads to better performance and greater satisfaction.
2. Autonomy
Another key component of employee motivation is autonomy. Robbins defines autonomy as “The degree to which the job provides substantial freedom, independence, and discretion to the individual in scheduling the work and determining how to carry it out.” Not surprisingly, we tend to be happier and more motived when we have the ability to direct the course of our own work. Would you rather be a writer, with the ability to determine when and where you work, or an Executive Assistant, at the constant beck and call of your boss? Most people would prefer the former, even if it paid less. In his book Drive: The Surprising Truth About What Motivates Us, author and researcher Dan Pink identifies autonomy as one of the three pillars of motivation (purpose and mastery being the other two). As he succinctly puts it: “Control leads to compliance; autonomy leads to engagement.”
This helps explain why team members are more engaged and motivated on Agile projects than Waterfall. On a Scrum project, the Scrum Team—not the Project Manager—decides which User Stories they are going to pull into the Sprint. And, in the Sprint Planning meeting, it is the Scrum Team—not the Project Manager—who determines how they are going to get the work done during the Sprint. This lies in stark contrast to Waterfall, where the Project Manager dictates who does what and when. Given traditional project management’s roots in industrial-era factory production, Waterfall’s distinctly top-down approach is not at all surprising.
3. Task Identity
Managers frequently turn to extrinsic rewards like bonuses to motivate employees. However, when designed properly, the job itself is a much more powerful source of motivation. “The writings of Maslow, McGregor and Herzberg all touched on the importance of looking at the work itself as a possible source of motivation. Recent research in job design providers stronger evidence that the way the elements in a job are organized can act to increase or decrease [employee] effort,” writes Robbins.
According to research on Job Character Theory (JCT) conducted by Greg Oldham and Richard Hackman in the seventies and eighties, a key component of satisfying work is something called “task identity.” Task identity is the degree to which a job requires completion of a whole and identifiable piece of work. That is to say, people are happier when they complete entire tasks from start to finish, rather than working on a single slice of a task. This is why it so much more satisfying to be a craftsman who creates products he’s proud of, than a factory line worker who monotonously assembles one piece of an item over-and-over, yet never sees the finished product.
Unfortunately, as a direct descendant of turn-of-the-century factory management techniques, the Waterfall methodology leads to poor task identity. In a Waterfall project, different team members work on different parts of the project at different phases of the waterfall, so they rarely get the satisfaction of seeing the whole project come to fruition. This was definitely the case with the team members I spoke with. They complained loudly about the discontinuity they experienced on Waterfall projects, as they were put on and taken off projects at various phases in the project lifecycle.
Agile projects, in contrast, promote strong task identity. Because team members work concurrently to produce tangible, potentially shippable work at the end of each Sprint, every team member sees the project come alive before them, and they see how their work directly contributes to the larger whole. The team members I spoke with loved this aspect of Agile, and they had a much deeper sense of pride in the work as a result. This helps explain why the quality of work is so much better in Agile projects—everybody simply cares more about the end product. It also helps explain why the team was happier even when they were working longer hours. Their greater motivation helped balance the stress of burning deadlines.
4. Skill Variety
The JCT research conducted by Oldham and Hackman also identified skill variety as an essential component of job satisfaction and employee motivation. Repeating the same task over-and-over is boring, unsatisfying and demotivating. Variety, as it turns out, is not just the spice of life, but the spice of good job design as well. Jobs that allow employees to exercise a variety of skills are much more meaningful, satisfying and motivating.
Scrum projects enable greater skill variety in two ways. First, the Scrum Team itself is responsible for determining the best way to approach the work in the upcoming Sprint. This means the team is continually adapting and changing the way they do their work on every project and every Sprint. Second, there are no discipline-specific roles in Scrum, which leads to more task diversity among team members. In Scrum, there’s the Product Owner, the Scrum Master and the Scrum Team. This means that everyone doing the work shares the same role of Scrum Team member. Scrum Team members are expected to complete the work in any manner that works best—even if that means playing out of position and performing tasks outside their normal discipline. The team members I interviewed spoke fondly about how designers would pitch in to help review bug tickets toward the end of the Sprint, or how QA would help out the Scrum Master when she got swamped. They all enjoyed doing new and different things. This also created a deep sense of comradery, as they tended to identify with the team first, and their discipline second, during the project.
Waterfall projects, on the other hand, limit skill variety. The role each team member plays is determined in advance and enforced through a detailed schedule of Waterfall phases. Much like the factory line worker, Waterfall team members are required do one thing and one thing only, over-and-over, on every project.
5. Flow
Traditional organizational research tells us a lot about employee motivation. But there are new theories of motivation that have sprung up recently, and they come from an unlikely source: game designers. Game designers have developed a deep understanding of how to keep people engaged and motivated because their business depends on it. Game designer and TED speaker Jane McGonigal writes about the power of game design in her book Reality is Broken: Why Games Make Us Happy and How They Can Change the World: “Game developers know better than anyone else how to inspire extreme effort and reward hard work. They know how to facilitate cooperation and collaboration at previously unimaginable scales. And they are continuously innovating new ways to motivate players to stick with harder challenges, for longer, and in much bigger groups.”
According to McGonigal, game developers seek to provoke a series of basic human emotions to motivate and engage players. They do this in a number of ways. First, they establish clear and purposeful goals at each level: reach the landing zone, destroy the pigs’ structure, fend off an attack of approaching zombies. Second, game designers work hard to develop a sense of Flow. Flow is the extreme level of focus and concentration caused by playing at the limits of your ability. It is that wonderful feeling you get when you tune out the world and focus on the intense challenge in front of you.The Scrum framework is designed to elicit Flow too. It achieves this through several means:
- The Scrum Master’s mission is to keep the team focused. He protects the team at all costs and removes any obstacles that keep them from completing their work.
- Outside of the 15 minute daily Stand-up, formal meetings are eliminated during the Sprint. The work itself is the focus, not reporting on the status of the work.
- Most Sprint teams are either physically or virtually co-located. This substantially streamlines communication and greases the wheels of productivity.
- Much like levels in a game, Scrum breaks down projects into shorter Sprints, each of which has a clear and challenging goal: to produce a tangible unit of work by the end of the Sprint. Throughout the course of the Sprint, the team remains intensely focused on completing this challenge.
Another way game developers design engaging experiences is by tapping into the primal rush of satisfaction you get when you overcome adversity to accomplish your objective. According to McGonigal, game designers call this universal feeling Fiero: “Fiero is what we feel after we triumph over adversity. You know it when you feel it—and when you see it. That’s because we almost all express fiero in exactly the same way: we throw our arms over our head and yell. The fact that virtually all humans physically express fiero in the same way is a sure sign that it’s related to some of our most primal emotions. Our brains and bodies must have evolved to experience fiero early on the human timeline—and, in fact, neuroscientists consider it part of our ‘caveman wiring.’”
Achieving fiero is difficult (the challenge has to be difficult, but not too difficult, and you must actually succeed in order feel it), and designing experiences that culminate in fiero is even harder. But if you’re able to pull it off, fiero has deep benefits. In fact, scientists have determined that fiero is one of the most powerful neurochemical highs we can experience. It activates circuitry in our brain that is most often associated with rewards and addiction. And, according to the science, the harder the challenge, the more intense the rush.
Certainly, not all Scrum projects culminate in fiero. But, in the interviews I conducted, I observed fiero-like reactions from those team members who had completed the most challenging projects. Because Scrum establishes clear objectives throughout the project and fosters a sense of flow, those people who were assigned to highly challenging projects experienced a deeper level of satisfaction upon completion. And I can attest to the fact that there were some arms thrown in the air when the team pulled off an amazing feat (most notably mine!).
7. Mastery
Mastery is another key component of motivation. Mastery is simply the desire to improve one’s own ability. Research has long identified mastery as a powerful motivator, but we can also see its effectiveness in games, where players are confronted with escalating levels of difficulty, spending hours replaying each level until their skill improves enough to move on to the next one. The irony though, is that once a game is mastered, it becomes boring—it’s the process of mastery that is the enjoyment.
Dan Pink identifies mastery as one of the three pillars of motivation (alongside purpose and autonomy). According to Pink, mastery requires flow (we need a deep level of engagement—and lots of time—to approach mastery) as well as a “Mastery Mindset” that embraces the belief that your skills are not fixed, but can be continuously expanded and improved. Mastery can never be attained, but that doesn’t really matter because it is the continual pursuit that is the true source of motivation: “The joy is in the pursuit more than the realization. In the end, mastery attracts precisely because mastery eludes,” writes Pink.
The Scrum Framework promotes a “Mastery Mindset” through its focus on continual adaptation and through the use of the Sprint Retrospective. In Scrum, at the end of each Sprint, the team conducts a Retrospective to discuss what worked well in the last Sprint, what didn’t work so well and what the team should start doing in the next Sprint to improve the process. This simple practice has a profound, two-fold impact on productivity: the team gets more efficient as the project progresses, and the team sees they are improving which increases their level of satisfaction and motivation. I have seen first-hand how the performance and confidence of a Scrum team improves throughout the course of the project—and it’s pretty cool to watch the transformation.
The Waterfall methodology, in contrast, doesn’t include the concept of a Retrospective, which is why people rarely conduct them in Waterfall. And even when they do conduct a review (often referred to as a “Post-Mortem,” implying death rather than ongoing improvement), they are conducted after the project is complete. As a result, learnings can’t be used to improve performance during the project (when it’s really needed) and the team members are out of the flow by the time the meeting occurs (since they’re working on other projects), and thus they tend to be less receptive to any insights that are gleaned.
8. Feedback
The final reason why Agile leads to greater motivation is due to its emphasis on feedback. Job design research has shown that feedback can increase employee motivation if delivered properly. In fact, practices like goal setting and mastery require solid feedback in order to be effective—setting a course only helps if you can gauge where you are in relation to it. But the flipside is that feedback can be demotivating if not delivered correctly, as anyone who has ever received an unfairly harsh performance review can attest to.
Game designers know this, which is why they spend so much time designing both positive feedback (e.g. sounding a pleasant ring when I collect a coin) and negative feedback (e.g. showing me a slow-mo replay of my demise when I get killed). Interestingly, positive failure feedback can actually be an enjoyable experience. According to Jane McGonigal, research indicates that the right kind of failure feedback is a reward, and it makes us more engaged and optimistic about our odds of success.
That Waterfall methodology, unfortunately, fails to promote frequent or positive feedback. It relies on the formal and infrequent presentation of artifacts that represent work product (e.g. functional specifications, design comps, wireframes), rather than frequent reviews of the work product itself. This can lead to a potentially contentious and demotivating situation. The client hasn’t had an opportunity to review the work along the way and is thus understandably anxious about what they are about to see in the review meeting (What if the team embarrasses me in front of my boss?). Furthermore, the meeting is usually a formal one, which tends to create a feeling of us (the client) versus them (the team), instead of a greater sense of collaboration.
Making matters worse, the client often doesn’t have an opportunity to review and give feedback about the final product until the end of the project, during the User Acceptance Testing (UAT) phase. This means that the client sees the actual work for the first time during the most stressful time of the project—right before launch. And invariably, the final product will have changed from the paper representations that the client has been reviewing because, well, they were only representations. Needless to say, in these situations, feedback is rarely delivered in a motivating manner and the ability for the team to successfully incorporate it is limited.
Scrum projects, on the other hand, promote frequent feedback in two ways: (1) through the Sprint Retrospective, as discussed in #7 above, and (2) through the review of tangible, potentially shippable work at the end of each Sprint. By having the Scrum Team review actual work product with the Product Owner and stakeholders every few weeks, the team is constantly getting feedback about the work they’re doing. Furthermore, because the Review meeting (or “ceremony” in Scrum parlance) is designed to be a working conversation rather than a formal presentation, the tone of the meeting is much friendlier, resulting in more open and motivating feedback.
Conclusion
I’m continually amazed by the number of ways a simple process like Scrum can be beneficial to projects. On the surface, Scrum is a straightforward and intuitive framework. But the more I try to understand why it works, the more layers of depth I discover. In this regard, Scrum is a bit like an onion. But the truth is we don’t really need to understand why Scrum works, we just know it does. Above and beyond what the science says about Agile, I can attest to the fact that Scrum leads to a better outcome based on my own experience—plus I have the video-recorded smiles on my colleagues’ faces to prove it.