We are just starting our Shape Up experiment, where a small part of the Scrum team separates and does a 8 weeks Shape Up cycle on their own. With this setup, we do not have enough front end engineers neither in the Scrum team nor in the Shape Up team to do a meaningful code review.
Cross team code reviews would introduce both, distractions during the cycle, when doing reviews and waiting on outside work, when receiving reviews.
How do people do code reviews with these very small Shape Up teams, which can not review their own code?
Or do you accept worse code reviews (e.g. by a backend or even a ux person) in order to keep the dependencies low?
We have a company policy, that every code has to be reviewed. So we can not skip this.
have the Scrum team review the Shape Up team’s PRs and vice versa
have the CTO review and approve everyone’s PRs
rotate daily or weekly: one front-end, one back-end on code review duty
use AI code reviewers to speed up code reviews
have 1 day per week where everyone does code reviews (but these might be an already merged PRs - not ideal)
push code reviews to the Cool Down phase (not ideal, as it’s better to review PRs right away)
This isn’t a Shape Up-specific issue anyway, usually the team lead reviews the PRs and approves merging them.
I think it’s most natural for Shape Up to think of this as reactive work, similar to bug fixing. Except if it’s a blocking PR, the submitter can do a self-review or use AI to code review without waiting for approval.
Also, under Shape Up, PRs will be much larger than in Scrum, and developers will have much more ownership of the code, so the code quality will be higher than in Scrum with its short sprints, developers working on unfamiliar code, when different developers working on the same code, and they close much smaller Jira tickets.
Thanks for your answer.
We are currently going with option 1.
AI reviews sounds interesting, but I guess until that works, it is still a long way to go.
The reason, I think this is a thing in shape up and not so much in scrum is the tiny team size, which does not lend itself for peer reviews within the team. You are right, if we were to do all reviews by a team lead, that would solve the problem. But we do practice peer reviews, and do not have a dedicated person for the reviews. Maybe a reviewer role could really be a (ungrateful) solution.
What makes you say, that the PRs would be larger in shape up? Do you do 6 weeks long living feature branches?
I guess I would not want to give up on trunk based development for shape up. If we had several shape up processes running in parallel, the merge at the end of the cycle would be deadly.
I am curious if your thesis holds, that code quality is higher in shape up. That would be cool.
What makes you say, that the PRs would be larger in shape up?
The vast majority of all feature development at Basecamp has a 1-1 relationship between a project and a pull request. This relationship provides all the tie-in necessary to match the work with the planning, at a coarse level that doesn’t rely on micro linking every individual piece together. (I’ll write another post about why I don’t fancy breaking up the work into multiple small pull requests per project.)
– DHH
I worked this way under RUP (Rational Unified Process) SDLC where every developer had an ownership of the feature from collecting requirements to design, development, testing and integration. We had a long-lived feature branches (from several weeks and up to 2 months), no individual commits, no issue trackers, no JIRA tickets (except for bugs). We only had peer code review in case of the show stoppers, otherwise team leads periodically reviewed the code of their team members. We used DVCS which unlike git allowed everyone to see even uncommited/unpushed changes.