Recently I had a colleague that implemented a feature without being in the plan or discussed in detail but on his own time during the weekend. The feature was discussed briefly, it is a technical improvement, that is not complicated but requires a big number of changes and it does change the way of work in that area.

I appreciate his dedication to the project and he is a fairly good developer, even if that feature is not a state of the art is still good, and it will be reviewed by peers before adding it, but it feels wrong to appraise extra work time (can lead to burnout) for a feature that wasn't discussed in-deep technically (step required by our way of work agreement). On the other hand, I am afraid that a bad comment would cut out his enthusiasm.

So should we encourage, welcome or prevent these situations? How would a good approach look like?

  • Have you asked the dev why they felt compelled to go outside the normal work stream to get this done? IME people only do that if something is broken with the process. It’s certainly a project smell, but I would examine your own actions before examining theirs.
    – RubberDuck
    Commented May 1, 2018 at 16:15

3 Answers 3


His dedication, enthusiasm, or skills is not relevant. The only thing relevant is that a change was introduced without approvals. Controlling change and configuration are leading practices and changes out of control is an undesired practice. You don't have to analyze impacts because they are already well known.

Just teach your guy about change management. When he becomes a PM he'll be glad you did.

EDIT: I misread a couple of points in the OP, pointed out by @Rubberduck. In this case, I think while I like my original answer for a scope creep issue my answer for this specific OP needs to be different.

This developer chose to invest his own time for the betterment of your project. You must encourage this kind of behavior! This is how innovation works. You cannot plan for it, you cannot forecast it, you cannot predict it. When it happens, exploit it! Do not worry about burnout. We have a lot more bandwith than forty hours a week.

Sorry for my original answer. It was wholly incorrect for this situation.

  • 1
    But, thank you for providing a comment with the negative vote. That is lacking on this site and I think it encourages discussion and understanding. Commented May 1, 2018 at 11:38
  • 2
    There was no vote from me, I don't agree or disagree with it. Thank you even so for your response, it opens a few areas to look for a possible source of problem or solution. Commented May 1, 2018 at 14:07
  • 1
    Downvote from me for assuming the only possible career progressive for a dev is project mgmt. smh...
    – RubberDuck
    Commented May 1, 2018 at 16:17
  • 1
    Absolutely yes @StephanWeinhold. Also because the original question clearly states the feature wasn’t added to the mainline without any change management.
    – RubberDuck
    Commented May 1, 2018 at 16:24
  • 1
    @RubberDuck is correct: 1) I did make that assumption, which is certainly not always correct, but--in my defense--scope management should be taught to all types of practitioners, PM or otherwise; 2) I misread the OP, missing the peer review. This makes my answer, while correct in general IMHO, incorrect for this OP. I think I'll edit. Commented May 1, 2018 at 16:59

Puh, I've been through this several times. Some lone-wolf-developers can be hard nuts to crack.

Let's have a look how Scrum handles this: team members should be encouraged to write user stories - especially technical ones. And agile PM-methodologies also know the concept of a Story Owner. Plus thinking above the own tellerrand is in the vibe of DevOps. So I appreciate this kind of thinking in "traditional" PM too.
But seeing a potential improvement and to add this to the planning is a completely different thing than to implement new code in a cloak-and-dagger operation. This is against the team, against the software architecture, against the quality plan (at least I hope your quality plan says so) and against the PM. Plus chances are high it is gold plating.

So if I was you, I'd try to channel his enthusiasm. Give him the feeling that you trust him and that you trust his experience and skills. But also show him that there are guidelines that have to be followed. Make sure, there's a routine of how to add new features. And talk about such things openly and honest. If those lone-wolfs feel save and understood, they can become your most valuable team members.

  • And Scrum also knows the concept of a Story Owner. Please show, in the Scrum Guide, where Scrum talks about a Story Owner? The word "story" does not appear in the Guide. The Guide also states that the accountability for delivering work belongs to the team as a whole, not individuals.
    – Thomas Owens
    Commented May 2, 2018 at 9:47
  • 1
    @ThomasOwens I can edit this to "real life Scrum" - the Scrum Guide is way too religious for me. But basically you are right, yes. Thanks for the reference! Commented May 2, 2018 at 10:44

If lone wolf programmers can add features without review, then you have the possibility to save some serious money by firing everyone in your configuration control team. Seriously, there is no point to doing configuration management if you're not going to manage the configuration.

And while they are at it, they can save money by canning that developers management. Apparently that manager feels that it is OK for programmers to devote time to coding and installing whatever they feel like. Most companies are under the illusion that the company and the customer choose what will be deployed. But apparently this particular programmer's whim is more important than the priority of features chosen by the system owner/product owner. SO we can pink slip the product owner.

And if people can bypass your QA team, why pay them?

Objectively speaking, he is not a good developer - he is a rogue developer with no respect for his team, his management, or the long term health and welfare of the product. If he were my programmer, I'd call him into the office and shut the door an explain that either he works on the team, with the team and for the team, or he doesn't work on the team. - I'm happy to provide him the number of the unemployment office with his termination for cause letter and the legal paperwork that the company is preparing to file against the damage done to reputation.

Of course, I'm a jerk; most people would probably take a more constructive approach. I was trying to convey that this is largely tongue in cheek; this is not a constructive approach and will not solve the problem. I do think that the employee needs to understand the full implications of these actions, but this is not realistic or constructive.

  • I'm genuinely curious - do you take this tough approach always? Do you think it gives more results? As for the developer, he is a good guy, on daily work he follows the procedures, this time I think it was overexcitement and a need to stand-out. He wasn't going for a full rewrite of the application nor for a critical area in the end. Commented May 1, 2018 at 8:04

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.