Our solution

In post 2 we peeled off the layers of software delivery. We discovered that we need to solve progress tracking and handling the unforeseen disruptions. Buckle up; it will be a deep dive.

What does our solution look like?

A. Real-time tracking of the delivery progress; our solution.

Here are some common assumptions for progress tracking in software delivery:

• It is a complex problem.
• You need regular meetings and updates.
• Your confidence depends on how much you trust the dev leads.
• You cannot track the progress on a dev level without difficulty.
• Getting the devs onboard with project tracking seems difficult.

But how much do those assumptions really hold?

What if we could automate progress tracking on a developer level? Then from it we could also deduce the overall progress. Automatically. No trust required. Update meetings would then become obsolete. Progress tracking would become a no problem. It would no longer be up for debate.

What if we automatically send the progress report and make it accessible in real-time to everyone? Then communicating the progress becomes a no problem as well.

In our solution:

• Developers break down and estimate their tasks in days. They need to own their estimations.
• Each estimation can be up to max days.¹
• The project manager assigns developers to the project and sets start dates for them. He can add a buffer to each dev.²
• Due date is computed based on the developers start dates and estimations. No need for an expert.
• Every time a dev starts, makes progress on, or closes a ticket, his/her progress is updated automatically.³ Individual progress is monitored with a precision of 1-2 days.
• Overall project progress is composed from individual developer progress. It is clear, objective, and accessible in real time to everyone.

Through composition, you can track progress at any level. You can track a project with a single developer, a single team or multiple teams. You can even track a team's contribution to a multi-teams project, or a project of projects.

Identifying early any developers struggling with delivery and how this impacts the deadline. And thus allowing for early adjustments if needed.

Supported by continuous transparent communication to everybody of the progress at set intervals. This includes the devs, dev leads, project managers, and product. No broken messages, no need to coordinate anymore. Trust is built, no longer required.

B. The unforeseen disruptions; our solution

Here are some common assumptions for unforeseen disruptions in software delivery:

• Disruptions are exceptions and should be minimised. Teams view blockers or scope changes as anomalies to avoid.
• Detecting, tracking, and communicating their impact on delivery requires ad-hoc effort. Keeping them manually in ad hoc lists. Requiring extra diligence to follow up on actions that need to be taken.

When, in fact, disruptions are just a part of reality. We cannot avoid them, we need to embrace them.

Systems should be designed so that everyone knows how to handle them in a principled way.

We should be able to build a project delivery timeline with little to no manual work. All disruptions should be raised there in a structured and consistent way. Each disruption should come with a specific CTA and owner. Never again dropping the ball or not knowing who dropped it.

In our solution:

We embrace the likelihood that changes can and will happen. To tame the chaos caused by them, we need to expect them. Relying on the following 3 principles:

1. Automated or manual surfacing of anything that can go wrong in the project's timeline. Any delay in the deadline is immediately visible.
2. Clear CTAs on what to do and who should do it (no mental effort on how to deal with it every time).
3. Continuous and transparent communication to everyone in preset channels.

More specifically,

Scope creep

• Automatic detection of scope creep (tasks added, deleted, or estimations updated). The effect on delivery clearly communicated to everyone.
• Clear CTA for the delivery owner to approve and tag what kind of scope creep that is. (check post 2 for more)
• Summary view of all extra scope that has crept into the project and why.

Shifting priorities

• Automatic detection or manual entry that a developer has started working on something else.
• A clear CTA for the delivery owner to approve this due to higher-priority tasks.
• Summary view of developers being shifted due to other priorities.

External blockers

• Tagging a task as a blocker raises this to the project's timeline and blockers list.
• Responsibility for moving the blocker is split.
• The delivery owner must find who should handle the blocker and get him/her to commit on a due date.
• The assignee now has the incentive to respect the date he/she promised. Any delay is directly linked to the project delivery.
• Conflicting priorities across teams resolved using a clear, defined escalation hierarchy.

Unplanned holiday

• Track any time off requested by the developers and its effect on project delivery.

Supported by continuous transparent communication when a disruption is raised. Informing the person accountable to take an action. Transparent broadcast of their impact on delivery to all stakeholders. Including those higher in the chain of command. They can resolve escalated conflicts.

The core pillars of our solution

Truth and fairness

The progress of the project is not up for debate. Everybody syncs on the truth. And it is fair because the devs provide their own estimations. They are the ones delivering after all.

Ownership and accountability

