Tuesday, April 21, 2009

My Favourite Core Protocols

I already mentioned the Core Protocols in my first post on this blog. But maybe I need to say more about just how powerful and effective - let's admit it, how cool - they are. Here are my four favourite protocols, in some kind of order. (For reference, there's a link on this page to V3 of the Core Protocols, in PDF form.)

A word of explanation: yes, they're called protocols. But don't think of them like a Japanese tea ceremony. Colleagues of mine have commented that they're like Robert's Rules of Order, which is closer to the truth, but they're much more succinct and general. Think of them more as tools to use if you want greater productivity, more effective teamwork, and maybe even a fuller and richer life.

Decider
This really works. Making decisions in a team can be quick, easy and effective. This protocol allows anyone to cut through endless debates and get to the meat of the matter. It can be used to speed up meetings, or even achieve a consensus on whatever you want: a protocol, an approach, a goal, a vision. Though the consensus might not match the idea you were thinking of at the start, it is possible to converge on an idea that everyone can support.

Check In
The Check In protocol is all about expressing your own emotions, and allowing - even encouraging this - in a team context. It's valuable for building trust in a team, but a Check In is most valuable for the person expressing their emotions: having to articulate how you feel is key to being in touch with yourself.

This protocol also ties in with two different books that I've been reading lately. One is called "Assertiveness: Step by Step" by Dr Windy Dryden and Daniel Constantinou. It defines assertion as "the flexible pursuit of having our preferences met, our opinions voiced, our emotions and beliefs honestly communicated in an appropriate way at the relevant time". Honestly communicating beliefs is what Check In is all about.

The other is "Peoplemaking" by Virginia Satir. This is an older book - it may be out of print now; I bought it second-hand through Abebooks. Virginia Satir was a family therapist, but I heard about her through reading what software developers and managers were writing, in particular those associated with the AYE conference. She claimed that when one is feeling threatened, one can react in five different ways: by blaming, placating, computing, distracting or leveling. Of these, leveling - matching one's words to one's feelings and one's expressions and body language - is the only healthy response in the long-term. And this is what Checking In is all about. So this protocol is connecting with a whole lot of things for me and making a lot of sense.

Ask For Help
I've been amazed at the quality of the answers and help that I've got from using this protocol. Yes, people have sometimes said no, but that's fine, that's part of the protocol.

There's two things in particular that I appreciate about this protocol.

Firstly, it removes the shame from asking for help - something that I have had trouble with in the past. Asking For Help (using the protocol) is emphasized in the Core Protocols and supporting material (including the book Software For Your Head) as the best way for the team to achieve its goals. In fact, it's made clear that you can't Ask For Help enough.

Secondly, part of the protocol is that you should only provide help when you're asked. Providing help when you're not asked is dubbed a Rescue (one of the team Anti-Patterns). This leads to less unwanted advice and (as I'm slowly coming to understand) less chance of overpoliteness and oversensitivity (two faults that I'm prone to).

Personal Alignment
It may seem a strange tool to use when trying to achieve better teamwork, but the Personal Alignment protocol is all about achieving your own individual goals. The protocol is all about listing these goals, putting them on record, then working out what would help you most to achieve those goals. Other team members are encouraged to help in the process. I'd identified long-term goals for myself years ago - helping others, making a significant difference in the world - but using this protocol with others' help has really helped me understand myself that much better. I'd set up obstacles for myself that I hadn't fully realised; naming them and bringing them into the light has shrunk them in my mind.

For the record, building Ighalsk into a game that people want to play and enjoy playing, and building a community around Ighalsk are two of my short to medium-term goals; and wisdom is what I most need to help achieve that goal. This includes, but is not limited to, the wisdom to understand what people are looking for, and where people are. And wisdom is something that I'm still seeking - I'm very aware that I still need much more wisdom!

EDITED: 3 typos corrected - thanks Harold!

EDITED AGAIN (2nd August 02009): As pointed out in comments, the link in the last sentence of the first paragraph is broken. Here is where you can download v3.02 of the Core Protocols.

Ighalsk - Coding Guidelines

Here are the coding guidelines that I'm endeavouring to follow for Ighalsk. They're guidelines at this stage, not rules.
  1. Everything can be changed.
  2. Creating, extending and sharing is good and should be as easy as possible.
  3. All tests should pass.
  4. Names should be meaningful.
  5. Comments should express intent.
  6. Don't repeat yourself.
  7. Do the simplest thing possible.
To expand on these somewhat:
1. Can also be thought of as, "everything can be refactored". If a module can be rewritten to make it cleaner, simpler or more readable, it should.
2. An open-source principle, but it should also apply to objects in the game: monsters, items, powers, special levels and professions.
3. Irrelevant and/or obsolete tests can be removed.
6. From Pragmatic Programming - Extreme Programming calls this the "Once and Only Once" principle.
7. An Extreme Programming principle.