This chapter relates Agile development team motivation to established organizational behavior principles. I've included this chapter because Agile development has the potential to significantly increase motivation, but it is squandered by the persistence of Waterfall planning. Organizational behavior principles can explain why and what you need to do to establish highly motivated Agile development teams.

The chapter begins with the experience that led me to this conclusion. It reveals six principles of organizational behavior that enable you to measure and maximize motivation in your organization. It ends with a discussion of the myriad books on motivation, and why the advice usually doesn't work in your organization.

If you're an engineer like me, you are probably skeptical at this point about the application of psychology in a technical environment. I was. I took Psychology 100 as a required humanities course for engineering students. There were lots of theories, but psychology lacked what I valued in science – the ability to predict outcomes based on foundational principles. For example, I could predict the orbits of the planets with an understanding of the laws of gravity. I learned basic organizational behavior principles that help engineers understand, and even predict, how people behave in their organization. Behavior can be predicted and changed with an understanding of the consequences in your organization.

13.1 Background

You're probably wondering how an engineer like myself is qualified to talk about organizational behavior. I'll start with a true story.

It began in the large telecommunications company I worked for. I had just been promoted to director by a new VP who was appointed because of the division's recent history of quality issues and late software deliveries. To be fair, quality and reliability expectations were extremely high in telecommunications, and the quality levels were much higher than what you find with most software developed today.

I had started out as a software engineer at the start of a project developing a revolutionary digital telephone switching system using the latest technologies. This involved digital switching of encoded voice samples, the latest communications technology at the time. We also employed dozens of new Intel 8086 processors throughout the system. I know we were on the cutting edge because we couldn't get the 8 MHz parts we needed at the start of the project and had to initially test with 6 MHz parts. For comparison, today's processor clock rates exceed 2 GHz! I experienced the challenge of working with hundreds of software engineers on a massive project under tight deadlines. The time squeeze made engineers skip software engineering quality practices, only to bear the consequences later.

Soon after my promotion to director, I heard that the new VP had hired someone to focus on quality processes. She had a PhD in psychology. Of course, my first reaction as an engineer was skepticism. What does psychology have to do with software development? I was sure this was a big mistake.

I learned what the connection was. Execution of quality processes involves behaviors. A behavior is an action you can observe. For example, you can observe an engineer writing or executing test plans. You can observe someone doing a code review. Getting our culture back to one of process discipline involved behavior changes. Within three years, our organization attained national recognition for quality because engineers followed processes. The division became successful. Schedules were met. Engineers were motivated to follow processes.

The woman who opened my eyes and changed the company's culture became my wife, Susan. She has been my teacher and consultant. What I will share with you is based on learning the fundamentals of behavior and applying them successfully throughout my career.

13.2 Why You're the Only Smart One in Your Organization

This is a facetious title for explaining the mystery of organizational behavior. How often have you heard things like?

Why doesn't my product owner realize how important it is to be available to the team so we build the right product?

Or

Why isn't my product manager attending sprint reviews? This is their chance to provide input.

I can give you a real example. I did an assessment for an organization that was rebuilding their platform from scratch. They wanted to make sure they obtained input from their product stakeholders, so they created cross‐functional teams to participate in requirements development. Their software was used by internal operations. Operations had criticized the existing product, so this was their chance to provide their input. “If they don't provide feedback, they can't complain later.” It sounded like a great plan.

The problem was that the operations people assigned to the teams weren't showing up for the meetings. I heard engineers say, “Why don't they understand that this is their opportunity to shape the product? They can finally change the things they've complained about for years.”

Whenever I hear, “Why don't they understand?” or “How can they be so dumb?” I recognize it as a behavioral problem. There is a good reason for the disconnect if you understand the consequences the person anticipates for the desired behavior, and there is a systematic way to analyze consequences. The problem was solved by a PhD holder in psychology named Aubrey Daniels, a pioneer in the application of organizational behavior principles in the workplace.

Susan was smart enough to recognize that the root cause for not following quality processes was an issue of consequences. Even when engineers had time, they often skipped code reviews or unit testing because they found it laborious, and it lacked any recognition for the reviewer. She contacted Aubrey Daniels and brought in his organization to help us.

If you're uneasy at this point because behavior change sounds like some kind of mind‐control or manipulation, I assure you it's not. Everyone in the organization, including the engineers, was taught the principles. It was embraced by all because the solution requires overcoming negative consequences with positive consequences. What's not to like about an organization where people feel sincerely recognized for their achievements? Manipulation is when you fool someone to do what you want.

