What can be done about a task with a tight deadline and no analysis?

Question

I am a software engineer. Today in the middle of a Sprint I was told to drop all my activities and start doing another task whose Jira entry has like 3 words.

The deadline for this task is very tight and they're all telling me to complete it as soon as possible. But I am on this project only 3 days and I have no idea what I'm supposed to do with this task at all. I don't know the architecture or the code of this project.

What course of action should I take here? It certainly doesn't feel pleasant to work like this. Is this normal in scrum?

I work for an outsourcing company and I feel like I can't voice this as a concern during our stand up meetings because I will be told by my manager that it's an internal issue and that we shouldn't talk about it when our client is there.

Answer 1

Let's start with the basics: No, that isn't Scrum. In fact, that type of action is expressly forbidden from multiple angles in Scrum.

Next, understand the consequences of whatever action you're going to take. Are you ok with this work environment? Are you allowed to request being assigned elsewhere if you are not? Picking a fight on this issue probably won't end well for you, so you should understand the consequences of any action you take.

If you decide to go along with it but are still uncomfortable, this may be something you can bring up in the retrospective.

Finally, on this specific point, the Scrum Master should really be your advocate here. They seem a bit absent in your story.

Now, the company is clearly not practicing Scrum. Just for broader knowledge, here is how that should go in a Scrum environment.

Step 1: Very important item comes in. It gets entered into the product backlog to be prioritized appropriately.

Step 2: If it is critically important, the person bringing it to the team would sit down and have a conversation with the Product Owner and the Team. They would explain the need and impact and the team may share some ideas of what it takes to address it. At this point, one of two things will happen.

Step 3a (pragmatic): This is technically against scrum, but it's both common and pretty harmless. The PO, team, and person raising the concern may reformulate their sprint plan to make this the number 1 priority of the whole team and they'll agree to what must drop.

Step 3b (by the book): The product owner crashes the sprint. All sprint work halts, new work is planned and at the front of it is this item.

Step 4: The whole team rallies around getting this item done as fast as humanly possible. I mean, if it was that important, it deserves everyone's attention.

This is the way it is supposed to work in Scrum. Work comes to the team. The team determines how to field it. Sprint priorities are respected and if something that important comes along, then it gets the urgency from the whole team it deserves. This makes sure that:

• the team fields work most effectively
• the team stays focused
• the team pivots as needed

Answer 2

Typically my advice in your situation is to reflect the pain. That is to make it clear to everyone concerned the difficulty of the task you have been given to help them have a realistic expectation of when the work will be completed.

However, as your manager has told you not to talk about it in front of the client then you are being put in a very difficult position.

Personally I would be looking to speak with my manager and to express my concerns. Depending on the answer I got I would then determine if this was an organisation I wanted to work for.

Answer 3

What do "as soon as possible" and "tight deadline" mean? As soon as possible, to me, means that this becomes your highest priority and you put in your best efforts to achieve the best schedule duration you can. This could be two days, four months, three years. Tight deadline means, to me, that someone is asking you to target to finish at your most optimistic, best case estimate. Again, based on the task, what is that value? If there is no discussion of that value, you don't have a tight deadline. You don't even have a deadline.

If all you were told as soon as possible, then your next task is to provide them your best estimate of what that might be. If you have to investigate the task, what it is, what the code is, architecture, root cause, etc., then do so and then provide your estimate.

Essentially, when I hear "as soon as possible," that means to me the assignment is my highest priority and I have license to table whatever else I have in play. It doesn't mean I have to finish it tomorrow. I get to provide my estimate of when I might finish, I get to provide the risks I see, I get to design and layout my plan to finish the work. If they say my best estimate is not good enough and assign a tighter deadline, I'll respond with, I don't think that's possible, and then get to work.

Answer 4

I feel like I can't voice this as a concern during our stand up meetings because I will be told by my manager that it's an internal issue and that we shouldn't talk about it when our client is there.

What "you feel" and "what is" are not necessarily the same thing. You won't know until you do it. If you do not feel stand-up is the right environment, you must bring it up. Historically, stand-up is a valid time to do this.

You can bring it up now (when something can be done about it) or after the fact (when it's too late). Which of these statements do you want to hear:

• If it couldn't be done, why didn't you say something. We could have got you help or clarified the task, or re-assigned it?

• You were right; it couldn't be done. But at least we all knew this was likely to happen.

It could also be that somebody DOES know and can guide you or take the task. This is one of the main reasons for having a stand up meeting.

Answer 5

What course of action should I take here? It certainly doesn't feel pleasant to work like this. Is this normal in scrum?

No, it is not normal in scrum. I guess your project has no method and uses word "scrum" to cover up incompetence.

What to do? This is what I would do in your place:

1. go to www.scrum.org and read how it should be done
2. remember that agile is team sport -> go to the team and talk to them
3. remind my manger that agile is about trust and transparency -> we talk about problems with the customer
4. in retrospective I would share how I felt during onboarding and when I got the task without necessary information.

Answer 6

Your boss explicitly told you to not discuss it with the customer, so this clearly isn't part of the standard process anymore. Therefore Scrum won't give you the answer how to handle this situation. You can not discuss it in the Daily Scrum nor in the retrospective.

Forget processes, do whatever is necessary!

Your managers decided that this is such a critical task that they do not care about processes, forecasts or other priorities, therefore they do not need to hear your concerns at the moment. Pick up the phone and call whoever can explain the issue and start fixing it. If you don't know how to fix it, pick up the phone and ask someone who knows.

They trust you that you can handle it, take it as a chance to prove yourself.

Post mortem

Of course this must not happen every week. After you solved the problem, do a root cause analysis. For example ask the 5 Whys and make adjustments, so that it will never happen again.