I’m Doing it Wrong? Really?

I chafe at how freely many of us will say you’re doing it wrong.

Sometimes distinguishing a right way from a wrong way is easy. Sometimes it’s not.

Holding a telephone handset upside down appears laughably wrong – unless you’re doing a comedy bit (where it might appear laughably right).

The wrong way to produce software is not as obvious as holding a telephone handset upside down.

Producing software involves contextually-dependent variables. We are faced with business constraints, technical hurdles, and inter-personal challenges. Constraints, hurdles, and challenges are situationally-dependent. Constraints, hurdles, and challenges vary from product to product, and change from one environment to the next.

What might have seemed wildly right in one context, might be wildly wrong in another.

Your Dogma Ran Over Your Karma

A post was shared on agile .net practitioners with the title “If you are building applications without writing your tests first then you are doing it wrong. The title was probably meant to attract attention, and the post was probably written in the vein of self-promotion, but it got my attention.

I have benefited from the virtues of Test First, but the statement, “If you are building applications without writing your tests first then you are doing it wrong” seems hyperbolic, naive and unnecessarily dogmatic.

Situational Utility

Test-Driven Development (TDD) and Test-First have become catchphrases. Who hasn’t been endorsed for TDD on their LinkedIn profile?

Several developers I know use Test First exclusively. Many more developers I know talk about Test First, but do Test After. Still more developers I know appreciate and espouse the virtues of Test-Driven Development, but rarely use it. Hardly anyone doesn’t, at least, pay lip service to TDD.

Developers encounter many different situations. It follows that there are many ways to approach the tasks at hand. TDD is not the holy grail.

Craftsmanship Surcharge

There is at least one situation, and perhaps several more, where TDD or Test First adds a gratuitous craftsmanship surcharge to the bill.

Lets say you are contracted by a start-up to iterate from an initial proposition to a viable business model. Is TDD a cost-saving approach? Probably not. While the code might be flawless, TDD slows down the cycle of testing a business proposition thereby increasing the start-up’s burn rate. Many start-ups don’t need flawless code during the market testing phase. The reality is that there is going to be throw-away code, particularly in the context of a lean start-up where the team is meant to be in iterative learning mode.

Be Kind, Rewind

Several of the useful things many of us picked up in the early days of XP, and during the maturation of Agile, are too often applied as blunt instruments to pummel our less dogmatic teammates.

TDD can be a blunt instrument. Just like the common misapplication of Stand-ups, Retros, and Burn-down charts, Test First can degrade to an abrasive command-and-control directive as readily as it can prove to be a prudent practice.

The What and The Why

Approaches, practices and tools have a place when they serve The What and The Why. We agree craftsmanship deserves attention. As practitioners we love bullet-proof code. Many of us have gotten proficient at The How and The When.

I’m self-critical. I know I might be doing it wrong. In many cases, I presume to be wrong. But increasingly I don’t care so much for The How or The When.

I’m reviving my old mantra: Don’t Lose Sight of The What and The Why.

Say No to Brogrammers

I have observed a disturbing trend in software circles where cocky, mean-spirited brogrammers infect development teams. Urban Dictionary defines brogrammer as:

1. brogrammer 151 up47 down
A programmer who breaks the usual expectations of quiet nerdiness and opts instead for the usual trappings of a frat-boy: popped collars, bad beer, and calling everybody “bro”. Despised by everyone, especially other programmers.
Oh my god, John is talking about football and chicks again. That guy is such a brogrammer.
programmer frat boy bro douchebag developer
by seldo Dec 2, 2010

