47

We get this statement from the PMs quite frequently during sprint planning:

I know our capacity for points is X story points per sprint - but we're taking on extra as a stretch target.

The PM then proceeds afterward to get aggressive with the Tech Lead about not doing enough on the business-related story points.

My question is: What to do about Software Project Managers aggressively overloading the Tech Leads?

Improve this question
3
  • 112
    The scrum answer is "No we're not, because you don't get to decide what goes in the sprint", but I'm assuming you're doing some dysfunctional form of scrum here?
    – Erik
    Commented Jan 17, 2018 at 10:30
  • 2
    Comments are not for extended discussion; this conversation has been moved to chat.
    – Jane S
    Commented Jan 18, 2018 at 0:50
  • 1
    Can you clarify what you mean by "to get aggressive". This could mean everything from pressuring, foul language, raised voices, physical threats, other threats, or even violence.
    – sehe
    Commented Jan 18, 2018 at 9:30

6 Answers 6

Reset to default
73

I'm assuming you are the tech lead.

Ask for priorities

As soon as you know the to-do list, send an e-mail to your manager :

Hi [Name], (or Hello Mr(s) [Name] if you are not that close)

I have seen the tasks we're supposed to take care of for this sprint and, based on the estimates, we're not going to be able to take care of all of them. Could you please prioritize the task ?

Regards,

[BlahBlah]

(you can also present a priority list and ask for agreement)

That way, if they answer and you do only top priorities tasks, you can use this as an argument. If they don't answer, you will be able to tell them that you raised an alert and they ignored it. You did your job.

Improve this answer
8
  • 10
    It's not the OP's problem. He told his manager he can't do all of this (he raised an alert), suggested a solution (priorization). It's now up to his boss to choose to use this solution or to come with another one if he can't do this - like adding ressources to the project (even if his boss ignores the alert, OP is covered thanks to his e-mail).
    – LP154
    Commented Jan 17, 2018 at 15:11
  • 2
    Prioritising is (or should be) a component of the sprint planning excercise. Entering the sprint, stories should already be in priority order.
    – patchandthat
    Commented Jan 17, 2018 at 15:21
  • 4
    I seriously doubt the OP has a problem with no prioritization. The problem is the PM wants the team to increase their BVP Velocity(Business Value Points) meaning the PM wants more business stories finished than the team is willing to commit to. My suspcion is that the PM does not like to be the one paying to fix the tech debt.
    – IDrinkandIKnowThings
    Commented Jan 17, 2018 at 20:00
  • 1
    "ask for priorities" how naive. Everything is a priority!
    – speciesUnknown
    Commented Jan 17, 2018 at 23:41
  • 3
    @SimonB: Priority is not exactly the same as importance. Even if all requirements are mandated by the contract, not all requirements have to be satisfied by the end of the first sprint. If the PM wants something to be pulled into the sprint, (s)he's implicitly saying that it's higher priority than something else. A good PM will make that explicit, and will indicate what that "something else" is (or at least will be open to doing so).
    – ruakh
    Commented Jan 18, 2018 at 6:45
38

Stop working in a 'twilight zone'

As a company, a decision should be made: do you want to move towards an Agile way of working with Sprints and all other things it entails or do you want to adopt a more 'classical' approach?

If sprints are to be used, then the only people who can decide what work will be done in a sprint are the scrum team: the product owner and the developers. Note that there is no 'project manager' in this scenario. The product owner is the one who decides the priority of all the different stories and functionalities and then the scrum team decides during sprint planning which items they will pick up during that iteration. There is no room here for anyone to force the developers to take on more work. If the different project managers (who will become stakeholders in the new structure) want the priorities to change, they will need to convince the product owner to change the priorities. If during a sprint it turns out that the stories are all fully done (including testing) and there's room for more work, the scrum team will have a quick meeting to decide which stories they will take into the sprint in addition to the stories that were decided on during the sprint planning. If multiple stakeholders have conflicting priorities, the product owner should have a meeting with all of them and have them decide together what they think the priorities should be, of which they can then attempt to convince the product owner.

