John, you are right, it really depends on who's in driving seat and for what reasons.
Last 7-8 years I've personally only experienced "agile" when implemented to benefit management only and it's been really more vehicle for them to get easy reports on progress.
We ran with agile-like process starting around two years ago, and we really got to this extremely well oiled factory setup, I was happy and proud, because my team was getting things done, on time, with testing and fixes all baked into the process, making managers happy.
Unfortunately it was all designed around no-one wanting to spend "quality time" with developers and answer all these annoying questions about what suppose to be built exactly in all these corner cases, and instead hoping to have 1-2 quick meetings every 5-6 weeks and makes sure there's paper-trail of developers "doing something... anything" for the time they were paid for.
It really takes transparency, understanding and involvement of all levels and aspects of any company to make the most these principles.
First people incorrectly equate agility (the ability to change) to scrum, kanban, or some other small batch method for building software.
Someone told them they’ll get work done faster.
They notice scrum (or kanban) has more frequent checkpoints (stage transitions) than waterfall because of the small batches.
Finally they make the critical mistake here and think small batches are something that primarily benefits measuring and forecasting.
Accountability every release? Yay!
In reality using small batches makes it harder to forecast which is why that’s not the point of it!
The point of small batches is to make changing direction easier.
As soon as the focus is on measuring, the team is actually dissuaded from changing.
People become motivated to make the actual time reported to complete work follow their predictions.
They are also motivated to build what was forecasted for future sprints and not to modify the backlog based on feedback (don’t upset prior commitments to scope!).
If they’re going to do that they’re better off with waterfall.
Just my opinions ;)
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.
John, you are right, it really depends on who's in driving seat and for what reasons.
Last 7-8 years I've personally only experienced "agile" when implemented to benefit management only and it's been really more vehicle for them to get easy reports on progress.
We ran with agile-like process starting around two years ago, and we really got to this extremely well oiled factory setup, I was happy and proud, because my team was getting things done, on time, with testing and fixes all baked into the process, making managers happy.
Unfortunately it was all designed around no-one wanting to spend "quality time" with developers and answer all these annoying questions about what suppose to be built exactly in all these corner cases, and instead hoping to have 1-2 quick meetings every 5-6 weeks and makes sure there's paper-trail of developers "doing something... anything" for the time they were paid for.
It really takes transparency, understanding and involvement of all levels and aspects of any company to make the most these principles.
Totally agree and see this happen too often.
First people incorrectly equate agility (the ability to change) to scrum, kanban, or some other small batch method for building software.
Someone told them they’ll get work done faster.
They notice scrum (or kanban) has more frequent checkpoints (stage transitions) than waterfall because of the small batches.
Finally they make the critical mistake here and think small batches are something that primarily benefits measuring and forecasting.
Accountability every release? Yay!
In reality using small batches makes it harder to forecast which is why that’s not the point of it!
The point of small batches is to make changing direction easier.
As soon as the focus is on measuring, the team is actually dissuaded from changing.
People become motivated to make the actual time reported to complete work follow their predictions.
They are also motivated to build what was forecasted for future sprints and not to modify the backlog based on feedback (don’t upset prior commitments to scope!).
If they’re going to do that they’re better off with waterfall.
Just my opinions ;)