Describing value using Situation Cards

EDIT: I have since found out that Situation Cards are really similar to Social Story and Comic Book Conversations.... read more here

A while back I wrote about situation cards, which Dan Rushton and I came up to help connect developers with the reason why we were doing a particular story.

Our team works on systems where we are essentially passing messages between different services which is particularily difficult (read: boring) to demonstrate in the review. We all hate Powerpoint but looking at Fiddler or SoapUI is way more dull.

Dan's brainwave was to use the situation cards to introduce the stories we had worked on during the review. The feedback from the stakeholders was excellent and they wanted to see this happening earlier in the process.

We now include making situation cards as a part of our prep sessions. We ask the team "How would you explain the value of this story?", putting them in the place of the customer. Sometimes a single card with a one-liner can be used, usually it takes a mini dialog to explain the value:

In the example above, the value stems from additional information to help the customer pin down issues in an area of logic which is hidden from them. By handling the error differently we can show which data item is the cause allowing our customer to find the problem in the logic that drives the output from simply asking the customer which data item are showing as errors.

You might notice that it took me a lot more words to describe this than we used in the situation cards but the level of detail is essentially the same.

This does not happen by accident - a series of conversations happened before we came up with the dialog in the situation cards. The words are not accidental, we arrived at them through discussion.

The cards provide context which helps but they also act as a constraint. At a very simple level, we have very little room! Further, when we are writing them, we are thinking about how we will read these during the review - they need to be short and direct otherwise you sound like a crazy person.

We can easily refactor conversations to convey the value in as few cards as possible by changing the dialog and removing cards.

We have a series of these to represent different situations - we usually use the man on mobile to covey the customer and the man at the workstation to represent the response from the team. We also have a man in a call centre to represent interactions with our customer's customer which has come in handy too.

These become Powerpoint presentations which we then use as initial storyboards in TFS - we simply attach them as storyboards which are stored on our local network. We create them in prep and then use them when we introduce the story to the team to kick start the understanding of 'Why' we are doing this story, which is what we originally intended these cards for.

Interested to know if anyone else uses these or something similar - feel free to leave feedback if you have :)

Don't kill good behaviours

Just recently, an update to GMail totally threw me when it subtly changed the way it did something that I use many, many times a day. Although this change probably seemed trivial to the team at Google, it really has been a pain in the neck for me.

Changing the user experience for a popular piece of software is a difficult tightrope to walk. Too little change and you stifle progress whilst changing it too much risks loosing or annoying the user base.

So what caught me out? I get a notification of what has changed in my groups as a top level entry in my inbox. I found this useful since I could simply go to the group, see what has changed and read the items that were of interest at that moment. I return to my inbox and the notification would be removed - happy days.

The update has subtly changed this. Now, it seems to want me to read ALL of the items the notification is related to. If I don't then the notification remains at the top of my inbox until I have viewed everything it relates to or I simply dismiss the notification by swiping it to the left.

This is a tiny change in all reality, it could even be a mistake but I find this change in behaviour very annoying since it requires more action from me. I imagined how this might have been recorded:

Given 1 or more groups have been configured
When the user enters their inbox
Then a notifications is displayed for each group that has new mail
  And the notifications are at the top of the inbox
  And the notifications are ordered descending by the amount of new mail in the group

It has long been my contention that the words we use in scenarios are often a bit sloppy. In this case you could easily interpret this in 2 ways, which revolves around how we interpret a 'new' mail item. Is a mail item new if it has never been opened or when it has been seen via clicking on a notification?

By not really explaining what 'new' means we may have killed existing behaviour by simply misinterpreting what the original intention was. In this case the word 'new' is not clear as it is open to interpretation.

A good practice is to think how this could be interpreted in the future. Would this be exactly the same as now? If there is any doubt, then deliberating over the words used is a good use of time. The emphasis should be on the author to think about this rather than make the assumption that the reader will interpret correctly.

It is worth thinking about what you know and they don't - the conversation for my scenario may well have included what 'new' meant or it could have been well established by that specific team. Since it completely missing from the scenario, we will never know.

As the author we have access to the whole context of the conversation, so the odd word here or there does not appear to matter. If we take a step back and put ourselves in the place of our intended audience we can often see assumptions we have made and save them a lot of time and effort in the future.

Connecting developers with the customer's problem

The holy grail may be that developers engage with their customers but there are plenty of situations where this can be difficult. Sometimes, it is also unclear who the customer is especially when the product is sold to public institutions - is the institution the customer or the members of the public that it serves?

I found many companies still have barriers between the developers and customers. Although they are often working to break these down, institutional change is usually slow. The more people in the way, the more chance the 'why' is lost and the problem is not addressed.

I wanted to come up with a way to connect the developers with the concerns of the customer irrespective of how removed they were. Collaborating with Dan Rushton, we started to think about conversations that would help make that connection.

All the way through this, I had Melissa Perri's excellent phrase 'Problems not features' ringing through my ears. I wanted to expose the problem we were trying to solve for the customer.

We eventually came up with a concept where we imagined the developer overhearing support calls in a call centre. We saw this as the primary interface for many customers with the companies that provided them with services. We also felt that this would be how a company would get most of it's feedback about it's service.

We thought that overhearing the customer explain the problem they were experiencing would provide excellent context for the developer to better understand why we were building something to solve that problem.

