I walked into an iteration planning meeting once convinced I knew the right answer.
The team was leaving tasks unassigned. No names next to anything. Just stories, priorities, and a shared understanding of what needed to get done first. My instinct was that something was missing. Where was the accountability? Who owned what? If a task slipped, who were we going to ask about it on Thursday?
I kept quiet, watched, and listened. Then I went back to my desk and looked it up.
I was wrong.
Where my instinct came from
Most of my career has been in federal IT, where assignment is a form of proof. Contracts, status reports, and oversight reviews all want a name next to the work. If you can point to the person responsible, you look in control. That habit is useful in a lot of places. Iteration planning is not one of them.
What I was calling accountability was really a comfort blanket for whoever was watching the board.
What SAFe Principle 8 actually says
SAFe Principle 8 is about unlocking the intrinsic motivation of knowledge workers. It sounds soft when you read it on a slide. It is not soft in practice. It is a statement about how work actually flows through a team.
Pre-assigning every task on Day 1 looks like control. What it actually does is remove the team's ability to self-organize, and self-organization is the whole mechanism that makes iteration planning work in the first place.
Here is the failure pattern. The highest-priority story hits a wall. The person assigned to it is stuck on a dependency or an environment issue or a question nobody can answer until Wednesday. Everyone else on the team keeps moving on their own lane, because their lanes were assigned too. The top story sits. The iteration goal drifts. On paper everyone is busy. In reality the one thing that mattered most is not moving.
Nobody did anything wrong. The structure did it.
How the pull system fixes it
A pull system flips the default. Work gets assigned just in time, usually during the team sync, not locked in on Day 1.
- If someone finishes early, they pull the next highest-priority task instead of starting something lower down that happens to be "theirs."
- If a story is at risk, the team swarms it. Two or three people converging on the blocker beats one person quietly struggling with it.
- The Kanban board makes overload visible. When one person has four things in progress and someone else has none, you see it before it turns into a missed objective.
The team stops optimizing for individual utilization and starts optimizing for finishing the most important work first. That is the whole point.
The exception I live with right now
That said: I currently have one developer on a team. And I assign tasks.
At that scale the pull system has nothing to pull from. There is no swarm. There is one person, and the most useful thing I can do is make sure they always know exactly what matters next. The framework is designed for teams, not for one individual wearing every hat.
I don't think that contradicts anything above. It confirms it.
Reference architecture, not rulebook
SAFe is not a rulebook. It is a reference architecture. The practitioner's job is knowing when to apply a practice as written and when to adapt it to the context in front of you.
The mistake in both directions is the same. Applying a practice mechanically when the context doesn't support it is cargo cult. Ignoring a practice because "we're different," without understanding why the practice exists, is just as bad. The only way to tell the difference is to understand the principle underneath.
That is what I missed walking into that room. I knew the practice I was used to. I didn't know the principle the team was operating on.
A few questions worth asking before you assign
If you are a Scrum Master, Team Coach, or Product Owner heading into your next planning event, try these before anyone writes a name on a card:
- If the top story gets blocked on Day 2, what happens to the rest of the team's work?
- Is anyone being assigned work primarily so they look busy?
- Would the team swarm without being asked, or do they need permission?
- Are we assigning because the context requires it, or because it makes the board feel safer to someone outside the team?
If the honest answer to the last one is "the second," that is worth a conversation.
The part I keep coming back to
Being wrong in that room was one of the more useful things that happened to me as a practitioner. Not because I learned the pull system. I could have read about that anytime. Because I learned to question the things I was most certain about.
When did you last question something you were certain was right about your process?
