A group of mostly junior developers
Hi Everyone,
I am curious about your thoughts about this. I am currently a Scrum Master / Coach to one development team. Soon to be two. I have been a Coach/Scrum master for many years and have learned a lot, but of course there is always more to learn as one thing I have learned is " No two companies are the same and no two development teams are the same" What works for one does not neccessarly work for the other.
My current setup is this 1 Senior Dev/Architect , 3 Junior Devs and 1 intermediat. we are doing scrum and I puroposly did not fully enforce the process in order not to turn the juniors off.
The junior ones are so eager to develop that they forget to do things properly. The Senior dev was overloaded helping them all over the place , so I decided to hold off with enforcing fully processes etc..
Now I see some of the things that are back firing, like communication. Outside of the daily, non exsistant. I had to do a quick session before the daily to explain to them the importance of Transparency in scrum, and why using the team chat is so important. (I even had to explain to them that it is so important to accept meeting invitations :) ) .
I have to admit , two things that I am puzzeled by: 1- Home office and lack of communication which directly effects 2- Junior developers and how to get them stay motivated and at the same stay connected .
and the icing on the cake is that the environment is a German Speaking one which makes it a bit of challenge understanding everything :)
I would love to hear what your thoughts are on this. How to deal with Homeoffice, increase communication without sounding a bit bossy. (How I do it right now is through a series of 1 on 1 and direct chat messages which I feel are not enough.. Once voice inside of me says relax it takes time and the other says, hey you are failing :)
Thanks in advance..
...I decided to hold off with enforcing fully processes etc..
Now I see some of the things that are back firing, like communication.
That's right. The decision not to apply Scrum well means that transparency over these issues, along with awareness of the challenge being faced, is reduced. That's all you really get out of this sort of compromise. The belief that Scrum is too hard is an illusion. It's the problems Scrum makes people acknowledge which are difficult.
If it's any consolation, transparency is not yours to enforce anyhow. What you can do as a Scrum Master is to shine a light and wonder about what you see.
@Ian Mitchell is absolutely correct. Especially about this not being your issues to enforce a solution.
If the team feels there is a problem, help them solve it. You can suggest ideas but you shouldn't force them on the team. Often what you see is not the problem but symptoms of the problem. Have the team discuss their ideas or pain points. Let them decide which are more important to address. Facilitate the discussions and help them realize that they have to try something in order to determine if it is right. Explain the "disagree but support" philosophy to encourage them to try different approaches. Iterate on the solution.
For example, you said you Sr Dev is overloaded from the Jr Devs needing help. Maybe the Jr Devs didn't realize this was happening. Has anyone suggested that the Jr Devs work together more before approaching the Sr Dev? It might take longer to get to a solution but it is helping them to grow. Has the Sr Dev thought of doing pairing sessions with two or more of the Jr Devs at the same time? Does the Sr Dev always fix the Jr Devs problems or do they help the Jr Devs to learn? All of these are common behavior but not always the best behavior.
In the remote world of today, people have to become more comfortable with digital discussions. We use team channels on our messaging app. These channels are the first place people will post questions so that anyone on the team can help. This is encouraged over direct messages. In a team channel, others can learn from something that they haven't encountered yet. We use a lot of video conferencing and pair programming. You have to find ways to replicate the things that people liked about sitting in an office together. To do that, you have to know what they liked. Again help them solve the problem and do not try to force a "fix" on them.