Safety in decision-making and action-taking is all caught up in expectations and working agreements, and many of ours have been unspoken, unwritten, and un-negotiated. As a result, it is easy to drop things, expecting others to pick them up when they don't know to do it. It's also to do things that seem to step on your colleague's toes or which work at cross-purposes.
I was doing some work for a very dear client of ours, and I needed to revisit the Debian New Package Maintainer's guide. What appears on page one? A set of working agreements.
This is actually a pretty good set of working agreements for any project, church, or even commercial team.
We are all volunteers, if we could go elsewhere and do something else. Therefore, imposing on others or not doing things you can manage on your own is inconsiderate of others.
Friendly cooperation is the basis of any team, whether they consider themselves volunteers or not.
Likewise, constant improvement is the law of the land in any software project. We should be flexible to adopt any improvements that come our way -- even going so far as to radically change our programming habits (see TDD, Refactoring, Code Smells, Pair Programming... )
The item about not being a school is probably the only area where Debian guidelines and team software development team part ways. A good team is a highly effective school, or it's not really a great team. The learning is a key part of the landscape.
Face it, if you program today exactly like you did three years ago, you've wasted three years. There is no shortage of useful skills to add to our repertoire.
When we pair program or mob program, we have ready teachers. We need all the information we can get to make decisions quickly (enough) and well (enough). We lean on each other more, but that includes being someone others can lean on.
- We all are volunteers.
- You cannot impose on others what to do.
- You should be motivated to do things by yourself.
- Friendly cooperation is the driving force.
- Your contribution should not overstrain others.
- Your contribution is valuable only when others appreciate it.
- Debian is not your school where you get automatic attention of teachers.
- You should be able to learn many things by yourself.
- Attention from other volunteers is a very scarce resource.
- Debian is constantly improving.
- You are expected to make high quality packages.
- You should adapt yourself to change.
This is actually a pretty good set of working agreements for any project, church, or even commercial team.
We are all volunteers, if we could go elsewhere and do something else. Therefore, imposing on others or not doing things you can manage on your own is inconsiderate of others.
Friendly cooperation is the basis of any team, whether they consider themselves volunteers or not.
Likewise, constant improvement is the law of the land in any software project. We should be flexible to adopt any improvements that come our way -- even going so far as to radically change our programming habits (see TDD, Refactoring, Code Smells, Pair Programming... )
The item about not being a school is probably the only area where Debian guidelines and team software development team part ways. A good team is a highly effective school, or it's not really a great team. The learning is a key part of the landscape.
Face it, if you program today exactly like you did three years ago, you've wasted three years. There is no shortage of useful skills to add to our repertoire.
When we pair program or mob program, we have ready teachers. We need all the information we can get to make decisions quickly (enough) and well (enough). We lean on each other more, but that includes being someone others can lean on.
No comments:
Post a Comment