null && void

processes that result in additional meetings, documents nobody reads, work that doesn’t directly support the organization’s purpose, or involve erecting obstacles to keep people on the “correct” path- these are bad processes.

Under Agile, technical debt piles up and is not addressed because the business people calling the shots will not see a problem until it’s far too late or, at least, too expensive to fix it. Moreover, individual engineers are rewarded or punished solely based on the completion, or not, of the current two-week “sprint”, meaning that no one looks out five “sprints” ahead. Agile is just one mindless, near-sighted “sprint” after another: no progress, no improvement, just ticket after ticket.

“Agile” is a culture of terminal juniority [...]. Agile has no exit strategy. There’s no “We won’t have to do this once we achieve ” clause. It’s designed to be there forever: the “user stories” and business-driven engineering and endless status meetings will never go away. Architecture and R&D and product development aren’t part of the programmer’s job, because those things don’t fit into atomized “user stories” or two-week sprints. [...] Aside from a move into management, there is the option of becoming a “Scrum master” responsible for imposing this stuff on the young’uns: a bullshit pseudo-management role without power. The only way to get off a Scrum team and away from living under toxic micromanagement is to burrow further into the beast and impose the toxic micromanagement on other people. What “Agile” and Scrum say to me is that older, senior programmers are viewed as so inessential that they can be ignored, as if programming is a childish thing to be put away before age 35.

Agile eliminates the concept of ownership and treats programmers as interchangeable, commoditized components.

Getting rid of fixed iterations was by far the strongest thing we did. We used to run two week sprints which broke down roughly like this : Days 1 and 2 : Fixing the stuff we had hacked to make it look like it all worked in the last review. Days 3 and 4 : Planning. Sitting in a room *determined* to plan every last detail of the next two week’s work. Three people talking all the time, three people sitting quietly in the corner, two people rocking slowly back and forth contemplating suicide. Days 5 to 8 : Yay !! Coding, testing, working, producing good stuff, doing what we were employed for. WOO !! However, we did need to also work out a way to crow-bar defects through the system when they weren’t actually attached to a story, and they weren’t new work . . . they just didn’t fit – perhaps we could have a bug-fix Sprint next time, maybe we should exclude them from the burn-down as they aren’t new work, perhaps we could just fix them in over-time etc etc ? Day 9 : Start hacking unfinished stuff to make it look good for the review. Day 10 : Finish the uncomfortable hacking, arrange the mirrors, start the smoke machines. Review at 2PM. By 4PM everyone feels down that they haven’t been able to focus on actually getting good stuff done, but hey, it’s the weekend now, byeeeeeeeee. Then rinse and repeat with a constant background of noise from management’s morbid interest in the shape of the graph and the particular curve of the burn-down chart and exactly when that line was going to get steeper. Now, I am explicitly and very loudly *NOT* blaming Scrum for this any more than I blame geography when I can’t find my car keys, but the framework/process gave us an excuse to focus on the wrong things and it really helped us to fool ourselves that we were being successful because we were following the process well even though we weren’t producing any product.

The following practices are particularly subject of my ire, particularly because teams too easily fall into the trap of believing that these are the “point” of Agile: - Tasks - Task Estimations (often in hours) - Individual capacity planning - Iteration commitments - Iteration burn-downs - Daily Stand-ups Is your individual and team value defined by how well you perform these activities? Do you invest significant time in these practices? Are you getting value out of them? Does the team feel they have the empowerment to stop doing any of these? To be fair: the real issue is how Scrum is (mis)applied, rather than Scrum itself. However, how many times does Scrum have to be misapplied before we treat it as a fault in the framework itself?

Let’s look again at the four values:    Individuals and Interactions over Processes and Tools    Working Software over Comprehensive Documentation    Customer Collaboration over Contract Negotiation, and    Responding to Change over Following a Plan The phrases on the left represent an ideal—given the choice between left and right, those who develop software with agility will favor the left. Now look at the consultants and vendors who say they’ll get you started with “Agile.” Ask yourself where they are positioned on the left-right axis. My guess is that you’ll find them process and tool heavy, with many suggested work products (consultant-speak for documents to keep managers happy) and considerably more planning than the contents of a whiteboard and some sticky notes.

When Copy and Paste becomes a Problem