{"id":1409,"date":"2015-01-16T08:34:22","date_gmt":"2015-01-16T15:34:22","guid":{"rendered":"http:\/\/10kdev.net\/?p=1409"},"modified":"2015-01-16T08:35:40","modified_gmt":"2015-01-16T15:35:40","slug":"agile-weve-gotten-what-we-can-from-it-time-to-move-on","status":"publish","type":"post","link":"http:\/\/10kdev.net\/?p=1409","title":{"rendered":"Agile; We’ve Gotten What We Can From It. Time To Move On."},"content":{"rendered":"
\"\"<\/a>

Delicious snake oil. LEAN and healthy.<\/p><\/div>\n

I think finally the outrage against the manipulation of Agile methodology is coming to full head.<\/p>\n

Years ago in discussions with colleagues we came to the conclusion that Agile had a built in flaw:\u00a0 it allows people to manipulate the software management process for their own goals, and since everyone does not have the same goals, this creates conflict and in the end a bad product.<\/p>\n

You can take note from this article by Erik Meijer: AGILE must be destroyed, once and for all<\/a>.\u00a0 This kind of angst is showing up everywhere:\u00a0 let us just develop software, dammit, and stop micromanaging us.<\/p>\n

Now certainly I understand that management needs a way to measure it’s field hands to assess productivity.\u00a0 I get it.\u00a0 I understand there have to be measures in place to assess risk and holes in software’s security, code stability, defect management and the like.\u00a0 Agile has created a systemic problem whereby all this get’s bypassed.\u00a0 How?<\/p>\n

    \n
  1. Agile management tools are picked to accommodate management, not software building.\u00a0<\/strong> The people who *buy* Agile are not the one’s subjected to it.\u00a0 For instance, who decides whether to use Rally, Version one — heck even Git vs. Subversion?\u00a0 rarely if ever a developer or even a 50% developing architect.\u00a0 It’s almost always a manager, who is so far removed from the actual build process, who usually has less than a year of development under their belt and has been weeded out into management.\u00a0 The tools have become so invasive to daily software making they are in the way.\u00a0 One thing I hate is that it’s become so micromanaging that even style is part of the code checkin now.\u00a0 You can say this matters (for python), but a tool eating up CPUs to see if I tabbed or spaced is a bunch of BS.\u00a0 it doesn’t add to the supportability.<\/li>\n
  2. The open\/communication aspect of Agile accommodates verbal people, but most engineers are spacial.<\/strong>\u00a0 This means that in a world of constant scrums, reports, and social media that people who spend their time talking and writing get deference over people actually making the software.\u00a0 Agile allows the complainers to get what they want.<\/li>\n
  3. Agile has created a booming industry for people who are snake oil salesmen.<\/strong>\u00a0 So much money is being wasted on “evangelists” and speakers saying feel-good “yeah, I get it!!” talks.\u00a0 Then are hired to parachute in with their Agile\/Lean\/Whatever methodology.\u00a0 And you know what happens?\u00a0 Same thing that happened to waterfall before.\u00a0 The snake oil genies spend their time trying to make their system fit a business in order to sell it, laying on yet more layers of cruft in what might be an already unnavigable project management methodology.<\/li>\n
  4. Agile has de-individualized contributions, lessened innovation all while creating more paths of stupid accountability.<\/strong>\u00a0 You can have a manager turn on all the metrics: Sonar, Cobetura, security checks, process, style checks.\u00a0 All off line from the developer’s building efforts.\u00a0 But in the end even after that the manager blames developers for anything that went wrong.\u00a0 If a mangers are finding ways as to not be accountable, and are looking for tools to offload their responsibility then this is a culture that then pervades the entire industry.\u00a0 The less developers willingly take on responsibility, the less they will want to solve the problems that can safen that responsibility, the less they will be innovative.<\/li>\n
  5. Agile tools were created to collect objective information but are now wielded by management against developers.<\/strong> When I first saw a scrum tool, I thought to myself: this will be used to measure and micromanage developers and rate them.\u00a0 And now it has, but, it fails because you can’t measure intangibles.\u00a0 For instance a person completing 15 easy tasks vs. a person doing a really difficult code task in many tools looks like a 15 to 1 score.\u00a0 Some places even still use lines of code or checkin numbers to measure a “developer’s productivity.”\u00a0 The intial creation of Agile management tools was so we, as developers, could improve of our own volition.\u00a0 Sonar to decrease errors, SWAG estimates to measure and make our estimates better in the future.\u00a0 Estimates are abused constantly; and you will now always see over estimation to protect developer’s behinds.<\/li>\n<\/ol>\n

    There are things that I like about the industry.\u00a0 I like a lot of the testing, as long as it is used sanely.\u00a0 I like the continuous integration engines.\u00a0 I like some of the documentation things about projects in the new tools.\u00a0 But I am not sure we are writing software any better or faster than a decade or two before.<\/p>\n

    One thing that burns me is the lack of objectivity in the industry and the winning by the “verbal” people to use religious and orthodox arguments to get to their goals.\u00a0 This is . . . political.\u00a0 Which means objectivity is out the door.\u00a0 A great Ted Talk video explains how this happens in what is the holy grail of objectivity, the scientific method:<\/p>\n