Skip to main content

Team member working ahead of sprint during off hours

Last post 06:49 pm February 24, 2023 by Trudy McCulloch
4 replies
06:42 pm February 23, 2023

I have a development team member who likes to work on the development of stories not yet in a sprint. He does this outside of normal working hours. Meanwhile there are tasks which are not complete in our current sprint. Because he's doing it during his own time I'm not sure how to approach this. To me it feels as though he's simply not committing to the completion of stories in our sprints. But, he says he just won't do the overtime if he's not allowed to work ahead. So more work is being done. But stories aren't necessarily being completed. And other developers end up having to do more testing while he barrels ahead with more development. As everybody in software development knows, developers don't like testing but the rest of the developers in the team do always step up and offer to take testing tasks when needed in order to finish stories within the sprint. This also hurts the morale of the developers who are always taking on testing tasks while this one developer doesn't.

Any suggestions on what to do?


01:04 am February 24, 2023

It's potentially a less creative and robust solution when only one person is working on it, and hence this overtime imay not really be doing anyone any favors.

How effectively does he collaborate with other Developers during the normal working day? Does he help with testing then, like the others apparently do? If not, I wonder if the overtime is some sort of attempt at providing compensation.

Anyway, the separation of testing from development is interesting. It doesn't sound as though the Developers are doing TDD/BDD as an essential agile hygiene, and they don't seem to require it for work to be Done. Why not?

 


12:23 pm February 24, 2023

No, we're not doing TDD. I'd love to but we just don't have enough people. Our dedicated QA person does start writing test cases at the very beginning of the sprint and works with the developers but we haven't moved to that among development. I'd like to move that direction for development but right now it's not what I'd like to focus on.

The rest of the team does work for Done. This is why developers do pick up testing. Everybody else in the team commits to completing our stories and does everything they can to do so. The only person who really only does one job other than this one guy is our QA person. When developers take on testing duties for stories she reviews test cases to be sure they're comprehensive enough for the scope of the change, often having already written test cases before the stories are ever at the stage of being deployed to our test region. No the stories aren't just thrown over the fence to her. She's often working closely with developers doing testing using the development region and providing feedback at that point in the story. Testing and development really do work as a partnership. But we can't always get things to Done because he doesn't pull his weight within the sprint. Everyone else does work their butts off to get things Done but I try very hard to keep an eye on their overtime because the guys in India would work 18 hour days if I didn't push them hard to log off for their own wellbeing.

He really doesn't collaborate with anybody but me. And really only when he doesn't have strong feelings about what should be done. I feel like he's throwing me a bone to be able to say he's collaborating and not just going off on his own to do his own thing. We do butt heads a lot when he goes off on his own, especially since he doesn't like to follow standards or even do anything any way but his own. No, he does not help with testing then. And frankly I don't actually believe him that he only does future work on his "own" time.

As for his overtime, I personally think it's just an excuse to do what he wants. I agree that his solutions are not as robust as they would be if he was collaborating more on the designs and approaches. Recently he went off and designed something for getting data to his old boss (another application within our company) and once it was thrown to the rest of the team the design had to be modified to be much more robust so that it could be beneficial to others. He found this tooth and nail. If he had just done the development himself it would not have been the best solution. I think this is what I need to focus on.

I was stewing over this last night and realized that I think I may have to try working with him and our boss to get agreement that he just won't do any overtime if that's the only way he won't work on stories which are not yet in our sprint.


03:39 pm February 24, 2023

But, he says he just won't do the overtime if he's not allowed to work ahead. So more work is being done.

I don't see a downside to him not doing the overtime.  In fact, it would probably be the best solution.  One of the goals of agility is to be able to consistently react to changes as they occur.  If he is coding on items in the backlog before they are selected for a Sprint, there is a distinct possibility that he may be doing the wrong work.  The information gained from the stakeholders during the Sprint Review could impact future work.  If you look at this from a Lean perspective, he is increasing the chances of wasted effort. 

So, take him at his word and ask him to stop working ahead. The "more work being done" may be doing more harm than good.


06:49 pm February 24, 2023

Sounds perfect! I'll try that. THANK YOU!


By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.