Aubrey's organizational behavior principles provided a structured way to predict behavior. I had believed in self‐motivation in professionals earlier in my career. It was just a matter of getting more self‐motivated people on your staff by getting rid of the unmotivated and replacing them with the self‐motivated. Of course, I soon realized that you may be able to do this for a team with a handful of people, but not a department of hundreds of engineers. When I realized that Aubrey offered an analytical model of organizational behavior, I became hooked. I realized my responsibility as a leader was to motivate the unmotivated, which comprised most of my department. These were the average engineers who came in every day, did what was asked of them, and then went home. Fewer than 20% were the superstars that did whatever it took to achieve their goals – the so‐called “self‐motivated.”

An understanding of organizational behavior made me realize that as a leader my primary responsibility was to manage behaviors to motivate the unmotivated to achieve business results.

13.3 Consequences and Behavior

I recommend Aubrey's book, Bringing Out the Best in People [1], for those who want to gain a deeper understanding of organizational behavior. However, I will summarize the principles I have applied to create highly motivated teams.

13.3.1 Performance and Organizational Culture

I have always been a positive leader trying my best to recognize people for their contributions. I observed cases where a department or project continually missed schedules. The leader was then replaced by someone known to be tough. They didn't accept excuses. People who were late on schedules were “called on the carpet” at 7 a.m. meetings. Managers were threatened with being fired if they couldn't meet schedules. Suddenly, schedules were met.

This was a mystery to me. Should I be the tough leader or the positive leader? With the new insights of organizational behavior, I was able to create the chart (Figure 13.1) to explain what was happening.

The vertical axis represents the degree to which desired results are produced by a department. Individual behaviors create the results. The horizontal axis is the extent to which individuals experience positive or negative reinforcement. We know that either positive or negative consequences drive behavior. Why use one over the other?

Aubrey had a good answer. You only get results for what you can measure with negative reinforcement. For example, project task tracking can provide the basis for punishment in project reviews. Quality metrics are another good example. How many engineers look forward to the project quality metrics review? The other consideration is that people will do the minimum to get by under negative reinforcement, and, of course, there are other side‐effects like finger‐pointing to avoid blame.

Positive reinforcement on the right‐hand side of the chart leads to higher performance. People with a history of positive reinforcement in an organization will seek ways to obtain positive reinforcement. For example, they anticipate recognition from the team when they volunteer for an extra task on the Kanban board. They will put in extra effort to complete their user stories on time in anticipation of recognition.

A culture of positive reinforcement results in what is called today the mysterious “employee engagement.” HR departments conduct annual surveys with hundreds of questions to analyze how they can increase engagement. The answer is simple – incorporate positive reinforcement in the work of the people. Think back to a job where you were totally engaged. I'll bet that you were receiving frequent and timely recognition for what you were doing.

Let's talk about the middle of the chart where there are no significant positive or negative consequences. I call this, “being nice.” You can provide all the great benefits you want, and even provide the gourmet lunches and on‐site dry‐cleaning, but they will not create a high‐performance culture. Startups have none of that, yet they have some of the highest performing engineering teams because people are getting frequent reinforcement for their contributions.

Aubrey's principles disprove the adage that “happy employees work harder.” I can think of companies that have great benefits and terrific social gatherings but low performance. There is no pressure. People are happy. They do some work every day and go home at 5 p.m. They miss schedules with no consequences. It's not a high‐performance culture. The relationship between happy people and performance is that we observe happy employees in high‐performance organizations. They are happy because they are getting positive reinforcement from their work. It's the positive reinforcement built into their jobs that makes them happy and engaged.

People often ask me the question, “Does that mean we need to be positive all the time?” The answer is “no.” There are times when negative reinforcement can be used effectively. The good thing about negative reinforcement is that it gets results quickly. People will usually respond immediately to a threat. I believe it's based on human survival instincts. However, people require a history of reinforcement to anticipate positive consequences so it takes time to become effective. You can use negative reinforcement to get a desired behavior started immediately that you can then positively reinforce. Remember this is not about being nice. It's about effectively applying consequences in your organization. However, you want to shift to the engagement side of the motivsation curve in Figure 13.1 as quickly as possible to maximize performance. Avoid the middle of the curve.

