Agile Won't Fix Your Products(firstround.com)
firstround.com
Agile Won't Fix Your Products
http://firstround.com/review/im-sorry-but-agile-wont-fix-your-products/
2 comments
I agree that Agile can be the middle ground, but it can also can be dangerous.
When my previous employer implemented "Agile" they payed what I imagine was tens, if not hundreds of thousands of dollars for an "agile framework's" consultants to come in and teach us how to agile correctly.
1.5 years after that I saw that our time was more micromanaged than before. We were told regularly we were "empowered" and to speak up when we had any doubts or anxiety or saw a problem with our plan, but when we did it we were either chastised or disregarded or in some cases convinced it wasn't an issue.
That and the entire development organization treating estimates as infallible. That was the worst. Being told to estimate as best you could because agile was about adapting to change. Then getting reamed for being wrong. I gave up pointing out all the double-speak (release dates are flexible! as long as it is done by the release date) going on in the "agile ceremonies" (2 day 4-hour Release planning meetings with all 30 dev teams in one room.)
I know it's just one org I'm speaking about, but after almost 3 years I don't know if their dev organization is any better off than when they were waterfall. Now I'm curious just how wide spread this particular issue is.
When my previous employer implemented "Agile" they payed what I imagine was tens, if not hundreds of thousands of dollars for an "agile framework's" consultants to come in and teach us how to agile correctly.
1.5 years after that I saw that our time was more micromanaged than before. We were told regularly we were "empowered" and to speak up when we had any doubts or anxiety or saw a problem with our plan, but when we did it we were either chastised or disregarded or in some cases convinced it wasn't an issue.
That and the entire development organization treating estimates as infallible. That was the worst. Being told to estimate as best you could because agile was about adapting to change. Then getting reamed for being wrong. I gave up pointing out all the double-speak (release dates are flexible! as long as it is done by the release date) going on in the "agile ceremonies" (2 day 4-hour Release planning meetings with all 30 dev teams in one room.)
I know it's just one org I'm speaking about, but after almost 3 years I don't know if their dev organization is any better off than when they were waterfall. Now I'm curious just how wide spread this particular issue is.
Agile won't fix your products because you can't fix clueless, bumbling, incompetent engineers. I've done the whole agile thing in small teams of 5 and gotten more done than working with 100 offshore developers who find excuse to complain about everything every chance they get. Agile doesn't fix the pride you have in the work that you do. That's the primary motivation for good work. Knowing that your work matters and you're not just there to collect a pay check and check out as soon as possible.
A better idea would be for the entire team to be motivated, for them to be aware of the customer, to be able to drop something half-way and pick up a priority as a customer scenario unfolds.
In nearly every effective team, I've been part of, the most important detail was that anyone of us could be swapped out for someone else - it's not that we were fungible, but that the UI guy could write backend, the backend guy could write the deploy code. All coming to one point - the specialist could do it faster and neater, except they could do a hack-job in someone else's module anytime.
And if you can get yourself five people who are like that, manage some conflict then you can get a lot more done than any other method I've seen.
Take away the pride, the motivation, point them at misdirected goals, then you end up with nearly nothing.
Agile is the middle ground here - you're demotivated? Go pick something off the burn down chart. You need to leave early? Tell us at the standup. Can I borrow two developers for a week? No, the sprint plan has them accounted for, can I drop features?
Not as a bad as that, but it's not a substitute for a tiny cross-functional team which isn't pulled about by external forces.