5

I would like to discuss and hear some advice from you about a pretty common situation.

We develop the functionality that has huge business value for the customer’s project and thus the customer is particularly interested that this feature is completed asap. I selected the most appropriate developer for this task based on my team’s current workload, experience with the project and vacation schedule in the team. The developer started researching the problem. The functionality is completely new, connected to the integration with third-party API and plugin and contains numerous technical and business unknowns. The developer made an initial rough estimate of the task and it showed that by the time of his vacation there might be an MVP of the feature. I communicated with him on a daily basis and the progress seemed satisfactory. I felt that by the time of his vacation the developer would finish the main bulk of the task and the other team member could assist with its testing during the absence of the key developer.

Before the vacation, I gathered both developers to define a set of actions that an interim developer should do during the vacation week. Planned functionality was not completed as expected and another developer could not test anything yet. Interim developer listened to an explanation of the feature, read the code and said that he was not able to continue development since the feature was so huge that it required at least a week to research everything. In addition, there were still several unanswered questions that might impede the development of the feature.

1) What should be my actions in this situation now? I cannot tell the client that the development of the feature has stopped because the dev went on vacation. This would be unprofessional.

2) What could I do earlier in order to avoid this situation?

Improve this question
1
  • Maybe consider an idea of cancelling the sprint (as it looks like the sprint goal is hardly achievable now) and start a new sprint with the task in question reassigned to another team member / other team members according to its priority?
    – oleg.mosalov
    Commented Aug 18, 2019 at 17:31

3 Answers 3

Reset to default
8

What should be my actions in this situation now? I cannot tell the client that the development of the feature has stopped because the dev went on vacation. This would be unprofessional.

Honesty is the best. You don't necessarily need to mention vacation, but being up front that, due to circumstances, the work will not be completed as originally projected.

What could I do earlier in order to avoid this situation?

No one works alone, in isolation. Things happen - people take vacations, people get sick, people win the lottery or get hit by a bus. These are risks that need to be managed. Building cross-functional teams where everyone on them is capable of getting work done is best. Everyone isn't going to be equally good at everything - everyone will have strengths and weaknesses - but there shouldn't be single person bottlenecks on a team.

Improve this answer
6
  • Thank you Thomas! I totally agree with the second answer, it was my blunder, but there was the only dev available for that moment. Regarding the first question, what could be the possible ways to solve the problem?
    – Artem
    Commented Aug 8, 2019 at 21:31
  • 1
    @Artem Having a single point of failure is another risk that needs to be managed. If you don't manage it, you'll have to accept the consequences if it comes true.
    – Thomas Owens ♦
    Commented Aug 8, 2019 at 21:33
  • I mean maybe allocate resources of additional developer from our team to finish the task faster? What would Scrum guru do in such situation?
    – Artem
    Commented Aug 8, 2019 at 21:51
  • 1
    @Artem Scrum would recommend a cross-functional Development Team of between 3 and 9 individuals who, as an entire team, work toward accomplishing the Sprint Goals and have the honesty, courage, and transparency to ensure that appropriate stakeholders are always aware of the state of work and risks or impediments to success.
    – Thomas Owens ♦
    Commented Aug 8, 2019 at 21:53
  • Thomas you are breathtaking! :) Thanks once again, I see where I am now. Let's call this situation "Learning from mistakes". We will continue solving the issue with the interim developer.
    – Artem
    Commented Aug 8, 2019 at 22:10
6

In terms of how to do better next time:

It sounds as if you identified the risk as one of medium risk (might be ready) and high severity (huge business value), and you decided to monitor the risk (communicated with him on a daily basis and the progress seemed satisfactory).

Monitoring the risk basically left you in a situation of "success-oriented scheduling": by the time it was apparent that the risk had manifested, it was effectively too late to do anything about it.

Given medium risk and high severity, I would suggest taking action to mitigate the risk: plan for the likelihood that the risk will manifest right from the start, and make a contingency plan.

On day one, when you determined that he might have something ready, and that the bulk of the work would be complete before he left: if you had asked yourself "What's my contingency plan if those things don't happen on time?", what would you have answered?

Personally, I would likely have assigned 2 devs to the feature from the start; or at minimum had the "interim dev" doing design & code reviews and otherwise getting debriefed by "prime dev" every few days so they are fully up to speed and don't have a big learning curve at the handover. But I'm sure there are other possibilities.

Regardless of the specifics, the principle is to determine from the start whether monitoring is sufficient, or mitigation is necessary; and avoid "success-oriented scheduling" for things that matter.

Hope that helps. Good luck!