As an example, perhaps you have an Agile team continuously missing sprint goals even though you have encouraged them to adjust their velocity. You have looked at other potential factors, like sprint backlog instability caused by new work being added during the sprint. You feel the team has been trained and is capable. It looks like a motivation problem. Perhaps the engineers are frustrated by having to implement software on top of an unstructured and poorly documented software base, or they are consistently being told that they built the wrong thing in sprint reviews. Either way, you need to motivate the team.

If you have exhausted external influences, it is fine to apply negative reinforcement to make the team realize you're serious. You might have everyone make a personal commitment to you to complete their tasks to meet the next sprint, and anyone not completing their tasks can join you in a 7 a.m. meeting after the sprint to explain why they didn't.

Turn to positive reinforcement as quickly as possible. Give them recognition when they meet their first sprint, perhaps even a lunch with the team at a local restaurant. It's not about the free lunch. It's about the social recognition you provide during the lunch by showing them you value them enough to sacrifice your time. Ask them how they did it and recognize individuals for their specific contributions.

You may be thinking that the immediate effect of the negative reinforcement will result in a very conservative estimate of the stories they can complete in the next sprint in this case. This will create angst for those of you who use negative reinforcement where, “It's better to set the goal high so we get closer to what we want.” In fact, you want them to initially establish a conservative goal they can meet to receive the recognition. You either believe in the motivation curve in Figure 13.1 or not. If you do, accept the fact that frequent and positive reinforcement will create the engagement to maximize performance, or be the tough leader that everyone fears. Let the team set goals they can meet.

Based on my experience, most software organizations are in the middle on the chart. Software managers find it difficult to confront people to enforce accountability, and managers have not been trained to instill positive consequences into the work of their people. The good news is that Agile enables management to establish this motivational environment. Can you think of a software development framework where engineers can work in teams and set and accomplish visible goals every two weeks? Just don't screw up Agile with Waterfall planning where engineers can't meet goals.

Principle 4

You don't have to reinforce the desired behavior every time.

As you can read in Aubrey's book, there are reinforcement schedules to instill a behavior as a habit. The essence is that you use frequent reinforcement to increase a specific behavior, and then reduce the reinforcement schedule. It turns out that the most effective reinforcement schedule is when the individual receives reinforcement after a variable number of behaviors. Think of slot machines. People are willing to spend hours pulling the handle with no result. Social media companies like Facebook are very skilled in effectively applying reinforcement schedules, as is the video‐game industry.

Principle 5

Don't confuse reward with recognition.

Rewards have tangible value. Recognition is an expression of gratitude. Recognition is positive reinforcement. The problem with rewards is that the tangible value is often associated with the value of the work itself. Consider an example of an engineer returning from a meeting with her manager with a $10 Starbucks card in hand. “I worked the last four weekends to meet our release date and all I got is this $10 card.”

However, rewards can be vehicles for recognition. Consider an example where a manager takes time over the weekend to purchase a set of golf gloves to recognize an employee for a significant accomplishment. “Ken, I really appreciate the extra effort you put in to meet the sprint goals. The team and I appreciate what you did. I know you're an avid golf player, so I stopped off and picked these up for you.” In this case, it's not the value of the gloves. It's the recognition, made more significant by the manager's willingness to invest their own time to provide the gloves.

Given everything above, I highly recommend not using rewards like certificates and plaques. The fact is that you don't need them to motivate engineers, and they can backfire. For every engineer who receives a plaque, there are 10 others dissatisfied because they didn't. Not only that but who do we give the awards to? The self‐motivated.

It's actually very simple to provide motivation in the engineering workplace, and it doesn't cost anything. I've found that engineers require only one of two prompts.

Show me what you built.

Or

Tell me what you know.

The first is especially powerful. Why do you think engineers work long hours eating stale pizza at a hackathon? Do you hear the buzz in the room? It's the peer reinforcement they are receiving for what they create. “That's cool. How did you think of it? Let's show the rest of the team how you did it.”

There is an important point here that leads us to the motivational environment of Agile. The most powerful reinforcement is from peers, not an occasional “great job” from a manager. Agile has removed management from the details of software development so they are less likely to know what to reinforce. Developers spend most of their time with peers. This leads to our last principle.

Principle 6

The most important role of engineering leadership is to establish work environments where frequent peer recognition takes place.

