The Agile Architect
Motivating Your Agile Team
Agile can't work without agile teams, and agile teams are made up of people. People can't work effectively without motivation. Our Agile Architect discusses different ways to motivate agile teams.
Let's start with a tale of two employees:
You're living the good life. You wake up in the morning refreshed and relaxed. You kiss your spouse goodbye and head off blissfully to work. The sun is shining. Birds are singing. The distance to work is a short 12.5 minutes. The perfect commute, you think to yourself. Not too much time that it eats into your day, but long enough that it gives you good separation from home.
You breeze into the office, skip into the war room, grab a pair, find a new story on the Kanban board and get to work. You're eager to get the story done. It's fun but there's a lot to do. You and your pair discuss the best approach. You grab the attention of the rest of your team, discuss your proposed path, take some suggestions and get to work. It's a hard problem but you and your pair are enjoying working together and are eager to show off your solution to everyone else. And suddenly, the story is done. You follow the Kanban process to shepherd the story through a UX review and testing. Then its time to pull another story. You and your pair part ways per your team charter. He pulls a new story and grabs a teammate from a story in progress. You seamlessly slide into the seat just vacated to work on the story in flight. Your new pair brings you up to speed, sharing the acceptance criteria, reviewing the code and tests already written, and the tasks still to be done. You decide to run the automated tests before writing new ones but soon you are at it again, writing failing tests, making them pass and getting the story "done done".
At the end of the day, exhausted but in good spirits, you look on with pride at the Kanban board. The team got 10 stories done and 18 story points; a great day by any measure. Heading home, you find yourself smiling. It was a good day at work. Now it's family time.
Your life is horrible. You drag yourself out of bed in the morning, tired and restless from another night of tossing and turning. You take a long shower, procrastinating as long as you can. Standup isn't until 9 a.m. There's no point getting to the office before then. You kiss your spouse goodbye and head off apathetically to work. The commute is only 12.5 minutes. Not nearly long enough. Soon, you'll be in the office and have to figure out what to do with yourself.
Despite your best efforts, you make it to standup on time. Looking at the board, you don't see anything particularly interesting. So you decide that its time to see if you can clean up some old tests. It's relatively easy, routine work and its not like anyone is going to notice anyway. You could take a story instead but why? There's no looming deadline. Just one damn story after another.
The day drags on as it always does. You try to brighten it up with as many "smoke" breaks as possible. You spend some time talking with other teams. Why does their work always seem more interesting than yours?
At the end of the day, the team got 10 stories done and 18 story points. A pretty average day. You think to yourself how pathetic that the team just can't seem to accelerate their velocity. You know why, but no one's asked you. Bringing it up would just make people mad and dump more work on you. Why bother?
Do you recognize yourself in either Shawn or Alex's story? I sure do. In fact, I can pin down specific times when I've thought like both of them. But why?
For me, it all boils down to how motivated I am to tackle my work. I've learned about myself that I am much more motivated when I am solving interesting, new problems that require creative solutions. I'm never more fulfilled at work than when I am on the path to solving a problem that everyone else thinks is impossible. It really doesn't matter too much whether the problem is deeply technical, process, coaching or managerial. When I'm deep into a problem, the days go by fast and I have fun. On the other hand, I can be working on a fantastic project, surrounded by great people, making great progress, and be completely bored and unenthusiastic. In other words, my biggest motivation comes not from the speed of my work but from its acceleration.
What's telling in my own description of my motivations is that it is almost completely devoid of descriptions of my coworkers, environment, and social aspects. It's probably a horrible thing to say about myself, but my own internal motivations are much more driven by the problems I'm solving than the people I'm working with.
But that's not completely true, is it? I've certainly left jobs because the environment was stifling even though the work itself could have been interesting and rewarding. So there is a threshold beyond which I'm not willing to tolerate.
Everyone Else's Story
As hard as it is to understand my own motivations, it's even harder to understand others'. Everyone has their own personality, their own likes and dislikes, and their own motivating factors. And out of those individuals emerges a team personality with its own motivational factors.
As I work with more teams, helping each to establish their own practices, it becomes obvious that what motivates one team is completely unimportant to another and vice-versa. Let me give you an example.
I was working with a team that was using eXtreme Programming. Every two weeks, they'd have the obligatory pre-iteration planning meeting and iteration planning meeting. Only they hated it. They did everything they could to avoid the meetings. They just wanted to be able to keep working. The team decided to experiment with one week iterations and that made things even worse. The team was not happy and not motivated.
Enter Kanban with its continuous process. No pre-iteration or iteration planning meetings. The team loved it. They got a real thrill out of seeing stories move across the Kanban board. They loved it when they finished a story and got to pick up another one. There was an excitement and energy to moving stories across the board quickly. They were well motivated by the continuous movement of stories.
Flash forward: I'm working with another team that is using the Kanban process. They are extremely unmotivated. Every day is like the one before. There's no short-term deadline to give them focus. After months of struggling, we switch to an iterative process, establishing short-term deadlines through iteration planning. Suddenly, the team has more energy and excitement around hitting our deadlines, and their velocity increases. They got almost no motivation from watching stories flow, but they did get motivated and excited about hitting near-term deadlines.
So which method, iterative or continuous, is better for motivating a team? Experience tells me that it depends on the team. And that's true for almost anything.
When helping a team to be more motivated, its important to understand the difference between intrinsic and extrinsic motivation. Extrinsic motivation is something you can do for them. It's having team-building activities, setting up a great work environment, providing good compensation, helping them understand the importance of the product and perks like free soda.
Extrinsic motivation is important but intrinsic motivation is even more powerful. It's the motivation that the individual has inside them that drives them to do what they do. Helping your team members tap into their intrinsic motivation means that you don't have to keep supplying extrinsic motivation. Now, it's personal.
Dr. Mark Balbes serves as Vice President, Architecture at WWT Asynchrony Labs, and leads multiple Agile projects for Government and Fortune 500 companies. He received his Ph.D. in Nuclear Physics from Duke University in 1992, then continued his research in nuclear astrophysics at Ohio State University. Dr. Balbes has worked in the industrial sector since 1995 applying his scientific expertise to the disciplines of software development. He has led teams as small as a few software developers to as large as a multi-national Engineering department with development centers in the U.S., Canada, and India. Whether serving as product manager, chief scientist, or chief architect, he provides both technical and thought leadership around Agile development, Agile architecture, and Agile project management principles.