Everyone is held accountable for their part in delivery. No more blurry boundaries. The roles are clear.

Transparency

Hard work can no longer go unnoticed. No room for different interpretations on the project's status. No assumptions on what derailed the project. No blame games. Only facts.

Eliminating coordination costs

Everyone has real-time access to the same report. Progress and disruptions are visible to everybody. No need to coordinate, no delay in the feedback loop. Only actions.

What did we gain?

In post 1 we talked about the cost we usually pay when doing software delivery. Let's see if we managed to address it.

Do we have true control over the running projects?

• Progress tracking is done automatically. Total control of progress per developer, with 1-2 days accuracy. No time or effort spent on it. No chasing people around. Dev leads focusing on dev stuff.
• Disruptions are either detected or entered manually. Each one has its owner and a CTA. Their impact on delivery is visible to everyone.
• Progress updates and disruptions are sent out transparently to everyone. Again, no time or effort spent on communication.

True transparent control over the running projects. Without the mental strain of repetitive work or dealing with grey areas. No room for dropping the ball when it comes to detecting and announcing any risk in delivery.

Can our process scale?

Scaling across projects

• Keeping track of the progress requires zero effort. It can scale to any number of projects and still the effort will be zero.
• Individual progress can be composed to track progress of teams, projects or projects of projects in any way desirable. No need to double-track anything.

Scaling across people

• Role definition: Each player has clear responsibilities. No time lost in waiting for someone to pick up the ball. Well-defined roles and CTAs, no superhero dev leads and PMs needed.
• People robustness: A newly promoted PM or dev lead does not have to re-invent software delivery. He starts with a ready-to-use system from day one.
Key players leave. The delivery system does not have single points of failure. It only gets better over time.
• Coordination: Coordination is reduced to the bare minimum. The progress and any delivery-affecting change are automatically sent out to everybody in predefined intervals.

What did each player gain?

The developers are always aware of how many days behind or ahead of the plan they are. This might sound stressful, but they win significantly in other ways.

• They pick the estimates themselves (fairness) thus they have ownership and accountability.
• No more "you delayed" the progress when other things are in play (scope creep, shifting priorities, blocked by other teams).
• Their hard work is publicly visible, it can no longer go unnoticed.
• They are no longer dragged into progress update meetings. They can focus on the thing they love, coding.

The dev leads do not have to track the devs' progress or report it. At all. They also don't have to chase other leads or PMs into advancing blockers. Two major problems lifted from their shoulders.

• They can now focus on tech, or helping out people who might struggle. Easily re-adjusting the plan when delays are detected.

The project manager has real-time access to progress. Total control over it. And more importantly, free time for more important things, like resolving blockers. Or laying out the groundwork for future projects in the roadmap.

Product people or any other stakeholders are now included in the loop. By default. No segregation from the tech team. No extra meetings, no disbelief on what tech has promised. Everybody syncs on the same report.

This is just the start

But there is so much more to it…

Accurate and effortless tracking of the project's delivery progress is only the foundation. It unlocks the following very important features.

Project replanning

Tracking progress is only useful if you can act on it.

When projects fall behind the dev lead can add more developers. Or shift tasks from one developer to another. When a project is far ahead he can move developers elsewhere.

With any change he makes, he sees the impact on delivery dates. He can easily adjust and find the best plan.

Roadmap planning

We track when all ongoing projects are to end.

We track when each developer becomes available.

By adding future projects as well, we can create a clear, visual roadmap in a Gantt chart.

This includes:

• A project-level roadmap for delivery insights.
• A developer-level roadmap for resource planning.

Delays are flagged early, showing their impact on future projects. With this up-to-date view, planning and prioritization become seamless. ⁴

Action needs taking

You've reached this far and you liked the core ideas - so what now? Let's repeat what we said in post 2.

It is not about specific tools or methods.

You can start applying it manually. Using your existing tools. That being Jira, Trello, Google Sheets or whatever.

Take a look at the tasks of each developer and calculate his progress. Compose them and you have the project progress vs the promised deadline. Prepare a report and send it twice per week to everybody. Truth and accountability matter.

Be consistent and meticulous and write down every disruption. Now you know what to expect. Develop a principled way of handling each one of them. Evaluate their impact on delivery and share your findings with everybody.

Things will be simpler and you will have gained quite a lot already. But it will not scale without effort.

Take a breath and start automating any of the above. Step by step.

Take true control of the delivery process.

And if you need any help contact us.