The Problem Space

Software delivery, the problem space

If we step back and strip away all the methods, tools, and processes, software delivery is, at its core, two distinct things:

1. tracking the actual progress in real time, and
2. handling unforeseen disruptions (things that can change during the delivery itself)

A. Real-time tracking of the delivery progress

When working for a project, the biggest factor in its delivery success is tracking progress. All the players share this responsibility. The project manager, the dev leads, and devs must work together so that they know, at any point in time, if

• The overall development progress is ahead of or behind schedule.
• Any of the teams involved are ahead of or behind schedule.
• Any of the developers themselves are ahead of or behind schedule.

Only then they are able to evaluate with confidence what the current delivery risk is. And if you detect the risk early, you can protect the deadline.

Delivery success is then reduced to anticipating and handling any disruptions.

B. Handling the unforeseen disruptions

Disruptions to the original delivery plan during development are common. While dealing with them, immature teams tend to pray for an ideal world.

"That's it - no more changes from the product mid-development". "The designers/API must deliver before we begin our work".

But this leads nowhere. In software delivery, change is the only constant. Anticipate it and be ready to handle it ahead of time when it happens.¹

These disruptions fall under four categories:

👻 Scope creep

Scope creep refers to the uncontrolled expansion of a project's scope due to factors such as

• Missing or unclear specs, like designs not handling edge cases (e.g. error messages).
• Changes in requirements, like when the product team adds new features based on fresh insights.
• Unanticipated dev work, like not accounting for the complexity of integrating with external systems.

🔀 Shifting priorities

Developers are often pulled away to address urgent issues or support other teams and projects due to shifting priorities.

A release gone bad. A production incident that needs urgent fixing. An urgent request from marketing or another stakeholder. Regulatory deadlines. You name it...

⛔ External blockers/dependencies

Dependencies on other teams, systems, or third-party services can cause bottlenecks. They can slow down delivery if not identified and handled ahead of time.

For example, waiting for the backend team to finalise an API, or for copies and translations from marketing, can delay the frontend's delivery.²

📆 Unplanned Absences

Holidays, sick leave, or other unexpected time off during project delivery affects developers' availability.

Ok, what's the point?

In your company you might be doing software delivery using Scrum, Jira and daily standups. Or you might have switched to SAFe and Trello and no ceremonies at all.

The truth is that it does not matter.

If you strip away

• the methodologies (Scrum, Kanban, Waterfall, SAFe)
• the tools (Jira, Trello, Asana)
• and the processes (daily stand ups, retros)

the core of software delivery is A. progress tracking and B. handling any unforeseen disruption. Period.

What matters most is how your solution addresses A & B. Failing to do so in a focused way leaves room for friction and inefficiency to creep in.

Our solution aims directly at the core, tracking progress and mitigating disruptions. In an opinionated and streamlined way.

Stay tuned for the next post in the series.