Team velocity declined after legacy declaration

Question

I am the manager and I am struggling with a declined velocity. I have tried to discuss with the team what is going on, and they say they got better at story point estimation. But I suspect they are not motivated.

A few months ago, the director announced that the company planned to phase out the software the team had been working on and replace it a different product from the market. He said there were no timelines yet for the sunset date and it was not their intention to leave users without alternatives. It is not clear if the team will have any role in the new product, so their future is uncertain.

Ever since the announcement, the velocity has declined by up to 50%. I suspect the team are either interviewing or ramping up their skills to prepare for their next job. How do I motivate them to restore their velocity?

I know it is not common for management to rely on velocity as a measure of productivity. But in this company, velocity and individual points are how teams and individuals are evaluated.

Answer 1

Stop Abusing Velocity

I know it is not common for management to rely on velocity as a measure of productivity. But in this company, velocity and individual points are how teams and individuals are evaluated.

So, you know the company is doing the wrong thing and following an anti-pattern, and yet you're expecting a different outcome. That isn't reasonable.

More importantly, your company is making the cardinal mistake of treating velocity as a proxy for productivity, rather than as a planning value or estimation tool. You already know this is an anti-pattern, so don't do that either.

Examine Your Process and Your Messaging

From a process perspective, you have a couple of options:

1. Hold a retrospective to examine the process.

   It seems extremely likely that your application is being sunset (eventually) because of technical debt, product complexity, or other systemic drags on development productivity. Deciding a priori that it's the developers' fault is another anti-pattern.

2. Identify any other root causes.

   What else has changed in the environment? Has funding been cut? Have tools and equipment been re-allocated? Is there anything else standing in the way of productivity? Ask the team. Investigate. Find out!

3. Hold senior management accountable.

   If there's a genuine decline in productivity (rather than simply a reduction in a capacity planning metric like velocity), and if it's attributable to management's communication or de-prioritization of the project, then it's up to management to fix the problem.

   In business, executives asked to stay on a sinking ship are generally given bonuses or incentive pay to reduce "flight risk." Warm fuzzies, gamification, or pizza parties will not fix a management message of:

   You will all be out of a job at some indefinite time in the near future.

   Your developers are people, and if your organization treats them as disposable or fungible assets then they have no claim on their personal loyalty. If that turns out to be what's actually going on, senior management must fix it in a constructive way, rather than flogging everyone in the vain hope that morale will improve.

Personally, I suspect #3 is your likeliest problem, but you need to ensure you correctly identify the real root cause and eliminate all other process problems before you start tilting at organizational windmills. Regardless of why the process is now broken, a Scrum Master or project manager is responsible for communicating the problem upwards so that senior management (who collectively own all risks and outcomes, regardless of cause) can resolve any issues that the team can't resolve for itself.

Answer 2

You should definitely be careful. Velocity is a subjective measurement. As teams stabilize, it usually reflects productivity with some degree of accuracy. However, it is not productivity and it can move independently of productivity.

That said, it is possible that the team is right - their estimates are just more accurate now. If that is true, they may actually be more productive right now. As a leader in the organization, it may be your job here to stand up for them.

Also, your suspicions may be right. Demotivation can have a huge impact on anyone. As a manager, how have you explored this existential threat with the team? Have you raised your own observation about the uncertain future to the director? I don't know if this will have any impact on velocity, but if you are observing people being anxious, helping them resolve that certainly won't hurt the team.

Ultimately, velocity is a lagging indicator. Trying to change velocity is sort of like moving the needle on a speedometer to make the car go faster. Your post suggests that you are observing the team and identifying multiple hypotheses for why circumstances are what they are. That's exactly what you should be doing - see that through.

Answer 3

Your boss also erred by telling the team that their product was going to be scrapped without apparently giving them the promise that they wouldn't be. Therefore, for what should be perfectly obvious reasons, the developers stopped caring about a product that the company no longer cares about, and put their job searches into high gear. Very soon you won't have a team left to manage. (Maybe you should be putting your own job search into high gear, too ...)

Answer 4

Bear in mind that once velocity becomes a productivity metric it can EASILY be gamed - just scale up the complexity points for each feature/story! As stated above, the only real productivity metric is delivered working features.

In your given scenario though, it does sound like your team is voting with their feet...