Using the Cards with a Colleague

If you have one card set each, you can use the cards in even more ways.

Discussion

When you discuss an important design decision, use the cards to describe your arguments. As a key rule, you should never play out more than one card at once. Find the card that you think is most convincing and explain why this argument supports your preferred solution. Then it's your colleague's turn.

This ensures that you both have an equal share on the discussion which is especially helpful if one of you is more talkative than the other. As a result it's not the loudest person who has the most impact, it's not the quantity of the arguments that counts but it's the quality.

In case none of you has a strong tendency to one of the solutions, just randomly assign positions so the different solutions are all discussed. Even if you both tend towards one solution, it can be helpful to have one of you play the devil's advocate and argument the other way. Important decisions should not be made based on feelings but they deserve a discussion that uncovers all the relevant aspects.

Discussing Software Design

Arguments for different solutions

Prepared Discussion

Alternatively you can both take five or ten minutes to prepare the top three arguments for your solution. Use the related cards section as explained above. Then each of you explains the respective three arguments and enter a discussion phase afterwards.

Using the Cards in the Whole Team

Moderated Discussion

Some design decisions, normally those concerning public API and architecture, are so important that the whole team discusses them. Even more than discussions among two developers, these meetings tend to be dominated by one or two people while the others often do not get the chance to participate to the same degree.

Question and Action Cards

Using the same core rule as describes above (never play more than one card at a time) the discussion can be evened out. Junior developers have a chance to follow the argumentation as you have to explain why your argument is an instance of the argument on the card. And the experienced, yet quiet ones get a chance to provide valuable input to the discussion.

In such cases it might also be helpful to appoint a kind of moderator. Ideally this is someone who is not a direct stakeholder in the decision, a scrum master or a developer from another team. This moderator then gets the orange moderation cards and takes care that the core rule is adhered to.