Is it OK for a Scrum Master to allow a developer to work on a story not prioritized by the Product Owner, if it is on own time?

Question

Here is the story (no pun intended):

1. The Product Owner had a fairly common feature prioritized in the second sprint.
2. It was estimated with low story points.
3. The story was completed and in testing the team discovered that it didn't work as required for one class of users.
4. The developer who did the work thought it was a permissions issue and should be fairly easy to fix.
5. We logged a bug and prioritized it in the third sprint. It appeared to be a problem with the open source framework we are using. Developer tried installing some patches that appeared could be related. Didn't help.
6. The Product Owner agreed to carry the bug to the fourth sprint at the request of the developer, however with a low priority. On seeing more time being wasted on it, the Product Owner moved it to the backlog.
7. Now we are in the sixth and final sprint and getting the product ready for beta release. The developer, who is highly skilled and very committed, reported that he intends spending own time looking for a solution. Looks like it has become a prestige issue for him.

As the Scrum Master, I told the developer to stop working on anything not prioritized by the Product Owner regardless whether own time or not.

Answer 1

TL;DR

I told the developer to stop working on anything not prioritized by the Product Owner regardless whether own time or not.

From a framework point of view, this is likely to be the correct approach. It's certainly what I would recommend as an organizational statement of policy. It reinforces Scrum processes and practices (e.g. time-boxing), and reduces risks to the organization, the team, and the developer himself.

However, from a psychological point of view, the correct team-management answer is less clear. A person's personality and drives, as well as his individual requirements for remaining tightly engaged in a project, need to be balanced in terms of the overall benefits to both him and the project as a whole.

What follows is an examination of some of the benefits and risks associated with allowing off-the-clock work. It is certainly not exhaustive, but should provide a solid starting point for your own risk/reward analysis. Your mileage will definitely vary.

Benefits

There are a few potential benefits to letting the developer work on something he's passionate about in his own free time. These may include:

1. Supporting his passions.

   Many knowledge workers value personal achievement, pride in their work, and the approbation of their peers at least as much as they value a paycheck. Supporting these values can be good for individual and team morale.

2. Personal growth.

   Encouraging developers to grow as programmers by expanding their knowledge of programming techniques solving problems they find interesting may lead to improved code quality and new insights for the team. Doing this outside working hours costs the company nothing, financially.

3. Individual investment.

   Someone who feels passionately enough about a service or product to work on it on his own time is likely to be more engaged than someone who just wants to show up every day and collect a paycheck.

4. Product quality.

   People who are passionate about their work may be inspired during through their off-hours activities, whether or not those activities are directly related to the project. The project can certainly benefit from such inspiration, and (barring any risks as detailed below) such contributions may improve the overall value or quality of the team's product.

In short, caring about one's work or about a project that consumes close to 40% of one's waking life is generally a Good Thing™. On its face, there would seem to be few reasons to discourage this, but the potential upsides should be carefully balanced against the potential downsides for all involved.

Risks to the Team

The risk to the team is that it may encourage the organization to think about non-billable hours as available for their estimates. Scrum is specifically about setting a sustainable pace within time-boxed iterations, so work that occurs outside the time-box skews the metrics and sets unsustainable expectations for the team.

In addition, it risks confusion about some core agile principles such as:

1. Time-boxing. Something is either done or not-done within a time-box, and you don't want to set the precedent that time-boxes can be disregarded.
2. YAGNI. If the feature isn't part of the current Sprint, and isn't important enough to the project to be a priority on the Product Backlog, then it isn't important enough to expend resources on. Even if it's just the developer's personal resources, working on YAGNI items sets a bad precedent for the team. It may also reduce respect for the Product Owner's essential role in setting project priorities.

Risks to the Organization

While unlikely to be a significant legal problem with the one-sided, work-for-hire contracts most IT workers sign these days, it's still a bad precedent to accept unpaid, private work into a commercial code base that isn't under an open-source license. You might want to consult your legal department about this, but it just seems like a Bad Idea™ to me.

Risks to the Developer

The developer himself runs a few risks here. In particular:

1. He risks developing bad habits related to time-boxing and sustainable cadence.
2. He risks a poor work/life balance that makes sustainable pacing at work more difficult.
3. He risks losing sight of the collective ownership of the code by thinking of portions of the code as "his."
4. He risks identifying with the code quality of his contributions, rather than with the ability of the team to deliver value within a time-box.

Answer 2

That's an interesting situation you describe there!

Obviously, you cannot deny the developer to search for a solution in his free time. However, there has to be a clear separation between his free-time work and the project. If he works on the project's code, trying/integrating a solution, the separation is not clear anymore. This is a problem you, as the Scrum Master, need to prevent.

I experienced a similar situation not to long ago: I worked in a student team on a 1-year-project. We used Scrum. One colleague was really into finding an elegant solution for the bootstrapping logic of our program. Despite our "working solution", he spent more time to implement an even better one; out of personal interest. It turned out to be more complicated than he anticipated, but since he already invested a lot of time, he kept spending more and more. In the end, this effectively reduced his working time, because after he spend much time on the issue, he wouldn't work on something else that long. He intended to separate the tasks, but he didn't manage to do that, because somewhere in his head working on the project still was working on the project.

So much for the risk. End of the story is: the developer turned up with a very elegant solution that saved us a lot of work since that day. Don't know if as much as he spent, but, in the end, some might say it was worth it.

However, the difference between my project and yours is that we were students, while you are employees. It maybe that this makes the separation easier, but in my eyes it also makes it more important. Especially if the PO already gave you additional time (multiple times) for the issue and you weren't able to fix it. If it's a corner case to him that's not worth further effort, than this is his decision to make. Developers tend to have a different view on such things, especially if their personal pride is involved. But it's the PO's decision. The team has to accept that. Period.

If he wants to figure out a workaround for the bug in the open-source framework, he's free to do that at home, in his own setup. He should not work on it from the company, nor using the project's code. If he should come up with a solution and still be interested in integrating it, you can talk to the PO again. Then you can tell him it will be so and so much effort and you know it, because your developer actually already tried it and it worked. If it's not too much work, I'm pretty sure the PO will accept the change. After all, he want's a robust product.

Hope this helps somewhat.

Answer 3

As the Scrum Master, I told the developer to stop working on anything not prioritized by the Product Owner regardless whether own time or not.

This is an awful approach, and smacks of a lack of managing acumen. It's possible that he should not be working on it, but it's also possible that he should. Instead of dictating how to move forward, you need to open a dialog that integrates developer feedback into the sprints.

If you don't do this, the better developers will leave. As the developers who remain become more and more skilled they too will leave, and you'll be left with high turnover, training overhead, and mediocre developers.

Answer 4

This is an awkward situation. I really liked the TL;DR answer, and agree completely with everything under the benefits - supporting passions, personal growth, individual investment, and product quality.

The risks to the team could be easily mitigated by having a team meeting to discuss the desire of this team member. That way, everyone on the team has a chance to voice either support or concern over this. If the decision is to go for it, the team as a whole accepts the risks. If it's no go, that decision is handed down by the team, not by you, possibly avoiding more focused resentment.

Additionally, if the task has been removed from any active sprints and pushed to the bottom of the backlog, what about removing it from the backlog, or resizing it to 0, so as not to affect velocity? It could set a bad precedent, but it could be a way to pull the story in without impacting velocity and sustainability.