Developing a project with incomplete requirements

What are developers NOT doing while participating in a call or a meeting?

Developing.

I don’t suggest dropping all communication with your developers (quite the opposite, as you’ll see in the next point) but bear in mind that these interruptions take time and also hinder concentration and focus.

Getting the work process back up to speed after every meeting eats away at your team’s performance.

A few simple recommendations:

– Keep interruptions to a minimum — if it’s not important to have a tech person on the call, don’t add one.

– Make them brief — between 15–30 minutes should be quite enough to discuss anything and everything important.

– Be focused — exclude topics relevant only to a small number of the participants and discuss those later in private.

– Be prepared — gather all your questions and details beforehand and discuss everything during a single meeting.

– Schedule meetings & calls in advance — don’t suddenly interrupt your developer’s workflow with a surprise call to ‘quickly ask something’.

Your developers need your guidance and regular participation in the decision-making process.

Not because they can’t work on their own, but because they are building a product for you and according to your requirements. So when an issue arises it’s your job to provide feedback.

In the worst case scenario, a developer may have an issue that could be solved in multiple ways (each having various strong and weak points) and the product owner is nowhere to be found or is ‘too busy’ to share their thoughts.

Developers have a few options in such situations:

– Stop working and wait for the product owner

– Switch to another task

– Or decide by themselves which approach to take (which often backfires when the product owner finally finds the time and then chooses a different solution).

You should be the one making strategic decisions. Because of that, you have a key role in the agile team.

Try to be reachable and answer questions from your dev team regularly. Block small amounts of time each day during which developers can reach you. Or even gather questions throughout the day and aim to answer them all together before you head home.

This is arguably the thing developers that hate the most (at least in my experience). But why? It doesn’t seem like such an issue…or does it?

Imagine you are a developer who is implementing a new feature.

The code you are writing is, in one way or another, entangled with the rest of the features and/or dependent on them. You have already written down few hundred lines of code and you are halfway through the project.

But your project manager asks you to immediately start working on something else (because the client said it’s very urgent).

So you switch to the new task.

Then the same scenario repeats because a ‘quick’ estimation is needed (which is another frustration; see next point).

This is a never-ending cycle and, in the end, nothing gets fully finished. Or at least the working tempo suffers significantly. When the developer finally switches back to the initial half-completed feature after a few such ‘jumps’, they first need to re-read the code they already wrote, figure out what they were planning to do next and start doing it.

It gets worse the longer it takes the developer to switch back to your half-completed task. The task they had previously worked on most likely depended on other parts of the code — which might now have been changed. The dev will need to rethink or rewrite code to get the new feature to work, losing what was already done.

Managers and clients shouldn’t make a decision without having time and cost estimates for the development.That’s totally understandable.

But there is a fine line between understanding the overall time that will be needed and asking your developers to provide you with a down-to-the-minute estimation for every single task.

Here are a few things to keep in mind:

Estimations are not accurate.

They are just an educated guess based on the available (at the time of estimating) information and developer’s previous experience. Estimations cannot foresee every issue that will arise or every requirement that will need to be changed during the development.

Good estimates take effort.

Sometimes research is required. Other times it will take a bit longer to determine how the implementation will happen. The developer may even have to write some test code.

Estimations take time.

Don’t expect that your developer can estimate a project fully in 15 minutes flat. Detailed estimates can easily take anywhere from a half to a full day for even a small project.

Estimates are not deadlines.

It’s normal that one task will take more time than initially intended and another task will take less. Don’t freak out about this. In the end, they usually cancel each other out and the total time spent is close to the initial estimate.

Don’t expect the estimation to stay the same if you change the requirements.

Even a small change can have a significant effect on the time needed for implementation. Clarify all the details and specs before asking for an estimation.

Don’t pressure your developers to give you a smaller estimate just because it doesn’t match your budget or time-frame.

In the end, the developer will probably agree to your unrealistic time frame just to make you go away so he can continue working on his tasks. Guess how accurate that estimate will be?

This could take a lot of different forms:

– Your UX isn’t quite finished. – You still have to define how certain features will function. – Your screen designs aren’t completed. – You haven’t decided who will develop the other components of the project. …and so on.

Developing (or even estimating) such a project can easily become a nightmare.

Developers often have to decide on a project’s architecture or take global tech decisions. When important specifications are not finished, they can only guess at what the missing pieces are and set up the project based on these assumptions. This can easily backfire.

Imagine if you were to begin building a bridge by simply assuming how wide the river was? It could only lead to one possible outcome — a disaster.

Spend the additional time to clarify all the details before you start developing. This might make the difference between a successful project and a complete failure.

Imagine you’re a small startup with a team of five people. They hire you to build the company website — but everybody has differing opinions, ideas and requirements.

Or perhaps there is a product owner for the project, but his boss is constantly interfering and overruling his decisions.

Who should the developer listen to? Who should they ask, if a decision needs to be made?

Provide your developer with a single point of contact. You as a project manager/client/product owner should be the one who coordinates all interested parties and ensures their expectations are aligned.

Testing is one of those things that product owners and clients usually forget to think about. Especially when we speak about small projects and startups.

Flawless apps and websites don’t simply happen on their own! There is always somebody (or a team of people) responsible for making sure everything works as expected.

That’s what testers do — they spend all of their time looking for ways to break the finished code so that your developers can fix any potential issues.

Developers also test their code while writing it — but an outside perspective is always beneficial.

If having a dedicated tester is out of your budget (which is usually the case for small projects), find somebody else to do this. They just need to go through each and every way the user could interact with your product and make sure it works and looks like you want it to. The project manager or the product owner are good candidates for this.

Try to figure out your developer’s pain points and fix them. Remember that, at the end of the day, making the developer team happier can only improve the quality or speed of their work.