2

I'm working as a part of a team, I'm a backend developer. I work with two front-end developers.

Last three sprints we missed delivery on things that were related to the front-end.

My work is usually (not always) without problem and finished on time by end of the sprint. So much so I have time for refactoring, fine-tuning testing data sets, and some other nice-to-have maintenance tasks.

I really put myself into my work and if I can I always go the extra mile. However I don't feel the same from my front end developers, they don't care too much, and are quick to blame when there is an issue and overall I'm not satisfied with their work (I have worked on frontend projects before and I know what good UX looks like - you have to care and work from your own initiative and have to fine-tune every little detail).

When I count lines of code it supports my hunch they just don't do much. Last sprint reflecting on this I offered my help to work on the front-end so as to not jeopardize our roadmap and keep the project on schedule, but my offer was declined and created tension within the team.

Normally I would mind my own business but this starts to affect my motivation and is really anticlimactic to see we are missing one delivery after another. I would like to bring this up on our next retrospective but I'm afraid I would be too harsh and unfair.

Can someone please share what are DOs and DON'Ts when talking about this sensitive topic?

Improve this question
3
  • 6
    One Don't: basing anything on lines-of-code.
    – jcm
    Apr 25 at 4:53
  • 1
    Who is your manager, is she sitting with the team? You mention sprints, are you using scrum? Since you did front-end development before, are you able to pick up front-end tasks?
    – Helena
    Apr 25 at 8:52
  • 1
    "Going the extra mile" sounds like "voluntarily" doing overtime. Don't go there unless you must.
    – Thorbjørn Ravn Andersen
    Apr 26 at 11:00
14

Take blame out of the picture. It's a thief, an excuse. Foster the entire team in the blame, "if one of us, then all of us". Then move into solution mode. Ask questions that don't point fingers:

This feature was missed. What could I have done to help get it across the line?

We're missing features regularly. Are we planning too aggressively?

Always bring the conversation back to a focus of "we". As a team you are all accountable to successful delivery. So as a team the solution should be found. Avoid using directional language like "you", "your", "yours". Focus on plurality such as "we", "our".

Take the people out of the problem. If someone mentions a name, discard it visibly.

Let's not worry about George. What was the element that was missing and created a problem.

People are rarely the problem. It's what we expect of people's actions that ends up creating those kinds of problems. Focusing on the problem itself rather than the person involved is a much more difficult concept than it sounds like. It will take practice.

Always be attentive to the end goal of "what are we doing about it?" Is not acceptable just to see a problem and do nothing. What is the team doing about it? Everyone has a part in the team's success, and that means everyone gets an action item as a result of every solution.

Improve this answer
4
  • 4
    "People are rarely the problem." I'd like to believe that. I really do. Unfortunately, it doesn't match my experience in the software development world. I've seen too often how replacing a bad, non-caring developer with a good, caring developer in a project suddenly and miraculously makes all problems disappear that needed "managing" before.
    – Heinzi
    Apr 25 at 18:19
  • 1
    @Heinzi: I think if you examine that a little more closely, you'll see that your expectations were the problem. The person is just a person. You expected someone to be better and more caring than they were. I agree that I would prefer to have someone who meets those expectations without any managing, and that's not really the world that we live in. If you adjust your expectations or manage to them, the person stops being the problem and you can make real progress.
    – Joel Etherton
    Apr 25 at 18:41
  • Hmmm... food for thought. Thanks, I'll ponder on that.
    – Heinzi
    Apr 25 at 21:04
  • @Heinzi That assumes you have another developer standing by ready for replacement. In this case that may not be an option - you have those people you have.
    – Thorbjørn Ravn Andersen
    Apr 26 at 11:03

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .