Definitely formal process and roles definition. From how the team receives backlogs, development process, review process, testing process, release process up to bugs management.
If you’re a manager like myself, I suggest not to be involved into technical details too much e.g. about which CI/CD tools to use. Let the team decides how to do it in technical details while you decide what to do, i.e. the process itself and strategical stuffs.
I wouldn’t worry about defining banal ground rules such as meetings, evaluations etc. If you decide to have scrum most of these rules have been defined already and you only need to adjust the rules from time to time.
I agree with the technical details thing, though it is easy in days of such change (eg new team leader or reorganization) to have increased tension and change-everything attitude. We also tend to be a very opinionated clan of people :)
So how would you resolve such conflicts if consensus is not an option?
From how the team receives backlogs, development process, review process, testing process, release process up to bugs management.
That is so true.
I wouldn’t worry about defining banal ground rules such as meetings, evaluations, etc. If you decide to have scrum most of these rules have been defined already and you only need to adjust the rules from time to time.
Indeed for the meetings, I think evaluations though are still DIY in such frameworks though. Correct me if I am wrong
Here’s how I do it for my team. Every team member is free to give suggestions about tools, libraries, technologies, etc. If a team member wants to apply a tool/library for the whole team (e.g. CI/CD tool), then he/she must persuade other team members first. Then the team comes to me with the suggestion and justifications. I am the one that approve these tools/libraries before the team is allowed to use them. Ultimately I want to make sure that, among other things, 1) the licenses are fine 2) if it’s a paid product I have the budget for it 3) the tools/libraries are mature, stable and well supported and 4) if I need to replace the team member(s) I can find replacements easily.
If the team needs to decide on technologies but they can’t do it because occasionally they are such an opinionated bunch, then I will gladly make the decision for them based on my judgement.
Regarding evaluations, scrum has retrospective and review which in my experience are sufficient to evaluate the team’s performance. I don’t conduct yearly personal evaluation due to several reasons 1) it’s an outdated concept 2) a year is too long for an evaluation and 3) I evaluate my engineers when I need to address decrease in their performance and try to fix it ASAP before the performance decrease becomes a burden for the team.
How do you defend any raises or appraisal results in general to HR or high technical management? Depends on the company, of course, smaller companies tend to be more flexible here and others favor formality.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Definitely formal process and roles definition. From how the team receives backlogs, development process, review process, testing process, release process up to bugs management.
If you’re a manager like myself, I suggest not to be involved into technical details too much e.g. about which CI/CD tools to use. Let the team decides how to do it in technical details while you decide what to do, i.e. the process itself and strategical stuffs.
I wouldn’t worry about defining banal ground rules such as meetings, evaluations etc. If you decide to have scrum most of these rules have been defined already and you only need to adjust the rules from time to time.
I agree with the technical details thing, though it is easy in days of such change (eg new team leader or reorganization) to have increased tension and change-everything attitude. We also tend to be a very opinionated clan of people :)
So how would you resolve such conflicts if consensus is not an option?
From how the team receives backlogs, development process, review process, testing process, release process up to bugs management.That is so true.
I wouldn’t worry about defining banal ground rules such as meetings, evaluations, etc. If you decide to have scrum most of these rules have been defined already and you only need to adjust the rules from time to time.Indeed for the meetings, I think evaluations though are still DIY in such frameworks though. Correct me if I am wrong
Here’s how I do it for my team. Every team member is free to give suggestions about tools, libraries, technologies, etc. If a team member wants to apply a tool/library for the whole team (e.g. CI/CD tool), then he/she must persuade other team members first. Then the team comes to me with the suggestion and justifications. I am the one that approve these tools/libraries before the team is allowed to use them. Ultimately I want to make sure that, among other things, 1) the licenses are fine 2) if it’s a paid product I have the budget for it 3) the tools/libraries are mature, stable and well supported and 4) if I need to replace the team member(s) I can find replacements easily.
If the team needs to decide on technologies but they can’t do it because occasionally they are such an opinionated bunch, then I will gladly make the decision for them based on my judgement.
Regarding evaluations, scrum has retrospective and review which in my experience are sufficient to evaluate the team’s performance. I don’t conduct yearly personal evaluation due to several reasons 1) it’s an outdated concept 2) a year is too long for an evaluation and 3) I evaluate my engineers when I need to address decrease in their performance and try to fix it ASAP before the performance decrease becomes a burden for the team.
I like your approach the tech things.
How do you defend any raises or appraisal results in general to HR or high technical management? Depends on the company, of course, smaller companies tend to be more flexible here and others favor formality.