remember writing is hard work (code or prose)

Stephen Wilbers is a writing consultant. He wrote an column on effective writing in the local paper for many years and offered this advice on editing in his farewell column(published in the Minneapolis StarTribune 10/29/04):

Show respect for the person who created the copy. Remember that writing is hard work, and writers often feel sensitive or defensive about changes in their copy.

Know the rules and conventions of language. You owe it to your writers to know your stuff. Don't move a comma or change a word as a matter of personal preference. Base your revisions on what you know to be correct, as supported by a standard reference guide.

Distinguish between grammar and style. Be more definite when you recommend changes involving grammar and usage; be less definite when you recommend changes in idiom and style. Don't present your notion of style ("It's wrong to begin a sentence with and or but") as a rule of grammar.

Don't over-edit. Remember, there's more than one right way to do something. If you tend to be overly zealous in your editing, first read the copy from beginning to end without making any changes. This approach will allow you to tune your ear to the writer's voice before you begin altering the copy.

Substitute few words and this advice fits for commenting on code, too. Good points to remember for pairing, technical reviews, and inspections.

Talk, talk, talk

A couple of weeks ago, I attended a fund raiser and was seated next to a person I didn't know. I struck up a conversation, asked a few questions, and learned that the person next to me was a manager in a IT department.

This week, I had lunch with another manager in a high-tech firm.

Here's what struck me about these conversations:

In both cases, the other person did the bulk of the talking. The first manager didn't ask any questions; the second manager asked one question. In both cases, it was hard to get a word in edgewise.

Now, these were both social situations, and these two people may be very different at work. Then again, maybe they're not -- a leopard does not generally change his spots.

If these managers do all the talking when the meet with the people on their teams, how do they know what team members are working on? How do they learn where team members are struggling, what their strengths are, and what they want to do with their careers?

It's a puzzle.

Managers, coaches, and technical leaders do need to talk -- to explain company and department goals, communicate important information and tie tasks to strategy. When they aren't doing that, managers need to ask questions and listen.

The proportion should be somewhere around 30% talk and 70% listen.

Tim Bacon posted a great set of questions for managers/coaches here.

Notes on Retrospectives from my open session at Better Software Conference

A couple of weeks ago, at the Better Software Conference in San Jose, I lead an informal session on Retrospectives. I agreed to put the notes from our session up on my blog. This is a combination of the notes and my editorial comments :-)


I use a framework for retrospectives, regardless of how long they are. My framework comes out of the ICA Focused Conversation method, which is based on empirical knowledge of how humans process information.


Start with the data (Objective level)


Then find out how people responded emotionally (Reflective level)


Step back and look at the interplay of the data and responses to figure out the significance to the group (Interpretive level)


Decide what to do (Decisional level)


The short form is: What? – Gut? – So what? – Now what?


No matter how long your retrospective is, or how much time your retrospective covers, going through each of these steps helps the group take a learning journey together.


Choose exercises based the context of the group, the duration of the project/iteration and the time dedicated to the retrospective.


In our session, we shared exercises we’ve used at each level. I’ve made some notes about adapting for an iteration retrospective at the bottom of the post.


Objective: the data about the project

Recreate the project timeline

Present project data e.g., time spent by phase (as a pie chart), staffing levels, LOC, bugs found

Create a time line with subject lines from emails

Create a time line of monthly status reports

Show time spent in meetings vs. not in meetings

Data related to project specific questions:
How are the data structures holding up?
What were the major refactorings?


Reflective: what life was like on this project
I know, I know: some people aren’t comfortable talking about emotions ( I very seldom use the “F” word –Feelings— when I do retrospectives). And it’s critical to surface emotional responses – this is where we learn what was important to people. Reflective data tell me where people’s energy is and where there’s likely to be some juice for learning.

Seismograph

If you’re using a timeline, use color cards or color dots to mark events: green = great, blue = low spots, yellow = surprises (or a color scheme of your choosing)

Have people draw pictures on the timeline or draw pictures of how it felt to be on this project

Ask “Did this project succeed?”

Create a visual stress-o-meter

Interpretive: what do we make of the data so far. Insights and meaning to the group

This is where most people start post project reviews. My experience is that you get much deeper insights – and more group support for those insights – when you start with the data and emotional responses.

Some questions to ask at this level are:

Norm Kerth’s 4 questions:
What did we do well that we want to continue?
What would we do differently (knowing what we know now)?
What did we learn?
What still puzzles us?


This was the best project because … (list the reasons).
This was the worst project because … (list the reasons).

What would we do exactly the same?
What would we stop doing?

What was really good?
What are suggestions for improvement?

Decisional: taking insights into action

For a retrospective covering a longer period of time consider these strategies:

Make a contract that identifies who will follow up before the retrospective.

Take the results back to budget and line managers.

Feed insights from the retrospective forward into risk management and inspection checklists.

Prioritize insights. Develop action plans for issues the team can effect. Develop recommendations for issues that need budget or approval from management.

Write patterns

Evangelize

Use Open Space to support people in taking responsibility for working the issues they have energy and commitment to address.

Convene a project management round table to share good practices, problems, insights, etc.

Attach costs to poor habits and ineffective practices


For iteration retrospectives after an iteration of 1 week to 30 days try exercises that
combine Objective and Reflective levels:

Histograms showing satisfaction with the Product, the Process, Teamwork

Create a diagram that shows:
How well we are doing on core practices and
How well we’d like to do next iteration

Interpretive

What could we do smarter next time?

What was really good?
What are suggestions for improvement?

Decisional

Develop action plans

Charge members of the team to invent a Big Visible Chart on the status of a habit/practice they want to improve.

Ask:
What would we do exactly the same?
What would we stop doing?

Further resources:

Project Retrospectives: A Handbook for Team Reviews. Norm Kerth
Facilitators Guide to Participatory Decision Making. Sam Kaner et al.
The Art of Focused Conversation. Brian Stanchfield, ed.
Requirements by Collaboration. Ellen Gottesdiener
Singing the Songs of Project Retrospectives in Cutter IT Journal (mining patterns in retros). Linda Rising and Esther Derby

Note There's something funny going on with blogger, most of the tool bars are missing. I'll add links and pictures (fingers crossed) later. And spell check.