Work in software development is made up of 2 essential parts: planning and doing. It stands true for any methodology, be it agile or lean or any other variety thereof. The theory of project management has it, that a project can accommodate 10-20% of time spent on planning, tracking, adjusting trajectory, wiping the binoculars, etc. At least, we used this approximation when I worked in an outsourcing company many years ago, and it varied depending on the challenges the project was facing.
With projects, this world has only 2 options for anything else than doing:
Option #1: the bulky "talk-plan-remake-do it again" cycle is a given.
Option #2: over-indulgence in all things talking and planning is a waste.
The hardest job is to distinguish if a project falls into option #1 or option #2. If the option #2 is disguised in the make-up of a given, developers and other performers will feel troubled about whatever they're working on. When someone has a job to do, all they need is to be left tete-a-tete with their work, and as little contacts with the outer world as possible.
The unwelcome "talk-plan-remake-do it again cycle" usually happens if planners are not directly involved in the ship-deliver activities, and lack foresight in tracing the hurdles in advance. For the actual performers, being subjected to all kinds of catch-up moves feels like a huge annoyance. Performing is a raw and healthy thing. Some software developers naturally feel more inclined to performance-based activities, and their philosophy is: "I care only for what I have to ship, and I don't want to mess with the waste of talking." If we draw a parallel with performance on stage, the feeling after having shipped a piece of work would be akin to this: I've worked my a.. out, I'm sweating and exhausted, but I'm happy because I performed and delivered the show that people liked!
There's nothing as fulfilling as a happy experience of a well-accomplished performance, and performers find delight as they ship something on any given day. All the tiny dwarfs in the world run a round of applause at that. The deliverable can be a piece of code, or those few milliseconds of faster load times, or a finished design element, or an HTML-coded web-page. If it feels like too much unwanted planning and discussing that undermines this desire to perform, your team is in trouble. This feel signals that the whole act of planning is misinterpreted, and is seen as a thing-in-itself that lives in isolated reality, unrelated to a shippable outcome. Besides, it's a proof that the keepers of "talk-plan-remake-do it again" routines lack competence in nailing down the optimal solutions at the right time. If that's what's happening in your organization, remember that talkers and planners are not the rainmakers. Performer is the rainmaker, and planners would be better off if they let performers perform, or better yet, get to performing and doing rather than talking and planning. The catch here is that with time some sort of organizational blindness might develop, as talkers and planners manage to come across as rainmakers. Beware that optical illusion.