Meeting Driven Development
I've recently been involved with a project which I originally thought lost its way. We had been on several different methodologies before (Agile/Scrum). Although, those are pretty much the same thing just named differently, so take it for what its worth. Though we no longer have an official methodology of how to progress with providing or developing a solution, we do in fact have many tasks to complete with a finite amount of time to complete them. Recently the project has hinged very much on what I'd like to call Meeting Driven Development, because as I realized today, though there is still plenty of madness, this turbulence is, in fact, a result of a particular process.
The process begins with a single meeting. This meeting in turn drives management to prioritize a set of tasks and to set forth delegating those tasks to appropriate resources. That's a fine way to handle the tasks at this point. The team now has a guideline, focus and set of tasks to accomplish. The defining point of this method, however, is revealed in the second iteration of the process. A different meeting is had with some or all of the previous management team, but with a different user base. This user base may be users complaining about performance, or client side management complaining about improper reporting tools. Which ever the case may be, management redefines priorities and tasks based on this new meeting. Though the teams original tasks may have included performance issues, the team's new task is to focus on management reports. The team sets gears into reverse, which can often take a day or two depending on the difficulty of their previous task, and refocuses their efforts. You can imagine that another meeting iteration will lead to new tasks and new priorities. This is often matched with executive requirements being placed on top of the task stack at any given moment. Because despite the fact that the executives new tasks were not part of the original scope of the project, executives are given this leeway because they are in fact the ones who started the project, so they can interject tasks at their will and without regard to project scope.
As the process drives forward, it leads itself to its logical conclusion. There's lots of work to do and all of the tasks are partly done. Which means "wins" for the team, or even finishing a task completely, are few in far between. This drags down team morale, confuses management, and ultimate delivers nothing on time without some over the top individual commitment at the lower ranks.