2
3 Comments

Team: Everybody responsible for everything or each is responsible for his part ?

I've had a talk with friend who is a SCRUM coach and he says that every dev should be able to work on all parts of the product. E.g. GOLang dev should work on frontend, should do DevOps tasks, should work on PHP parts and etc. So that the responsibility is shared for everything and that there is no such situation that one dev is done with his part and waits for everybody else to finish or that the blame of something not working is being forwarded to other devs.

What everybody thinks of this ? Should we train GO devs, Frontend Devs, etc. to be all-in-one ? Or it is not a good idea ?

  1. 2

    In my experience it is ideal if two developers are actively working on a given part of a codebase, while a third one has latent knowledge.

    The latent knowledge can be acquired by being cc-d in code reviews and included in design discussions, for example.

    Responsibility is a different thing: it's better if exactly one of those active devs is responsible for the part of the code. Overly shared responsibility means no responsibility.

  2. 1

    I agree with all the points made by @Primer

    One thing I would add from my experience, is that usually the number of developers working cross discipline is inversely proportional to the quality of the code base.

    I have seen things get out of hand to the point where the code base was a breeding ground for conflicts, and new developers would run away screaming once they had to work with the code for a little while.

    In most cases, if everybody is responsible for everything, nobody will be held responsible for anything.

    Then again, if a single developer was responsible for the development and maintenance of a core module, and they unexpectedly leave the team, the consequences can be very expensive.

    Juggling these hurdles is more of an art form than a science, and you need competent management to keep things in check.

  3. 2

    This comment was deleted 4 years ago

    1. 1

      @Primer, yes, sorry, of course SCRUM.

      thanks, I like the explanations, because I was thinking in terms of my team, but I just don't see my front end devs doing backend stuff - they don't like it and therefore won't be good at it and dev-ops tasks - we have some complicated configurations, I would rather give them to experienced dev-op.