How should I present my work when I repeatedly run into unexpected roadblocks?

Question

I'm a software developer. When my team meets for our daily standups, our business analyst/project managers attend the meeting as well in order to gauge the team's progress. 9 times out of 10, this works perfectly fine.

The last couple of weeks, though, I've been working on a particularly stubborn task. I've repeatedly thought, in good faith, that I was within a couple days of having it completed. But each time I got into my "final" testing for the project, an unexpected roadblock appeared and added several more days. I've talked with my development-savy boss about it, and he agrees that I have been doing good work on the project, it's just one of those times where we've been unlucky.

I'm nervous about how this looks when I give my updates during standups. For the last couple of weeks, I've given enthusiastic updates saying I'm just about done with my project, only to show up at the next meeting saying that something came up and I'm going to need more time. Communicating the details of what's going on is helpful to the developers on my team, but this can't look good to the project managers. This isn't the first time I've been in this situation either. I'm nervous that I might be developing a reputation as being unreliable.

What is the best way for me to communicate my progress in siutations like these, where a task repeatedly takes me longer than expected for reasons that could not have been predicted? My goals are to be honest with the project managers, but also to give them information that is useful to them instead of wasting their time with overly technical details and to avoid presenting myself in a way that seems flaky.

Answer 1

I feel the root issue is often breaking the same engagement multiple times in row. Mostly everybody knows that almost all developers are trying their best, so it is part of the development to be blocked, but hearing someone at the daily stating that a specific task will be completed tomorrow, then hearing the same person repeating the following day the same specific task will be completed tomorrow and not making it happen is ruining this person's credibility and emphasizes the failure.

In our teams, when people are facing impediments, we usually encourage them to share small victories or what they have learned the previous day to share and feel a progression and emphasize on acquiring new knowledge.

Example:

Yesterday I faced this impediment related to this technical topic.

I learn that, that and that.

Today I will continue to implement this feature.

We are trying to not commit in time by just stating the fact: "I am working on this feature" instead of "This task will be done tomorrow".

This also make you referent of this technical topic. As soon as another person hits the same impediment, there is a high chance he will come to you.

Additionally, whoever has the lead role will warn the product owner there is a possibility that all the tasks may not be completed during the current sprint so they may need to be prioritized again.

Answer 2

The purpose of standup meetings (from an agile sw development textbook) is to help the team to communicate better. Managers in the room may hinder open communication just because someone may be afraid to discuss issues and perhaps their own shortcomings openly.

A solution to this is to separate reporting to management and team meetings. Assuming you are using sprints, involve managers in sprint planning and in reviewing sprint outcomes. What happens inside the sprint stays with the team.

This way you get some buffer for tasks that take longer than expected and you do not have to explain yourself every day. If a task does not fit in one sprint, perhaps it should be broken down. If the impediments come from above you, the sprint review is a good moment to escalate the issue.

Answer 3

If you are developing a reputation as "unreliable" it likely isn't based on the fact that roadblocks keep popping up (as all developers know that this occurs), but rather that you're doing a really poor job of accounting for them in your estimation of difficulty or completeness, especially on this particular task which has shown itself to be hard to estimate.

You don't mention how experienced you are, but part of a developer's maturation process involves developing a sense of which projects or tasks have lots of known and unknown risks, and developing strategies to mitigate them. Of course, you might get it wrong, but if you are repeatedly doing so, your team might very well start thinking you are "unreliable" in your ability to estimate a project's difficulty.

This project has already illustrated that your difficult estimator is out of tune; next time you're asked to provide such an estimate, take a bit of time to really think about where the "gotchas" might lie, and try to come up with some strategies to get a better estimate of the work ahead.

Answer 4

Mention some details of what your stumbling on.

These meetings are to say what you did yesterday and what you're going to try to today. So do it - even if the net result was nothing. Talk in as much detail as you can without derailing the meeting time limits, eg:

I wasn't able to get the data loading correctly, I ripped apart the threadpool library, found a bug in it - unfortunately that didn't help. Also worked with Sam, since he touched this code a few weeks back. Didn't get anywhere. Also tried rewriting socket read function, still didn't fix the corruption.

Today I think my next best guess is to add stronger debugging checks for the serialisation library and see if that helps.

Your not promising anything, your peers and manager start to understand that you're actually doing lots, and they get a feel for the difficulty, and I find that little bit of detail might spark something in your co-workers.

Also, I raised this exact point in a my performance reviews: "I feel bad if I don't have anything to show within a business day of my last standup." A few of us made a case that its a blocker to R&D, that we're too afraid to go and spend a few days researching out of the box solutions to a problem, management listened, and stand-up meetings were moved to twice weekly.

Answer 5

First of all, the estimates of how much work it will take to complete a story are just that: estimates. There is always some level of risk that the estimate was wrong and it will take more work.

The estimates are based both on the current state of the code (as best your team knows it) and the team's knowledge about how to implement the story. (This is why the same story might have different estimates from iteration to iteration: in a later iteration you might have new code in the codebase or know of a new technique or library that could be used to reduce the implementation work.)

In this particular case, it seems that the team was lacking in knowledge about the story you're working on and, not knowing about some problems that could arise, mis-estimated (in retrospect) the story.

To avoid the appearance of being flaky, when giving the status of a story you're working on you want not only to explain that the estimate was wrong but show that you're doing risk management, now and for future work. So when you run into a problem that increases the amount of work you need to do, do a bit of analysis to figure out why the estimate was wrong, what impact this new knowledge should have on your current estimate for this and other stories, and what techniques should be used to mitigate this risk.

As an example, if the problems you're running into are because a library you're using is buggy, you might say:

This story has now exceeded its estimate several times due to bugs in library X that I discovered only late in the process of implementation. It seems clear that library X is not very trustworthy and, in light of this, we should revise any estimates of things that rely on it. Further, I am addressing this now by writing a few basic units test to show the actual behaviour of the APIs I use in X, it would probably be a good idea to do the same for other stories relying on X, and we should probably consider estimates for stories that rely on X to be fairly inaccurate until the tests that confirm X's needed behaviour are written.

This shows that, though there were unanticipated problems, you're taking steps not only to deal with them now, but also ensure that the newly-discovered risks you've found are better handled in the future.

One more thing about stand-up meetings: they're not only for giving status, but also sharing information (such as the problems with library X above) and requesting and offering help. It's worth saying, when you run into problems, "If anybody here has any thoughts on how to deal with this better, please contact me after the meeting so we can discuss the details." (This is especially true if you're not happy with your mitigation techniques; it can be difficult to think of good ones and others in the group may have good advice on this, or even be willing to work on it.)

Answer 6

I'm nervous about how this looks when I give my updates during standups.

Don't be. Standup meetings are not performance reviews. They are meant to convey status.

What is the best way for me to communicate my progress in siutations like these, where a task repeatedly takes me longer than expected for reasons that could not have been predicted? My goals are to be honest with the project managers, but also to give them information that is useful to them instead of wasting their time with overly technical details and to avoid presenting myself in a way that seems flaky.

You just briefly convey the status in a way that is understandable to everyone.

If anyone asks or wants more details, you invite them to a follow-up meeting where you can delve into the reasons as needed. That way, you don't waste everyone's time.