Core Roles in Scrum
What are the key roles that should be in a Scrum team?
Scrum defines only three core roles for the framework.
A Product Owner, whose role is somewhat of an amalgamation of a traditional Product Manager and a Project Sponsor, but has a lot more interaction with the Development Team than a more traditional role would require.
A Scrum Master, who is the process referee that ensures that the methodology is followed. A Scrum Master is also responsible for coaching the team and the organization on how to make the most of Scrum's processes and artifacts.
The scrum master acts as a coach, guiding the team to ever-higher levels of cohesiveness, self-organization, and performance. While a team’s deliverable is the product, a scrum master’s deliverable is the self-organizing team.
Sims, Chris; Johnson, Hillary Louise (2011-02-15). The Elements of Scrum (p. 74). Dymaxicon. Kindle Edition.
A Development Team, which is a cohesive, self-organizing, cross-functional group that contains all the skills necessary to deliver on the project goals.
Scrum teams are highly collaborative; they are also self-organizing. Team members have total authority over how the work gets done. The team alone decides which tools and techniques to use, and which team members will work on which tasks.
Sims, Chris; Johnson, Hillary Louise (2011-02-15). The Elements of Scrum (Kindle Locations 976-978). Dymaxicon. Kindle Edition.
Code Reviews
Who conducts the code reviews in a Scrum team?
Code reviews are a practice, not a framework requirement, and not one that is universally embraced. For example, see Code Reviews Considered Hurtful.
Nevertheless, some Scrum teams do adopt code reviews, either because they are identified as helpful during a Sprint Retrospective or because they are required by the parent organization. Unless the parent organization provides a mandate, how code reviews are handled are an issue for a self-organizing development team to work out for themselves.
Ultimately, the goal is high-quality, maintainable code. If the development team finds code reviews helpful in meeting their accepted "definition of done," that's great. If not, perhaps test-driven development or some other practice will work equally well (or better!) for a particular team.
Your job isn't to task someone with doing code reviews; your job is to referee the process to ensure that the team is continuously inspecting and adapting its practices.
Titles for Development Team Members
Do Scrum Teams have a role called team lead, and tech lead?
The Scrum framework promotes collective code ownership, and the team succeeds or fails as a group. As a result, titles that differentiate team members are antithetical to the tenets of Scrum, although they are nevertheless used by the parent organization in job descriptions and Human Resources files.
Look at it this way: if you designate Bob as the team lead, then you are assigning responsibility for specific deliverables to Bob. Why should Alice take on Bob's responsibilities?
Likewise, if you formally make Alice "the QA person," why should Alice take collective ownership of code or work on architecture stories? Doubtless she was brought into the team to ensure that there was some specialized QA knowledge available to the team, but "cross-functional" doesn't mean siloed responsibilities within the project.
Team members will have titles within the organization, which occasionally reflect the skills they bring to a project team. However, it's up to the team to self-organize and distribute responsibility within the team. As a Scrum Master, you should only step in if it's obvious that the team is failing to self-organize--which you measure by whether or not the team is meeting its Sprint Goals and the "definition of done."
Assigning leadership roles within the team is not an agile practice, and is certainly not Scrum. If you find yourself in a position where this is necessary, then you should certainly revisit your overall process, and try to identify what is impeding the self-organization of the Development Team.