As a scrum master, how do I get everyone to take deadlines seriously?

Question

Overview

I'm a scrum master and also manager of an average team and honestly its my first time I'm responsible to manage a group of developers more than 10 people(around 12). So maybe my question seems unclear or misunderstood by some of you but please be patient with me as I want to learn from you guys as its my first experience. Also please share any resources you think can be useful.

When I managed some small teams in the past years, I never encounter such problems, but it seems when number of team members grow, the management is significantly harder.

Problem

The problem begin when I first came into the team (its almost 10 days) and from the first day I realized some of our veteran employee's velocity is lower than expected, work output is not on time and in overall some times we are missing deadlines. I just tried to monitor everyone's daily work performance and realized that some of them don't have enough engagement with the work (like they are working with their cell phone, surfing social medias, dont care about deadlines and trying to escape the office as soon as possible) and as I don't have any defined standards anywhere I can't act properly. I don't want to go around and talk to each one about this or bullying and start banning all cell phones / social networks. I think these approach won't be effective at all.

I really and truly appriciate everyone's effort and I'm not saying they are too bad, but I truly expect more...

Goal

My goal is to increase employees engagement during work such that everyone of them feels the sense of ownership of the company and start to caring about deadlines, focusing on doing tasks and have more engagement when they feel company is in trouble and need their help as a team. Another goal is to help them avoid disturbing activities during work. My ultimate goal is to achieve better results and I realized its because team is not completely focus on the tasks because of mentioned reasons.

Question

I want to know what is your way/suggestion for me to increase employees engagement during work in such situtation. Do you suggest to ban working with phones and social medias to help employees focus on their actual tasks OR I should focus on encouraging everyone to work better and increase engagement by preparing some events/trips OR increase their salaries (however they are getting more than country's average salary regarding their position and I don't think it will be effective) OR start talking with each one of them and asking about what can I do for them to increase their engagement OR any other idea? I just don't want to be a pain in somewhere! And don't want to poorly react with the situation. I have to get the things on schedule and It will be counted as my first reaction/decision in team.

More info

Note that we are doing scrum, we have daily meetings, log all works and our PM tool is Jira and using Confluence as our knowledge management.

My question is specifically about "improving engagement in a software company". Specially when the company is in a critical situation.

Answer 1

Your team members are not engaged because they're not enjoying the work. Your first response would be to sit down individually and privately with the under-performing team members and ask them how they feel about the work they're doing. Once you've identified the issues, you can then take more specific actions.

Is it a tools issue? Help them get the tools they need (for example, having to use Visual Studio Express simply because the company is too cheap/frugal to pay for a Pro version is demoralizing.)

Is it a fatigue thing? Are they tired of killing themselves to meet deadlines they had no say in? Try to balance deadline pressures with time off. More hours often does not equate to more productivity.