In a more classical approach, something similar should happen. Since the project managers are not the ones doing the work, they should leave the judgement of what can be done within a given timeframe to the experts: the tech leads. They can always ask for more, but should trust the judgement of the tech leads. If multiple project managers depend on the same set of people to get their tasks done, those project managers should decide between themselves what the order of priority in the tasks should be and then trust the tech leads to ensure that this order is respected. In this case there's no such thing as a 'stretch goal': the work gets completed in order of priority and if someone happens to run out of tasks they will go up the proverbial foodchain to ask what their next task should be.

By trying to work in the classical way within an Agile/Scrum structure of sprints, an incredible amount of pressure is created on the developers, which is practically always counterproductive. In such a classical structure, it should never be up to the developer to decide whether they should be working on a task for one project manager or the other, since they are unable to correctly assess which task has the most business value. The way of working that seems to be described in the question here will lead to developer burnout, which leads to developers leaving for greener pastures.

Improve this answer
5
  • 11
    OP can get the last paragraph put in a frame and hang it on the metting room wall with big letters and point to it everytime the PM gets aggressive
    – jean
    Commented Jan 17, 2018 at 12:55
  • This is the way to handle in the end, but its not something the op can do themselves. That kinda breaks this answer
    – IDrinkandIKnowThings
    Commented Jan 17, 2018 at 20:06
  • You seem to conflate Scrum and Agile. You write about working in an Agile way and then assume that there is a Scrum team. Project managers are entirely compatible with other Agile methodologies.
    – Dughall
    Commented Jan 19, 2018 at 12:20
  • @Dughall I may be mistaken, but to my knowledge of Agile methodologies, only Scrum works in sprints. This is what lead me to my assumption. I'm always a fan of getting details right so if you have concrete suggestions on how to make the answer better, please feel free to propose an edit.
    – Cronax
    Commented Jan 19, 2018 at 14:12
  • Isn't sprint just a pretentious word for iteration? Several Agile methodologies use iterations. It's not really important, we're probably going too far into software engineering for the workplace stack exchange.
    – Dughall
    Commented Jan 20, 2018 at 18:28
23

What to do about Software Project Managers aggressively overloading the Tech Leads?

You need to manage their expectations by establishing boundaries. It's a topic you could write entire books about so I'll cover just the specific issue you keep running in: PMs overloading your team with requests they know to be unreasonable.

The way they've worded this actually helps you a lot, because it makes it easy to push back. The next time a PM asks you why X features weren't done, your reply should cover some of the below phrases:

  • As you know we took on more than we could deliver so we had to prioritise X, Y and Z.

  • As you recall I mentioned that we wouldn't be able to do more than X and that we would only do Y if we were significantly ahead of schedule.

  • Our original estimate was pretty accuracte so we didn't have time to look into that.

If you're taking on a regular workload, a PM is adding on extra features on top of that and is then complaining why those extras weren't done, use a variation of:

  • As I understand it X and Y were considered extras that we would take on if we still had time available. Our original estimate/goal was quite accuracte so we weren't able to take this one.

  • I'm not sure I follow, you said these were stretch targets right? We focused on the main targets (X, Y and Z) and those are done but we didn't have time to take the stretch targets on.

If you're using an agile delivery model it can help to throw around the lingo:

  • as discussed that was a stretch goal that was outside our forecast
  • we had to refine the backlog
  • we'll have to push this to the next sprint

The point is to make it clear that your team has a limited capacity and that you obviously have to prioritise when you're assigned more than you can feasibly deliver.

