Issues can arise when you are not willing to change. There is a positive side to this, as it can be effective to maintain the status quo when a system is working. However, when the environment changes, it is important to be willing to abandon processes that are no longer effective, and create new ones that are effective.

A common issue is when transitioning to a new coding environment, team members often maintain the coding style and conventions from the previous environment. This is part inertia and part stubborn refusal to embrace a new way of doing things.

Often the case is that a team member is attached to a specific way of doing things. Normal work tasks are no problem, but it becomes very difficult to improve the work processes. Over time as unresolved issues in the workflow stack on top of each other, and it becomes exponentially harder to add new features and more and more time is spent doing trivial bug fixes.

If about 70% of your time is spent on bug fixes, it could be possible that you are trapped in a low level fix-as-fail (reactionary bug fix) loop. You can break out of this loop by moving up to a prevention loop (prevent the bugs from happening), then a fix-the-root-cause loop (fix the root issues that are generating the bugs) then finally to an anticipation loop (anticipate what is going to happen and setup processes to avoid bugs before they occur).