02. Work in Progress Is the Enemy of Completion

Busy Is Not the Same as Done

At JPSoftWorks, one of the most persistent "smells" we encounter isn't broken pipelines or missing tools. It's teams that are constantly busy but strangely ineffective.

Boards overflowing with open tickets.
Sprints packed to the edges.
People juggling five things "just to keep things moving."

Yet delivery crawls. Quality degrades. Trust erodes.

This is where Work in Progress: WIP: stops being an abstract Lean concept and becomes painfully real. Too much WIP doesn't just slow teams down. It hides risk, kills learning, and turns DevOps into theatre, again.

And when you add invisible work to the mix, things really go sideways. Allow me to explain.

Why WIP Breaks Flow

In systems thinking, flow beats utilization every time. This is deeply uncomfortable for organisations that equate productivity with "everyone being busy." If You can visualize this as plumbing, it's not about how much water is in the pipes, so much as how much, reaches it's destination.

WIP is inventory. And inventory hides problems.

The more work you have in progress:

• The longer each item takes to finish
• The harder it is to see bottlenecks
• The more context switching you introduce
• The less predictable delivery becomes

This isn't opinion: it's queueing theory. It's also the central lesson of The Phoenix Project: everyone is working hard, but nothing important gets done because too much is started and too little is finished.

DevOps doesn't fix this with better tooling. It fixes it by making work visible and limiting WIP.

Invisible Work: The Silent WIP Multiplier

Most teams believe they understand their WIP because they can count tickets. That belief rarely survives contact with reality.

Invisible work is still work:

• Unplanned security reviews
• Manual environment fixes
• Knowledge trapped in one person's head
• "Quick favors" done over Chat
• Rework caused by unclear acceptance criteria

This work consumes capacity but never shows up in planning. The result is predictable: teams overcommit, fall behind, and compensate by multitasking: which creates even more WIP.

Remote work doesn't create this problem. It exposes it. And curiously, it ends up in DevOps's lap.

When Work Skips the Board, the System Goes Blind

This is where things get uncomfortable.

One of the most damaging patterns we see: especially in high‑pressure environments: is the superhero bypass.

Highly capable individuals jump straight into "the work."

• No ticket.
• No kanban card.
• No sticky note.
• Just execution.

The intent is good. The impact is not.

When work isn't represented in the system:

• Product owners can't validate intent early
• Stakeholders don't know what's in progress
• Risk remains invisible until "delivery"
• Acceptance becomes emotional instead of factual

Outcomes turn into a black box. And black boxes destroy trust because they carry unnecessary risk.

Work Items Are Alignment Contracts, Not Bureaucracy

At JPSoftWorks, we treat work items: whether Jira tickets or yellow stickies: as lightweight alignment contracts.

Not legal contracts.
Operational ones.

They answer a few essential questions:

• Why are we doing this?
• What does "done" look like?
• Who needs to accept it?
• What risk does it carry?

When superheroes bypass this step, they unintentionally remove clients and product owners from the conversation. That's how teams end up delivering something: just not the right thing.

This is not a delivery failure. It's a visibility failure.

Trade-offs: Size vs Number (Pick Consciously)

There are only two levers available:

1. Reduce the number of items in progress
2. Reduce the size of items in progress

Everything else is wishful thinking.

Large tickets feel efficient during planning and disastrous during execution. Small items feel slower at first but enable learning, feedback, and control.

Our rule of thumb: if a ticket can't move states within a day or two, it's hiding complexity or assumptions. Probably both.

You don't need perfect sizing. You need consistent slicing so flow becomes observable.

Governance Implications: WIP Is a Risk Signal

From a governance standpoint, WIP is not neutral.

High WIP means:

• Extended exposure to risk
• Late discovery of bad decisions
• Security controls applied under deadline pressure
• Cost overruns discovered too late

Small, flowing work items allow governance to operate early and calmly: where it belongs.

This is how governance supports delivery instead of obstructing it.

Security Integration: Flow Makes "Shift‑Left" Possible

Security hates half‑finished work. That's where risk hides.

When tickets remain open for weeks:

• Threat models go stale
• Dependencies change underneath you (aka invisible work)
• Security context evaporates

Small, flowing work items enable security to behave like quality engineering:

• Automated checks
• Repeated validation
• Embedded controls

Security‑as‑quality depends on flow. Without it, "shift left" remains a slogan.

Automation as a Learning Engine

Here's the underrated part.

When work is visible and consistently completed, automation improvements become measurable.

You automate a pipeline step.
You standardize an environment.
You embed a policy‑as‑code check.

If work items flow, you can see the impact:

• Cycle time drops
• Variability shrinks
• Throughput stabilizes

This is how DevOps proves ROI: through observable, objective, measurable improvement, not promises.

Failure Modes and Anti‑Patterns

Patterns we see far too often:

• Giant tickets that go on for days
• Work started "just in case"
• WIP limits ignored habitually
• Blocked work left untouched
• Delivery driven by heroics

If someone regularly "delivers" without tickets, the system isn't fast: it's blind.

Cultural Impact: Completion Builds Trust

Completion changes behaviour.

When work finishes regularly:

• Anxiety drops
• Planning becomes honest
• Commitments regain credibility
• Teams feel momentum

Culture follows flow. Always has.

Implementation

What works in practice:

• Explicit WIP limits per column. You shouldn't have more than a ticket per person, at any given time.
• Tickets small enough to move daily
• Blockers surfaced immediately and safely
• "Stop starting, start finishing" enforced "socially". Make it a team mantra.
• Flow metrics reviewed, not weaponized

Important habit shifts:

• Starting less is a skill
• Splitting work is engineering
• Visibility precedes improvement, it is necessary, for it to exist.

Subtle collaboration issues:

• Specialists often masquerade as hidden bottlenecks
• Work hoarded "until ready"
• Helping others deprioritized in favour of personal throughput, as a consequence.

Closing Insight

DevOps doesn't fail from lack of effort. It fails from too much unfinished, invisible work.

If work is visible, it can flow.
If it flows, it can teach.
If it teaches, it improves.

At JPSoftWorks, we don't ask teams to work faster. We help them finish more often: and let the data speak for itself.

If your boards are full but it seems like landing is difficult, let's talk. Sometimes the fastest way forward is simply doing less: properly.

Links & References