Delivering in time is a matter of observing the details

After seven years of experience with software development, different companies and technologies, having as consequence experimented many methodologies to manage work and teams, I could see that regardless of the process your team has, you'll find yourself with problems to deliver.

One big contributor to the failure of most of the software planning is the waste of time. We tend to spend more time than we should in many situations and the total time lost is big enough to affect the project.

From my experience, the situations are mostly related to communication and represent a big bottleneck:

1. People waiting for answers or decisions regarding a changed spec;
2. Tasks being blocked by other tasks;
3. Lack or slow communication.

This week I was working on an important task that had a requirement change one day before the deadline. A small change, but with two text options and we had to wait for the Project Manager to decide.

The waiting time wasn't so big, but enough to create a Butterfly Effect and delay the task in one day (conflicts, new bugs in other tasks, QA started later, new deploy in another system being queued before, etc). We could have solved the issue by simply creating a flag or A/B test based solution where we could just deploy and then enable the first or the second text based on the PM's answer. The cleanup would certainly take less than the waiting time.

Here are some examples that may improve your team ticket and processes' flow:

Example 1 - Slow communication

• Developer finishes a task, submits a PR (Pull Request) and doesn't tell people there is a new review to be done.
• Reviewer finishes a review and doesn't ping back the developer to perform the fixes.
• Reviewer approves a PR and doesn't ping the QA person to start the testing.

Sometimes people think the others will get notifications and will act promptly. This doesn't happen. They will do only after three, four hours or even one day after.

Solution: create a culture of always communicate to all involved whenever there is a change to the task state, using the team's main communication channel.

Example 2 - Waiting for a decision

• There is a decision to be done and the developer is waiting.

Solution 1: try to imagine what would be the most appropriate choice, choose it and work on it.
Solution 2: make both work behind an ON/OFF switch.

Note: The solutions above highly depend on the scope of the decision .

Example 3 - Waiting for another system

• There is an API endpoint for another system that needs to be finished before the developer can complete the task.

Solution: Split the task in two. The first task will log instead of calling the API. The second task will replace the log with the API call.

Example 4 - Waiting for ticket

• There are no new tickets to work.

Solution: Code review, pair with another dev.

Example 5 - Developer is taking too much time in a ticket

• Sometimes there are tickets bad specified and we end up with one developer working alone for a long period of time.

Solution 1: Split the ticket into non-technical subtasks as much as possible, so other developers can pick each of the subtasks.
Solution 2: Split the ticket into technical subtasks containing deployable pieces. The feature can then be activated after the last piece is pushed (For instance, we can have a task to perform a database change, another to add a new HTML template, and finally, one including one URL with some app logic, showing the page and using the new database updates).

Note: in this particular case solution 1 and 2 can be perfectly done together. Instead of one big ticket, for instance, we could have three subtasks, each one with three technical parts, and many developers could work on it instead of just one.

Example 6 - QA is holding some part of the process

• QA has to test everything and is slowing down the process

Solution 1: Some pieces can be pushed and skip the QA process, like a template file that will not be used until the final feature is done.
Solution 2: Even business logic pieces can make use of A/B test flags, and if they are pushed turned off by default, QA can do a small test just to verify nothing is broken and the real test can be done later.

Example 7 - Bugs found in pre-releases

• A bug is found in a pre-release and a fix is needed.

Solution 1: Fix the bug, of course.
Solution 2: If the bug only happens when a flag is inactive, deactivate the flag, so you unblock the push and then you can work on the fix and do a second push.

Note: solution 2 can only be done if the flag is new and is going to the next release.

Example 8 - Work depending on a still open PR

• The developer has to work on a new task, but it depends on a PR still under review.

Solution: Create a branch on top of the branch under review. Most developers here tend to say he/she is blocked and waits. There is no reason to wait. Work on top of the previous work, that's it. When the PR is approved, rebase.

Example 9 - Someone is blocked. You are blocked

Solution: Ask yourself: what do I need to do to unblock her/him? What do I need to do to unblock me?
People like to say "I'm blocked" or "I'm blocked by someone/something" and do nothing about it. It's comfortable. There is an excuse. You have to be able to say "hey you can do X, Y, Z, done, you are unblocked".

Starting to change is hard but it pays off. In the beginning, you really have to keep monitoring everybody, detecting when every "time waste" situation happens, and work hard to unblock people.

When you start to feel they are doing by themselves, i.e., it is becoming a habit, you can certainly expect more successful deliveries anytime soon. Remember: your job as a developer is not only writing code, but deliver value.