Is company management crazy and the developers have a hard time buying into their crazy vision? ("Crazy" is a subjective word -- does the team agree with management's direction and vision.) Offer to help buffer them from the craziness and let them focus on their work.

Is the work uninteresting? Help them find their own purpose in the work they're doing.

Are they simply underperforming? You might have to remove them from the team and replace them with someone more competent and suited to the tasks.

Answer 2

Your problem is in the first sentence:

I'm a scrum master and also project manager

You have 2 roles that are at odds with each other.

A Scrum master has two remits:

• Remove obstacles
• Ensure the agreed process is followed and coach where it is not

Notice I don't say anything about meeting deadlines, there are no deadlines in Scrum.

You work in set intervals (sprints/scrums/timeboxes etc), the amount of work you can get done is based on metrics (velocity in Scrum) and if something cannot be finished in the current interval, it keeps on in the next (but ideally you keep stories small enough that it doesn't tend to happen).

This isn't project management, which is usually based on fixed dates. The reason for this is that selecting an arbitrary date has been shown to not work and Scrum (and other Agile processes) are designed to deliver without this.

If the team are not "delivering" you need to look at your metrics. Are they maintaining a velocity? If not, why (things proving more difficult/technical debt/unclear stories etc)? If there are issues with how the team are working, get together and work it out with the team (self managing, remember?).

As Scrum master you should know about any impediments, or is it because you're pushing them for dates, and as a result they're not telling you? By the end of the Standup you should know of any issues and be on it. Think of strategies you can suggest to make things work better.

You also should look at the stories, sizing and dependencies specifically. Use the following on them:

• Independent
• Negotiable
• Valuable
• Estimable
• Small
• Testable

What I find works is to do the biggest work at the story end, work with the teams at creation time to make stories similar small sizes, extract dependencies and minimize work NOT DONE.

Once you do this you can start tracking metrics on Lead time/average story time etc, and this should allow you to abandon the 10% estimating for the team, and use the priorities to work out long term plans for your project.

As you then monitor story times, you can negotiate with PO/business etc on stories/priority to ensure the most valuable stories are delivered in the planned time, and give them a realistic timeframe for delivery.

Scrum (or other Agile processes) is about mindset. It is deliberately simple to do, but requires discipline and interest to work. Nothing crashes and burns quite like an Agile process where people are just paying lip-service, as things can appear to be progressing when they are not, until it's too late to stop the ship. If they don't really buy in, it can be better to go back to an approach where you are tracking start/stop on tasks, so you can push them when they miss a task deadline.

Answer 3

You can't "make people care about deadlines" in any way that will produce positive results.

It's tautological to say so, but developers work at the rate at which they work. This is their capacity. Capacity can be reduced by many things, but it can't be increased except very slowly, and that's more to do with an individual developer's experience than anything you can do. With the exception of investing in a decent training budget.

Telling a developer to work "twice as hard!" will not work, even if it looks like it did. A deadline may have been trivially met, but consider what work wasn't done in order to meet it.

Which comes to the crux of the issue: one thing that is under control is what work is done; what that capacity is filled up with. What is prioritized; what gold-plated features are trimmed down to size. Smaller, more comprehensible tasks tend to be accomplished sooner and with higher quality. Breaking down large features into these small tasks is the purview of the Product Owner, however. Ensuring these larger features are properly specified may require alignment with you as Project Manager. Ensuring that tasks are broken down properly may require involvement with you as the Scrum Master.

But managing by deadlines? Promising customers the impossible and then insisting that development caters to it is not the finest starting point.

Final point: I would advise not measuring developers' individual productivity. It just doesn't work that way in a team environment.

Answer 4

This is fairly common especially with new managers. You need to make your mark, it's not a beauty pageant.

Have a meeting and set down some ground rules, unimportant what they are at this point, so long as they're going to be broken. If the rules stick, add some more gradually and problem solved. If not, find the worst offender (but make sure it's not someone you can't lose because they might not take legitimate discipline professionally since they're not acting professionally already), take whatever disciplinary action is available and make an example of them, and then sit back and watch the rest fall in to line.

You don't reward people until they give you a reason to reward them, that's a fallacy I have seen many managers fall into. Yes it makes the employees like you, but it doesn't make them respect you anymore than it did. A manager who is a hard task master and not afraid to crack the whip eventually earns more respect and 'real' liking than one who doesn't.

I've done this with every team I've had an issue with, and it's a wake up call for all concerned and soon shows me the calibre of the team members which is useful to know in itself. But it's primary usefulness is it cuts through the rubbish and mollycoddling and gets things on track and accomplished quickly.

Answer 5

My suggestion would be that you switch to an agile development process. I know you say you're a scrum master, but what you're doing is clearly not the standard agile system of estimation and iteration as used in XP an Scrum. In particular, by trying to increase "velocity" you are utterly breaking the whole point of agile planning. (Velocity is the metric you use to get an accurate estimate of how much work the team can currently do; pushing for increases to it leads to point inflation with higher numbers but no more actual work done, inaccurate estimates, or both.)

Within standard agile processes the product owner works in cooperation with the developers to create stories and he then gets to decide in what order the stories will be worked on. He has no input into the estimation process and, if he has or wants things delivered at certain times, his only ability to do that is to change the order of stories to have certain ones worked on earlier.

The developers work with the product owner to create stories, but they are the only ones allowed to estimate them. (Not even you, as either their manager or the agile coach, has any input on the estimates unless you're also actually working on the implementation of stories. You can't order them to do something in less time.) At the end of each iteration you sum up the total estimate of all the stories that were successfully completed and your estimate for the next iteration will, in general, never be higher than that. It's particularly important that neither you nor the team tries to bump up that number; that's directly destructive to your ability to estimate because you're no longer using the real world data that actually shows how much you get done.

If this sounds as if there's not a huge role here for a manager, that's correct. Agile teams that are running well are very much self-managing, and that's a big part of the reason they can produce good work. It's also incredibly satisfying to be a developer in such a team because you no longer have a manager hovering over you trying to force you to meet unrealistic deadlines or do counterproductive things.

If you do decide you really do want to do agile, I'd strongly suggest you find a coach who knows agile fairly well. If there's nobody in your team who does, you'd have to go outside your team for this, but there are plenty of consultants out there who could work with you for a few months to get you up to speed. Misunderstandings of how agile works, such as those that you have, usually lead to process failure. (Please don't take this as an insult; there's nothing terrible about lacking knowledge in a certain area so long as you're aware of it and take steps to remedy it, if necessary.)

