A placeholder for a conversation

Agile ways of working have become so commonplace these days that I don't think we even refer to them as "agile" anymore. Rather it's just how we work. Over the past 10 years, I have seen this transition firsthand from having to get buy-in to even try agile practices to people not even asking about agile practices when interviewing because "it's just the way we work". But I think along the way we've also forgotten some of the basic ideas that made agile ways of working highly simple, effective, and fulfilling. Take for example the idea of a card (or perhaps a user story as you might know it).

What is a card? A card is a placeholder for an increment of value often expressed in the format of a user story. We could debate the pros and cons of the user story format, but let's use it for this example. For my current work at Dealkit, a card might look like "WHEN I'm done negotiating I WANT to be able to sign all documents at once SO THAT I can get this deal closed." My team and I might add some acceptance criteria. We might add some designs. We might add some test cases that we'll use to write automated tests and accept the story. But in the beginning, before work starts on the card it's just a card. It's just a title with perhaps a few rough ideas. And perhaps an estimate.

At Dealkit, we've recently been starting most of these activities on a card when pulling it. Of course, we're a team of 3 people so that's perhaps easier than working in an organization of 100 people. But still, we start figuring it out when we pull the card. As I learned long ago, a card is just "a placeholder for a conversation." When we pull a card, we start a conversation to figure out the details. We figure out the acceptance criteria. We figure out how this might fit into the bigger picture. We sketch a rough design. We start implementing it. We demo what we're implementing to each other and share feedback and suggestions. We iterate, test, and ship it a few days later. Then we show it to a few users. Then we iterate some more if needed creating another card.

This is arguably a fairly simple but effective approach but I bet you might already have a few objections to it. What about the lead time to conduct research, create designs, and validate everything along the way? Sure you could do that. But why not just start the next most valuable thing and figure it out along the way? Why not build an architecture and organization that's optimized for being able to work in that way? It certainly has fewer dependencies and is more fulfilling for me as part of the team doing that work. The decisions we make are based on the most real-time version of reality. And it can still be transparent to the organization. We update cards along the way with designs and notes. We record and share Loom demos. You can always check the card for the most up-to-date information or ask a question.

I think part of the aversion to working in this way of pulling a card and then figuring it out is an aversion to being uncomfortable. It's a common trait of human nature to want a feeling of certainty. Pulling a card and figuring out the design and implementation in real-time can be challenging and uncomfortable, especially when paired with having to collaborate and align with other human beings. Perhaps doing upfront research and design and refinement produce a better product. But I think part of the impetus for those activities is trying to bring back the feeling of security we find as humans in big upfront planning and design.

Upfront design and planning activities can help us feel like we're in control when we're really just throwing spaghetti at the wall. It's not that those activities aren't valuable. I still find it helpful to at least create rough sketches for a large body of work (a feature, epic, etc) before diving into the details. But if we are honest and zoom out there are a lot of other factors that will determine the success of a business. Things like product market fit, customer acquisition and activation, pricing, packaging, serendipity, and a good bit of timing and luck. So while I want to be part of creating a helpful product that users love I also want to be part of shipping things into the real world so that we can get feedback and iterate based on what we're learning in the real systems of the real world. And so for now I love having cards that are just "a placeholder for a conversation."

Wishing you spacious work,

-Adam

This post is part of my Spacious Work series, exploring mindsets and practices for more humane, enjoyable, and fulfilling ways of working. If you enjoyed this post, consider subscribing to be notified about future posts, and letting me know what you found helpful in the comments.