Yellow Squad Weekly Topics: July 6

Summary:

• gary_poster/benji: Personal feedback loops
• bac/benji/gary_poster: Poorly specified tasks

[introduction] [project report] [tricks] [topics]

gary_poster/benji: Personal feedback loops

We already have team feedback loops, in the form of weekly internal retrospectives and weekly external goals, deliveries, and reports.  They help us identify when we need to evaluate and improve our processes.

What about personal feedback loops?  Could they help us identify when we need to improve ourselves, individually?

What would the requirements be for these feedback loops?

• Feedback comes regularly. Weekly, for instance, might be acceptable.
• Providing feedback is extremely easy and quick.  It can become habitual.
• Feedback is actionable.
• Feedback is generally positive; negative feedback is rare and likely to be a valid warning.
• Feedback encourages self-improvement, and discourages competition.
• An experimental run of the feedback loop is cheap.

Our first proposed experiments in this direction are a weekly focus on collaboration and external communication.  We define collaboration as working with other members of our squad to productively move an active task--an active kanban card--forward.  We define external communication as productively communicating with another community connected with our squad, within our company or not.

The rationale for emphasizing collaboration is that we work better as a team, and working together takes practice.  The experiment will work as follows.

• The goal is to have collaborated with at least two and ideally three of the other four squad members every week.
• The results are a bright green light (collaborated with three or four other squad members), a green light (collaborated with two other squad members), a yellow light (collaborated with one other squad member), and a red light (collaborated with no other squad members).
• Anytime you collaborate with someone new that week, record it "in the web app."
• For the cheap experiment, everyone will record the collaboration "in the web app" by sending an email to gary_poster with a subject like "bac and frankban collaborated" and no body.  gary_poster will collect, process, and send out the results at the end of the week (each of which will have exciting subjects like "collaboration: bright green light!").

The rationale for emphasizing external communication is that productive external communication builds our ability to work within the larger communities that surround us.  This in turn helps us move faster when we need help outside of our squad.  It also encourages us to consider solutions that should happen upstream, rather than workarounds that we hack locally.  The experiment will work as follows.

• The goal is to productively communicate with other communities connected to our squad and its projects at least once every week.
• The communication might be a blog post; a bug, patch or branch sent upstream; an email to a widely distributed list (within the company or within another connected community); or some other relatively high-content, productive communication.
• The results are a bright green light (communication with two or more external communities that week), a green light (communication with one external community that week), a yellow light (no external communication this week, but some external communication last week), and a red light (no external communication for the past two weeks).
• Anytime you make a productive communication to an external community that is new that week, record a link to it "in the web app."
• For the cheap experiment, everyone will record the link by sending an email to gary_poster with a subject "external communication" and a body that is the link.  gary_poster will collect, process, and send out the results at the end of the week (each of which will have exciting subjects like "external communication: bright green light!").

Any discussion? People seem interested in the experiment.  Let's do it.  ACTION: gary_poster will document the experiment (see above!) and then we will start.

bac/benji/gary_poster: Poorly specified tasks

bac, benji, and gary_poster all were involved in two active kanban cards that took more than 24 hours to move.  Per our squad's policies, that triggers questions: why?  Is there something to improve?

In both cases, the tasks that the project/team lead (gary_poster) had specified on the cards seemed to be relatively clear cut.  However, after the developers started the tasks and then asked for review or feedback, it turned out that the goals were not as well defined as they had seemed.  This resulted in rework, and a longer-than-desired development time.

What can we do to address this?

• Remember to have pre-implementation calls for each task.  That's been part of our process for years, but we've neglected it for awhile in our squad.  It could help.
• The person making cards for a project should explicitly identify cards that are clearly defined, and those that are less defined "goal" cards.  The "goal" cards might be rewritten and exploded into multiple better defined cards when the task is started and the goal is better understood.
• As we close our daily call, we should call out the kanban cards we plan on starting.  This can give a chance to review and identify cards that can be started but need clarification or pairing.

ACTION: gary_poster will add these items to our checklists.