I Follow My Rules, You Follow Yours

It's ok when I follow my own rules, and when you follow yours. As long as we agree on the value of each other's output.

In software projects the behavior of team members is guided by practices. Practices on how to document requirements, how to estimate work, how to commit source code, how to write test code, how to deploy solutions, etc. So, team members use practices (some might call them processes, or rules) to convert input to output. That means that project team members are no different than other types of "agents", in other types of complex systems. Bees in an beehive also apply rules to generate output from input. And so do neurons in a brain, and antibodies in an immune system, and so on, and so on…

What is different in the case of software development, however, is that there's a lot of variety among the rules that team members use. Sure, there's some diversity among bees as well. But most of a bee's programming is genetic, not learned, while team members don't acquire their daily practices just by being born into a hive. Team members acquire their practices through learning and copying other people's behavior. (And sometimes, as often in my case, by stubbornly inventing and following rules of their own.)

And each team member maintains his own set of rules. One developer commits test code to a branch in source control before writing production code, while another prefers to shelve all code, committing everything to the trunk only after it runs flawlessly. One designer constructs interaction designs in Visio wireframes, while another claims that nothing beats slate and crayon markers. One tester documents acceptance tests together with their requirements in some collaboration tool, while another prefers to produce simple MS Word files. And I'm still in favor of sparse source code comments, while everyone else seems to prefer source code headers with a size comparable to the United States trade deficit.

Is it bad when people follow their own rules?

Well, no, yes, maybe. It depends…

For a ScrumMaster it would be very inconvenient when each team member adopted a different way of estimating user stories. The whole team has to agree on some things, like story points vs. ideal hours, or it would be impossible to calculate velocity. Likewise, there must be agreement on dates and times for meetings, the length of sprints, etc.

But there may be no need to fully synchronize their source code practices. As a team member, as long as the code on the trunk is fully tested, I could live with other people's own preferences for shelving, branching, commenting, etc. And I don't really care about the medium used for the interaction designs. I care more about the team members being motivated. And I care about myself being motivated, which means I'm not going to pair program when I'm not in the mood for it. (Which is quite often.) I want to be judged for the value of my output, not the manner in which I created it. If I can produce the best quality source code while sitting naked in a conference room wearing only boxer shorts on my head, then who's to complain? (This is just an example. I tried it, but it didn't work.)

People often want to impose rules when there's no real need for it. Sometimes that's because they don't like to see team members following other rules than their own. But managers should guard against useless synchronization of rules. It can often be good to allow people to do things their own way. The freedom can motivate them. And team members can copy each other's rules when the output of others turns out to be better than their own. (If the code I wrote in that conference room had been nothing short of amazing, I'm sure many people would have followed my example.)

Last but not least, different competing rules in a team can actually strengthen the whole. Problems with source code might go undetected when all team members handle code in the same way, using the same rules. And team members can improve their communicative skills when they are able to work with different types of input. In a previous post I wrote how diversity can increase a team's flexibility, resilience and robustness. I believe this doesn't just apply to people, but to the practices they follow as well.

And that's one other reason to keep inventing and experimenting with new rules. You will not only improve yourself, but the quality of the team's as well. Next time, I'm going to try coding in the board room, and I might swap the boxers for briefs.

Follow me on Twitter – Subscribe with a reader – Subscribe by email!

Latest, greatest and favoritest posts:
Real Agile Teams Can Flock
How Smart Managers Think
To Motivate or Not to Demotivate