ScottLilly.com Posts

As a contract programmer, I’ve worked at several companies “doing Scrum” – and seen many of them lose efficiency from a common problem.

Here’s a small change in thinking that can eliminate the problem and increase your team’s productivity.

The situation

At the end of the sprint, some of the stories are “done” – but have bugs or need new features that were discovered during development.

The ineffective “solutions”

Usually, I’ve seen these “solutions” to this problem.

1. The Manager, Product Owner, or ScrumMaster berates the team for violating the Scrum “rule” that they must “commit to completing the story by the end of the sprint”. This completely ignores the fact that writing any piece of code will “take as long as it takes”. The developers gave an estimate – a guess – and it turns out the story was more difficult than they guessed. Now, the developers are being told their guesses must always be 100% accurate.
2. The user story is marked as “done”, but a new story is added to finish the remaining work.
3. Developers finish their stories a few days before the sprint ends, but don’t want to pull in any additional work. They don’t want to violate the Scrum “rule” that you can’t change the stories during the sprint. Or they’re worried they won’t complete the story and eventually be admonished for that.

What really happens with these “solutions”

In the first scenario, no one likes to be regularly berated by their boss. It makes them feel like their job (income, health insurance, etc.) is at risk.

So, they (often sub-consciously) start increasing their estimates of stories. To be extra safe, they’ll start breaking stories into more and more small stories. This should give them enough padding to accomplish any story within a sprint.

I remember once when there was a feature that took a single developer three days to do. However, during the story grooming session, the team originally broke the feature into many small stories. Each of those small stories was estimated as several points of work. The total estimated time for all the small stories for the feature was equal to most of the team’s capacity for three weeks.

In the second scenario, you see the line on your burndown chart get very horizontal. For every story point of work completed, you add a quarter to a half point of work to the project with the new user stories for the bug fixes and unexpected requirements.

Upper management starts wondering if the project will ever be finished, or if they should cut their losses and abandon the project.

Even worse, the team gets used to this practice. Your end of sprint ceremonies and deadlines become meaningless. But you need to continue acting like your project planning is reality – because that’s the rules of “Agile/Scrum/whatever”.

In the third scenario, your projects end up taking more time than they needed. Your developers had extra capacity to do work but didn’t – just so they wouldn’t break an arbitrary rule.

A sad thing is that these problems are often brought up during retrospectives. In my experience, the solution 100% of the time has been to split stories into smaller stories and estimate them as taking more time – to give the developers a better chance of completing 100% of the sprint’s stories.

This is a prime example of Goodhart’s Law – when a metric becomes a target, it ceases to be useful as a metric. The focus becomes on gaming the system, to meet arbitrary goals, and not to quickly deliver high-value software to users.

A better solution

The objective of every software team is to deliver high-value software quickly.

The objective is not to “Do Agile” or “Do Scrum”.

The map is not the territory. And, acting like the plan is more accurate than reality is a sure way to have your projects fail. Reality will eventually win.

The realities of software development project management:

1. Estimates are guesses. Some people are better than others, but no one is 100% accurate.
2. Work takes as long as it takes. If it takes eight hours to write the code for the TPS Report, it’s going to take eight hours regardless of whether you’re using Scrum, Agile, Lean, Kanban, SAFe, or Waterfall.

If you’ve seen these problems on your Scrum teams, why not try something a little different?

In my experience, most corporate custom software development works better using more of a Kanban style of project management.

Stop treating your sprint ends as some hard deadline that must always be 100% completed

You can still estimate stories. You can still have daily standups to see if a story is taking longer than expected. You can still have demos and planning sessions every two weeks.

Stop pretending estimates are accurate. Start using them as indicators that maybe the developer needs help, or that the work may need to be re-scoped or re-prioritized.

If your developers are working on the most important tasks, you’re clearing any blockers, the users are happy with the product, and the people with the budget believe they’re getting value for their money, that’s about the best you can get from any project management technique.

But, if you’re going to focus on metrics like completing 100% of your stories every sprint, all you’ll get is massively over-inflated estimates for every user story.