My team has problems pushing work items through all the stages in the Kanban board to done.
The work items hit code review and pile up and stay there for a long time. The following stage (the QA stage) is starved of work until suddenly everything is in QA and the testers have too much work instead of too little. The testers complain that they are expected to test all the sprint's work items the last day of the sprint. However it is worse than that. It is more like two or three sprints' worth of work items on the last day.
Our scrum master says that the work items are too big, and wants to break the items down further.
Our Manager says that team members need to review each other's code more quickly and more frequently.
Our Team Leader (me) says that there is too much work in progress and we need to enforce column limits at each stage.
The bigger problem is that solving the three above smaller problems is necessary but not sufficient in order to change the outcome. The way the team treats collections of work items as indivisible renders the other problems moot.
The team is divided between the old guard and the new guard. The old guard has been with the company more than ten years and the new guard less than one year. While the new guard breaks work into smaller pieces and pushes each work item though the pipeline one at a time, the old guard refuses to move work items from review to QA until all items in the same epic have been reviewed. Worse they refuse to merge their code into the main branch until they are ready to move their items to QA, this causes merge hell when everyone's code is integrated into the main branch and errors are frequently introduced during the merging process.
The old guard is resistant to changing to a process with more flow. They complain bitterly about the new guard, saying that they are not doing things the right way. Complaining that the way the new guard frequently merges their code makes it difficult for the old guard to integrate their code into the main branch without merge conflicts. They also complain that in depth review is impossible without reviewing the entire epic as a whole. They also complain that they can not release the software if it contains a partially completed epic that is merged into the main branch.
The old guard have reached a local efficiency maximum of sorts where any small change will make things worse and only radical change will help. To improve the outcome there needs to be a lot short term pain for a lot of long term gain and I don't see a lot of appetite for paying that price.
Personally I prefer timely piecemeal feedback from reviewers and QA over delayed comprehensive feedback. I am also skeptical about how in-depth their epic wide feedback will be as my experience so far is that the feedback is poorer and more delayed the larger the pull request.
The merge problems are worse the longer the branches are kept unintegrated. I know a lot techniques to break dependencies and to keep new features hidden from customers, however all of those techniques are based on the new guard way of doing things. I don't know anything that will help if they want to keep doing things the old guard way.
I have made a lot of small incremental changes to how the team does things. However I have run out of small things. Real improvement is going to require bigger changes.
I feel the biggest blocker is the insistence on getting all of an epic reviewed before merging to the main branch. And the biggest blocker to changing this is fear of delayed releases due to partial completed features.
So which is better: large feature branches or merging frequently? Are there any arguments pro or con that I missed? Is there any way out of my dilemma?
The pushback from the old guard against my changes is significant. There is support from on high for some of their arguments.