Let me start off...
...by saying that im in a kind of "weird" situation right now i would say, thats why im writing this.
I've been wo...
For further actions, you may consider blocking this person and/or reporting abuse
Hello,
First of all, you need to have management onboard with your proposals. You'll achieve nothing if they don't support you.
Changing how a team work is a management decision. So i see two options here.
If you don't want to do management, you are stuck with the first option.
Now if you want to convince them. Here are some things you can do :
If they accept, do it right. propose to recruit a scrum master and a product owner. You'll not be agile without those, and you'll fail.
If your efforts do not work, and you feel Bad and not enjoying your work anymore, i would seriously consider resigning. But do not use resignation as tool to make them change their mind. Just resign and enjoy another company where you'll feel better.
Hey,
thanks for your comment, really appreciate it!
I'm pretty sure that i already have the management on my side. They already said that they would make sure that they do what they can in order to help me achieve the things im trying to do. But as we all know a management saying this and at the end actually doing this is a far different story.
About the scrum master and the product owner:
im a scrum master myself, i did that scrum schooling for a scrum master and a colleague of mine did the one for the product owner. Im just not quite sure if im supposed to be a developer+teamleader+scrum master. i feel like thats the wrong direction, because its simply way to much in one person and scrum is really based on everyone doing what their role is told.
im not really the type for resigning but i guess if thats the case i have to look out for other options, but thats far future.
Combining 2 roles is usually doable.
Combining 3, you're looking for trouble.
If you prefer combining dev+lead, you'll keep in touch with technical leading.
Doing scrum+lead and you'll slowly loose touch with the tech part. You'll have to give a tech lead position to someone else to help you take decisions.
Depends on what attracts you most.
well in that case i would go with dev+lead and drop the scrum stuff. i just love being a developer to much for that haha
"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
Hi. Sorry to bust the bubble, but I think the mindset is misplaced. As a team leader, I think it's not about enforcing procedures. It's about good communication and mutual understanding. I always find it ironic that the original first quote of the agile manifesto "Individuals and interactions over processes and tools" transformed into sets of procedures and certifications.
Forget about it. What do the developers want? What does upper management want? What does the client want? A good understanding of each other is the best first step IMHO. And talking is also the best way to make others understand your choices and support you.
To go back to your practical worries...
What about the others? Perhaps some like it. And if nobody does, then everybody would welcome the change anyway, right? Personally, I do think that this *outdated" model is good in many situations though.
Well, agile/scrum won't magically solve this. Again, this is a matter of experience and communicating the inherent uncertainty of estimates.
Well, that won't change either. I would even argue that the waterfall model would be "let's be clear about the required features beforehand" while scrum is iterative by nature and an open door for on-the-fly changes.
Just be sure to be on the same page as your devs. As a side note, I'm personally often pissed by all this scrum "bureaucracy" that I often find either annoying or time wasting. I personally just need three things: clear goals, prioritizing features/bugs and regular meetings. The whole within a pleasant, friendly, helpful atmosphere and that's it. That's my methodology.
Well, does he even care about "how you organize yourselves"? ...I mean, why would he give a shit whether you make daily stand ups or not? Perhaps here again, some basic understanding would be helpful. His job is to sell the product and ensure financial stability. So I guess he would be mostly interested in hearing about good products, ballpark estimates that roughly fit the bill and if the team works efficiently, that's great.
...well, basically, I don't really know what you are asking, nor what's the problem. Nevertheless, I would advise shifting the focus away from methodology and redirect it to the people to ensure smooth interaction and their satisfaction.
Review previous projects and use those as an example in terms of what went wrong, wasted time & money (actual figures). Next, using same examples explain how things would have been different if your preferred methodology was used. (Again figures).
Finally project 12month outcome of we continue working the same way we do now.
They need to understand the issues/inefficiencies and the actual cost of those (work hours etc..)
I would love to do that, issue is just that im "just" a developer. im not even allowed to know the exact $ per hour we're charging and that differs from customer to customer. management just doing managementstuff