How can I address productivity issues in a Scrum Team missing deadlines?

Question

I am a Scrum Master of a game dev team, and we are having issues with productivity. We are always late for our deadlines. I know Scrum doesn't have typical deadlines but we do, and it's really important for us to keep them.

We have three types of teams: prototyping, working on published games, and teams working on iterations. We don't really work with traditional Sprints. We have a Product Backlog and product, prototype, and iteration goals. We have milestones during development of each product which have their goals. We divide epics into user stories, and user stories into tasks. We give hourly estimations to our tasks. We do it with planning poker. For us the speed is really important, especially during iterations and prototyping, but lately I've noticed that the development might take more than twice the estimated time.

How I can measure team productivity more accurately to avoid missing deadlines?

Answer 1

My first suggestion is always, "ask the team."

Do some brainstorming at a retro: what leads to our missing deadlines? what were the causes of work being underestimated in the last couple of sprints? What slows us down? What makes things more difficult?

How many of those things are within our control; how many are things we can influence, but not control; and how many are entirely outside our control? (My team calls these categories "dogs, cats, & fish") Things entirely outside your control should be escalated; things partially outside your control should possibly be escalated, too, but you can work on fixing the part that is within your control.

More brainstorming: What could we possibly try to address one or more of those causes? Then dotvote the suggestions, and try the highest voted for an iteration or two.

It isn't your job to fix the problem. It is your job to help your team figure out how to fix the problem.

Good luck!

Answer 2

TL;DR

You certainly appear to have a problem, but you have turned it into an X/Y problem. You have delivery deadlines, and while deadlines in the traditional sense are not mentioned even once in the 2020 Scrum Guide, it's not all that unusual for a project using the Scrum framework to have them.

The actual X in this X/Y problem is that you've somehow decided, without any evidence provided in your question, that the problem is the Scrum Team's "productivity." That's unsubstantiated, and rarely the actual underlying cause in Scrum implementation failures.

You should be collaborating with the whole team to identify the root cause of missed project targets, any ineffective or inaccurate estimation techniques, or other systemic issues. There may also be organizational structure or culture issues at play that need more transparency. In short, you need to create visibility about the impedance mismatches that are causing your Scrum implementation to struggle.

Regardless of the reasons the project is not currently on track, the whole Scrum Team should be working together to identify something actionable that enables the team to collectively address the right issues. You as the Scrum Master should not be making a priori assumptions about the root cause, or defining a solution on behalf of what should be a self-managing team.

Analysis and Recommendations

Deadlines and Constraints

Projects often have delivery deadlines, whether you're using scrum or not. While not directly addressed by the Scrum framework, this is often done using a variation of the agile release planning methodology I've previously articulated. The primary caveat is that meeting deadlines requires that scope be the flexible constraint, since the theory of constraints and the project management triangle posit that you can't keep all the sliders for cost, schedule, scope, and quality fixed at the same time.

You must have at least one flexible constraint. In Scrum, that constraint is typically scope. The framework specifically states that quality never declines, and the framework itself is based on the notion of a predictable run-rate per Sprint and schedule is actually a predictable cadence rather than a fixed end date for the project. So, once the team has identified the root cause, it should then examine its options for working with stakeholders (often through the Product Owner) to adjust scope and allocate focused Sprints to meet deadlines.

Inspect and Adapt

In addition, the team should be leveraging Sprint Retrospectives to identify process problems. If your Sprints lack a cohesive Sprint Goal, your user stories are too big or too tightly coupled to deliver incrementally, or the schedule isn't a realistic estimate based on the team's skills, knowledge, or available resources, then you can focus on addressing those things within the process. If the root cause is something else altogether, that's fine too! The point is that the team has to agree on what the problem actually is ("inspection") before it can do something to fix it ("adaptation").

The inspect-and-adapt loop is fundamental to the success of agile frameworks like Scrum. Incremental delivery, iterative product and process refinement, and an organizational willingness to pivot or modify processes whenever changing expectations or situations impact the project are foundational to the success of any agile implementation. Without meeting those basic expectations met, you should expect the project to struggle.

Productive ≠ Successful

I started with this point, but it's really the most important thing to keep in mind. Broadly speaking, productivity is a measure of how much work a team or person is getting done. However, doing lots of work or completing lots of backlog items doesn't have anything to do with being successful.

Success isn't about doing more things or doing them faster. Success is generally the result of doing more of the right things, and stopping the wrong things sooner rather than later. Errors, missed estimates, or "successfully" completing a misfeature or poorly-communicated goal are common to every type of project; Scrum is not immune to that. However, by leveraging the inspect-and-adapt process and taking an empirical approach to both product development and process refinement, Scrum gives you a framework that helps you reduce the long-term impact of such inevitabilities.

By stating that your project is unsuccessful and then positing that this is due to a lack of productivity, you are quite likely to be proceeding from a false premise. Instead, the whole team should be discussing what success looks like. Then, if the project is falling short of that definition, identifying the reason(s) and available options to address the issues is the logical next step. The "five whys" technique is a relatively informal but effective whole-team approach to this type of root cause analysis (RCA). Regardless of how you perform your RCA, you need to involve the whole team if you want them to be part of the solution.

