One of the greatest enemies of software is complexity, since it invariably leads to Software Entropy. It increases the cost of producing software. The good news is that we’ve gotten better over the decades at assuring best practices steer away from complexity – but sometimes people who implement the software processes themselves do not understand the why of things and create complexity in the software process itself – and even create new and interesting problems.
A simple thing like code reviews can be made complicated by different disciplines sharing the same space. Let’s say that you have code that uses stored procedures. Clearly, you’ll want a DBA doing the review of the stored procedure(s) and table changes – you might not want to call it a code review, but it is a review of a sort. Would you create a new column on your Agile board to track DBA reviews? I would hope not, if you’re using a decent tracking system. You can expect a DBA to make loud noises about them being so different, but if you take a step back… it’s just another type of review that can stay on the board without adding complexity to the board.
Further, differentiating that from the other reviews almost always assures that the code review and the review of the SQL related code is done separately – and since they will go into Production together, it would make sense that the reviews be synergistic. The Software Engineer and the DBA should review together, not separately, so that there are no assumptions made. The short term ‘gain’ of doing them separately results in a potential loss of quality.
How could it be done? Sure, the DBA needs to know to do the review, but that can be done by assigning two people to the review (a DBA and an Engineer) or creating two linked tickets for the same issue and making sure that the review is done at the same time. Simplify, simplify, simplify.
Simplify. It will take a little more time, but it will avoid quality issues – and keep your Agile process more simple.