Finding the Software Nectar

I have quirks. One has to do with information workers named Jerry.

When I meet a Jerry, I’ll insist that this new Jerry suffer the whole Seinfeld sitcom shtick where I, in thinly veiled disgust, say

“Hello Jerry”

and he, on queue, snidely responds to me with

“Hello Newman”

This all started years ago with a Microsoft practice director named Jerry. The shtick with this particular Jerry works well since I’ve long suspected we don’t trust each other.

“You know who you are, Jerry.” 🙂

This Seinfeld repartee amuses more than embarrasses (although increasingly more Jerrys have never watched the 1990’s Seinfeld TV series).

When I find myself enduring an insufferable meeting with Jerrys, my Jerry-tick possesses me like a pesky eye twitch. Every time this Jerry makes a constructive suggestion, I’ll respond with

That’s gold Jerry, gold!

It’s obnoxious, but I’m no Kenny Bania.

I apologize, in advance and in arrears, to Jerrys future and past.

Many agile software teams are burdened with stakeholders and product owners that set direction grounded in whim rather than on hard data. My guess is that most product owners don’t possess savant-like industry knowledge.

I’ve had it with coding to whim.

Should the next step be sarcastically applying That’s gold Jerry, gold! across the range of names to software product owners setting direction based on whim?

Many species, like honey bees, must forage optimally to survive. There is too much churn on most agile software projects. Burn-down charts have developers buzzing, but today’s programmers are worker bees bewildered by the fog of business whim.

There must be more efficient means to find the nectar.

Scrum’s Achilles Heel & Where Scratch Meets Itch

Anders Storm, Head of Development and IT at Tekis AB, posted a cogent reminder of all that’s good about Scrum (see Anders’ post Why I Like Scrum! on his blog Product Development).

Scrumbaya (like Kumbaya)

Anders and I share many of the same likes about Scrum. Scrum was my first step into Agile (thanks Markus). I started a jaded curmudgeon (my apologies Markus), but my Scrum-mates revolutionized my thinking. I am grateful to the pioneers of Scrum.

I like Scrum for its humanity, accountability, explicit trust in programmers, and inherent fairness.

Needs Improvement

I have one criticism of Scrum, but it’s a big one…

The Achilles Heel of Scrum is the Product Owner. The Product Owner is a serious flaw in the approach. In my experience, Product Owners operate on notions about what’s most valuable (what’s a high priority), rather than on verifiable data.

The Scrum community applauds itself for its transparent burn-down charts and their inherent “velocity” when what they’re actually transparent about is speed (e.g., because the direction component is sorely missing).

It bears repeating that

It doesn’t matter how fast we deliver, if we deliver junk.

Verifiable Value

Scrum must evolve beyond the concept of a limited user proxy, like Product Owner, then figure out ways to better understand, measure, and verify the user experience.

In almost all cases I can think of,

the people actually using our software is where the scratch meets the itch. 

Our goal, as always, is to produce incremental value. But in this case, it comes via verifiable value (direction) and not just speed.

I am looking for ways to get to Verifiable Value and to limit Seat-of-the-Pants Guesses.


Nothing Gums Up a Well-Oiled Agile Team Faster

I ran into fellow Agile-ist Chris Bartling in the halls of the fine organization where we both consult on different projects (I’m working with an enthusiastic team building a collaborative community called Law School Exchange).

We yammered about the importance of Product Owners grooming and feeding the backlog. Today I noticed Chris blogged about, what else? … The Importance of Grooming the Story Backlog.

This is often overlooked. But as a well-traveled, in-the-trenches developer I can say that

Nothing gums up a well-oiled Agile team faster than the business not feeding the hopper with meaty stories.

The first step is understanding what makes a useful story. Lots of people have written about, and know much more about, useful story generation (e.g., Agile coach David Hussman).

I volunteered to help our business side write story cards for a couple of Sprints ahead; they were not keeping up with our dev team’s appetite. Developers love meaty stories.

Fortunately I have earned the trust of the Product Owner, so that I can say “We’re on the verge of flailing, how can I help?”. I met with him and his lieutenants for 3 hours yesterday afternoon. We generated about 20 meaty stories.

I hoped to suggest, in a non-abrasive way, the kinds of things that help developers be productive after, for example, reading the tests that constitute done, on the back of the story card.

Here are 3 simple things I hoped to impart about Story cards:

  • Meaningful story title (card front);
  • Blurb encapsulating the gist; AND
  • Tests (card back) that “constitute done” using personae (e.g., Law Prof Larry can mark a document “private”).

Once we understand how to write a useful story, the next step is make a grip of them. Lay out the path as far as you can. Developers love that. No one wants to see the business flail. When a Product Owner is not allowed to focus on the product, and starts to flail, projects get axed.

Product Owners need to be several Sprints ahead in the Backlog. I also suggested to our Product Owner that he have weekly meetings with his lieutenants to GROOM and FEED the backlog.