Answer 3

If deadlines are the goals - optimise your process to hit them (quite a damaging thing to do).

If they are value outcome focused - introduce forecasting with deadlines flexible, or outcome progress flexible, but always ensure there is follow up work after the deadline to fulfill the end value. Otherwise, what's the point?

I am all about Kanban. Hence I can suggest you a longer read about working with timelines and deadlines while doing Kanban in this post.

Most essential ideas are to structure your flow, start measuring it, start using forecasting instead of estimations. Finally, have an agreement among stakeholders about this approach and show them value of forecasts.

Answer 4

Productivity vs deadlines

How can I address productivity issues in a Scrum Team missing deadlines?

How I can measure team productivity more accurately to avoid missing deadlines?

Productivity and meeting deadlines are two very different things, one does not singlehandedly map to the other.

To point out why these are different, consider that if your truck does not arrive at its scheduled destination when you expected it to, that does not prove that the truck must have driven slower. Maybe it got lost and is driving in the wrong direction. Maybe it's not lost, but it knowingly had to take a detour because of something it had no control over.

If you treat these as the same, and communicate this to the team, then you're effectively communicating that they are being judged on when they finish working on something rather than the quality of the work they put forward. This is going to lead to developers cutting corners when anything threatens their deadline, which is going to give you a short term win (meeting your deadline) at a steep long term cost (technical debt accruing).

Setting deadlines for specific tasks

prototyping, working on published games, and teams working on iterations

More commonly known as spikes (prototypes), greenfielding (iterations) and maintenance (working on published games). Just pointing this out because it'll help you in navigating documentation on the subject of scrum.

For us the speed is really important,

That's what everyone says. Not because it's not true, but because everyone would like the same things done faster if they could make it happen.

especially during iterations and prototyping,

Prototypes are spikes. Spikes cannot be estimated as they are the equivalent of uncharted territory, and therefore they should be rigorously timeboxed. If your team is struggling to manage their time for timeboxed tasks, then that's a team culture issue of not listening to what has been planned in the sprint.

A timeboxed task is very simple in terms of time management: you stop when the time is up. There is no official goal here, there's a time allotment to see what could be delivered during this time.
If a team member feels that a short extension of their allotted time could help them reach a meaningful milestone, then that is something that needs to be explicitly discussed during standup. It depends on your team culture whether you allow your devs to make that call themselves and retroactively let you know they used more time, or if you mandate them asking permission before spending more time on the task. In either case, when more time is added to the spike, you simply add it to the "estimate" for the task; which in turn means that it detracts from the available time in the sprint for other tasks.

In other words, if the question at the end of the sprint is "why did this one-day task not get done?", the justifiable answer is "because we added an extra day to the spike", and this settles the matter without it leaving any negative impression on the team's productivity.

Estimates

but lately I've noticed that the development might take more than twice the estimated time.

If the estimate is consistently around 50% of the actual time taken, then this shouldn't be a problem. Consistency is great. That means that you can just double whatever estimate you get and therefore end up with a consistently accurately planned sprint.

If the ratio between estimate and real time worked is highly volatile, you need to dig into what the consistency is. Some examples:

• Maybe specific developers are shown to be bad estimators, which indicates a mentoring opportunity.
• Maybe specific developers are shown to be bad implementors, which indicates a mentoring opportunity (on a different topic than the previous bullet point).
• Maybe the issues only occur when the estimator is different from the implementor, which suggests that you have an expertise gap between different team members. Such a gap is best minimized as much as possible.
• Maybe tasks that touch on certain technologies are badly estimated, which indicates a lack of expertise with these technologies.
• Maybe tasks involving specific games/components are badly estimated, which indicates a higher degree of technical debt (or lack of documentation) in these games, which suggests that you need to invest in engineering improvements for these games so that the source for the delays can be "fixed", rendering future estimates more accurate
• Maybe some tasks are defined too vaguely or ambiguously and it's leading the team to estimate something different from what actually needs to be done.

Distractions

Maybe it's not related to the estimate at all, the team is simply tracking their time inaccurately, failing to indicate that they spend significant amount of time on other things. Whether this is company communication, helping others, dealing with IT support issues, having to consistently respond to emergencies in unrelated topics, ... It possible that the team are considering these events as "part of the daily work" but are not accounting for this in their estimates nor are they tracking these distractions separately.

If the latter is the case, you need to create some consistency between what is estimates and how the real work is tracked. There's several solutions here:

• Your team could include daily distractions in their estimate, which makes sense if the daily distractions are consistent in size.
• Your team could omit daily distractions from their estimate, and track them separately. This is difficult one to get right because it requires a lot of active time-tracking and context switching.
• Your team could omit daily distractions from their estimate, but you could add an estimate of distraction amount to your sprint. A previous company I worked with assumed that 20% of time would be consumed by distractions, effectively assuming that a work week is only 4 days.

Generally, I would advocate for actively suppressing daily distraction as much as possible, but whether or not this is feasible depends on your workplace environment and business context, this is not universally answerable. If it can be avoided, it should, because context switching is a massive productivity killer.