One of the best ways to establish the environment of peer recognition is the Kanban board. Even if you're doing Scrum, make sure the team has a physical Kanban board they can gather around to recognize each other for progress. Don't, as I have sometimes observed, put the Kanban board online to make updates “more efficient.” There will be no opportunity for social recognition.

Charts and graphs that demonstrate progress can be used as opportunities for positive reinforcement, the so‐called “information radiators.” A burndown chart prominently displayed can provide opportunities for reinforcement. A written comment of appreciation for meeting the last five sprint goals will go a long way. Encourage teams to display their quality metrics to show improvement.

If you find your team does not want these charts posted, it's because they associate them with negative reinforcement. “I don't want to be criticized when we don't meet our sprint goals.” If that's the case, you haven't built up the anticipation of positive consequences needed to sustain high performance. Once you do, they will embrace quality charts. This happened at the telecommunications company where I learned about the power of positive reinforcement. Engineers would even recommend their own metrics and start using them within their teams. Metrics became scorecards for success, not opportunities for punishment. You'll know “you've arrived” when this happens.

I'll end this discussion with sports analogies that often come up to challenge the behavior model of motivation. People give examples of very tough football coaches who yell at their players, and rarely provide positive reinforcement. Professional sports teams recruit players with strong histories of success. They are selecting players from champions. The players have built up a history of positive reinforcement to become “intrinsically motivated” to play their sport. This is not your situation at work. You have new people struggling to learn their jobs and fit in. You have people taking on new jobs who lack confidence. You probably have over 50% of your employees in the “OK” zone who rarely receive positive reinforcement. You will only bring out the best in them with positive reinforcement. You are not selecting champions. You are growing them. That requires positive reinforcement.

13.4 Agile and Motivation

Agile can provide the frequent positive peer reinforcement needed to maximize performance. The founders of Agile innately understood the motivational power of a team frequently setting and meeting goals. They become winners. The founders were familiar with the demotivational aspects of Waterfall development. In the Waterfall days, engineers were given assignments and may work alone for weeks to finish a piece of functionality. Many times engineers felt they were “cogs in the wheel.” There was no immediate reinforcement. In fact, they were called out at project meetings when their deliverables were late!

Amazingly, software management can establish highly motivated Agile teams with advice expressed in one sentence – “don't screw it up!” I have seen many cases where Agile teams almost never meet their sprint “commitments.” The word “commitment” itself infers negative reinforcement. Teams are pushed to add stories to the sprint to meet feature and schedule commitments, and then chastised when they don't. Work is added during the sprint with no relief for “committed” functionality. These Agile teams feel like losers.

I've seen cases where an Agile transition has occurred without redefining the role of project managers. What do project managers do? They continue to perform the tasks that they were reinforced for in the past, which has little value in Agile. I've seen project managers tracking story completions! It's not the fault of the project manager. They weren't taught the valuable role they can play in Agile development by proactively managing external dependencies and performing risk management, becoming an asset for the team.

Sprint reviews can often be a punishing experience for engineers. I've seen cases where product managers do nothing but criticize a demonstration without a hint of recognition. Often, the product managers have provided little or no direction to the team or product owner during development but take the opportunity now to tell them how they got it all wrong. It's sometimes an opportunity for an arrogant product manager to show how much smarter they are than the engineers on the team.

Much of what I see in Agile is based on attempts to perpetuate the negative reinforcement used to drive most software projects. “Stretch them so we get most of what we want.” These organizations have observed that setting lower goals allows engineers to “slack off,” and, of course, that's true. You are using negative reinforcement, and if you let down on the negative consequences without a complete movement to the positive reinforcement side of the motivation curve in Figure 13.1, performance will indeed decline. It's a self‐fulfilling prophecy.

Principle 6 stated, “The most important role of engineering leadership is to establish work environments where frequent peer recognition takes place.” If you don't see the excitement and engagement in your Agile teams, you have failed. It's not the fault of the people. You have not set them up for success.

Strong and effective leaders establish umbrellas around their teams where positive reinforcement takes place. The leader needs to deal with all the politics and shield them from others who persist in using negative reinforcement. Your teams should be able to set sprint goals they can achieve at least 90% of the time. Encourage them to forecast fewer story points in their sprints until they obtain a rhythm of success. Once they do, performance will increase well above anything you might have attained through negative reinforcement.

Let's use the motivation model to consider the current trend of working from home. Most of the studies I've seen try to make a case that working from home is as effective as working in the office, or perhaps more so. The problem is that most companies have not established an environment of frequent peer reinforcement so working remotely doesn't make much difference. However, these organizations are missing the opportunity to create high‐performance teams.

