There are many ways to motivate (and demotivate) people. As a development manager, project manager or ScrumMaster, it might help to use a mental balance sheet in your head, for each person in your team, to monitor their motivation.
Here's how it works...
When I was only 12 years old (which was shortly after the last ice age), one of my teachers told my mother that my attitude was like that of a territorial animal. I hated sharing my comfort space. I didn't like it when pencils and other stuff (of the kids next to me) occupied some inches of my desk. And I also kept pushing away the schoolbags that were invading my territory on the floor. This attitude has never changed. I still don't like it when people trespass on my belongings, my living space, or the results of my creative efforts. I once had a partner who carelessly opened my mail. He still carries my bite marks. And I feel no shame in admitting that it took me three years to agree on a shared bank account with my current spouse. Reluctantly.
Not surprisingly, I also don't like sharing my code with other people. That's why I consider collective code ownership, as promoted by Extreme Programming, to be in direct violation with my personal well-being. My code is mine. Your code is yours. Sure, I'd love to interface, and I'm eager to make improvements, but it will happen under my conditions. I don't want other people to touch my stuff. My code is not available for a collective rewrite. (Surely, I hope you're not suggesting that others can rewrite my articles too, are you?)
So, if you think a new practice is required, how are you going to handle your people's motivation?
Well, imagine a motivational balance sheet that lists the things that motivate and demotivate a person in your team. It is important to understand that "best" practices have different effects on different people. Collective code ownership demotivates me. Therefore, it subtracts one point from my motivational balance sheet. But my good friend Niels, who is the truest socialist I ever allowed to come close to my private life, and who sees no problem in handing over his belongings to some collectivist system for "the common good", would probably be delighted to hand over his code as well. Therefore, a collective code ownership policy might motivate him tremendously, and his motivational balance sheet would earn a big point.
We should treat all other debates on best practices in a similar way. For example, I prefer working in a large open space, so that can I see everyone, and always know who stole my chair. But I understand that other people prefer a private office, so that they can enjoy some peace and quiet while they're working. Fortunately, that's one positive point for me on my balance sheet, as my current office is one big open floor, shared with 80 people, three printers, one coffee machine, a big red balloon, and a ship's bell. And I like it. However, I think my friend Niels values his privacy more than I do, so maybe he would score a negative point on this issue. If he were to work for our company. Which he doesn't. So, good for him!
Likewise, we could discuss whether to estimate features using "story points" versus "ideal days" versus "feature points" versus "bananas", and whether the iteration length should be one week or four weeks, and whether to use a fancy electronic tool or pink paper sticky notes as an agile planning tool, and whether to use C#, Ruby, Python or Lisp for our new project, and so on, and so on... But the best thing is: by simply supporting your team members in having these discussions you score positive points on every motivational balance sheet in the team. It's like creating wealth for free!
My Motivational Balance Sheet is positive. I'm motivated!
There are many ways leading to Rome. And while the ways leading to successful software projects might be somewhat less numerous, there are still plenty of choices along the way. On the forks in the roads I often come across discussions and heated debates on "best" practices that don't take into account the first value of the Agile Manifesto, which is still "People over Process". Motivating your people is always more important than establishing your own favorite processes. Just face it, if you are ever unfortunate enough to be managing a project team full of people like me, then they are never going to like the collective code ownership policy, no matter how many Kent Beck Signature books you try to throw at them. You will have to balance that new policy with some other very convincing and motivational practices, or you will have to lick your wounds and try something else.
Every person in your team has a different motivational balance sheet. The processes and tools you introduce will score both positive and negative points across the team. Sure, it might be necessary to introduce a new rule that sends most of your team into turmoil. Like writing time sheets, or taking turns listening to a customer. Sometimes there's no gain without a little pain. Just make sure to keep in mind the 1st Law of Software Development: Motivate People. Whatever practices you preach, motivate your people, and keep their sheets balanced.
Subscribe to this blog with a reader or by email!
Latest, greatest and favoritest posts:
The 1st Law of Software Development
Simple vs. Complicated vs. Complex vs. Chaotic
Eat Chaos, Poop Order
