4 ms·

I felt like Agile was like rewarding people for rats tails, so people start breeding rats. There was too much focus on clearing out stories, even if it meant a

I felt like Agile was like rewarding people for rats tails, so people start breeding rats. There was too much focus on clearing out stories, even if it meant a ton of bugs, but the bugs were good because those led to more stories and the PM could take credit for "getting so much done." This was at a certain dysfunctional, highly political networking hardware company.

nradov 8y ago
That type of dysfunction can occur under any methodology, regardless of agility. It indicates an inadequate definition of done and poor quality procedures.
aaaaaaaaaab 8y ago
So that’s why all network gear needs to be power-cycled at least weekly to function correctly!
- outworlder 8y ago
  No, although that could be part of it. You are probably talking about consumer gear. Consumers usually have two requirements: a) FEATURES FEATURES FEATURES. All of them. 200 beamforming antennas. Interplanetary internet. b) Price. All of the above for the lowest price possible. FTL communication? Cool. It better be under $50 or I'll buy the competitor. So this is what the companies optimize for. Who cares if DHCP is broken if it works most of the time. Memory leak? Just have it reboot. IPV6 broken? Most customers won't even know or care. You'll find that 'enterprise' hardware performs way better. At a price premium.
Jtsummers 8y ago
That's not agile. That's goal-driven motivation systems. "Finish twice the average stories per month and you get a bonus!" People game the rewards system by generating smaller, achievable stories. I had a colleague once who [0] would save up test cases (we were on the V&V side) to develop that were smaller. He could've had them all done and delivering value in two weeks, 200 test cases done! But if he did that he'd be left with the remaining 50 test cases that each needed 1-3 weeks to develop test systems for (sometimes shorter, I think 2 weeks or so was the average). So if he found himself looking bad on the burndown chart, he'd churn out 20 finished test cases from the easy ones. This way he was always "on track". If he'd done them and gotten ahead, they would've wondered why he slowed down (because not all test cases had the same size, duh) and penalized him for it. The problem is, that goals like that (as carrot or stick) don't change the fundamental system. If I manage to churn out 20 story points this week, but only 10 every other week, is it sustainable? Was it a fluke? Was it because I did 40 hours of OT? Or was it that they were overestimated? Maybe I had a unique skill set or insight that let me solve it more quickly than had been anticipated. Maybe something in my brain clicked (remember that moment early in your career where a "hard" concept suddenly became obvious, and all your programming tasks became much easier?) and the new level will be sustainable. On the other hand, if you create a goal to double efficiency/capacity and provide access to resources to change the development/deployment/whatever system then you can get something useful. I wrote a tool for data analysis for a project (actually a collection of related projects). The tool cut down test analysis time from hours to minutes. An activity done daily by the V&V team. I saved them years of work in that first year. The goal was to reduce the bottleneck (test results took too long to get so developers were waiting or operating blind). That goal, by itself, was worthless. It was only able to change the system of that team because I had been given permission to work on tools that would achieve it. [0] We had a manager who did things like this, though no carrot all stick.

nradov 8y ago

That type of dysfunction can occur under any methodology, regardless of agility. It indicates an inadequate definition of done and poor quality procedures.

aaaaaaaaaab 8y ago

So that’s why all network gear needs to be power-cycled at least weekly to function correctly!

outworlder 8y ago
No, although that could be part of it. You are probably talking about consumer gear. Consumers usually have two requirements: a) FEATURES FEATURES FEATURES. All of them. 200 beamforming antennas. Interplanetary internet. b) Price. All of the above for the lowest price possible. FTL communication? Cool. It better be under $50 or I'll buy the competitor. So this is what the companies optimize for. Who cares if DHCP is broken if it works most of the time. Memory leak? Just have it reboot. IPV6 broken? Most customers won't even know or care. You'll find that 'enterprise' hardware performs way better. At a price premium.

Jtsummers 8y ago

That's not agile. That's goal-driven motivation systems. "Finish twice the average stories per month and you get a bonus!" People game the rewards system by generating smaller, achievable stories. I had a colleague once who [0] would save up test cases (we were on the V&V side) to develop that were smaller. He could've had them all done and delivering value in two weeks, 200 test cases done! But if he did that he'd be left with the remaining 50 test cases that each needed 1-3 weeks to develop test systems for (sometimes shorter, I think 2 weeks or so was the average). So if he found himself looking bad on the burndown chart, he'd churn out 20 finished test cases from the easy ones. This way he was always "on track". If he'd done them and gotten ahead, they would've wondered why he slowed down (because not all test cases had the same size, duh) and penalized him for it. The problem is, that goals like that (as carrot or stick) don't change the fundamental system. If I manage to churn out 20 story points this week, but only 10 every other week, is it sustainable? Was it a fluke? Was it because I did 40 hours of OT? Or was it that they were overestimated? Maybe I had a unique skill set or insight that let me solve it more quickly than had been anticipated. Maybe something in my brain clicked (remember that moment early in your career where a "hard" concept suddenly became obvious, and all your programming tasks became much easier?) and the new level will be sustainable. On the other hand, if you create a goal to double efficiency/capacity and provide access to resources to change the development/deployment/whatever system then you can get something useful. I wrote a tool for data analysis for a project (actually a collection of related projects). The tool cut down test analysis time from hours to minutes. An activity done daily by the V&V team. I saved them years of work in that first year. The goal was to reduce the bottleneck (test results took too long to get so developers were waiting or operating blind). That goal, by itself, was worthless. It was only able to change the system of that team because I had been given permission to work on tools that would achieve it. [0] We had a manager who did things like this, though no carrot all stick.