Starting a scrum team for the first time, old lead dev has concerns about team skills
Hey everyone, we are going full in on Scrum for an upcoming project, but the existing waterfall team's lead dev has some concerns, primarily revolving around code reviews. I am trying to steer the conversation towards having peer code reviews but the concern is that we don't think the team has enough programming knowledge to execute these well enough. I think I am ok moving forward if we have a plan to make the entire team cross functional, but at the same time, I don't want a member of the team being an authority on how they should be doing things. I am thinking about how we can get there, and my initial thought is to have the current lead dev be a member of the team who performs "pair" code reviews with the team as they perform their peer code reviews. That sounds like an authority within the team though. I have also considered having this role be outside of the team and they can function like a trainer or a consultant, performing pair reviews. But I really worry about outside people influencing the team's work.
Any suggestions for this situation?
Have you asked the development team how they feel this could be done? One of the premise of "full in on Scrum" is that you are allowing the Scrum Team to make decisions as a group instead of having 1-2 people telling them how to work. You are still thinking in the command-control management style of waterfall. Scrum is a servant-leader model where the people doing the work are able to make decisions on how to do that work.
People new to Scrum will make mistakes. That is expected, and in some cases encouraged. The team needs to learn how to make decisions and what they need in order to be self-organizing and self-managing.
That sounds like an authority within the team though. I have also considered having this role be outside of the team and they can function like a trainer or a consultant, performing pair reviews. But I really worry about outside people influencing the team's work.
Also: what would that mean for the team's ability to create "Done", releasable increments of work?
My advice is not to focus quite so much, at this stage, on who does code reviews within the team. Instead, focus on ensuring that the team has a clear "Definition of Done" which is understood and genuinely of release quality, and that they can meet it.
Once the team demonstrate an ability to produce Done work each and every Sprint, you can optimize workflow. Put transparency over flow, including any bottlenecks. You might then have the evidence you need to highlight and remove a dependency on a particular team member for code reviews.
We are so early into this that I haven’t even met the team yet! I will be having a first meeting with them on Monday. But I agree that we should let this be the team’s decision, and if problems arise, we address them through retrospectives.
It’s going to be quite the shift for us to let teams self organize. I’ve been so cautious to make sure we are doing that that it seems I have ended up trying to direct organization! Thanks for the advice!
Keep in mind, especially when just starting out in Scrum, that it will not be perfect, it may in fact be pretty ugly, but the goal is to start, and then gradually improve over time.
If you're identifying any concerns or issues in your initial observations, file them away for now, and simply try to guide and educate the team on why Scrum may be a better way to work.
Good luck!