I had a team of about 8 junior people. We would do a daily morning sync where we went over open tickets. The main purpose of the meeting was to see who was struggling with something and needed help.
In my experience junior people often wait too long to ask questions when they are stuck on something out of fear of looking bad. But if you are junior it is totally normal to not know a lot of things and thus get stuck frequently. If it is something that can be Google’d, sure let them learn to look, but often it is something internal to the company and they just need someone to point them in the right direction.
I would take note on who was having problems and call them throughout the day to unblock the situation. Sometimes I would invite 1 other person into the call to share some knowledge and preferably have them explain it to each other.
In general I would try to make these calls educational rather than just telling them the solution. You want to build up the team so they become more and more independent.
When major new topics came up (new feature, completely new use-case) I would organise a team meeting to discuss the topic and work out a design. I usually prepared these meetings to the point I more or less knew the design we wanted to go for because the team was very junior. This allowed me to led the team brainstorm and occasionally guide them or point out issues.
The key is that you want to try to facilitate rather than dictate. If you dictate too much they won’t learn or learn slowly.
Second, junior people often say they understand something without actually understanding it. Have them explain it back to you. But don’t be too critical when they get it slightly wrong, that can be demotivated.
Also try to pull involve individual team members into higher level discussions from time to time. I would sometimes invite someone to the architecture review meeting. This helps them gain perspective.
Finally I would do a meeting twice a year to discuss their progress and ask their feedback and how they are feeling in the team etc.
This mostly applies to a team full of juniors. I bootstrapped two junior teams this way.
> We would do a daily morning sync where we went over open tickets. The main purpose of the meeting was to see who was struggling with something and needed help.
Oh no, don't call it a "daily scrum" or the anti-Agile folks will descend on you like a pack of locusts :)
But that really works, it's easier to get people to ask for help or say they're stuck in person than over chat.
> But that really works, it's easier to get people to ask for help or say they're stuck in person than over chat.
Which is completely different from saying "daily syncs make it easier for people to ask for help or say they're stuck".
What you actually need for people to ask for help or say they are stuck is to make them feel safe and comfortable doing it. As a human, not as an agile guru. If one can't get there, maybe one needs to work on their human skills instead of adding bullshit agile processes.
In my experience junior people often wait too long to ask questions when they are stuck on something out of fear of looking bad. But if you are junior it is totally normal to not know a lot of things and thus get stuck frequently. If it is something that can be Google’d, sure let them learn to look, but often it is something internal to the company and they just need someone to point them in the right direction.
I would take note on who was having problems and call them throughout the day to unblock the situation. Sometimes I would invite 1 other person into the call to share some knowledge and preferably have them explain it to each other.
In general I would try to make these calls educational rather than just telling them the solution. You want to build up the team so they become more and more independent.
When major new topics came up (new feature, completely new use-case) I would organise a team meeting to discuss the topic and work out a design. I usually prepared these meetings to the point I more or less knew the design we wanted to go for because the team was very junior. This allowed me to led the team brainstorm and occasionally guide them or point out issues.
The key is that you want to try to facilitate rather than dictate. If you dictate too much they won’t learn or learn slowly.
Second, junior people often say they understand something without actually understanding it. Have them explain it back to you. But don’t be too critical when they get it slightly wrong, that can be demotivated.
Also try to pull involve individual team members into higher level discussions from time to time. I would sometimes invite someone to the architecture review meeting. This helps them gain perspective.
Finally I would do a meeting twice a year to discuss their progress and ask their feedback and how they are feeling in the team etc.
This mostly applies to a team full of juniors. I bootstrapped two junior teams this way.