"they have to implement yet another feature which wasnt in the planning right from the beginning but is wished by the customer or hasn't been seen from the beginning."
It sounds like your main problem is requirements gathering, more specifically the absence of a comprehensive requirements gathering process.
Here's a report about how requirements gathering is critical and often not conducted as it should be in many companies: web.archive.org/web/20130917021904...
As a leader what you could do is:
Gather examples of things going wrong (project overruns).
Identify patterns like you've done when you say "things hasn't been seen from the beginning" (poor requirements gathering and poor change management).
Ask people what they think about the situation and your analysis (project overruns don't come from lack of technical skills but poor requirements gathering).
If I'm right and your problem is a lack of requirements gathering process, the next step is to sell this idea to the whole development team and then to ask your boss, in the name of the team, to improve the process requirements gathering.
You should consider that your boss might not care about developers being pissed, so I suggest you to talk only about the cost of bad requirements gathering. I encourage you to read the above report if you need ammunition.
More generally as a leader, your role is not necessarily to find solutions for the team, but to help the team figure out a solution by initiating the process, which is what you've done here.
You're completely right, we do have a massive problem with gathering the requirements at the beginning of a project. Thats one reason my colleagues want to swap to a more agile-like development process. I wouldn't particually say that our issue is gathering the requirements ourself, its more the customer not knowing 100% what he wants and in the end coming up with new wishes during the development process and somehow noone saying anything against that simply because "the customer pays for that" but in the end he kinda doesnt, because we made the estimation at the beginning and he pays for that estimation. Most customers want to pay a set sum for a project but also want to be involved in the development process (which is understandable) but that creates alot of overhead for us, not only workwise but that work gotta be payed.
I've been working for and with agencies for +10 years, from junior developer to technical director, I'm just giving my opinion about my own experience.
"Most customers want to pay a set sum for a project"
Yes, it's the revenue model of an agency, and the reason why agile software development is incompatible with the agency model: the customer commits to a scope and the agency commits to a price. Not exactly the definition of agility.
The problem is that, once the project has started, both actors will try to maximize their own interests:
The agency will reuse existing work instead of developing a new solution, and will take advantage of the blurry boundaries of the scope to exclude as much work as possible from it.
The customer will take advantage of the blurry boundaries of the scope to include as much work as possible from it. Since you're the expert and the advisor, you should have understood better.
Reuse of work is fair. As a developer, building reusable components and building systems that leverage reusable components is part of the fun when working in an agency.
Fighting over contracts, words, and interpretation is toxic. When developers are left alone in this battle, it's even more toxic because they haven't committed either to a scope or to a price themselves (estimates are not a commitment).
To make customers and developers happy, to build a good reputation, retain employees, attract more candidates, etc, it's in the interest of the company to avoid creating a toxic work environment.
How?
First, before starting the project, by conducting a requirement discovery phase to identify some of the new wishes you talked about.
Often customers have limited abstraction skills and need to visualize something to reason about it. Most of them don't spend hours in front of a computer, thinking about OOP patterns and SOLID principles. That's when whiteboards, wireframing, and prototyping can help. Also, it's cheaper to move boxes on a whiteboard rather than to rewrite code.
Then, during the project, you need strong project management skills to manage scope creep (see Managing Scope Creep). You need a brave project manager that can tell the client something like:
"Of course we can develop this feature. Despite the comprehensive requirements discovery phase we've conducted, we never talked about it before so, I hope you understand this is a modification to the scope we agreed on and we need to evaluate the impact of such a request."
This way you can involve customers in the development process, refine requirements, and still control the scope of the project.
"somehow no one saying anything against that"
If there's an honest discovery phase before starting the project, people will feel more confident saying no to a customer. They'll have evidence to show, and they won't fear damaging a good business relationship or looking like they are acting in bad faith.
One of the big challenges of the agency model is how to charge for this discovery phase somebody that is not a customer yet. Kind of a chicken or the egg problem.
after reading alot about Scope Creep i have to admin that this is EXACTLY our problem. More it is the customer on the one side that it is fine, but on the opposite side they start to complain once the sums start to roll in
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
"they have to implement yet another feature which wasnt in the planning right from the beginning but is wished by the customer or hasn't been seen from the beginning."
It sounds like your main problem is requirements gathering, more specifically the absence of a comprehensive requirements gathering process.
Here's a report about how requirements gathering is critical and often not conducted as it should be in many companies: web.archive.org/web/20130917021904...
As a leader what you could do is:
If I'm right and your problem is a lack of requirements gathering process, the next step is to sell this idea to the whole development team and then to ask your boss, in the name of the team, to improve the process requirements gathering.
You should consider that your boss might not care about developers being pissed, so I suggest you to talk only about the cost of bad requirements gathering. I encourage you to read the above report if you need ammunition.
More generally as a leader, your role is not necessarily to find solutions for the team, but to help the team figure out a solution by initiating the process, which is what you've done here.
Your post is a proof of leadership 👍
Hey,
thank you aswell for your comment!
You're completely right, we do have a massive problem with gathering the requirements at the beginning of a project. Thats one reason my colleagues want to swap to a more agile-like development process. I wouldn't particually say that our issue is gathering the requirements ourself, its more the customer not knowing 100% what he wants and in the end coming up with new wishes during the development process and somehow noone saying anything against that simply because "the customer pays for that" but in the end he kinda doesnt, because we made the estimation at the beginning and he pays for that estimation. Most customers want to pay a set sum for a project but also want to be involved in the development process (which is understandable) but that creates alot of overhead for us, not only workwise but that work gotta be payed.
I've been working for and with agencies for +10 years, from junior developer to technical director, I'm just giving my opinion about my own experience.
"Most customers want to pay a set sum for a project"
Yes, it's the revenue model of an agency, and the reason why agile software development is incompatible with the agency model: the customer commits to a scope and the agency commits to a price. Not exactly the definition of agility.
The problem is that, once the project has started, both actors will try to maximize their own interests:
The agency will reuse existing work instead of developing a new solution, and will take advantage of the blurry boundaries of the scope to exclude as much work as possible from it.
The customer will take advantage of the blurry boundaries of the scope to include as much work as possible from it. Since you're the expert and the advisor, you should have understood better.
Reuse of work is fair. As a developer, building reusable components and building systems that leverage reusable components is part of the fun when working in an agency.
Fighting over contracts, words, and interpretation is toxic. When developers are left alone in this battle, it's even more toxic because they haven't committed either to a scope or to a price themselves (estimates are not a commitment).
To make customers and developers happy, to build a good reputation, retain employees, attract more candidates, etc, it's in the interest of the company to avoid creating a toxic work environment.
How?
First, before starting the project, by conducting a requirement discovery phase to identify some of the new wishes you talked about.
Often customers have limited abstraction skills and need to visualize something to reason about it. Most of them don't spend hours in front of a computer, thinking about OOP patterns and SOLID principles. That's when whiteboards, wireframing, and prototyping can help. Also, it's cheaper to move boxes on a whiteboard rather than to rewrite code.
Then, during the project, you need strong project management skills to manage scope creep (see Managing Scope Creep). You need a brave project manager that can tell the client something like:
This way you can involve customers in the development process, refine requirements, and still control the scope of the project.
"somehow no one saying anything against that"
If there's an honest discovery phase before starting the project, people will feel more confident saying no to a customer. They'll have evidence to show, and they won't fear damaging a good business relationship or looking like they are acting in bad faith.
One of the big challenges of the agency model is how to charge for this discovery phase somebody that is not a customer yet. Kind of a chicken or the egg problem.
I hope this helps.
after reading alot about Scope Creep i have to admin that this is EXACTLY our problem. More it is the customer on the one side that it is fine, but on the opposite side they start to complain once the sums start to roll in