0

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.

  • 4
    You need to learn to say "no," and mean it. – Todd A. Jacobs May 12 '16 at 11:39
  • 3
    His argument that you'll lose business without these "aggressive" timelines is utter bs. Consistently failing to deliver on time will do far more harm to the business in the long run. I wish I had better advice than "find a new job"... – RubberDuck May 12 '16 at 11:44
  • 2
    It sounds like you aren't doing Scrum and your manager isn't bought into it at all. This isn't how commitments are made and there is no project manager role. I assume you're looking for an answer in the context of your traditional metholdogy rather than the scrum answer? – Nathan Cooper May 12 '16 at 12:14
  • 2
    Someone has to decide, either you will use Scrum and follow its rules or you can stop playing on one. If the management does not want to accept that team defines work to be done in an iteration they should just say: We do not want Scrum. Also if the Scrum Master in not strong enough (not a criticism, but sometime s/he does not have enough support in the organization) the project should ask for some outside consulting which organization would value enough. – MasterPJ May 12 '16 at 12:45
  • 1
    @NathanCooper I am trying very hard to maintain scrum practices, facing some resistance. I know that it is working extremely well (when my sprint cycles are not disrupted) because like this week we had a sprint, and my team helped me deliver high quality work ahead of schedule. – bobo2000 May 12 '16 at 13:09
7

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."

  • Thank you Barnaby, that is really helpful. I have started this process with my boss but it is taking a lot of time for him to get around to the idea that aggressive sales deadlines do not work. – bobo2000 May 13 '16 at 9:09
  • 3
    I have found that a lot of non-technical managers assume that pushing hard with tight deadlines is the best way to get results. They have seen this work with sales and other areas of the business. Most don't realise that software development is a knowledge based industry and that this kind of management approach doesn't usually work. – Barnaby Golden May 13 '16 at 9:29
  • 1
    @ Venture2099 yes exactly. I am tired of reading comments that 'we are not really doing scrum', the problem is not knowing how to do it, but to be able to do it in such a way where everyone is happy. – bobo2000 May 13 '16 at 10:07
  • 1
    @DavidEspina the problem is that it is hard to accurately estimate how long something will take in software development. Implementation, testing, bug fixing can not be estimated accurately using time, whereas in other industries you can do this. For example; if I am asked to serve pop corn I can measure how much time it takes to put into a container accurately and so I can tell a customer it will take 50 seconds. This will always be the same, and there will be no unknowns. This is where I think that velocity which is apart of Scrum is a fantastic concept and software dev is different. – bobo2000 May 13 '16 at 11:11
  • 1
    @ David Espina I plan based on velocity, I use story points to give an approximate measure the complexity of tasks in a sprint. Every Monday when I start my sprints, I ask the product owner what the goal of that week (i.e. sprint). The team then has to respect it, if the team consistently never meet the sprint goals, then there is a serious problem. With client tasks it is the same, I will factor their work into the sprints, since we have more than 1 client if we keep on taking on work with tight deadlines and short notice the project management is going to break when resources are blocked – bobo2000 May 13 '16 at 11:48
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.

  • Often thought about switching to kanban, but that means ditching burn down charts - there is just something about scrum that I like – bobo2000 May 23 '16 at 19:38
  • @bobo2000: Even with Scrum you can use the described approach. The major difference is that you will take a set of stories from the product backlog at once (this becomes the sprint backlog) and if you boss wants to change the set of stories in the sprint, the complete set gets dropped and you start planning a new sprint (this is called abnormal sprint termination). – Bart van Ingen Schenau May 25 '16 at 10:54
  • @BartvanIngenSchenau defeats the point of Scrum in my opinion if I keep having to recreate the sprint backlog once a change requests comes through. Often individual stories gets changed, not the entire backlog from experience. – bobo2000 May 25 '16 at 11:59
  • @bobo2000: Abnormal sprint termination should not happen very often. But it is also a very clear message to management that changing the priorities of work being produced right now is costly. That alone should be enough to let them think twice about how important the new request really is. – Bart van Ingen Schenau May 25 '16 at 12:08
  • 1
    @bobo2000 is correct. Your manager isn't feeling the pain or seeing the cost of these late changes. If they request a shift in priorities, you need to show the the backlog and ask where this new feature should be prioritized. The great thing about a stacked rank is that it becomes very clear that when you insert one tiny story, everything else is pushed down. That makes the cost very clear. – RyanTheJenks Jun 7 '16 at 21:42
0

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.

-2

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....

  • I am not the DV, but I don't feel this is a good answer as it boils down to "suck it up". Whilst I would agree with the principles of driving innovation through pressure you are espousing, I got a distinct feeling that is not what the OP is describing. His has all the hallmarks of unrelenting and crushing pressure on a team, which many high-level managers consider to be "sweating the assets". The problem is that working a creative field where, after a point, you cannot be more productive by "working smarter", crushing pressure is exactly that; crushing. The OP is asking for coping strategies – Marv Mills May 13 '16 at 14:32
  • @MarvMills, the OP supplied no metrics. We don't know the before level of performance or the after level. We don't know his pre and post defect density values. It appears the aggressive deadlines are just now coming in and his team is just now starting to exceed a forty-hour work week. The only evidence we have is the team is complaining. – David Espina May 13 '16 at 14:50
  • There is no hint of 'just suck it up' in my answer. I am suggesting to analyze this situation like a leader. – David Espina May 13 '16 at 14:55
  • @DavidEspina to be fair on the team they are not paid to work overtime, so if the work exceeds 40 hours a week it is unethical for the sales team to expect the team to work beyond their contracted hours. – bobo2000 May 13 '16 at 15:07
  • 1
    @DavidEspina You may not have intended it to read that way but that is how it read to me because, I guess, instead of commenting on the requested coping strategies you seem to be saying that this pressure is healthy and the team should not be having the problems they are demonstrably having. – Marv Mills May 13 '16 at 15:30

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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