Tales of Agile Adoption

Monday, September 10, 2012

What is Coding Dojo

This is just a quick reference of what is a Coding Dojo; to go deeper please refer to this source.

Definition

A Coding Dojo is a meeting where a bunch of coders get together to work on a programming challenge. They are there have fun and to engage in Deliberate Practice in order to improve their skills.

Premises

Acquiring coding skills should be a continuous process

Characteristics

Non-competitive, collaborative, fun environment
All skill levels are welcome
Safe to try new ideas

Requirements

Meeting room with enough seats (typical attendance varies between 5 and 20 ?)
At least one PC or laptop
A digital projector ('beamer')

Total event duration

From 2hrs 30mins to 3hrs.

Who started the movement?

Dave Thomas, here you have two valuable resources:

PragDave, is the Dave's Blog; and,
CodeKata, the Coding Dojo's crib.

Sunday, September 9, 2012

Bad Communication Habits (2 / 3)

2. Inverted channels priorities

Background

I've seen many teammates taking to each other using an inverted priority for the following channels:

Phone
[Direct] Conversation
Emails or other text-based channels

Any time a person is involved within a negotiation (requirements, specifications, bugs reports, ...); that person will prefer to talk all others involved with the most formal channel in order to protect herself and document all agreements.

So they, try to send all details first in a written form (email or similar); if that does not help they try with a phone call, usually a conference call for others to listen and be witnesses. Finally, if that does not help; they try with a direct conversation or meeting.

This approach is not effective for two things

The main focus, the intention behind, is to cover all possible future problems resulting from misunderstandings. The intention is to have (collect), evidences for future blame.
We always get better results, in terms of time and quality, with personal interactions than with any other communication channel.

Managing this problem

To manage this problem, we can use some practices:

Always honor your promises: if you talk, face to face, with anyone and agree upon something; but later you do not honor your word that person won't trust you in the future. This situation will lead your teammates to collect evidences any time they need your help with something; so they can blame your later when you fail.
Prefer, always, the inverse order (conversation, phone, email): if possible try to start any interaction first in person; then by phone and using emails if no other channels were available. If you constantly do this your teammates will start to change their style (at least when interacting with you). Remember to observe the first practice.
Structure your interactions: if you start requesting to everybody that they should meet with you personally, some people can argue that you are just too far away and that they prefer to call or email you. Also, they can argue that this approach consumes too much time. The answer to these reactions is to schedule your interactions. If you constantly receive request for changes, manage to have a meeting every X day of your release cycle.

If you can follow these 3 practices, you'll have better agreements; you'll increase the confidence of your teammates (about you); and finally, you'll invest less time in interactions that do not lead to an easy understanding.

Today's mood I

Random thoughts, resources and information that I think are useful in one way or another ...

Pages