29 January 2010

Backlog Logjam

log jamWith Twitter hash tag #rethinkingbacklogDavid Hussman mused

I see many people who hear backlog and think "things I will never get"
Then he asked
Is it time for a new word?
Here's a sampling of the responses to David's query

It might be a hayseed rearing in one of the Little Boxes made of ticky-tack in the sardine suburbs of Tony Soprano's New Jersey, but I suggested Hopper. No reaction. Crickets chirped on Twitter. So let me explain.

If Agilistas used Hopper instead of Backlog, then hoofed ruminant programmers like me would be gravity fed! It's unnerving to programmers when there isn't a stream of mouth-watering cud ready to be digested. Programmers wouldn't be beholden to trying to think for, and prod, hapless product owners. Immutable gravity would move whatever shit they tossed in.
hungry pig

Most so-called product owners do not know enough, or are not engaged enough with the vision for the product, to prioritize things...unless it's a startup and it is your bacon smoke going up the chimney. Otherwise, the concept of product owner makes no sense in the typical corporate paradigm. You don't have ownership unless you actually own it.

As a hungry programmer, I like the image of positioning my pie hole below the spigot.


In the corporate realm, I wonder if the more common scenario than a backlog so large people are concerned if stories will ever get into an iteration, is having a backlog so thin that well-intentioned people are scrambling around 10 minutes before iteration planning to make sure there is enough cud to toss into the UCS, or Usability Calamity Software (aka, agile tracking tool), for the salivating programmers.

This opinion might be slightly tainted by an un-coached, agile-lite project I once worked on. Please don't try agile without coaching.


Search the #rethinkingbacklog thread started by David Hussman on Twitter to see more replacement candidates for Backlog.


Thanks David - you spark some of the best discussions.

26 January 2010

Oppose Internet Censorship

I have joined Aussie mate Ergun Çoruh, author of Negative Matter, in support of The Great Australian Internet Blackout.

I believe everyone has a responsibility to oppose state-sponsored control (and censorship) of the free, transparent, and responsible flow of information over the Internet whether in China, Australia, or your home country.

From Monday, January 25th to Friday, January 29th, Aussie websites will turn their lights out — black out — to inform Australians and the world about the insidious threat of state-imposed Internet censorship.

No posts this week in recognition of the black out.

16 January 2010

Google's New World Order

In January 2006 Google's launch of a censored search engine in China was considered a black day for freedom of expression. Google believed the benefits of increased access to the Chinese people outweighed their discomfort in censoring some results.

It must have been difficult for Google executives to consider walking away from the potential AdWords and AdSense revenue. So they didn't.

The Electronic Frontier Foundation (EFF), an international non-profit digital rights advocacy and legal organization, criticized Google's capitulation with the Chinese government.

Fast-forward 4 Years

In A New Approach to China, a frustrated Google throws down the gauntlet to the Chinese government
no more censorship on google.cn
Co-founder Sergey Brin, the son of persecuted Russian Jews, is likely Google's conscience in this scuttlebutt with China according to the musings of Ken Auletta (journalist and author of Googled - The End of the World As We Know It).

Danny O'Brien of the EFF recently said of Google's turn-about
we'd now like to be one of the first to commend Google for its brave and forthright declaration to provide only an uncensored Chinese language version of its search engine.
I recalled Newman's most sage-like warning from an episode of Seinfeld - the American television sitcom from the 1990s
alright, alright, alright you go ahead, you go ahead you keep it secret, but you remember this...when you control the mail, you control information!

The first distinguishing characteristic of the new World Order that global conflicts are not always government to government. Conflicts are now corporation to government as well.


09 January 2010

Integrating Interaction Design Into Agile Projects

Thanks to advocates in Agile community, many software developers have gotten proficient at delivery. Perhaps now it is time to examine what we're delivering.
Better questions and attentive listening might avert those occasions where we do an outstanding job of delivering the wrong thing.
Discovery & Delivery

At last week's last week's CodeFreeze 2010 on the University of Minnesota campus (my alma mater), speakers David Hussman and Jeff Patton were wearing t-shirts that said Discovery & Delivery.

The authorized theme of CodeFreeze was Redesigning Agility. The unauthorized theme might well have been as David and Jeff's t-shirts said -- Discovery & Delivery.
How do we integrate Interaction Design into our Agile projects?
Looking retrospectively beneath the vaulted glass and wood ceilings of Memorial Hall, where CodeFreeze was hosted, one might conclude that the Agile community deserves kudos for improving our ability to deliver software. One also might conclude that we have yet to make significant progress integrating interaction design and usability into the Agile cookbook.

Interaction design and usability considerations will continue to play a significant role in whether people are satisfied using our products. We had better jump on the design band-wagon, or at least appropriate all the most forward-thinking interactive designers as our own.

