Typographical search continues. Font is Marker SD.
Source: Langr, Jeff and Ottinger, Tim
Index cards are an important part of the agile experience. We use them as tokens for user stories, for task breakdowns (sometimes), for backlog generation, for estimation, for reminders, etc. Here at Agile In A Flash, we use them as cheat sheets and motivational posters. There is a surprising amount of value to having an agile card posted in your workspace. Print one of ours out, and try it for a month.
Index cards are great. Why?
- They 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").
- They can be dynamically reorganized to order them by point cost, or functional area, or assigned teams, or originators. They can have connections one did not intend originally. This puts them a step above most software programs -- they are routinely re-purposed on the fly.
- They 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. They can have priorities added to them. They might have none of the above, only a two-word name. They can have pictures, and notes with arrows. If you have a card and a marker, your only constraints are space and penmanship.
- They are reminders for much bigger ideas. Being small, they can hold very little content. Yet they can have vast evocative powers. Take the agile flash cards on this site for instance. Once you know a principle or practice, a card bearing as little as three words can help you do your job better.
- They are extremely portable, being small physical items. 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. They don't mind being without web access and are immune to OS and browser incompatibilities. Whereever you are, they are the same.
- They are inexpensive and replaceable. Of course, you never want to be without your Agile In A Flash (tm) cards but most other cards can be lost without any real cost. If they are important, they can be easily reproduced. If not, maybe you didn't really need them. I think every day we can tear up a story card or two is a good day. They are not heirlooms to be maintained for the life of a project, and that makes them even better.
Nice post - I was just thinking about how much I like cards & this reminds me of a good way to describe the reasons why.
ReplyDeleteThese are the reasons why we'd never replace our physical story board with a scrum tool.
ReplyDeleteHowever, works only if the team is co-located.
One additional benefit is that you have to focus on what you really want to express with the card due to the limited space.
I'm working up a personal blog post that goes into why the tools are evil. In the case of distributed teams, thus, they are a "necessary evil," but that's still not an excuse for some of the vendors to build additional evils into the tool--the one I'm working with currently doesn't allow you to correct a mistake that has sat there for a while. "Build processes that prevent you from making mistakes" is what the vendor says.
ReplyDeletesome types of tools are great, but a tool that is focused on getting a team to do some work should produce an artifact that's always in the team's face,
ReplyDelete2 thumbs up for index cards?
Regards
Jeff
My agile blog
I actually recommend story-cards even when an organization still "requires" storing such things an a tool or database. Even if used solely as a means of requirements elicitation as part of a dialogue with the customer, they are still extremely useful.
ReplyDeleteOne advantage that I think was not mentioned above is that they impose a useful form of "content boxing" by limiting the amount of text available to write down about a story. This forces you to not only be more clear & concise, but helps "right size" stories by limiting them from being to verbose/complex in their initial expression.
Regarding "tools being evil" - I wouldnt quite go that far. I think the main reason there is such strong dislike for certain tools or kinds of tools is that they aren't a good fit for the way agilists need/want to work!
Many of the tools have models of usage hardwired into them that presuppose some aspect of waterfall phases or handoffs or social-separation of functional specialists from each other and/or of developers and their customers/management.
If the tools didn't do those things and were made from more of an agile perspective or especially a developer's perspective, I don;t think we see so many complaint's about their "evilness". I dont see many general complaints about code-editors, IDEs or version-control and build-tools being generaly "evil."
I think that's because those tools are deemed necessary and useful part of a developer's daily work. I may see complaints about some specific IDE or version-control tool, but rarely do I see them being categorized as (mostly) evil across the board. Because they are deemed quintessential to the daily activities of creating working software, by those who create it.