How to deliver on time – Result driven

Have you ever been struggling in a project that has a lot of work to do, but the estimates turn out to be way off? Have you ever encountered a project in which the integration phase resulted in many unforeseen problems, causing the project to get totally off the rails? Or did you happen to work on a project for which the work was clear, but you couldn’t deliver anything because all development had to be finished before the product would be usable? If so, you will know that situations like these make people (especially managers) unhappy.

The good thing is, there are ways to get better results than that. The way you’re planning greatly impacts the project outcome. This article shares some insights that yield better estimates. As a bonus, using these insights also give the project much more flexibility and make it much easier to deal with setbacks.

Visibility to the user

Years ago, I was at a conference where a speaker explained how agile development works in practice compared to the waterfall model (sadly, I forgot the speaker’s name). He started by explaining waterfall with a simple picture like this:

The vertical axis depicts how visible the product is to the user. At the start of the project, there is a lot of communication to decide about project goals and requirements. Then, a long period begins in which the product is developed, but the customer is not involved. In the end the final product is presented and handed over to the end user, so the project is very visible again.

The speaker then continued to explain the agile model, where the user is much more actively involved. He depicted it as this:

Agile prescribes that the product is delivered in small increments. For example, Scrum mandates that a working product is presented to the customer every 2-4 weeks. The customer is involved throughout the project by attending sprint demos and deciding about priorities.

However, many companies that decide to work in an agile manner, turn out to work in a manner like this:

There are many increments, but the customer is only involved in the beginning or the end of the project. There is also no product that is actually deliverable until the last sprint. If there are demos at all, only parts of the product are presented to project management (who already knows the status).

Although presented in a humorous manner, there still is a lot of truth in it. I have seen this happen, even when the project was started with the best intentions to do it in an agile manner. I think one of the reasons that cause this is the way in which the work is split up.

Planning for problems

Let’s imagine a new project to deliver a small application. There is a small team that is responsible for everything. They start planning in a way like this:

“Let’s see, this application will consist of four modules. We can plan to implement the modules one by one, so that we can focus on one module at a time.”

And so the work begins. The team works on module A. They define the specifications, its design with the other modules to be developed, and they start building it. Every sprint, they demonstrate improvements to module A. When they are finished, they start working on module B, and so on until all modules are implemented.

The sad thing however, is that the customer has no knowledge of the technical details. He won’t understand at all what module A is supposed to do and, therefore, he cannot think critically about it. He won’t be very interested in demos that just show some technical details to him (if they are held at all). Moreover, the team cannot really deliver anything during a demo, because module A in itself has no business value. All modules have to cooperate to show a working product, so when only a single module is demonstrated, there is only technical improvement to show. To the business, this means that you effectively have no result at all yet.

That is one cause of the graph of the last picture: demos are held, but the customer is not actually involved on a level that he understands.

What is going wrong here

Why is this happening? Since software developers are primarily concerned with the source code, they think in terms of source code and modules of them. When thinking along those lines, it is convenient to focus on a single module at a time. If that one module works, you have something less to worry about. Hence many developers are apt to define the work in terms of modules and interactions.

There is however one false assumption: you can never finish that single module on its own. That’s because you don’t know what you’ll encounter when the modules are integrated into an application, even if you think you analyzed everything beforehand. The only way to know what you forgot, is to make them work together.

This is what I call a “technical subdivision” of the work: have a look at the technical details such as interfaces, software layers or technologies, and define the work for each of those. This has a number of drawbacks:

You cannot involve the end user, especially when the work items get large, because you’re not using a language that he understands.
You get difficulties reporting the progress of your project. Saying something like: “Modules A and B are finished, and we’re working on C” doesn’t say a lot, since software modules often differ significantly in size or complexity. You can only report on the time spent versus time left, but:
Often crucial project stages like integration of the modules and deployment are not identified because they are not directly source code related (there is no such thing as an “integration module” or “deployment module”).
What’s making this even worse, integration can only be done when most of the modules are finished. When working this way, the integration phase is where the complex problems pop up. You don’t know if you’ve got a performance problem until you run everything together. Also, making the modules work together correctly is much more difficult than implementing a single module.
In essence, the actual project risks become only visible in the end stage of the project, where the integration problems are shown, and nobody knows what problems still remain. That’s what makes the project run out of time: you can’t plan on possible risks, and when problems appear it is too late to do anything about it.

A better approach

There is a better approach when defining the work: you can define the work in terms of end user functionality. You start with a “walking skeleton”: the simplest way that the application can work. For example, for a web application, you’re starting with an empty web page. As this is end user functionality, you have to integrate all components already to deliver this, but this is still on a very small scale. Then, you keep adding features incrementally, so that the application becomes more and more mature. Each feature is added, integrated and delivered.

For example, for a web shop, you could define the following features to be implemented:

User login
Checkout
Select a product in the shopping cart
Accept gift cards
Accept discounts

Advantages of planning based on user features

Subdividing the work along user features comes with many advantages.

You’re presenting features of a working program. It is the customer who requests the feature, so he can immediately give feedback on it. This allows you to make improvements before the project runs out of time.
When you have a list of high-level features (“login”, “multiple shipping options”, “gift cards”, etc.) you can agree with the customer on the most important features. When those are delivered, the customer can already have a working product before the complete project is delivered.
Also, because of the interaction with the customer, you learn a lot of what the application should do. You can include this knowledge throughout the project to get a better result.
The project risk is much less, since integration happens throughout the project. Integration issues stay small and only impact the current feature, because previous features are already delivered.
Most features tend to be independent of each other. This makes it easy to change the planning if the need arises. The customer can change his mind and ask new features to be delivered first.
It is possible to recursively divide features in subfeatures so that you can estimate the work in more detail.
Reporting the project progress can be done in terms of features. This is something understandable for the customer. Since you can divide features into subfeatures, you can have a team planning with features that are about the same size. That makes it possible to see early on if the project is on track. When the project runs out of time, the customer can decide to drop features that are less important.
At the start of the project , you can agree the set of features with the customer. You’re speaking his language instead of technicalese. This again gives you valuable feedback in case features are not as important as you thought, or when features are missing. You can also define what is out of scope.

Defining user features

How do you know if a feature is well-defined? Features that are well-defined share a number of characteristics:

They are defined as something that can be demonstrated to the customer. So they include integration and possibly deployment.
They add value for the end user.
The feature is independent of other features (INVEST).

You can regard the Scrum “story” a feature, however a feature is applicable in a broader sense. For instance in case of multidisciplinary projects where each discipline has to do some work. So while user stories define the work within a team, features may define work for multiple teams.

A feature can be split up over teams or into subfeatures (horizontal and vertical subdivision), depending on the architecture of the application. For a web application, horizontal subdivision might mean that the database team, backend team and frontend team align their work to deliver the feature.

Features are not project phases. You don’t need to complete one in order to start the next. In case you’re really lost with a feature, you can also deliver what you have and request the feedback from the customer.

Pitfalls when working with user features

In my experience, defining user features has two pitfalls:

It requires experience to do it well. I have seen situations where people started with the best intentions and ended up making nice technical descriptions. Defining user features requires thinking about the same product in a completely other way.
You cannot make user functions while ignoring the technical solution. A vision about how everything should work is still required.

What would you choose?

As discussed here, there are two main ways of defining the work for a project. It is very sensible to divide the work based on user features. This has many advantages compared to planning based on technical functions.

Defining clear end user features is more difficult than defining the technical steps, but you’re strongly increasing the change that you’re delivering the right solution. The effort is really worth it. What would you choose?