Your humble editor is a believer. When my significant other was managing editor of MacUser magazine, her most powerful management tool was a deck of index cards.
For the past year and a half, we have been creating Agile in a Flash index cards in blog form. These cards capture the wisdom of the Agile community plus our combined 20+ years of Agile and XP experience. The Agile community has generated many memorable mnemonics and lists, starting with the four values espoused in the Agile Manifesto, and including such stock phrases as “Red-Green-Refactor.” We’ve added a number of cards that represent our own inventions, such as Tim’s FIRST mnemonic that describes the qualities of a good unit test.
Our goal for the project was to produce a distributable deck of real, physical index cards. Many in the Agile community use index cards heavily to capture stories, later using these cards for planning and communication purposes. Capturing much of the essence of Agile thought in a handy card deck seemed so obvious to us that we’re surprised no one had done it before.
You can use the cards in many ways—as references, reminders, discussion points, posters on the wall, or even paper airplanes acting as air mail. You might even consider using them as the musician Brian Eno did with his Oblique Strategies card decks in the 1970s. The idea behind Oblique Strategies was to inject random ideas into the process of creating music, such as “Discover the recipes you are using and abandon them,” or “Go to an extreme, move back to a more comfortable place.” It’s amazing how many of the Oblique Strategies cards can provide useful insights for an Agile team. One card simply states, “Courage!,” an important XP value that mirrors one of our Agile in a Flash cards.
The cards in the Agile in a Flash deck can similarly work as triggers for new ideas. Struggling with what to tackle during retrospectives? Pull out a random Agile in a Flash card. Use the card to trigger discussions around how well your team is adhering to the advice. Then figure out what’s lacking.
In our eighteen months of blogging, we’ve produced almost 90 different cards. In preparation for publication, we carefully chose a deck of the best cards. The deck contains four categories:
The Idea—cards relating to Agile itself, including its values and principles.
The Plan—cards around stories, planning, and estimation.
The Team—cards discussing team practice, such as retrospectives, stand-ups, and pairing.
The Code—cards covering technical, code-oriented topics, such as TDD, continuous integration, and refactoring.
Each card provides a summary list or diagram on its obverse side and more detailed information—including nuggets of our experience-based wisdom—on the reverse. The nuggets are condensed, mind you: There’s not a lot of space on an index card to be wordy!
The Pragmatic Programmers are helping us realize our goal of distribution. We’ll share a few Agile in a Flash cards with you here. These are meta-cards—cards about the use of cards themselves.
We love index cards for their versatility as a tool.
Cards are low-tech and high-touch. You can put your hands on them, hand them to other people, stick them on the wall, tape them together, sort them on the desktop, etc. Having a tactile device such as an index card can make various workspace rituals possible (like moving a card from “in progress” to “done”).
You can dynamically reorganize cards to order them by point cost, functional area, assigned teams, or originators. You can use cards to discover and create connections that no one intended originally. This puts index cards a step above most software programs—you can routinely repurpose them on the fly.
Cards can hold schema-free markup. For instance, the security or documentation team can write notes on them. Developers and product owners can mark them up with issues or orderings. You can annotate them with priorities, pictures, or notes with arrows. Or they might be so stark as to contain only a two-word name. If you have a card and a marker, your only constraints are space and penmanship.
Cards are reminders for much bigger ideas. Being small, cards hold very little content. Yet they can have vast evocative powers. Once we discuss a story in depth, a two-word description written on a card is memorable enough to recall the discussions for the next couple weeks as we build the story. Our Agile in a Flash deck can also provide this power: Once you know a principle or practice, a card bearing as few as three words can help you do your job better.
As small physical items, cards are extremely portable. You don’t have to copy them to a USB drive or mail them to your teammates. You can use them on the bus, train, or hiking trail. The cards don’t mind being without web access and are immune to OS and browser incompatibilities. They move through airports without setting off metal detectors. Wherever you are, the cards are the same.
Cards are inexpensive and replaceable. Of course, you never want to be without your Agile in a Flash cards, but you can lose most other cards without any real cost. Tucking cards into jean or shirt pockets can expose the cards to the danger of a washing machine. But if they are important, you can easily reproduce your cards. If not, maybe you didn’t really need them (Mom always said, “It must not have been that important!”). Every day we can tear up a story card or two is a good day. Cards are not heirlooms to be maintained for the life of a project, and that makes them even better.
The Three C’s
Ron Jeffries refers to story cards as tokens. The cards do not provide every last detail to be implemented regarding a customer’s needs. Instead, when a development team has availability to work on something, the customer tells them a story about business needs. The team and customer discuss the story in further detail, until the team understands the story well enough to understand its scope and when they might be able to deliver it. The card captures a terse summary of the story, a simple placeholder or token.
The customer and team will need to continue conversations around the story as the iteration or sprint progresses. Often, the customer will omit at-the-time unnecessary detail when they first present the story to the team. The card is a reminder that both parties will have to continue discussions around exactly what should be built.
The specifics of what we’re building must ultimately be clear to the customer and the team who will deliver. The customer captures these criteria in acceptance tests, designed to exercise the system in enough ways to demonstrate that the feature really works. When all members of this set of acceptance tests for a given card pass, it confirms to the customer that the story is truly done—the software does what they asked. The nebulously stated card can disappear—the remaining documentation is the system plus its acceptance tests.
Story Card Format
Mike Cohn popularized this story format in his book Agile Estimating and Planning. It provides a simple template that you might consider for how you word the story summaries on your cards. “As an actor, I want to accomplish some goal, for some reason.” For example, “As an administrator, I want to see a list of multiple login failures, so that we can identify potential security breaches.” A story summary written in this form is almost like a condensed use case.
Using the story card template can provide some value. On a simple level, a standard template can help prevent wasteful arguments over formatting and wording. Thinking about the actors involved (the “as a” people) can help trigger the introduction of important stories that you might otherwise miss. The phrase “I want to” reinforces that stories are goals customers want users of the system to be able to accomplish, and not just technical pipe dreams. “So that?” As you write out dozens of stories in release planning, you’ll want to remember the rationale behind certain stories (but not all of them!) And sometimes understanding the “why” can trigger other useful considerations.
But before you insist that every card follow this rigid format, remember that the story card ain’t the thing, it’s a reminder that should stimulate more communication. It could be that the card has just one word on it, and that’s sufficient. During the course of your iteration or sprint, you’re not going to forget who the story is for, nor why it exists. Remember: The story card should disappear once implemented. The story details about what, how, who, and why are best moved to the acceptance tests.
We prefer a more spartan story summary on our card, viewing the boilerplate parts as oh-so-much-duplication that we would immediately stamp out if we found it in our code. But if you like the format, use it. Just make sure you re-assess the worth of your choices from time to time.
The cards we present as part of the Agile in a Flash project are tools, not gospel. They should help by prodding you if you get stuck and by giving you ideas providing guidance. In most cases, you should follow their advice unless you have darned good reasons not to. Even then, you should only take your own path once you understand why the advice exists.
Jeff Langr has been building software for over a quarter century. He is the author of Agile Java and Essential Java Style, plus more than 80 articles on software development and a couple chapters in Uncle Bob’s Clean Code. He runs Langr Software Solutions from Colorado Springs and happily builds software as an employee of GeoLearning.
In addition to developing the Agile in a Flash card deck with Jeff, Tim Ottinger has over 30 years of software development experience including time as an Agile coach, OO trainer, contractor, in-house developer, and even a little team leadership and management. He is also a contributing author to Clean Code. He writes code. He likes it.