The story begins with a new feature request that the "business" thinks is needed while the "developers" think is not. It's really hard to pick sides here without knowing more about the specifics. I've seen situations where developers are completely wrong about the business value of something and I've seen it the other way around.
If the new feature was indeed critical to the business then the boss finds himself in a situation where one of the best developers spends months trying to build some DSL and comes back with nothing. So we can understand the frustration on the business side of things. This is where things started going the wrong way and there's a loss of trust on the ability of the technical team to deliver.
Now obviously the new PM and his buddies (I've seen this before) only make everything worse. "Jira" or "Scrum" or "Agile" wasn't really appreciated by the old team used to doing whatever they wanted to do.
I think the truth here is there has to be some sort of balance. Developers need to balance architecture and refactoring with delivering new stuff. They need to listen and have a dialog with product management about new features. There has to be trust. When there is trust there are less controls. When trust is lost it's almost an unfixable situation especially when you have a combination of a tech team that isn't delivering anything useful (from the business perspective) with management who doesn't understand software development.
Clearly the best situation is trust combined with good management and developers who take ownership and see the big picture. Then useful stuff gets delivered and things like architecture or refactoring get taken care of.
> "business" thinks is needed while the "developers" think is not
Some correction here: "business" thinks is needed, while "developers" think is impossible. Have you really never seen that happen?
Then, a developer gets a great idea that turn an impossible idea into a possible mega-project. But, for lack of experience with this kind of project, thinks it's an small, viable one. Then, the project fails - big duh.
What's a problem here is that all it takes is one instance of this happening to the management to declare its team a failure and replace everything. Without any inspection or introspection. That's (if the history is complete) a profound lack of professionalism.
> Now obviously the new PM and his buddies (I've seen this before) only make everything worse. "Jira" or "Scrum" or "Agile" wasn't really appreciated by the old team used to doing whatever they wanted to do.
Everything I have read about agile is that if you do it right, everyone is happy. The customer, the developers, and the managers. Agile itself is supposed to be development-centric.
Tonight, I realized that Agile does not handle politics very well. I mean, how can it? It's just a software development methodology.
> Everything I have read about agile is that if you do it right, everyone is happy. The customer, the developers, and the managers.
So they said about all its predecessors, as well. Pretty soon, they start adding "...of course, you must have exceptionally competent people", and then they define 'doing it right' by 'having a successful outcome'.
Take a read at the Agile Manifesto, and I doubt you'll find any point there to criticize.
But then, take a look at any agile methodology, and try to explain how it fits the manifesto. Or better, explain how adopting any "agile methodology" fits the manifesto by itself.
If the new feature was indeed critical to the business then the boss finds himself in a situation where one of the best developers spends months trying to build some DSL and comes back with nothing. So we can understand the frustration on the business side of things. This is where things started going the wrong way and there's a loss of trust on the ability of the technical team to deliver.
Now obviously the new PM and his buddies (I've seen this before) only make everything worse. "Jira" or "Scrum" or "Agile" wasn't really appreciated by the old team used to doing whatever they wanted to do.
I think the truth here is there has to be some sort of balance. Developers need to balance architecture and refactoring with delivering new stuff. They need to listen and have a dialog with product management about new features. There has to be trust. When there is trust there are less controls. When trust is lost it's almost an unfixable situation especially when you have a combination of a tech team that isn't delivering anything useful (from the business perspective) with management who doesn't understand software development.
Clearly the best situation is trust combined with good management and developers who take ownership and see the big picture. Then useful stuff gets delivered and things like architecture or refactoring get taken care of.