I don't believe working remotely can be as effective in terms of Agile team motivation because it diminishes spontaneous peer reinforcement, and there is the loss of spontaneous collaboration to be considered. What can you do if you have no choice, as in the case where working remotely has become company policy? Standup meetings can still be interactive over video, but the positive reinforcement and information exchange from daily collaboration are missing.

It may help to establish core hours where people are expected to be accessible for spontaneous video meetings, say three or four hours in the day. Also, ensure that engineers can move from messaging to a video meeting with one click. Schedule a group meeting during the week where engineers can volunteer technical challenges they are encountering. This invokes the “tell me what you know” positive reinforcer that is so powerful for engineers. At the same meetings, ask engineers to volunteer what they've learned that week that may be useful to their teammates. Create an environment of active discussion where peer reinforcement can take place.

Investments establish good discussion topics for peer reinforcement. Have an Investment team present where they currently are in terms of translating stakeholder value into a software solution. Have the team go through the user scenarios they've come up with and let people volunteer improvements. Ask for suggestions on how technology could be applied in a solution.

Just remember that the purpose of these meetings is motivation. If done right, the meetings will not be viewed as just another one of those time‐wasting administrative meetings that engineers are forced to attend. If people aren't showing up for the meeting, you know you have not created the right environment and/or you are not holding these sessions frequently enough to make a difference in their weekly consequences. If you are still using schedules as negative reinforcement, don't bother adding these meetings. The negative consequences will outweigh any positive consequences you are able to provide at the meeting.

13.5 Measuring Motivation

I use a survey as part of an organizational assessment to benchmark motivation. I always like to get a read on the organization's level of motivation because nothing will really change without motivation to do so. The motivation curve in Figure 13.1 can be used as the basis for a simple survey question to find the position of your organization on the chart. It's based on the single question below:

Choose the word that best describes how you feel about your work:

1. Pressured
2. Frustrated
3. OK
4. Motivated
5. Excited

People who choose “pressured” are experiencing negative reinforcement. They are doing their work to avoid punishment, like being put on the spot in a project review for a late task. “Frustrated” means that the individual is trying to get work done but experiencing obstacles. This also usually indicates negative reinforcement. Under positive reinforcement, people will take obstacles in stride and overcome them rather than use them as excuses. We want people to at least indicate they are motivated, and excited is even better. These are people who can't wait to get to work to accomplish something.

“OK” is not OK. These are people “in the valley” of the motivation curve in Figure 13.1 who lack effective negative or positive consequences in their daily work. They do what they're told but nothing above the minimum. With one exception, the motivation index has been below 50% in all the companies I surveyed. The exception was an employee‐owned company in the corporate tax software business where everybody focused on putting out a new release each year with the tax year changes. I don't believe the high motivation was due to the financial benefits of employee ownership. A dividend check once a year is not a near‐term, frequent consequence. Performance was high because peer reinforcement was generated by aligned goals in the organization supported by an enlightened management team that provided positive reinforcement throughout the year.

Unless you have consciously decided to use negative reinforcement as your main motivation tool, you want to avoid the performance curve valley (Figure 13.1) and maximize the scores in the “Motivated” and “Excited” categories. This is arguably the most important Key Performance Index (KPI) for the effectiveness of the leadership team, and the productivity of your organization.

Viewing survey results separately for management and individual contributors has given some interesting insight into the ineffectiveness of negative reinforcement in software development organizations. There is typically little pressure on the engineering staff. All the pressure is on the management, especially first‐level management. The management is working under negative reinforcement to avoid missing delivery schedules while new work is piled on. The negative consequences for job performance are not passed down to individual contributors because engineering managers don't like to apply negative reinforcement to their staffs, especially these days when companies are trying to recruit and maintain engineering talent.

Figure 13.2 is an example of two surveys for a large medical device company taken five months apart.

I helped this organization make a transition to Agile development. The management contacted me with a concern that they had “reached a plateau” and weren't improving. Investigation showed that the management was still applying schedule pressure to the teams, from the top down. I had stressed to the executive team that they were moving to self‐directed teams that needed to be motivated through positive reinforcement. They all nodded, but changing from negative to positive reinforcement is a challenge because it has worked for most executives.