Note that all of the above only works if you are in a semi-strong position, which as tech lead you should be. Pushing back against unrealistic requirements is always tricky because they tend to come from unrealistic people. You need to know how to push back against people who demand more hours than your team can practically deliver, who insist on overtime when it doesn't make sense to ask that of your team, who say something is a stretch goal when they really mean "I won't take no for an answer". Handling that well comes with experience.

Improve this answer
5
  • 7
    The agile lingo has been changed because "commit to" turned out to cause more problems with PMs than it solved; the new lingo is "forecast", as in "the stretch goal was outside our forecast".
    – Erik
    Commented Jan 17, 2018 at 13:44
  • 1
    @Erik Shows what I know. :) Thanks for the heads-up.
    – Lilienthal ♦
    Commented Jan 17, 2018 at 14:12
  • @Erik - No the problems are PMs like metrics, and the story points seem like a good way to keep score. But they are not supposed to be score keeping. They are an estimate of how much work needs to be done. To make agile more business friendly it should be a bid to the dev team that they get paid X for completing the stories. Then management is going to prioritize stories that reward the department the most. Have an easy fix that would save your team lots of time/money. Through more money at the task and watch them get it done.
    – IDrinkandIKnowThings
    Commented Jan 17, 2018 at 20:12
  • @IDrinkandIKnowThings that sounds a bit like working with contractors instead of employees. (Also, money is known to be a bad motivator for many people, and throwing more money at people who have to do thinking work usually makes them less effective.)
    – Erik
    Commented Jan 17, 2018 at 21:25
  • 1
    @Erik - You misunderstand. I am not saying that the devs get that money the department they work for would. Its a business expense and the IT Dev team should operate like a business. Instead most places treat it like a cost center. The team makes money, they get better equipment, raises, etc with it.
    – IDrinkandIKnowThings
    Commented Jan 17, 2018 at 21:35
9

Assuming you know your velocity, you're restricted by how many story points you can complete.

The business need to prioritise the workload with the project manager.

I can't recommend overloading the sprint (because if you don't deliver on what was agreed, it defeats the purpose of planning and being Agile). If stories aren't delivered in time, the accountability ultimately falls with the PM.

Also, assuming the PM is reasonable (and knows how to work in Agile), they should know that if anything gets added to the sprint then something else has to be removed -- this is also their responsibility.

If you're concerned that it'll be your fault, don't be. The buck stops with the project manager to manage the project properly.

Edit: Just re-reading your post - a 'stretch target' is perfectly okay. It just means that, if the team complete all the sprint work, you can then bring in additional work... but only if you finish what was agreed. Rarely happens, in my experience.

Improve this answer
6

It is the tech lead's job to manage the expectations of the PM. It is the PM's Job to push the project along and get it done right, as fast and as they are able.

As a tech lead these are some tips for improving that:

  • Require any requests for completing "More Points" to be specific requests for which stories they want to see prioritized over the current work.
  • Explain that you do the work as it is prioritized on the board. That your team works as fast and diligently as can reasonably be expected, and that if the PM has concerns about specific team members not pulling their weight they should address those with the Team Lead.
  • Suggest that if your PM wants to see an increase in MVP Points completed the best way would be to increase the size of the team. Please note that if you have a looming deadline then this option is not practical. If you have months of work remaining then it is.
  • When your pm tries to do something outside of the Agile methodology your business practices you explain to the PM what they are doing, why it is a problem, and how to properly address their concerns within the methodology being used.
Improve this answer
0
4

Naming things is half the battle.

Don't refer to them as "stretch targets", consistently refer to them as "grooming the next sprint". If directly challenged you can say "we don't have targets in agile, we have forecasts, and there is no such thing as a stretch forecast".

If eventually other people stop calling them stretch targets you've probably won.

Improve this answer
1
  • 1
    If you rename the stretch target to "Things I doubt we will get to by who knows" then PM's just insist on loading up more on the main. The problem is a business desires to save money and get work done, outweigh
    – IDrinkandIKnowThings
    Commented Jan 17, 2018 at 20:18

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .