Motivating an Agile Team
Aaron Bjork talks about how to motivate your agile teams without getting in their way.
The first and probably most important statement in the Agile Manifesto speaks directly to software development teams: "We have come to value individuals and interactions over processes and tools"
. Bottom line, people are more important than anything else.
This might feel like an odd opening from a "tools guy", since I work at Microsoft as program manager on Team Foundation Server and Visual Studio. I build tools for a living, and there is no doubt that I want software teams to use those tools. However, I'd be a fool to suggest that teams will succeed because of the tools. As the Agile Manifesto states clearly, team success is achieved by first valuing the people on the team and their interactions. Tools and process are important, but they are not more important that the team itself.
This emphasis on people is a big reason I love Agile. It tells us to pull our heads out of our tools and to look up at the team around us. It tells us that if we want to find that pot of gold at the end of the software development rainbow, we need to work together and value each other. It tells us that success depends on the team.
Last year I read a book by Dan Pink titled "Drive: The Surprising Truth About What Motivates Us". It was a fascinating read, one of those books I couldn't put down; I'd recommend it to anyone. I remember numerous evenings when I'd stop mid-chapter to inform my wife "You've got to hear this," before proceeding to read aloud a portion of the book. She eventually informed me that she would read the book when I was done, and asked me to save my breath. My point remains: the book captivated me, and it opened my eyes to some of the truths about motivation.
In Drive, Pink contrasts the traditional motivation techniques (rewards and punishment) with three new essentials critical to motivation in today's creative industries: Autonomy, Mastery and Purpose. The idea is that people crave these three characteristics in everything they do, and when they find them, good things happen. In this month's column I want to quickly touch on how autonomy, mastery and purpose are essential to building healthy Agile teams.
Autonomy. The first essential presented by Pink is autonomy: the ability for one to make his or her own decisions. For a software development team, this is critical. A team needs to feel empowered, and a team needs to be empowered. Why? Because Agile teaches us that change is inevitable during the software development process.
Learning about the product, the architecture, and the customers will occur after the team has started executing. The team must feel empowered to react to change and communicate what it is learning. This doesn't mean the team should have the authority to do whatever it wants; rather, it gives the team freedom to do what's right. A team lacking autonomy is more likely to blindly follow a plan handed down from above, while ignoring critical learning.
Mastery. The concept of mastery is fairly simple: people want to get better at what they do. We find this in all areas of life. Part of our basic DNA involves the desire to improve. Toddlers work tirelessly to master the art of walking. They usually need very little encouragement. By nature, they have a deep-rooted desire to master walking, and they work at it until it becomes second nature.
This doesn't change as we get older. I love to play golf, and I have a desire to be a better golfer year after year. Improvement is part of my love for the game. I'm certainly not a master (my career on the PGA tour hasn't yet materialized), but I continue to strive to improve hole after hole, round after round, and year after year. The process and the results are exhilarating.
Software teams are no different. Every software team has a basic desire to find newer and better ways to accomplish the goal set before it. Members of the team love to build software and love to solve difficult problems. If they didn't, they wouldn't be in a difficult industry. The challenge and the art of building an elegant yet functional solution drive them. Too often, however, we treat teams and the people on them as if they're pieces on a game board that can be moved, shifted and changed without consequences. We shuffle resources, change goals and randomize their priorities. By doing this we remove their ability to become masters. It's a pattern I see repeated again and again in the industry.
Purpose. The final essential laid out by Pink is purpose. Teams have a deep rooted desire to understand how their work fits into the big picture. As an engineer, I want to understand why the software I'm building matters. We need a reason and a purpose.
As a leader in your organization, find ways to ensure that your team understands how the value it produces is contributing to the business. Communicate the importance of new features delivered in the last sprint. Show them delighted customers benefitting from their solutions. Too often we disconnect our development teams from the business and from customers. We do this because we think they don't care, or we're worried that we'll distract them. But more often than not we end up alienating them and destroying their sense of purpose.
As your teams grow, mature and strive to be more agile, work to create an environment of autonomy, mastery and purpose. I have no doubt that you'll witness morale, innovation and efficiency improve as you do.
Aaron Bjork is a Principal Program Manager at Microsoft working on Agile experiences and tooling within Team Foundation Server (TFS). Prior to joining TFS in 2008, Bjork worked as a software engineer and development lead in Visual Studio. He is passionate about Application Lifecycle Management solutions and has a strong desire to see teams improve their software engineering practices. Follow Bjork on his blog at blogs.msdn.com/aaronbjork.