A reader points out how Agile development provides an entry point for converging technology companies:
It took a while to notice but there is something happening in even non-converged companies. They call it “Agile” in the instances I know of, but that has been around and revised for the last two decades.
It is being sold as what Apple, Amazon, Facebook, etc. use to get great gains in productivity and measure their teams’ performance. Instead, it is where the cancer can hide. That doesn’t mean you don’t yet have cancer, only that you won’t be able to tell as the nerves are dead.
Having been involved with it being “imposed from above” and discovering it in other companies I finally know why some of the stupid or meaningless kabuki is being used.
If something in your software development process seems either meaningless, stupid, or even counterproductive, it is because the purpose is not coding quality, probably is being celebrated elsewhere as a product of SJW convergence, but is being adopted and imposed on your team. I doubt it is even intended to weaken or destroy competition, but that is the result.
First, there is no measure of individual productivity. All that matters is the “team velocity” which is basically socialism coding (to paraphrase GitHub). This is bad enough when you have a fixed size of similarly capable coders working on the same thing. But what if the team consists of some HTML people, some CSS people, and some JavaScript people who do nonot know much about the other domains, or worse just 3 people, one of each? Yet the measurement is overall. Worse is you typically have a few stars, and supporting actors. So what happens when your two best Java Jockeys are replaced with Danny Diversity and Betty Bugwright that are actually a negative? The powers go into a tizzy and complain about the TEAM slowing down. Everyone on the team knows why but can’t say. And what is your evaluation and/or bonus or whatever based on? Being a team player, not a team winner.
Second is “the two week sprint”. Why two weeks? Imagine a complex subproject that will take someone good three months to go from start to finish, but you know that he can do it as he has been reliable. What this new process does is require it to be broken down into a dozen individual 2 week tickets with what needs to be completed – yes, a real deliverable – a each point. You might recognize this as the hardest part of any nontrivial change or addition. But Danny Diversity can’t even begin to understand how to do anything for the complex subproject, but can copy a bubblesort routine when it is needed for sprint #9. It is worse than that because 2 weeks is the MAXIMUM granularity, but the idea is to have half-day sized projects.
Note there will be “customers” that request a feature, and “the team” is supposed to estimate it, but in the new paradigm design is either omitted, relegated outside the team, or is done in parallel (usually as resented tickets trying to do a mini-waterfall inside the “agile” – usually it is the reverse). If you are making small patches, easily reversed to something like a website (e.g. add popup for shopping cart), this can work because the granularity is small, testability is high, it is a small mod, not a major design, and can be backed out instantly. Imagine if an OTA update bricks or introduces a huge vulnerability to a smartphone.
Third, one of the foundations of Agile is constant refactoring, often built in to the process, to avoid accumulating technical debt. If refactoring is one of those things that is avoided or treated like something that we haaaave to do, you are doing the converged version of “Agile”. Why? Because Betty Bugwright and Danny Diversity will get their tasks done in the sprint, but either any review will reject them or a clean-up tech debt ticket will have to be added. Can’t let there be a visible pattern of where the accumulation of technical debt is coming from. Like San Francisco wondering why the spontaneous appearance of the feces and needles on the side walks.
Fourth, Participation (a)Trophy Test driven code. Actual regression tests are very useful, but hard to do and take time and effort to code. Expecially cross module unit and system tests. Instead, we get kabuki where Danny writes a routine to verify Add(2,2) returns 4, which is still better than letting him modify any used part of the code. But you can add thousands of lines of meaningless clutter, imply that the quality is improving because it is now “tested” while the system is collapsing, and give the deadweight something nondestructive to do for the kabuki.
True Agile is a toolbox, with screwdrivers to remove screws, hammers for nails, and wrenches or at least pliers for bolts. But when all you have is a hammer…
This is an astute observation. I may have to include it almost verbatim as an example in Corporate Cancer.