It's very difficult to convince leaders to replace negative reinforcement with positive reinforcement. Anyone who has successfully applied negative reinforcement to get results is certain that it gets results – because it does. These leaders get what they want when they apply negative reinforcement, so it is positive reinforcement for them. As you would expect, it increases the behavior of applying negative reinforcement. A history of effectively using negative reinforcement instills the behavior. The higher up you go in organizations, the more likely that negative reinforcement is applied. A good leader can work under negative reinforcement while creating the positive reinforcement environment for their staff.

I found product management was dictating sprint content in this company, often making changes during the sprint. Teams almost never met sprint objectives. Standup meetings had become status meetings where a manager would go around the room asking each person what they had accomplished. Project managers applied pressure for task completions. The inherent motivational environment of Agile was destroyed.

I went through a round of training for the management and coached managers on how to support the team instead of trying to control them. The result was an increase in the motivation KPI (percent motivated or excited) by about 40% over six months. The client was extremely happy with the improvement in the motivated category and said they could see visible improvement in employee engagement.

A word of advice if you are going to use this survey. Don't set up focus groups to ask people why they don't feel motivated. Answers will be all over the board, like poor benefits, low salaries, and possibly because you don't provide gourmet lunches on‐site. People will not really understand what makes them motivated in terms of organizational behavior principles expressed in this book. Look at why they are missing frequent reinforcement. Do they have frequent short‐term goals they can meet so they can receive recognition?

13.6 Motivation Advice?

I'll end this chapter with treatise on motivation books. I've found that any motivation advice in motivation books can be explained in terms of consequences. The behavior model explains why sometimes it works, and sometimes it doesn't.

Do a web search on “secrets of motivation” to see page after page of advice. My question is, “If all the secrets have been revealed, why are there so few organizations with highly motivated teams?” The problem with most of the motivation books I've read is that they are based on anecdotal evidence. “I observed this at company X, and therefore you should do the same.” Some examples:

• “Engineers who receive more training are more likely to be motivated.”
• “Opportunities for growth increase motivation.”
• “Flexible work hours increase motivation.”
• “Empowerment increases motivation.”

You can now recognize that the above do not generate the frequent consequences required to increase motivation. They may increase retention, but they are not primary drivers of motivation.

Daniel Pink is brought up during most of my talks on motivation. I'm not going to contradict Pink, because I believe his “autonomy, mastery, and purpose [3]” can be observed in many organizations where people are motivated. “Autonomy” refers to the human desire to lead a life of one's own. “Mastery” is the desire to improve something that matters, and “Purpose” is the desire to serve something greater that oneself.

Pink refers to scientific studies that demonstrated rewards do not necessarily increase motivation and may even decrease motivation. I have no disagreement with these conclusions. The pitfalls of using rewards for motivation were discussed earlier in this chapter. Remember Principle 5, “Don't confuse reward and recognition.” The problem is that Pink does not distinguish between rewards and recognition.

It is the frequent peer recognition in Agile that motivates the team, not an altruistic sense of purpose. Take two theoretical Agile teams and imagine there is no frequent peer recognition on one. Replace recognition in that team with dramatic statements of the higher purpose, like “Customers will benefit from your software.” Or, “Shareholders will be richer as a result of your work.” Do you really think that both teams would be motivated to the same extent? It would result in the stale work environments where negative consequences are necessary for motivation, as opposed to the high level of engagement possible with Agile development.

I believe Pink's theory of motivation has been embraced by professionals because it makes them feel good about themselves. They are the self‐motivated people who can apply themselves to any goal they want to accomplish. They believe they are above requiring the extrinsic reinforcement needed by nonprofessionals. Those who have become intrinsically motivated through a history of positive reinforcement will believe that everyone should be just like them, but as we discussed earlier, the objective is to motivate the unmotivated in your organization.

I'm not going to say that Pink is wrong. He's not. It's just that his definition is not useful as management advice. Autonomy certainly helps as we see in the self‐directed teams of Agile development, and I agree that there is a high degree of mastery in many software developers. But these won't make much difference unless the frequent positive consequences exist.

Let's examine “purpose.” The Merriam‐Webster dictionary defines it as follows:

Something set up as an object or end to be attained.

Pink presents a cyclical argument. Having purpose means that someone is already motivated to attain something. The question is, “How do you create the motivation to achieve the purpose, especially when the desired result is far in the future?”

