How to be Productive
The Agile Samurai: Chapters 9, 10, 11
Scenarios and stories
Effective user testing
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.
A visual view-controller of the user stories for
a physical board
in a shared team space
Alternatively, an online visual tool like
Github project boards
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)
means story has been specifically evaluated with users
Backlog to Task Board Flow (Common)
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
, help a teammate finish one rather than start a new one
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
Put prioritized tasks in the
Ready to do
When starting a coding session, pick whatever task is on top
Start a feature branch, tell the team
If you can't finish, throw away the branch
Don't Push. Pull Work Items for Better Results
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
<More to come!>
Thanks to Hakim El Hattab for
the slide template