2

I think DevOps defines the best practices here: specifically the principle of small batch sizes. In other words, if the batch sizes (code commits) are small, then the code reviews can be frequent and short. I would live with the frequency because that's more of an Agile thing and it's OK! Build a team culture that supports it. DevOps also tells us to ...


2

I suspect there is no single answer to this question. Individuals are different. Some may find that doing a code review is a welcome distraction from their coding tasks. Others may struggle with the context switching or may not enjoy doing reviews. Teams are also different. I can see the nature of code reviews varying depending on many factors including: ...


2

Scrum intentionally does not layout exactly how the team will build the product. There are a number of reasons, but most pertinent to this question is that what works for one team may not work for another. Similarly, what works with the tools of the early 2000's may not apply as well today. One of the reasons we work in iterations is because it gives us ...


2

It depends. It's important to realize that Kanban doesn't have anything to say about code reviews. It's simply a set of tools for visualizing and improving the workflow and flow of work through a workflow. There are a few key concepts - the Kanban board which provides a visualization of the workflow, work on the board, work-in-progress (WIP) limits, work ...


Only top voted, non community-wiki answers of a minimum length are eligible