A product manager recently requested that we start using an electronic card wall because they couldn’t find a card. The question certainly got me thinking. What happens to your team and delivery process when you use something like Jira, or Leankit or the like? Here is an attempt to answer.

The answer I give is limited to my personal experience. Fifteen years working in software development creating applications for tasks such as medical and hospital services, police investigations, criminal surveillance to the more mundane selling insurance, houses and hotels.

During this time I’ve worked full waterfall where it worked really well (yes, I just said waterfall works) and when it didn’t, through more modern ‘agile’ in small companies and large enterprises, I’ve also worked in what my old boss called “post agile” others may call that “Lean”. I tend to over-simplify so feel free to disagree.

I personally find what happens when you have an electronic wall is that you raise cards for everything. This initially sounds great as then you don’t forget stuff. What actually happens is that you end up with a shed load of cards that you never actually do.

When you have an electronic wall you raise cards for everything

Now you have tens/hundreds of cards all in little electronic cards. Obviously you can only see the first n letters so they all say “As a user I want to…”. Not that helpful. Or possibly worse because of the limited view of the title in electronic walls you ditch the whole context of a card title and start writing things like “Update HotelsCollectionRFLD”…? WTF? WTF what does that actually mean?

Anyway now we have lots of lovely cards it means that many people can spend much time in prioritisation meetings moving jigsaw pieces around a virtual card wall (just check out any Jira card history for an example).

There does however seem to be a plus side with an electronic wall as you now have the ability to write stuff in the card. This allows many, many edits to occur during the extended lifetime of the card, by which I mean the months the cards sit in the overcrowded, overly analysed and prioritised backlog. This creates what I like to call “a slack channel for every card” or for the more enterprise amongst my readers, think of it as an Outlook folder where you put all the emails that pertain to that story card. Many cards many Outlook folders. Oh the warm feeling of ‘cleaning up inboxes’ on a Friday arvo.

I don’t need to kick this card off

What happens then is that developers take what is in the card as gospel, they read all the notes and think, “I don’t need to kick this card off” and happily start writing .net code. The problem is that their understanding is wrong so they code the wrong thing.

Isn’t this why we have testers to find those things*? Well when finished the card either mysteriously jumps the fence to QA or possibly a handover occurs with the BA and QA. Whereupon we find we have coded the wrong thing and hence bug cards can be raised. Once raised the bug cards plainly need to be put in the backlog and prioritised….

And so to using solely a physical card wall. On the physical wall a card is small. This is fundamental to what a card means, some book somewhere** noted that “if the detail of the card is too big to write on the card then the story is too big”. As a general rule I agree. On the whole I thought that book was quite good.

if the detail of the card is too big to write on the card then the story is too big

So you have a wall with cards. Because the cards are a finite size the stories are kept small and because a physical wall is a finite size you only put the cards on the wall you’re going to do. Basically you concentrate on the stuff you are actually going to do, and you do it. Because you’re only working on the important stuff the amount of card maintenance and prioritisation incurred decreases hugely. And because the details are kept to a minimum this forces the development team to work as a team and talk about the feature. Everyone has input into the card, everyone takes ownership. Problems are fleshed out, acceptance criteria are discussed, testing is discussed. Due to this discussion everyone understands what the card must do and why they are doing it, and because of this joint understanding errors are minimised and hence bugs greatly reduced, pretty much to zero.

Right about here we could talk about increased velocity and the like but I leave the pretty graphs to others, I’m a tester, I just like to see a wall without any pink cards on it.

Errors are minimised and hence bugs greatly reduced pretty much to zero.

So what do we have here at the wash-up at the end of the day? I guess we can synthesise the options down to the following:

The electronic card wall is excellent for the modern enterprise agile culture where there is a management structure to keep busy, business operation is fat and process rules over delivery. It allows your staff to write many emails and have lots of meetings. It allows your teams to be disjointed and not really work as a team with a sole purpose. I guess what I mean is electronic card walls tend to attract excess process and create bloat. If your team all sit in the same office don’t use them, if you use a distributed team located around this blue planet then its probably the best bet but always remember the pitfalls and ensure you always use video conferencing calls randomly throughout the day rather than only at specific times like standup. Always. Always. Talk.

The physical card wall is beautiful for pragmatic lean software development. Where developers, business people, testers, the CEO, marketing etc all work together for one single goal and are located close to each other. It encourages conversation and discussion, its good for a sense of shared vision and ownership. It ships software fast.

As for my product manager and their missing card… it was on the wall all the time.

* Note on why you have testers. The foremost requirement to enlist the services of a tester is to mitigate against producing errors. They are not a door through which only correct functionality walks.

** The book was User Stories Applied by Mike Cohn. I talk about this book in this post.