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 this wiki page 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 / set an alarm for T+20.
• 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
• 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.

• Review "topics for next", below

• 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?

Topics for next

• benji: what can we learn from bug 996729
• bac: what can we learn from bug 682772
• gary_poster: preferred technologies checkpoint: do we have any shared opinions?

Starting a project checklist

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

Depending on another developer or team checklist--someone new or with past delivery problems

• Doublecheck whether you can't do it yourself somehow, or get someone with proven cross-team delivery ability.
• Are you depending on a person or a team? If it is a person, consider trying to escalate it to the manager, to make it a team goal, or at least something with team visibility and managerial approval and encouragement.
• If they need something from you, ask what format they want it in in order to be able to process your request as quickly as possible.
• A corollary to the previous one: make sure that you are making the smallest request necessary and reasonable.
• While it is tempting, and sometimes necessary, to be flexible for interacting with busy people, if the work is worth doing, the sooner it is done, the more value you get from it. The longer you wait, the more likely it is that you will get no value from it. This is "lean" for our squad, and also for the company. Try to communicate this.
• Request a delivery date guess. Consider requesting that a call be scheduled on that date, either for handover or for reassessment. If there is a deadline for us, also bring this to the attention of the Launchpad manager (flacoste).
• If the delivery doesn't happen on the expected date, (on the scheduled call) ask for three things: a revised delivery date, another associated call, and a fallback plan. The fallback plan should be some reasonable remediation if the second delivery date fails. Also bring this to flacoste's attention, and discuss with him whether official escalation is appropriate.