Our first thought was to simply role play a conversation but felt that this would not involve the whole team and could make people feel awkward. We wanted it to revolve around a conversation that was focused but also collaborative.

We then started to think of a storyboard that we could create to convey a conversation. Knowing people can be a bit funny about drawing in groups (unless you work with creative types of course who usually ask for more art materials), we came up with the a neat idea that we called a Situation Card.

The Situation Card is a bounded box and contains a single character in the form of a stick man. A simple conversation needs only 2 types of Situation card - one for the customer and one for the call centre member of staff. More complex conversations can use more types of cards - we created ones for people doing surveys, developers working at their workstation, people on their mobile phone etc.

The character is in one corner and has no face allowing the team to add speech bubbles, thought bubbles, facial expressions etc to convey the content of the conversation.

We found A5 was a nice size. Laminating them means you could re-use them. Here is an example of a Situation Card for a person on a mobile phone:

The conversation is told through a series of Situation cards laid out like in a line or columns like a comic book or story board. You can limit the amount of cards so that the conversation is short and concise - you can also refine or refactor pretty easily since cards can be removed and rewritten easily.

The idea is to tell a story and link the problem the customer has with the feature of your product that solves that problem. In telling the story you can use cues like 'If you could hold the line, I just need to check with my manager' to stimulate conversation in the team and check facts or confirm understanding before continuing the conversation.

The conversation can start off as a complaint and then be refactored to a support call, where there is a happy ending since we have the perfect feature to the solve the customers problem. The process of creating the conversation allows the team to better understand the role of the feature. We also think it could be a good way of exploring if a feature does what we think it does, although we have not tried that yet.

In the experiments we have had so far, we found this useful for connecting the problems of the customer with an unseen bit of infrastructure or service which has no interface as such but still has a part to play in the service being provided.

Still a work in progress, I will post up some examples as soon as I can.

Christmas cards for your competition?

The Internet has thrown up some very counter intuitive business models in the last few years. In time, some of these could well be shown to be daft but for the time being they are on the cutting edge of business.

Conventional wisdom would suggest that having no competitors would be an advantage but in a market place as large as the Internet I think you need competition to ensure any sort of customer base.

Imagine a start up with an innovative idea. There is no established sector but there is potential to attract them, probably from other sectors that are related. Or maybe an established company with a niche product that needs to attract new customers to ensure growth or stability.

This is where competition comes in handy. Although you are all after the same customers, you are all marketing and drawing people to the same sector which advertises both you, your sector and potentially your competitors. So, you win some sales, you loose some sales - but you do stand a greater chance of getting them with competitors doing the same.

Different marketing strategies will target different people and conversions are not always obvious or guaranteed. So once the sector is discovered, customers will often look for competitors to secure the best service and/or price.

I would go as far as saying that entering a completely new sector would actually benefit from competition, so why not create some? You could open source your product and actively encourage people to provide a competing service to stimulate the sector.

Competition ultimately fosters innovation. Each company will be looking at their competition, assessing their products and comparing with their own. This basically creates a feedback loop, where we can reflect on what works and what doesn't work and plan what to do next. We get some new ideas from this new perspective, which starts the loop again from our customers perspective.

Our competitors also push us to iterate ideas faster, to forge better relationships and basically be better than them to ensure we get and retain our customers. All good things, if you ask me.

Complacency is too easy to fall into if we have no need to change. Competition forces us to look for value and act. Our competitors should be considered a mirror - what can we learn about ourselves by looking carefully at what they are doing?

After I wrote this thought process down, I found some other people with the similar points:

http://www.forbes.com/pictures/fgdi45eekll/5-reasons-why-competition-is-good-for-your-business-2/
http://www.shaunrosenberg.com/10-reasons-why-competition-is-a-good-thing

What does that mean?!!!

I hate three letter acronymns.

I think they represent a past that we have hopefully left far behind. They obscure conversation and serve only to make people think they sound intelligent. Unless you are a part of the club, their meaning can often be shrouded in mystery.

Over the years I have witnessed a massive change in the type of person who has ended up being involved in IT. I can still remember when it was unthinkable that anyone without a degree in comp sci could write software.

As the Internet gave everyone a new platform to write software for, the tools became more approachable and now everyone is invited to the party. This has been the single greatest change in IT and has brought about a new generation of conversable developers.

I will credit Dan Rushton with this phrase, it's a good one. He also bagged the domain where you can check out his ramblings.

I like to think that we can solve all the technical problems that are thrown at us. The bit we are missing is understanding what it is we are actually developing. It should be easy, right?

The idea that a specification can detail everything is frankly insane. If it could, it would likely be unreadable. The future is through the oldest of all forms of communication - conversation.

Conversations are the corner stone of agile software development. Nothing allows a team to convey ideas and gain understanding faster than conversation. If there is a problem, you can guarantee that a conversation will enable people to get to the bottom of it. If it's important, you pick up the phone and talk about it. Conversation is a natural instinct.

Although business value is pinned as what we are trying to uncover, I cannot see how this happens without good communication. Good conversations enable us to uncover value at all levels of the organisation. It is the unseen foundation for all agile principles.

As a developer, communication transcends all other issues. It is key to the success of my code and the organisation I work for. So, I write about my adventures whenever I can. Enjoy :)