I find the brogrammer vibe toxic for several reasons:

  1. Fun dies
    • Teammates dread coming to work.
    • Team outings become an insufferable chore.
    • Teammates can no longer laugh at themselves.
  2. Innovation suffers
    • Teammates fear hazing.
    • Teammates are afraid to speak up.
    • Teammates are afraid to fail.
    • Teammates are afraid to try something new.
  3. Productivity suffers
    • Teammates are not forthcoming. As such, disingenuous Iteration Retrospectives stifle self-correction.
    • Teammates are fearful of committing code without first performing checks and crosschecks.
    • Teammates are fearful of the potential humiliation of breaking the build.
    • Teammates are loath to ask questions for fear of retribution.
  4. Quality suffers
    • Teammates dread pair programming.
    • Teammates dread the humiliation of code reviews.
    • Teammates avoid questioning or debating a technical approach.
    • People-Haters use metrics like code coverage to flog rather than learn.

Two red flag artifacts of the brogrammer vibe are Build Monkeys and Nerf Guns:

  1. Build Monkeys – a stuffed animal, or mascot of humiliation, gleefully bestowed upon programmers who break the build (or otherwise defy bro-thoritarian rule).
  2. Nerf Guns – toy weaponry gleefully deployed to pelt & punish programmers who inadvertently imperil something as inconsequential as test code coverage.

Nerf wars seemed innocuous when perpetrated by the socially inept smart people we’d all grown comfortable working with on our software teams. But now that the brogrammer boys have entered the fray, the once innocuous joviality has morphed into mean-spirited team oppression.

“Let’s put the pro back in programmer…no more ninjas and definitely no more brogrammers.”
Daniel Hamlin, 7:33 PM – 25 May 12 Twitter for Mac

I value the people I work with much more than the technology, or the software product we’re building. I refuse to engage in this behavior and plan to defy Brothoritarian Rule.

Fear, hatred, and suspicion narrow your mind – compassion opens it.
~ Dalai Lama, 4:27 AM – 30 Apr 12 via Twitter

Additional Reading

Agile Anti-Patterns

A few Agile anti-patterns I have experienced as a developer are:

  • Business Allowed to be Lazy. A counter-productive friction exists between highly productive developers (held accountable by process metrics) and largely unaccountable business proxies. Often the business proxies abuse the flexibility of discovery in Agile and some use it as an excuse to be lazy or disengaged.

Why are developers asked to estimate a story if the business can’t articulate clear acceptance criteria or fail to deliver a simple sketch or wire frame?

  • Over-Emphasis on Velocity. Speed is mistaken for velocity. Velocity has two components – speed and direction. I’ve been on teams who were delivering working software iteration after iteration only to find we were building a product that was unusable, inferior, or somehow missed the mark because direction from the business was misguided or lacking. We focused on delivering, not on the product.

When the burn down shows “done” and the business has a product they couldn’t use or don’t want, it’s the business’ fault. Because the only way this could happen is that they didn’t show up to the demos, didn’t ever walk through the lab, didn’t talk to anyone building or testing the system. If there was no mechanism to make sure the blame was spread there, this is just pure corporate oncological dysfunction.
~Colonel Nikolai, post comment Oct 28, 2011 08:04AM.

  • What to do with Project Managers? Traditional PMs are too often shoe-horned onto Agile teams because the organization can’t figure out what else to do with them. Traditional Project Management is an extension of old-school Command & Control that savvy developers can’t abide. It is based on hard estimates and Gantt charts. I have observed PMs using Burn-down charts like a blunt instrument to flog developers.

Dear PM,
When you continually ask ‘Is it done yet?’, the veracity of the answers rapidly degrade to pure lip service.

  • Process Over Pragmatism. Teams often feel compelled to follow process for process sake or because it’s been decreed by the organization. The most effective Agile teams I have been on discovered what worked in the prevailing conditions. There is no one-size fits all.

Dear Process Cop,
Developers welcome process when it makes sense, but gratuitous ceremony is a waste of everyone’s time.

  • Standup as Status Update. Standup meetings seem to have devolved from the imagined intent to be informative and consequential to tedious status updates.

Dear Teammate,
If you don’t have something wildly informative or marginally consequential to say, please cede your turn. Standup is not CYA.

Do these seem familiar? Which anti-patterns have I missed? I welcome your feedback.

Silent But Deadly Guy

