Scrum: how to integrate work done by an overachieving developer out of band?

Question

We have a "typical" SCRUM team and we commit to work for a sprint, and also maintain a backlog. Recently we have run into a problem of trying to integrate/handle the work of an overachieving developer doing out of band work (choosing to work outside of the normal working hours/sprint).

To give an example, if the team takes in 50 points of work, let's say that they will complete all that work within the SCRUM framework by the end of the sprint and they and the company is happy. One of the team members decides to work on their own, on a backlog item, on their own free time. They do not check in this work, but instead save it (we use TFS and it is in a shelveset).

How to handle this? A few of the problems ..

• During the next sprint this team members says the programming work is 99% done and just needs code review and testing. How do you deal with this in the SCRUM and agile methodology?
• Other developers complain about not being involved in design decisions related to these stories, since the work was done out of band.
• Our product owner is tempted to pull in this "free" work and the overachieving members is likely doing this on purpose in order to get more features into the product that the team otherwise would not be able to accomplish in the sprint(s). There is a view that this is breaking the "process". Obviously QA, UI and documentation work still need to be done on this work.

I see a lot of discussion about not forcing a SCRUM team to work overtime, but what about a member of the team working above and beyond the expectations put forth during planning and execution of sprints? I would hesitate to reign this person in and say you cannot work extra (cautioning on burn out of course), but at the same time it seems to be causing some issues with certain members of the team (but not all).

How to integrate work done by an overachieving member into the SCRUM and agile process for software development?

Answer 1

Alright, so someone's enthusiastically writing great code that needs to be done, just not in order. With all due emphasis:

LET THEM

It's causing some complications in your scrum sprints. Does it really matter in the grand scheme of things? If he's accomplishing what he's supposed to, then let him go on and build great things for you.

I know several amazing programmers who have left companies because they did not let the programmers outside of the constraints of an artificial system like Scrum (I myself left my last job after being treated like nothing more than glorified QA). If there are complaints from other developers about input (perfectly valid complaints, I may add), it may be best to introduce a "20% time" program to let him (and others) do what they do best with minimal interference.

Instead of future stories (that may require input from others), let the developer experiment with new tech or features. You may find a great new opportunity that never would have been explored otherwise. I'm sure this developer has a few things they'd like to try out if you just let them.

Answer 2

There are two things I think you should consider here:

1. Don't hinder someone's creative flow.
   • If a dev wants to do out-of-hours work, then let them.
2. Don't create work for others.
   • If a dev wants to do out-of-hours work, it sure as hell better not be creating more work for others.

Point 2 is likely what the other developers are worried about.

Like you mentioned, they don't like the fact that the code is written without the entire team's input. This may be because, in terms of design, it ends up being inferior. And code with inferior design has a way of infecting other code around it.

So, what can you do?

Let the ambitious dev code to his heart's content, but make it clear that there is no reason to assume his extracurricular code will be used.

After all, he is part of a team, and so the team should be involved in how all code is developed.

If, however, his work is sound and fits in with the team's agreed upon design then he'll be able to use much of what he's already written (bonus!). If not, it'll force him to think more about his design the next time he decides to get a head start.

This way, nobody gets told NO, and nobody has extra work created for them.

Answer 3

Get him back into the team

You should ask yourself (or better the team, including the overachiever):

Why is this behavior a problem?

Since you label the developer as a overachiever I guess his work is of good quality, so I gonna assume this isn't a problem.

But there seem to other problems:

• The extra work is not tested properly
• it is not documented
• the rest of the team doesn't know it
• the developer decides on the next thing to implement, not the PO
• the developer doesn't get any feedback from the various stakeholders to incorporate in his work.

The next Why I would as is:

Why does the developer do it?

• If at the end of the sprint isn't enough work left, there should be a team decision (including the PO) about what to tackle next. Why does the developer avoid this decision?

Once you have answer to these questions you can start answering your own question:

• if it isn't a problem, let him do his thing. Although some people treat SCRUM as a religion, it shouldn't be like this.
• More likely you have two problems in the team: the one(s) caused by the rogue developer and the one(s) triggering the behavior of the rogue developer. Find a way to solve the later and the first one will go away.

Answer 4

Much as I like the idea that adding free work into the mix is a good thing, this isn't free work - not unless that single developer is also the tester, and the QA and the build guy and the designer and everything else. If his work can be put into the next sprint without any impact, then.. go for it. But I think that is never the case. Everyone else, at the very least, has to understand what he's done and what impact it has on them. They have to understand that his changes are in and so not to duplicate his efforts - its hard to tell someone they've worked hard on a task only to find the rogue guy did it last week.

You're working in an agile environment though, and one thing I do know about agile is that it is designed to work for you, not against you. So you need to change the way you work to allow this kind of extra-curricular activity to happen. That means getting everyone's input and agreement, you cannot do this without their buy-in. Its vital. If the team doesn't like it, then the rogue guy stops doing it. End of. It isn't one guy doing what he likes, no matter how good his work might be, its a team effort all the way. The team comes first.

So you need to sit everyone down at the next planning meeting and discuss this, all team members need to decide to allow it, or to change your process to manage this kind of activity better.

Maybe you'll get a solution where everyone works on their favoured projects and brings them to the table (you can imagine the chaos to your delivery that'd cause :) which highlights the problem with it in the first place) or you can mandate area where each dev has automomy to develop whatever solution they like that is the 'contributed' similarly to how many open source projects work, or you can give everyone some free time to experiment (the old 20% time).