Answer 6

Well, from your question I might assume you are a project manager on a software product or the sort.

How do you feel the work is not getting done when you know there are agile methodologies you can follow and you mention you know them?

How is this not perfect for you? https://www.mountaingoatsoftware.com/agile/scrum/daily-scrum

Set a daily sprint meeting from 8 to 8:15. Get everyone to talk what they have done the last day, and set VERY CLEAR TARGET FOR THE CURRENT DAY. Next day, do the same.

In many projects daily meetings were not the case as work would be done in weekly packages, I would have weekly meetings having everyone stand up, talk about their work and targets, and setting targets for the following week. You can do that daily.

If they want to spend the whole day on facebook and do the work overnight, it's their problem.

If, during the daily meetings, you actually feel that some of the professional are not carrying work efficiently, talk to them in separate and try to understand their problem. Is it you that are not setting their targets correctly? Is it the workload that's too much? Is it the deliverables that they are not understanding correctly?

Pardon my sincerity and if I sound rude, but looks like you need to actually manage the team, their deliverables, targets and work.

Answer 7

I feel a little reluctant to anwser since you dont explain your position, but honestly if you feel that production is lowered or not optimal talk.

People often feel like work is getting done when its not. It is a common Problem when there are no clear principles

As a Manager:

Make a meeting tell them whats Happening whats bothering you on the workfloor and ask for coöperation.

As a co worker:

Make a complaint with your Manager. Other than that don't disturb the work Relations you have with your co workers by doing your Managers Job.

Update:

Honestly since you are new I would not be to bossy since you are new. Go to the daily Meeting and just say the Deadlines arent being accompliced and I dont feel that they are impossible and I dont want to put up rules, but I am starting to feel like there are no other Options. And most importantly ask for suggestions for productivity improvement and their experience with the work that they are getting done.

Still I feel that a Company with 12 developers (which is kinda alot) should have Standards from Management regardless if they are going to like it or not.

Answer 8

I would be recommend not attempting to draw conclusions after the first day or even the first month. You appear to be taking a relative (somewhat arbitrary) concept like velocity and using it to rank people.

Take a step back and relax, I would assume you have a little time before you are expected to work miracles.

Work with your reports, and try to make their job easier.

• Do they feel they have roadblocks or bottlenecks?
• Do they feel they have have work which doesn't add value?
• Do they feel they have ownership over the provided deadlines?
• Do they understand how the work they are doing contributes to the project goals?

The job of a project manager isn't to keep people on task, it's to make the project succeed. These are adults (I assume), and I would recommend not attempting to manage their time for them.

Make it your job to help them first and the deadlines will take care of themselves.