Consider my code review example. I certainly understood the purpose of code reviews, and even evangelized the purposes to other engineers in my team. I had autonomy to schedule my time to review the code. I had mastery. Yet, the opportunity to receive immediate recognition for system debugging overrode everything. All the touted benefits of code reviews were in the future. Everyone understood the purpose, but behavior was driven by near‐term consequences.

I am not going to argue that there aren't people who embrace a higher purpose beyond personal benefit and who make personal sacrifices. People of strong faith are examples. But you don't have many of the people working for you who are going to develop software with the conviction of the faithful. The problem is that most software developers are unlikely to commit their lives to increase corporate profits. They must receive frequent positive reinforcement from their work.

The takeaway is that even though you may empower a group with mastery and a purpose, motivation may not happen. I've observed Agile teams where all three exist, yet they are demotivated. The importance to the company for meeting the release schedule has been fully communicated. They have been trained and have mastered the skills necessary to do Agile development. They have autonomy because they are given a backlog and empowered to divide the work among the team in any way they choose. However, there is no recognition from peers or anyone else because they never meet their sprint goals. They are still unmotivated.

Go ahead and read management books on motivation but use the organizational behavior model to understand cause and effect. Advice based on anecdotal evidence is unlikely to work in your organization unless the same behaviors are reinforced in your organization. Motivation is generated by a system of consequences in one company that may not exist in yours. Using anectodal evidence is like putting wood together and expecting a fire to break out.

Finally, a true story about creating motivation. I was leading a project to develop a new smart antenna system that reduced cellular interference. It was a small team of about 15 engineers with development skills that spanned software, digital hardware, and RF hardware. The team was highly motivated and collaborative because there were frequent points of integration where functionality could be demonstrated. I maintained an environment of positive reinforcement, which included team celebrations when milestones were achieved.

The project included specialized signal processing software that used a Digital Signal Processor (DSP). Completion of the software presented a critical path for the project. There was only one engineer who had the specialized skills. He told me he needed to take a few days off because his family was about to move into a new home that needed to be painted before the furniture could be moved in. There was no way I could deny him the time as he had already gone above and beyond to get us to where we were.

The team volunteered to paint his house over the weekend, so the DSP engineer didn't have to take time off work! The team, myself included, spent the weekend painting the interior of the house. That is the type of engagement that stems from positive reinforcement and supportive management, especially considering that these engineers were already voluntarily working long hours to meet their project goals.

Of course, this is much easier to do with a small team focused on a new project. Enabling leaders to create motivation within larger established organizations is the objective of this book. Common goals are clearly defined for Investment teams that will thrive in an environment of frequent positive reinforcement, and Investments allow you to leverage the inherent motivational environment of Agile by letting teams set and meet their own goals.

13.7 Summary

1. Motivation is the desire to perform a behavior to obtain a result. Therefore, organizational behavior principles can explain motivation.
2. Anticipated consequences drive behavior – not what you ask people to do.
3. Consequences during or immediately following the behavior consistently applied increase anticipation of the consequences, hence behavior.
4. Negative or positive reinforcement will increase behavior. Behaviors will occur to avoid punishment or to receive desirable consequences.
5. A culture of negative reinforcement is limiting because people will do just enough to avoid the punishment.
6. A culture of positive reinforcement creates “employee engagement.”
7. Avoid the lowest performance state with neither positive nor negative consequences.
8. Frequent and immediate positive consequences must be built into the daily work to reach high‐performance levels. Agile provides such a vehicle if implemented as envisioned.
9. Waterfall planning with fixed schedules and content reduces opportunities for positive reinforcement.
10. The Investment model supports the variable content necessary for teams to continually set and meet goals.
11. Investments create common goals for product management and engineering that promote peer reinforcement.
12. Effective engineering leaders and product managers establish umbrellas of positive reinforcement around their Agile teams.
13. Look more deeply into common motivation advice given the insights of the behavior model of innovation. Advice based on anecdotal evidence will likely not translate to your organization.
14. Working from home will likely limit motivation in your organization because it reduces opportunities for frequent positive reinforcement. Video calls can be scheduled where peer recognition will take place.

References

1. 1 Daniels, A.C. (2000). Bringing Out the Best in People: How to Apply the Astonishing Power of Positive Reinforcement. McGraw‐Hill Education.
2. 2 Kleiman, K. (2012). Try Some Smile Therapy. Psychology Today.
3. 3 Pink, D. (1995). Drive: The Surprising Truth About What Motivates Us. Penguin Group (USA) Inc.