Yellow Squad Wiki Home

https://launchpad.net/~yellow/+mugshots

Slogan for public consumption: Go go Golden Horde!

Slogan when we feel tired: Go go Yellow Banana Slugs!

Current project is LEP/ParallelTesting .

Daily call checklist

• Review cards in Deployment, QA, Active (slack, multi-branch, and quick), and Miscellaneous WIP/Done lanes.
  • Have any non-Done cards been in the same lane for more than 24 hours? If so, discuss pairing and problem solving.
    • Are the developers stuck? Consider "convening a panel" after this call (see checklist below) to become unstuck.
    • Have they been in the same lane for more than 48 hours? If so, consider adding or rotating programmers.
      • Is no-one available for regular pair programming? If so, strongly consider blocking an active card in order to get that developer(s) available for focusing on the non-moving card. If more than one card is not moving, consider focusing on one at a time.
  • Is a card Done that had been a problem (non-moving)? If so, record it on a kanban miscellaneous card [any other ideas?] as a topic for the Friday review call.
  • Do any non-done cards on the board have deadlines? If so, review as necessary.
• For each person, mention any items that the squad should know: remind people of reduced availability, request help such as reviews or pair requests, etc.

Unsticking panel checklist

• Take note of when the panel starts.
• Describe problem avoiding mentioning your own (stuck) solutions and ask for solutions and approaches.
• If that fails, describe your own solution and ask for solutions and ideas.
• If the panel has taken longer than 20 minutes, stop. Arrange for a pair programming or consultation as necessary.
• If no-one has said anything other than filler for three minutes, stop. Arrange for a pair programming or consultation as necessary. Consider rotation.

Pair programming observer checklist

• Be actively skeptical.
• Watch the other person's back.
• Be a planner: actively propose plans to tackle problems, and offer to be a "navigator," keeping the destination in mind while the "driver" handles the details.
• When something doesn't make sense, this is a trigger for both parties to check assumptions and step back.

Weekly review call checklist

• Briefly review where we are in project plan.
• Any new tricks learned?
  • Collaboration tricks?
  • Debugging tricks?
  • Communication tricks?
  • Checklists? Processes?
• Any nice successes?
  • Can you attribute your success to anything beyond the innate brilliance of yourself and your coworkers?
• Any pain experienced?
  • Questions to ask:
    • Are there any cards that are/were taking too long to move?
      • Are they blocked?
      • Are we spinning our wheels?
      • How long is too long?
    • Are we not delivering value incrementally?
    • Are we not collaborating?
    • Did we duplicate any work?
    • Did we have to redo any work?
      • Did we misunderstand the technical requirements, the goal, or a process?
      • Was the ordering of tasks that we chose broken?
  • Can we learn from it?
    • Checklist?
    • Experiment?
    • Another process change?

Starting a project checklist

• Prototype (no tests). Consider competing prototypes.
• Have a squad discussion about lessons learned and design decisions.
• Begin coding with TDD