Category: Learning (Page 12 of 15)

Its Purpose?
Every project has meetings or events that repeat. Sometimes they occur daily, others weekly and others less regularly. Sometimes they are informal and ad hoc, other times formal and repeated. It’s important for new people to understand what you call each of these rituals, how they work and why these rituals exist. Understanding what you call them, how they run and why helps them become a fully participating team member faster.

How Did We Execute It?
Before any repeating meeting we would have, if we had a new team member, I would explain what we were about to do, and explain the reason we met. Some rituals I didn’t explain in great detail how we would conduct the meeting since it would be faster to let them experience one. I intentionally explained it in front of the group to ensure we all had agreement about what we were all about to do, and to help remind newer participants why we have them again.

Here’s what it may sound like (you may of course, have different resons for running stand ups in the example below that are just as perfectly valid):

Explaning what: We’re about to start our “Daily Stand Up Meeting”.
Explaning how: In this brief meeting, we stand in a circle facing each other and share information that we think others will be interested in such as what we did yesterday, what we’re planning to do today, and most importantly any blockers we currently have.
Explaining why: We do this in the morning to help start our day and talk about what we did yesterday to helps others understand what progress we’re making. We talk about what we’re planning to do today to double check our priorities are correct for the day, and we want everyone to talk openly about our blockers because we want individuals to feel supported by the team in overcoming any blockers.

Here’s another example:

Explaining what: We’re about to meet for our “Tech Huddle”.
Explaining how: In this session, we want everyone to share an important lesson they learned today, or a gotcha others should know about
Explaining why: The system is becoming complex, and everyone may discover new things (or even old things over again). By sharing some important lesson or a gotcha, we accelerate the learning process and avoid costly mistakes caused by relearning the same thing over and over again.

Image taken from Ron Layters’s photostream flickr stream under the Creative Commons Licence.

Why Is It Important?

It’s difficult for team members to fully participate in rituals unless they understand what expectations you have for them and understand why it’s important to participate. Explaining what you call the ritual, and how you conduct each ritual and the roles team members play is a first step in the right direction. Once they understand the what and the how, the new people understand what the name of your ritual means to them and are now enabled with the ability to participate. Explaining to them the purpose of the ritual and the drivers behind it them helps build a reason for them participate.

Giving them both the ability (what the ritual is called, how it is run and how to participate) and the motivation (the signficance and value of the ritual) helps new team members stand out less by helping them avoid coping strategies of silence (“I don’t know what to do, so I’ll just sit and watch what others do)” or resentment (“What a crock! Why are they wasting my time?”)

You gain a secondary benefit from explaining the ritual following the what-how-why strategy. Explaining the what and the how helps you understand how consistently you repeat your rituals, leading to standardised work. Explaining the why helps you focus on the value of your ritual. Often many rituals lack value and, as a result, you should drop them.

What I Might Try Next Time
The next time I explain my rituals, I think I’m going to try to write what I say down to see if I’m being consistent. This might also work well as project documentation useful in handover to support or to observers who sit outside of the project.

Its Purpose?
Explicitly identifying code patterns in the code base as well as how and why they’re used helps new team members learn more about the system faster. Explaining the system in terms of well known patterns helps new team members identify variants and where patterns are being abused/mis-applied.

How Did We Execute It?
In trying to hand over some work to the support group, the team assembled a list of all patterns used in the system. We listed the pattern name, a reference to the pattern (either book or web link) and how it was being used in the system. We also wrote down the benefits or concerns each was bringing to the codebase. We listed each of these on the team wiki on a page called “System Patterns”.

When new people joined, I would print a copy of the wiki page, and then during or after walking through the System Architecture, helped them understand where they might use them or see them being used.

Image taken from Hubmedia’s photostream flickr stream under the Creative Commons Licence.

Why Is It Important?
Patterns are excellent vehicles for communicating intent and solutions to common problems. Identifying and explaining the system as a set of patterns helps new team members understand the system in much larger chunks, making it easier for new people to focus on absorbing incidental information. It also allows them to focus less on how the code works together, and more importantly focus on what the code does and what value it brings.

Well known pattern names help to identify common problems in the domain, and what the team’s general approach is for solving them.

The number of patterns also indicate a qualitative attribute of your system. If you have a very large system, and only a small number of patterns it potentially indicates that everything is done in very different ways and needs some refactoring. Alternatively if these small number of patterns are used everywhere in the system, then it could already be a very well refactored system. I would also consider looking at a very large set of patterns for a small code base as that might indicate over-design and excessive complexity. In both cases, I would watch out for patterns with only a handful of uses to see if they are actually useful or not.

Things To Watch Out For
Some new team members may not understand all the patterns used in the system. Giving them reading references helps though you may need to do more work to help them understand the pattern.

What I Might Try Next Time
I would revisit this list of patterns with new team members after they’d been in the code base for a while. I think although it’s useful to introduce the catalogue early, it would help to reinforce some of the larger picture after they’ve had an opportunity to discover more detail on their own.

Next time I would also try to link to some part of the codebase that implements the “ideal” version of the pattern and the benefits the team reaps.