How to be Productive

Readings

Backlog

  • A prioritized list of user stories
    • Not tasks, like coding or meetings
  • Use ordering to show priorities
    • Top means "we do this next"
    • Not top means "we may never get to this"
    • Don't assign numbers, "must-have", etc.
      • Everything becomes priority 1.

Task Board

Minimal Task Board (Good)

Task Board with Review (Better)

Ready to review means tested and committed, but waiting for client approval

Task Board with User Testing (Best)

User tested means story has been specifically evaluated with users

Backlog to Task Board Flow (Common)

Moving to Ready to do is not a small step.

Backlog to Task Board Flow (Better)

Define user goals, with user tests, along with code goals, with acceptance tests.

Task Board Flow

  • Move stories move from left to right until completed
  • Clear board and start over on each iteration
  • Limit work in progress
    • If two stories in Doing, help a teammate finish one rather than start a new one

Assigning Stories

  • You have an iteration backlog of user stories
  • You have a team of developers
  • You assign stories to each developer
  • This is a bad idea.

What's Wrong with Assigned Tasks

  • Assignments are made at a time of least information
  • Everyone assigned a task becomes a potential bottleneck
  • Tasks are owned by a person not the team
  • Assignments encourage silos and low bus factor

Pulling Tasks When Ready

Why Pull Tasks

  • No waiting for someone else to finish anything
  • Forces everyone to be ready to code any part of the app
  • Eventually everyone works on everything
  • Team ownership of code increases

Pulling Tasks Uncovers Problems

  • "I don't know how to do the top task!"
    • The tests for Done are bad, or
    • The team has a bus factor problem
  • "I can't do the top task alone!"
    • Why are you working alone?
    • The team's stories may be too big.

Throw Away Unfinished Branches

  • If you can't commit code, throw it away.
  • Never commit broken code.
  • Don't keep branches open for multiple sessions.
    • Long-lived branches are bottlenecks and sources of integration failure.
    • Every re-entry takes times and risks forgetting something.
    • Reconstruction usually create simpler solutions.

"I had to throw away a lot of code!"

  • Learn how to slice:
    • Example: to move email column from user table into separate table
    • Create, test, and commit code for new email table, not integrated into app code
    • Create, test, and commit code to redundantly add new / changed emails to both user and email table
    • Create, test, and commit code to get emails from new table
    • Create, test, and commit changes to delete email column from user table

Github Best Practices

  • Master branch always deployable
  • Make feature branches for multi-step changes, e.g., a user story
    • Should last only a day or two
    • When done, merge with master and delete
  • With client, create a long-lived development branch
    • Make feature branches off of development
    • Synchronize master and development weekly
    • Development always ready for user testing