Improve this answer
5
  • Thank you Vicki! sorry for my late reply, now I am a bit busy with this situation. I see what you mean and mostly agree with your point. Apart from the "assigned 2 devs to the feature from the start" which is the №1 solution, there should be more planning and monitoring of the prime dev. Also thanks for the idea of the debriefing. Also I want to add some solution of mine: as the prime dev did not complete planned functionality before his vocation he agreed to provide remote tech support to the second dev during his absence.
    – Artem
    Commented Aug 11, 2019 at 11:15
  • 2
    @Artem asking people to sacrifice part of their vacation because their work was not done on time is not a very good solution. It leads to resentment and rushed work, which only make issues worse.
    – Erik
    Commented Aug 13, 2019 at 12:23
  • 1
    Agreed. Plus you put the team into panic mode with the root cause being a (beginners) management mistake. Especially when bad things happen, the PM should act with prudence which is probably one of the biggest challenges in this job. But just heating the problem up usually causes more harm than good things.
    – kritzel_sw
    Commented Aug 13, 2019 at 12:47
  • 1
    @Artem, another thing to consider is how the monitoring that you were doing gave you the impression that things were on track, only to be surprised at what actually happened. When your dev gets back, have a convo with him about this that is coming from a place of curiosity and lessons-learned, and not looking to fix blame, only to understand whether there was a communications breakdown & how it could be prevented in future, and/or whether there were late-breaking surprises on his end, & how to prevent that in future.
    – Vicki Laidler
    Commented Aug 14, 2019 at 0:51
  • Wait, wait, wait. I didn't really push the dev to sacrifice his vacation, that was by mutual consent (but yeah without a material consideration). He was worried about that feature and the project in general. There were no panic, blame or resentment. Of course, this is not a general solution but it's possible, and you can remember it for the future (sometimes resources for compensation to dev could be less than for other solutions and at the same time dev could be happy to get it)
    – Artem
    Commented Aug 15, 2019 at 11:55
3

1) What should be my actions in this situation now? I cannot tell the client that the development of the feature has stopped because the dev went on vacation. This would be unprofessional

In fact I agree to Thomas' "Honesty is Best" approach. Having another developer assigned to the task will definitely not align with the budget and I suppose that this disruptive change in task assignment will not fully solve the problem. In such cases, I usually experienced:

  • feature still not developed on time
  • quality decrease
  • dissatisfaction of team members involved leading to
  • loss of reputation and authority for the project lead (me)

If you feel that it is inevitable to continue the work on the feature without any knowledge transfer, I strongly recommend to assign more than one developer to the task rather than introducing another person as the "single point of failure". Especially since I suppose that the main task is to "learn the concept from the code implementing it", it is good to have a small team of at least 2 persons so that they can correct each other. Psychologically, there is not a single programmer who takes all the (unfair) burden of compensating a management mistake.

Which leads me back to your question about communication with the client. By acting this way, you could tell a story like

"I am very sorry, but the programmer assigned to the project is unexpectedly unavailable for an uncertain period of time. We acted on this by doubling the resources assigned to the development of this particular feature. The feature may still be on delay but we do our very best to mitigate the impact for you, dear customer. I will keep you posted about the progress."

Improve this answer
9
  • 1
    Your suggestion doesn't like an "honesty is best approach" to me.
    – Erik
    Commented Aug 13, 2019 at 12:22
  • 1
    @Erik: What in particular are you referring to? In the comment to Thomas Owens answer, Artem said that honesty is not an option. So my answer proposes something which is very close to plain honesty and does not include any lies told to the customer. But it avoids telling the customer "I have missed a forseeable vacation, so I am sorry to tell you that your feature is on great delay"
    – kritzel_sw
    Commented Aug 13, 2019 at 12:41
  • 1
    It certainly includes the lies "unexpectedly unavailable" and "uncertain period of time". If you want to omit the lies, you might want to just use "currently unavailable" or "unavailable until next week".
    – Erik
    Commented Aug 13, 2019 at 12:50
  • 1
    Maybe...though it would not really make a difference for the customer. Anyway, I am just trying to find a better solution than completely hiding the problem away and trying to solve it by putting the team into panic mode under the constraint that Artem does not want to tell the customer about his mistake.
    – kritzel_sw
    Commented Aug 13, 2019 at 13:21
  • 1
    About developer's mistake: Sure but the situation that developers hope for the miracle to happen the last day before the deadline / their vacation is so common, that management should handle it. About your other question: I would not ask a developer to work on vacation but if he/she feels better in doing so to compensate a mistake, I would probably agree. It very much depends on the relationship between you, the individuals and the team.
    – kritzel_sw
    Commented Aug 16, 2019 at 5:55

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.