Software Team Sociology: Making Work Actually... Flow

ll Problems Are Not Created Equal

All teams have strengths and weaknesses. All teams have skill gaps. But every team is different—and so are their problems. There will always be problems, but is better to have smaller, less debilitating problems, and you do that by resolving one issue at a time.

One common problem is story or work item size. The solution is story splitting, but that solution is both difficult and deeply unpopular.

A quick rule of thumb: if your story takes more than 20% of your iteration to complete, it’s probably too big. However that is just a rough guideline.

The real test is

Does your work flow like a majestic river, or does it thunk through your system like a square boulder down a gravel hill?

So:

QA twiddling their thumbs early in the sprint, then drowning at the end?
Developers getting feedback a week later and saying, “Wait, what even was this ticket?”
Merge conflicts that are a tangled mess?
Constantly re-estimating because “uh, the scope changed again…”
Devs tossing out code halfway through because the requirements moved (again)?

If you said yes to any of the above: Your stories are probably too large.

Take Your Medicine

The team needs to split their work items until the symptoms and the pain caused by those symptoms goes away.
If the symptoms persist then keep cutting. I once worked with a team where the size of the work items was truly ridiculous, poor decisions at the start of the project sabotaged the prospects of success.

Other Common Culprits

While oversized stories are the usual suspects, they’re are plenty of other things that can clog your system:

Part-time key personnel
Unbalanced skill sets
Approval bottlenecks
Delayed feedback

For best results the value stream needs to flow smoothly. If tasks pile up in someone’s inbox while downstream coworker are twiddling their thumbs —then there’s a bottleneck. Remember: a pipe only flows as fast as its narrowest point.

Feedback is Oxygen

The best proof of quality isn’t a checkmark on a compliance document or test coverage—it’s a pleased customer. The longer you delay feedback, the more likely you are to ship something the customer no longer wants (or never wanted in the first place). Markets shift. New tech is adopted. Disruptive world leaders make policy changes that overturn the business environment. The customers needs evolve and the usefulness of your captured requirement decays.

At each stage the feedback loop needs to be tightened.

Can’t release to the public yet? Cool. Release to beta users. Can’t do that? Release internally. Worst case, throw it at someone without the “curse of knowledge” and time how long they take to figure it out. If it’s more than 30 seconds, you’ve got work to do.

The Hidden Cost of Admin Bloat

Long meetings. Inefficient processes. Manual multi-step deployment ceremonies. All of it makes your team slower and more resistant to change.

When the ceremony is painful, teams start batching work just to avoid it. That seems efficient, but workflow stutters.

The consequences

alternating periods of idleness followed by overwork and chaos.
Priorities are shifted and work reorganised to compensate for

Bottlenecked Resources
Need for the ceremony to complete (code freeze)
Delayed Feedback
Missing Approval

Also, remember the Christmas Rule:

Anything you only do once a year, you do badly.

So:

Frequent = smooth and fast
Infrequent = slow and broken

Want fewer errors? Do it more often

The answer?

Automate what can be automated
Have a clear, repeatable process
Eliminate anything that doesn’t provide value—ruthlessly

Developers: Check in Early. Check in Often.

Humans are terrible at boring, repetitive tasks. Computers are terrible at ambiguity. Delayed merges combine both in the worst possible way. And that means bugs.

Also, please don’t use GitFlow or long-lived feature branches unless you enjoy pain. They’re complexity traps.

Instead, use feature flags—and even then, only lock away the bare minimum (usually the UI). Hidden code means fewer eyes, less testing, and more risk.

Tack, Tick, Tock: Get into a Rhythm

Here’s a simple cycle I use to keep the chaos at bay:

Tack – Set the stage

Prep the codebase
Build or improve libraries
Boost Developer Experience (DX)
Make changes without changing behavior

Tick – Build the thing

Add the functionality
Show it to a customer proxy ASAP

Tock – Make it shine

Refactor
Polish
Pay off debt
Ship it!
Pay off more debt if needed

Miss a few Tocks, and your dev velocity will slow to a crawl as technical debt accumulates and interest payments come due.

After shipping, get feedback from actual users. Based on what they say, maybe you’ll need another Tock round. Or three.

Final Takeaway

If your team’s struggling, don’t let it slide. If the problems are left alone, they will multiply—and then you’re doing late-night hotfixes and questioning your life choices.

Instead: