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...
... they have been managing their projects in a waterfall-model type which i really dont like.
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.
... because we have alot of projects where the estimated effort turns out to be way more at the end
Well, agile/scrum won't magically solve this. Again, this is a matter of experience and communicating the inherent uncertainty of estimates.
... the team being pissed because they have to implement yet another feature which wasnt in the planning right from the beginning
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.
I want the team to transition to a more scrum-like or agile-like development style simply because i [like it]
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.
i dont see us actually being able to do agile because our financial/commercial management being someone who only wants to hear numbers and doesnt care about the rest
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.
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.
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.