Jeff Patton posed the following question to the CodeFreeze audience
If you evaluated the quality of your process based on customer satisfaction, what would that process look like?
Jeff's question helped solidify an approach I have been considering for months. Three influences on my thinking are:
  1. Google's slogan of Launch Early and Iterate (see my post Launch Early and Learn);
  2. Eric Ries' concept for startups of a Minimum Viable Product; and
  3. At CodeFreeze, watching Alan Cooper talk about Interaction Design and watching David Hussman and Jeff Patton talk about Discovery (e.g., Story Mapping).
I have concocted a recipe for a discovery & delivery process that I am eager to share and to take for a test drive.

User-Driven Rapid Prototyping

Lets call it User-Driven Rapid Prototyping. As the name implies, the approach involves rapid prototyping. It is also user driven because the people who use the application help the software team prioritize the backlog.  The challenge and proposed approach are a follows:

Integrating Interactive Design into Agile projects
Iterative Cycles of
  • N weeks discovery and 
  • N weeks coding & delivery

The diagram below shows what the iterative cycles of User-Driven Rapid Prototyping might look like

  • The hand palming the spiral is a Discovery or Re-Discovery Iteration
  • The subsequent handless spirals are Delivery Iterations
  • Discovery iterations, after iteration zero, are called Re-Discovery
  • Odd iterations are for coding and delivery, while Even iterations are for discovery (interactive research and design).
The software team consists of developers and interaction designers working hand-in-hand. Since the backlog will be now driven by the people using your software, the over-worked and frequently clueless Product Owner we're familiar with from Scrum, becomes redundant.

Iteration zero -  Iteration zero is a discovery iteration. The goal is to learn as much as is reasonably possible about the community for which you are developing the product. Iteration zero might include chartering, creating personae, and story mapping. Also it might include any of the groundwork you typically lay before iterating in earnest.

Iteration 1 (and Odd Iterations) - Iteration 1 is the first coding and delivery iteration. Iteration 1 might only include some user feedback screens, or a polling mechanism to enable the people using your application to help the team prioritize features, to call out usability snafus, and to bring to light potential design problems. In general, odd-numbered coding/delivery iterations are for adding new features and releasing a deployable prototype. During coding iterations, developers are coding while the interaction designers are working to stay ahead of the coding/delivery curve with ongoing user research and design deliverables.

Iteration 2 (and Even Iterations) - Iteration 2 is the first re-discovery iteration. The re-discovery iteration is a chance for the interaction designers to account for any feedback, then implement course corrections as needed. During this time, developers work with interaction designers to address the feedback, to re-factor code as needed, and to plan the next delivery.
Designers engage in "designing with your hands" which involves making multiple, low-resolution prototypes quickly
~Tim Brown, CEO of IDEO
There is no one-size-fits-all software process. There are conditions that are likely more amenable to the approach proposed here. Greenfield software projects and startup projects might be most suitable. For example, in the evolution of a startup, an ever-improving prototype might be used to attract rounds of investment to fuel continued development phases.

Wouldn't it be a kick if the picture below could just as easily be the people using your software as the people crafting it?

  • Tim Brown urges designers to think big in this video on Design Thinking.
  • In Usage-Centered User Stories & Story Mapping Part 1 and Part 2, I explain what post-Agilists like Jeff Patton and David Hussman, have been telling the Agile community how we might help teams enrich poorly conceived user stories and how we might better use our iteration zero time for product discovery. That is, how discovery might be improved.

02 January 2010

Curling Software

Over the past few months, I have the pleasure-filled dumb luck of working with a very smart and very funny person to review and edit a book about producing software written by a very smart and very funny mutual friend and mentor.

In anticipation of reviewing the final chapters, the very smart and very funny co-reviewer of the book, who coincidently is learning the sport of curling, tweeted to me from the Bemidji Curling Club about our upcoming collaborative editing session. I paraphrase the tweet:
Hopefully we'll get a good rock, take it to the house, and land it on the button.

All I know about curling is what I've learned from Wikipedia, but I'm a sucker for metaphors that help me understand what is we software developers do.

I haven't made a resolution for the new year, but I hope the upcoming decade is one where I can distill the navel-gazing goo that oozes like a Jell-O drip in our community, see things clearly and do some practical things with a healthy dose of humility that makes incremental progress.

Curling software is the anti-movement software movement. Curling software needs no manifesto.  And
We don't need no damn certifications
Curling developers out there know who you are. We're the people in black wool top coats and hats waving our brooms... unlike all the folks traveling to conferences in the neighborhood of make believe to talk about waving brooms.

Our call to action is simple, since all we do is
move the rock
Our goals are straight-forward, since we team up to
take it to the house
Our ultimate quest is somewhat elusive - like the meaning of life - nonetheless that doesn't stop us from trying to
land it on the button
  • The book, written by a very smart and very funny friend and mentor is coming soon to the Pragmatic Bookshelf.
  • The curling competition of the Vancouver 2010 Olympics will be held at the Vancouver Olympic/Paralympic Centre in Vancouver, BC.
  • Curling is on my bucket list.