Do your team members actually agree that code reviews and unit testing are Good Things, just there is no time for these?
Or do they just try to reject the idea with this excuse?
In the first case, the solution is to Start Doing It Now. (OK, if you are in the last days before a major milestone, maybe you can wait until after - but no more.) We had that situation in a previous workplace of mine, where I was Quality Engineer, responsible for improving coding practices and overall quality. We kept deferring the start of code reviews till next week. One day I realized we have been doing this for a month or so, and probably will be continuing till the end of times unless I try something different. So I announced the first code review for that week. I told the guys "no problem if it will be imperfect, or if we don't exactly know what to do yet - we will just start doing it, see how it goes and improve things as we learn". It worked, at least until I left the company.
In the second case, you may need more education and open discussion with the team. Discuss code quality issues, ask them what they see as problems in the development process (or lack thereof) / in the code / testing etc. And brainstorm together about how to resolve these. The ultimate aim is not necessarily to do code reviews - they are just means, while the goal is to improve the development process and the quality of its output. It may well turn out that there are other, more painful issues which could be improved easier, bringing more benefit faster; then take these first. They can even be trivial changes in the environment or the process; all of these will improve team morale, build mutual trust and help the team bond.
The bottom line is, you can't force quality upon anyone - you can only remove the obstacles of creating quality. By enforcing strict rules and mandatory practices without prior team consensus, you may alienate the team and ultimately prevent the quality improvement you are aiming for. OTOH by open discussion and aiming for agreement on what the most pressing problems for the team are and how to improve the situation, you are more likely to get team support. This will make a crucial difference in keeping up the quality improvement drive in the long run.
There are a few things that code reviews can do for you, and some things they can't. The arguments in favor of code reviews:
- Collective ownership
- Find bugs (QC)
- Enforce consistent style (QA)
- Mentoring
Many agile processes tackle those in different ways:
- Collective Ownership: everyone on the team is responsible for the project, which means everyone's eyes will be on the code at any given time.
- Free to refactor: this takes code reviews to the next level, and allows anyone on the team to perform refactoring as necessary.
- Unit tests (QC): unit tests are more efficient and less prone to human error then visual inspection. In fact, I have yet to find a more efficient means.
- Pair programming (QA): takes care of mentoring and provides early refactoring advice as the code is written. This is also still a controversial topic, but I find it helps while ramping up a new developer. It's also a good time to enforce coding standards.
In essence there are other avenues of taking care of the potential gains you would normally have doing peer reviews. My personal experience with peer reviews is that they are very inefficient mechanisms and are not effective at finding bugs or larger design flaws. However, they do have their place in some teams, and on projects where agile is not feasible (for whatever reason), they are quite necessary.
Best Answer
Reviews are part of the work that needs to be done to bring a task to completion, just like implementation and testing. For that reason, the review effort should be included in the estimation for the task.
As you already have different states for implementation and testing, it makes sense to add an additional state to indicate that the code for a task is being reviewed.
On a side note, if you find that implemented tasks often can't be picked up immediately for review or testing (because the other team members are busy on other tasks), you might want to add kanban-like "waiting states" to your tasks, like "ready for review" and "ready for testing". This can make it clear if there might be a bottleneck in the review and/or test phases, by having a pile up of tasks in the "ready for" states. It also means that the one who wrote the code doesn't have to assign a reviewer/tester (or ask around for one), but anyone with a spare moment can pick up a pending review/test task.