Sales team keep on setting aggressive deadlines

Question

So I had a quick meeting today, my Boss who is leading the sales team has given me one sprint to deliver a shopping list of work for a end client.

I have told him that a week is not enough time to deliver that amount of work and properly test everything. Only in the best case scenario, if everything works fantastically well, it will be delivered.

I am currently facing the following issues:

• My boss doesn't seem to care and will just set the aggressive deadlines anyway because it's an opportunity to get business in.

• My boss is not respecting the fact that my team are contractually obliged to work 40 hours a week (UK), he just wants this level of work delivered in a sprint even if it means a lot of overtime.

I have warned him about:

• Tech debt resulting from very aggressive deadlines and being able to create a contingency in my project management.
• I have repeatedly told him that we can't let clients dictate our sprint cycles this way, but his argument is that if we are not aggressive enough with timeframes we will lose business.

How can I handle this situation.

Answer 1

Reflect the pain back.

As things stand, your boss is not feeling the pain the team is feeling in delivering against artificial and aggressive deadlines. Your challenge is to make sure they see the consequences of their actions.

Produce a sprint report that details what has or has not been tested. Make it clear that by accepting a release under these conditions your boss is also accepting the responsibility for any bugs that arise from untested code.

For example:

"We have managed to test the new features delivered in this sprint, but we have not had time to do any regression testing nor have we we tested on other browsers or devices. The product may well have bugs that we have not discovered."

Do the same kind of thing with code quality. Every time you rush a delivery you build up technical debt and you reduce the quality of your code. This can be reflected back in terms of the difficulty of doing future enhancements on the code base:

"In order to achieve the last delivery deadline we had to hard code a number of values rather than using a more effective coding approach. The code base will be harder to work on now and as such we are likely to be slower to deliver any future work."

Finally, emphasise the impact of working long hours on the team:

"The team has been working evenings and some weekends for several weeks now. Team morale is low and motivation is much reduced. As the team members are tired all the time they are making more mistakes, which is resulting in increasing amounts of re-work."

Answer 2

This is precisely why I like the Kanban approach to PM.

1. Make a big unordered list of all the "wist list" features people have requested.
2. Rank each feature/story in priority order. Which ones must be done now and will help the business?
3. Once you agree on the priorities, the implementation is in your court. It shouldn't matter if the top story is going to take 6 weeks and the 2nd is going to take 2 hours. Sure, you could deliver it faster, but it's not the most important so don't do it yet.
4. You and your manager need to agree that you're not going to ship a feature that isn't complete. You'll focus as many resources (people, budgets, time, attention, etc.) on the stories in the agreed upon order and they'll be delivered to the customers when they're complete. No sooner and no later.

This is, without dispute, the fastest way to deliver value to the customers in the shortest timeframe. If, in a week, your manager says he needs a different feature delivered first, you say, "Great. Let's sit down and look at the priorities. Do we both agree that B should be done before A?"

If it's better for the business, then drop everything and do B. It's okay to make that decision as long as everyone knows what the costs & ramifications will be.

Answer 3

A well covered and detailed answer for the situation. Ensure you share few emails and reports supporting the facts about the difficulties and the flaws of tight and unrealistic goals for the team. Adding few of the tools through which each of this could be achieved.

Maintain a well documented and self explanatory Tracibility Matrix. This would cover the Scenarios and the Test cases that were executed in a specific Sprint for a release. In a release report mention the features that were not regressed. Make a practice to share a release report.

During your emails about the Code freeze details, mention the Code has not been self reviewed and Peer reviewed, due to the deadlines. The testing team is waiting the the implemented feature for their test activities. Thus, opening gates for few obvious issues.

Regarding the team moral and motivation issues. Do monthly one to one meeting with the team members. The goal of the meeting should be to set a monthly goal for the team members and identify and resolve any roadblocks for them. In such a scenario, the team members will come with issues that would be a red flag for the management. Share the same and seek solution to their issues.

Once, these discussions would come on the table, the management team and the HR team would look for a solution to the current difficulties the team is facing.

Answer 4

At the risk of more down votes:

This kind of question leads to a ton of feel good answers for labor. But feel good answers for labor are not necessarily the right answers for leaders and managers.

You cannot consistently use a planning value, an estimate, that has so much contingency in there to handle any and every threat, every random and non random variable, in order to meet that estimate 100% or near 100% of the time. Labor will want this and will scream for it but as a manager you cannot allow it. Fat estimates are not competitive and, if you want to stay in business, you have to commit to far more aggressive estimates and figure out how to get it done. Get comfortable with P30 and P40 estimates.

Parkinson's and Student Syndrome are real phenomena. If you do not challenge your estimates, you will end up with a constantly growing and overworked team that is producing nothing more than previously produced.

Teams adapt. With pressure, teams will adapt and find new ways to be successful. This is how innovation works. Without pressure, no change. This is not management BS. This is science.

Notwithstanding contractual issues, there is no link between working over 40 hours and low morale and increased errors. The origin of 40 hours it not based on science but based on politics. Human capacity can handle way more than this before both morale and errors increase. Morale is more tied to purpose, autonomy, and mastery. Nothing about 40 hours. Again, science, not labor feel good pop psychology.

There is a point of degradation in performance. You'd be surprised how far out that is than what it feels like. But without metrics to show when this is occurring, you have nothing. You cannot establish the judgement of "too aggressive" without metrics to show it...not one or two observations but consistent observations over a period of time of degraded performance.

Flame suit is on....