I get testy when the software community measures developers.

Many software projects use Sprint Burn-Down charts (SBD charts) thinking they are measuring Velocity.

My beef with SBD is that Velocity is misunderstood. I care most about the experience of a software product (e.g., general quality and usability). SBD is, at best, misused, if not useless.

Speed and Direction Define Velocity

We think we’re measuring velocity when we’re tracking the illusion of speed, and all the while, direction is AWOL.

Maybe speed isn’t all it’s cracked up to be. Here’s the thing:

We have already wrung most – if not all – the speed & efficiency we’re going to get from the  development team.

No more speed. No more getting faster. No more SBD.

If we want better software products, it’s time to critique the Teflon Players in the software equation — The Business. We’d be way ahead if we figured out how stakeholders can be accountable to the product team and to provide meaningful direction as a software product takes shape.

If you don’t know where you are going, it’s easy to iteratively not get there. ~David Hussman, 5:40 PM Nov 3rd, 2009 from TweetDeck

Silent But Deadly

The moniker Silent But Deadly Guy evolved during a software project that recently went up in flames. Silent But Deadly Guy was a gratuitous Project Manager the developers started calling Sprint Burn-Down Guy in recognition of his sole contribution to the effort — the daily Burn-Down chart.

Soon Sprint Burn-Down Guy was shortened to the acronym SBD Guy.  Then by a simple twist of acronym morphed into Silent But Deadly Guy.

The Silent But Deadly story encapsulates how I feel about ceremonial metrics like Sprint Burn-Down that have little to do with making kick-ass software.

Cadence is Crucial

There’s a delightful book called If You Give a Moose a Muffin. My forthcoming missive on iterative software development is tentatively entitled

If You Give a Clown a Metric

Cadence is the most important aspect of iterative software development. I am weary of misconceptions about velocity. I’m weary of re-treaded PMs turning velocity into a blunt instrument.

The Law of The Swift

Cadence is the vastly under-reported life-force behind iterative development.

So, two days into your second sprint, if your panic-strickened PM adds two new developers, then prods & pokes you about squeezing in another story or two, I advise you to diplomatically offer the reminder that

Half a Swift DOES NOT deliver twice the gas mileage.

This regressive misconception is formally known as Brook’s Law. Brook’s law says,”adding manpower to a late software project makes it later“.

Brooks more famously quipped

Nine women can’t make a baby in one month
~Fred Brooks

In the absence of distractive churn, seasoned developers need at least several iterations to establish a cadence. Forget the silly chart.

In honor of the 10th anniversary of the Agile Manifesto, developers who have, year after year, dragged dysfunctional balls & chains to the delivery finish line should not have to view another burn-down chart.

Adding a new developer mid-iteration is disruptive. Adding two new developers mid-iteration is, not surprisingly, also disruptive. Please don’t knock us off the beat. Let us play a few bars into the tune before you pull the fire alarm.

All we ask as developers is that succinct stories with a bulleted list of testable assertions roll into our purview like so many chocolate kisses on a conveyor belt. Then, please step away from the conveyor belt so we can syncopate while gorging on chocolate kisses.

Finding Cadence in Dysfunction Junction

Imagine we are rowing crew-mates. We’re sculling a river at an refreshing rate. Our cadence is palpable.

Now imagine adding a silly clown, with a silly clown-sized oar, into the mix. Imagine that the silly clown has no accountability to the crew, but has been ordered by a chief clown to stick his oar in.

The silly clown is ill-equipped since his oar is clown-sized. It’s immediately evident he derives no pleasure from helping you or your crew-mates propel the craft. He only wishes to demonstrate his paddlry.

The boat slows, then sharply veers off course.

In the Agile software realm, the clown with the clown-sized oar, is one flavor or another of architect (see The Chicken & The Pig). He fancies himself as a title rather than an agent noun. You can be certain he’s not on your team. If he was, he’d be called a developer…a developer who’s accountable to produce working software, rather than artifacts.

