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.