The Assignment Bottleneck Typical workflow: ├─ PM creates task ├─ PM decides who does it ├─ PM assigns to developer ├─ Developer gets notification ├─ Developer starts (maybe) Problems: ├─ PM doesn't know who's busy ├─ PM doesn't know who's best fit ├─ PM becomes bottleneck ├─ Developers wait for assignment ├─ No ownership - 'I was told to do this' Push System Failure Push = Manager decides, developer receives.
Symptoms: ├─ 'Why am I doing this?' ├─ 'This should be John's task' ├─ 'I'm blocked waiting for assignment' ├─ 'Nobody owns this problem' ├─ 'Ask the PM what to work on' Push creates: ├─ Dependency on manager ├─ Passive developers ├─ Resentment ├─ Mismatched skills to tasks ├─ Slow response to priorities Pull System: Developers Choose Pull = Developer picks from prioritized backlog. Workflow: ├─ PM prioritizes backlog ├─ Top items are highest priority ├─ Developer finishes task ├─ Developer pulls next from top ├─ No waiting for assignment Benefits: ├─ Developers own their choices ├─ Self-selection matches skills ├─ No bottleneck at PM ├─ Immediate next task available ├─ Intrinsic motivation Prioritized Backlog Model Backlog structure: ├─ Sprint Backlog (This Sprint) │ ├─ 1.
User auth - High priority │ ├─ 2. Payment integration - High │ ├─ 3.
Dashboard charts - Medium │ ├─ 4. Email notifications - Medium │ └─ 5.
Settings page - Low ├─ Product Backlog (Future) │ └─ Lower priority items Rule: ├─ Take from top of sprint backlog ├─ Can't skip to item 5 if 1-4 available ├─ Priority set by PM, selection by developer ├─ Trust the system When Assignment Makes Sense Some tasks need explicit assignment: ├─ Specialized expertise │ └─ 'Only Sarah knows the payment system' ├─ Development opportunity │ └─ 'Junior dev needs auth experience' ├─ Context continuation │ └─ 'Alex started this, should finish' ├─ Client relationship │ └─ 'Tom is the client contact' ├─ Critical deadlines │ └─ 'Must be done by Friday, ensuring coverage' Default to self-assignment. Assign when necessary.
Workload Visibility See who's doing what: ├─ Alex: 3 tasks in progress ├─ Sarah: 1 task in progress ├─ Tom: 2 tasks in progress ├─ Jordan: 0 tasks in progress Self-correction: ├─ Jordan sees they have no work ├─ Jordan pulls next task ├─ No manager intervention needed ├─ System balances itself Transparency: ├─ Everyone sees assignments ├─ No hidden workloads ├─ Fair distribution visible WIP Limits Prevent overcommitment: ├─ WIP Limit: 2 tasks per person ├─ Developer has 2 in progress ├─ Must finish one before pulling another ├─ Focus over multitasking Team WIP: ├─ Column limit: 5 items in 'In Progress' ├─ Team collectively manages flow ├─ Prevents bottlenecks ├─ Encourages helping others finish Skill-Based Self-Selection Developers know their strengths: ├─ Frontend dev sees UI task → Takes it ├─ Backend dev sees API task → Takes it ├─ Full-stack sees either → Chooses ├─ Learning opportunity → Stretch assignment Better matching: ├─ PM guess: 60% accurate ├─ Self-selection: 90% accurate ├─ Developers know their capacity ├─ Developers know their interest Mentorship Assignments Combine autonomy with growth: ├─ Senior developer tags complex task ├─ Junior can take with mentor assigned ├─ Both names on task ├─ Junior does work, senior reviews ├─ Skill transfer built in Balance: ├─ Autonomy for experienced ├─ Guidance for learning ├─ Not micromanagement Urgent Task Protocol Production issue at 3 PM: ├─ Task created with 'Urgent' flag ├─ Appears at top of board ├─ Anyone available pulls it ├─ Clear protocol, no confusion ├─ No waiting for PM to assign Escalation: ├─ Urgent not taken in 15 min ├─ Notify team channel ├─ Still not taken ├─ PM directly assigns Default: Pull. Fallback: Push.
Assignment Notifications When you need to assign: ├─ Assign developer to task ├─ Developer gets notification ├─ Reason in comment: 'Assigning because you know this system best' ├─ Developer can discuss if wrong fit ├─ Clear communication Self-assignment: ├─ Developer assigns self ├─ Team sees who took what ├─ No notification needed ├─ Natural transparency Team Capacity View Sprint planning support: ├─ Alex: 25 hours available ├─ Sarah: 30 hours available ├─ Tom: 20 hours (PTO Friday) ├─ Jordan: 30 hours available ├─ Team: 105 hours capacity Task estimates: ├─ Auth feature: 16 hours ├─ Payment: 24 hours ├─ Dashboard: 12 hours ├─ Total: 52 hours (50% capacity) Room for: ├─ Meetings ├─ Bug fixes ├─ Code reviews ├─ Unexpected work Assignment History Track patterns: ├─ Sarah: 80% backend tasks ├─ Alex: 90% frontend tasks ├─ Tom: 60% bugs, 40% features ├─ Jordan: 50/50 mix Insights: ├─ Is work distributed fairly? ├─ Is anyone doing only bugs?
├─ Are skills being developed? ├─ Any silos forming?
Data for retrospectives. Manager Role Shifts From: Task assigner To: Priority setter Manager responsibilities: ├─ Keep backlog prioritized ├─ Clarify requirements ├─ Remove blockers ├─ Coach and develop ├─ Handle exceptions Not: ├─ Decide who does what ├─ Track daily progress ├─ Micromanage execution ├─ Be the bottleneck Trust the team.
Focus on outcomes. Onboarding New Team Members New developer starts: ├─ Week 1: Assigned starter tasks ├─ Week 2: Self-select with mentor ├─ Week 3+: Full autonomy Gradual transition: ├─ Build confidence ├─ Learn codebase ├─ Understand priorities ├─ Join self-selecting team Getting Started 1.
Sign up GitScrum ($8.90/user, 2 free) 2. Create prioritized backlog 3.
Explain pull system to team 4. Let developers self-assign 5.
Review in retrospectives 6. Adjust as needed Trust breeds ownership.
Ownership breeds quality.
The GitScrum Advantage
One unified platform to eliminate context switching and recover productive hours.
