Predict Software Development Timelines with Precision

This newsletter is about software construction and team leadership. In this issue, we examine one of the most common leadership problems: controlling schedules, and predicting outcome.

One of the most common question students ask is: "how do we get control over schedules and predict outcomes with accuracy?" —This question can be exceptionally hard given the fact that software construction is entirely invisible.

Oftentimes project managers simply add up estimates from architects or lead engineers and this results in the preposterously inaccurate predictions we often see in software. It's a challenge, but there are ways to put a finger on the pulse of construction that are ultimately reliable.

By observing the activities each engineering team is actively engaged, we can determine the true state of progress as reliably as predicting the rising sun.

Software Is Made In Repeating Cycles

Firstly, we understand that expert software engineers work in a repeating, cyclical pattern that is much like the seasons of the year.

Observable activities and behaviors reveal the true state of the schedule, detectable from outside the box. This insight doesn't necessitate being the architect, designer, or lead engineer, nor does it require expertise in any specific language, tool, or technology.

This answer is revealed axiomatically by careful observation of activities.

Phases repeat in order. Thus, we can determine the boundaries of our schedule as surely as we can predict that spring follows winter.

Imagine seasons of the year; changes in phase represent the types of activities engineers are engaged in. If you are still working on a flawed architectural element halfway through your release schedule, you are late and this loss of schedule must be made-up, or accounted for.

Name Your Release

Start with a Release Name—a sort of 'theme'—and a handful of architectural elements, then adjust estimates with each team. Like contracting an accordion, whatever changes to schedule or resources, internal or external, the order in which things are done remains in-tact and the integrity of the release is assured.

As an example, we'll call this fictional release "Lightning" —this name suggests the central most feature will be performance improvements.

If you take each engineering phase in order, you can negotiate with each team what is the purpose or theme of this release is, and how each of these tasks relate and combine to complete a full release cycle.

If engineers spend too much time considering design, they'll not get to the bulk of development required and if they skimp on process and release procedure, the release itself can be at risk.

We Call This Balance

Even a short release cycle, like this example called "Lightning," will always break into these four repeating phases of development. Conveniently, we've given these phases clever names that all begin with the letter "D", however you can call them spring, fall and winter if you prefer, the idea is the same. Behaviors and activities change as we move through cycles, reflect the natural reactions to external changes and progression of time.

Since these well-balanced tasks must be completed serially, in order, we can line up these estimates into a schedule everyone can see and understand.

We Call This Serialize

By arranging these tasks end-to-end in sequence, we see how phase changes—or 'seasons'—dictate the types of tasks engineers undertake over time. This transparency offers a window into the otherwise invisible construction of software.

Ownership and responsibility come with the reward and recognition that emerge from this visibility and predictability. A natural form of self-governance is created by unanimous support of worthy and authentic schedules. This means that each engineer understands when it must be they, who stands up to be the difference between this release making schedule and not making release at all.

We Call This Reliable

By putting your finger on the pulse of construction, you can accurately assess where any given team truly is in the software cycle, and thus, you can control and report scheduling as reliably as predicting the rising sun.

However out of control the situation you may encounter, this method of organizing and observing software construction cycles offers an immediate remedy. This concept of "Balance and Serialize" will wrest control over release schedules immediately and across all teams at once.

Taking control of schedules and demonstrating reliable predictions of outcome that others can see, understand and rely upon is what makes some teams take off and —Go Beyond.