DEV Community

Cover image for Delivering in time is a matter of observing the details
Ivan Neto
Ivan Neto

Posted on • Updated on

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.

Top comments (6)

craser profile image
Chris Raser

I think it's great that you're thinking through strategies to remove blockages and get the team moving smoothly. I hesitate to even mention this, since your note seems solidly focused on the process, rather than the human element here.

But my experience is that the human element is harder to measure, and can get lost in the quest for a speedy process. 100% CPU usage is admirable on hardware. It's a recipe for burnout and high turnover to run a team at capacity all the time.

It may seem ideal for everyone on the team to quickly hand off tickets and move them through the process as fast as possible. But that tends to require a lot of context switching.

Context/task switching has costs in productivity, as well as human stress level and cognitive fatigue. It's really important to account for this when thinking about what delays are "unnecessary." Letting team members switch tasks at natural moments in their day is a non-trivial benefit to letting a PR or testing cycle wait for a bit.

I used to work on a team where we'd do PRs first thing in the morning, regardless of when they were submitted. That way, nobody got pulled of their train of thought, and devs could work on something else for the rest of the day without getting pulled back onto comments/fixes on the PR. It meant that PRs might sit for nearly a day before anyone looked at them, and that was fine. Having our day broken into two or three large chunks instead of 25 smaller ones was more than worth it.

There are lots of advantages to breaking down stories into their smallest shippable units. One of those advantages is that natural task-switching moments become part of the team's usual workflow.


ivancrneto profile image
Ivan Neto • Edited

Thanks for your input. Avoiding too much context switching is also really important. I think each team has its own characteristics and can find its synergy and then a developer will strike a good balance between working on her/his task and switching to helping other tasks to move.

If we make all developers able to observe the situations where the team is wasting time and eliminate them, that's a very good step forward, but indeed trying to reach a "100% CPU usage" will hurt.

craser profile image
Chris Raser

Yep. The team will naturally find an equilibrium that works for them. But I've seen through hard experience that when a team is under pressure to meet certain metrics, other metrics will be sacrificed, even if that sacrifice is self-defeating in the long-term. Team values and goals need to be explicitly stated, and repeated, or they get lost in the day-to-day work of trying to pay the bills.

There's a really good discussion of Agile and thinking about velocity in Ep. 15 of Tech Done Right.

eljayadobe profile image

In my experience, the thing that makes agile actually agile is not the process. It's the engineering practices.

ivancrneto profile image
Ivan Neto

I agree with you, but I also think we have to align the engineering practices with the process to be more effective.

eljayadobe profile image

I agree with that, too. :-)

Having a lightweight management process combined with agile engineering practices is a win-win situation.