For every wildly productive Agile project, I wonder if there are about five or so that have gone off the rails into dysfunction junction. It bears repeating that the Agile Manifesto has four easy-to-understand guiding principles:

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

Easy to understand, but challenging to implement.

It’s a personal quirk, but one of my red flags is when people pronounce Agile with a long “i”. There are other red flags, some funnier than others.

Sometimes red flags make me long for the white flag of surrender, then I remember practice and discipline.

I’m not a musician. Yet it’s clear there’s a distinction between loving the promise of sweet music and coaxing a coherent tune from a Stradivarius. The hard work can’t be skipped. The practice can’t be ignored.

I’m not an Agile software coach. CIOs who have the foresight to hire a coach to kick off an Agile adoption should be commended. Hiring a coach for Agile 101 sessions is like learning to play scales. Necessary, but not Mozart.

Without continued practice in Agile discipline, well-intentioned people revert to putting in more overtime while getting less done. Stand ups revert to sit-ins.

CIOs who conceive of an Agile adoption as a few cheerfully upbeat coaching engagements are mildly delusional. A realistic Agile adoption probably means a minimum 6-month slog by an embedded coach (or coaches).

If the principles are easy-to-comprehend, why is it so difficult to make it work? One impediment is people don’t have ownership. Most organizations pay a bunch of salaried folks to ponder what they’d rather be doing. They don’t give a rip about agile-smagile.

I’m glad I’m not talented enough to be a coach, because

What do you do with well-meaning folks who couldn’t lift a feather in zero gravity?

Red Flags & Cadence

Your execution of agility might be poised to implode if your organization

  • prefers spreadsheets or software tools over low-fidelity PostIts and a Story board;
  • can’t seem to re-purpose the static and limited title of architect into something helpful;
  • separates the people using the software from the people developing the software;
  • seems ladened with command & control management who are cynical about change;
  • doesn’t comprehend the poignant parable of The Chicken & The Pig;
  • is reactive & accusatory, rather than thoughtful & nuturing.

If you recognize these, I urge you to hire a long-term Agile coach (or coaches). Ideally this person is half rock-star developer and half rock-star psychologist. With any luck, this person is also willing to slog it out in the trenches for months into years.


I suspect iterative cadence comes from something akin to an athlete’s muscular memory. If that’s the case, then think about, and retrospectively examine, how your behavior, your team’s behavior, and the organization’s behavior, reflects the four guiding principles in the Agile Manifesto.

Give it time and practice. Focus on the four guiding principles. Minimize distractions. Row, row, row your boat…every day, every week, every month.

Agile in Toxic Organizations

Perusing the Agile 2011 proposals, I wondered if anyone in the Agile space addresses coaching Agile in the toxic organization. I’m not a coach, but I feel the coach’s pain.

I have seen the Bright, the Lite, and the Dark Side of Agile. Please explain to me how one can be helpful bringing the dark into the light.

Do some organizations have too much of a baked-in reactionary culture to reap the bounty of agility? Are the pathetic schlubs walking the halls with their heads down merely avoiding the shrapnel of IEDs (Iterative Explosive Distractions)?

Do these soul-sucking organizations have enough banked karma to deserve the best intentions of passionate Agile coaches and the elbow grease of super-talented Agile developers?

Overheard on a speaker-phone during Project Chartering introductions:

“I’m Rose. I don’t know why I’m here.”

A subject matter expert with a meant-to-impress title, Rose made her deadpan introduction to her soon-to-be teammates.

Queue the crickets chirping.

Also remoting in, the speaker-phone voice of the CIO explains Rose’s presence in the chartering session and what Rose’s hoped-for participation would be on the team. Yikes. Gotta love that business buy-in.

Toxic organization is a loaded term. One characteristic of a toxic organization is that

The people most comfortable with command and control often mistake agility for the more familiar reactionary.

Just bark at me if you think I might ease your slither from the dark into the light. Otherwise, I’ll join my heads-down comrades in C-Sharpistan.