Answer 5

Does this developer write tests and clean/solid code or is he/she just pushing out whatever he can get done quickly? I personally wouldn't allow anyone to work outside of the defined hours as it will mess up your estimates and as you pointed out other issues occur.

However, you should never be rigid in your process. Scrum is just a framework so you can always adjust the process to include the extra time (but again its difficult to plan for what someone might do).

You could also ask him to work on things other than the project. Looking at new tech or creating training on things he does differently. Bottom line though is anything done outside your planned schedule will destroy you estimates and I wouldn't let that happen.

Answer 6

we faced with same thing as well, basically we committed something like 20 points but at last week or even middle of sprint we ran out of coding task however because of Testing and rest of process we didn't risk to pick another PBI, So what programmers did was to to look into the backlog and start developing future PBIs (silently!) and informing the rest of team in planning that PBI is ready for code review and testing! just like you said.

It actually raised some concern from our POs that it seems we are capable more but we don't fully utilize our team's potential, which was partly true but yes, maybe our programmers could do more but our testers couldn't follow up that speed so there was a risk to fail the sprint. after thinking about this issue we found out that we need to change our view about scrum and the main issue is that people don't want to take that risk is because we Commit PBIs so team didn't feel good to take that risk of picking new PBIs in case that we have free programmer.

Simply we started to Forecast PBIs rather than make commitment. Forecasting basically means we pick 25 points at planning and start of sprint, And when programmer gets free at middle of sprint, because there is no more coding task so he/she picks one of the future PBI and put it in Current Sprint and start working on it, if the PBI could pass all of the process(testing, merging and etc) within same sprint, it is bonus point for team if NOT we don't fail the sprint because of that PBI and just carrying forward the remaining work(testing or meging or etc) to the next sprint and re poker for remaining job. So it can be done in two different sprint in worse case scenario. I know it might sounds like Scrumbut but it actually improved the way that we work. I just can summarize its benefits as below:

• It defeats the phobia of failing sprint because of taking the risk of taking more PBI
• It makes the extra work of your programmers and team visible
• It increases your team velocity

However maybe for a team with less experience, maybe it reduce the push that commitment gives to the team to finish the PBIs

Answer 7

Some of the other answers have suggested that the "overachieving" developer is "rogue" or "violating the principles of Scrum". This is incorrect and this developer should be encouraged (although you should not ask people to work on anything specific in this extra time, but you could make suggestions and help foster ideas).

There is nothing in Scrum to prescribe how people work and anything extra he did would naturally be incorporated into the velocity of the team.

His work should be brought in to the product backlog and estimated in the next planning meeting. If you can't predict what the remaining effort is straight away you should time box some time of the sprint to figure it out (that is, a Spike).

Interesting you describe the developer as "overachieving", I assume this means he is adding a lot more value than the other team members.

The difficulties doing extra work creates implies there is something sub-optimal (or maybe even dysfunctional) in your team.

If this is the case, you should ask yourself why is he achieving so much more, with presumably only a little bit of extra effort?

Is it possible for you enable the rest of the team to achieve more?

I've seen the situation where teams have been micro-managed, potentially over prescriptive user stories, definition of done, which ends up being stifling to developers. Is this developer doing the work that he wants to? I'm assuming he is making good decisions. Would working this way in the working week help the rest of the team too?

Answer 8

Have them also be a teacher

It is great that you have a star developer with the best and most advanced skills in the group. I would praise and compliment this. Often such folks are the 'glue' that hold organizations together.

I would view the challenge as 'how to get less experienced developers closer to the productivity of the most advanced developer'.

One great way to do this is to focus on getting the star developer to spend more time teaching, training and guiding the less experienced and slower team members. I would first discuss this in a 1-to-1 with the star developer so they know what you are doing and why. Other wise it may be viewed with suspicion as a hidden agenda / poor managment

When you do standups, once or twice a day, if this person runs out of work and others are still doing tasks, look to pair-programming so that she can pair with the junior members and impart her great knowledge and experience. Make sure to ask the question "does anyone need help? Is anyone looking for a pair?"

You could also find some 'side' work for the best developer for when they are out of work, such as enhancing the toolset being used by all, running a technical book club discussion group or being involved in other organizational projects.

Answer 9

I'm going to answer a different question. I think how to deal with this situation in Scrum is really not important. Scrum is more like a guideline anyway. If you want this to happen find a simple way to adapt your process like simply assuming the work is already done.

The real question is whether you want this dev to do what he is doing. I think several aspects play a key role in the answer to that question:

1. Is the programmer doing good work.
2. Is everybody okay with him doing his work on his own (be it good or bad). He is dodging the design process, after all!
3. Are the extra hours paid or not.

All of these influence whether it makes sense for your product that he is doing what he is doing. Again, incorporating your decision in the design process is not really an issue. Just be flexible.

Answer 10

This violates a tenant of Scrum because the team is not deciding the work in the sprint. This is a scrum team. The team needs to discipline this programmer if discipline is to be handed out.

Another issue this creates is that it screws with the team's velocity. Out of band work does not count towards velocity and burn down. So, this out of band work gets done, the team is averaging 50 points in velocity, but more than 50 points gets done. The product owner will see this and demand higher velocity in the next sprint. Velocity that might not be possible.

The team (not the PO or the ScrumMaster) needs to address this with the rogue programmer.