If a picture paints a thousand words…

If a picture paints a thousand words….what do you use if you only have one thing to say?

I spotted this line on AgileModeling.com, in a description of the ‘Product Owner’ role:

“There is significant evidence that the worst way to communicate information between people is via documentation“.

I couldn’t agree more. How many times have you read something, understood it completely, only later to find that you were in fact the only person in the Organisation that didn’t understand it (whether due to organisational terminology or the age-old “That’s the way we do it and we expect you to know that”)…?

In fact, even the quote above illustrates the problem of agreement via misunderstanding. I’m assuming the term ‘documentation’ means ‘text’ in this case. It might not, in which case this entire post would be pointless – but we always start with some assumptions…!

Give me a face-to-face conversation with a Stakeholder any day, especially if it is in the presence of a whiteboard and marker or, at the very least, pencil and paper. I know of no better tools for illustrating / explaining a concept ‘on the fly’.

However, it’s not always possible to have Stakeholders and Analysts in the same room at the same time (even if we know that is the best option, it can be difficult to get the decision-makers to agree that it is a worthwhile use of their ‘valuable’ time).

So, what’s the next best alternative?

For me, it’s using simplistic diagrams throughout Stakeholder documents, and the ‘ruder’ the better (i.e. ‘rude’ meaning “lacking sophistication”, rather than “offensive”!).

I like the idea of ‘Agile Modelling’ and it is something I do all the time (even before I’d ever heard of the ‘Agile’ philosophy), mostly for my own benefit because other Stakeholders want to see the complete picture.
Now, for the sake of clarification, in this context:

Agile Modelling means ‘Creating diagrams and models in the Agile philosophy so they only contain as much detail as required at the time of use‘.

Agile Modelling does not mean: ‘Strutting up and down the Catwalk on tip-toes, wearing the latest Designer creations, using particularly erratic stride-patterns, while balancing a kitten on one finger and juggling telephone directories in the other hand’.

Agile modelling is a very simple, but useful, method of ‘sketching out’ the domain, the systems, the process etc. By creating ‘rude’ models of the domain / concept, it starts the conversation in a place where the details are obviously and explicitly missing. This is very deliberate and is quite productive in trying to figure out the starting point of the discussion because there are no / few preconceived ideas or assumptions represented in the diagram. Often, it allows Stakeholders to discover that, even amongst themselves, there are differences of opinion / understanding of a system. Where these rude models are used in Stakeholder documentation, interspersed among the text, they can help to ‘lead’ the readers’ understanding of the ‘big picture’ by starting with ‘bite-sized chunks’ and building on them.
(And, no, ‘rude models’ are not what you think they are and this has nothing to do with Naomi Campbell…!)

For example, this ‘rude’ diagram could be used to start the conversation about a centralised Corporate Payments system:

The point of drawings like this is not to illustrate a system or process. There is no real detail in the diagram to clog it up or, more importantly, that might bias the discussion. It’s not supposed to be accurate or complete and (despite some familiar-looking notation) it is most definitely not supposed to follow any particular diagramming methodology, other than whatever works for the gathered group discussing the subject. Stick-men, boxes-and-lines, circles-and-arrows… all are fine as are any permutation of these or any oher visual representation, so long as the gathered group / intended readers understand what they mean (and, if they are ‘new’ concepts to the audience, they can easily and quickly be explained since the diagrams are usually very simplistic).

By the way, the above was made using the free tools at www.YUML.me in case you want a ‘quick-and-dirty’ diagramming tool with no download required – great when you’re working at stakeholder locations and don’t want to wait to get something installed. Equally great at making it visually obvious that these diagrams are not the ‘finished article’. There are myriad tools like this: YUML is just the one I use.

I’m sure there are Business Analysts the world over thinking “Aaaghhh!!! Where would I be without my diagrams and how could I model anything?” and I understand that mind-set totally. If you’re using diagrams & models to communicate useful information to Stakeholders, they are definitely preferable to using text (although text is better for some purposes). However, there is no law that says every diagram must include every bit of available information.
In simple terms, if a picture paints a thousand words, what do you use if you only have one thing to say? For me, that would be ‘a very small picture’. If you take the ‘Agile’ philosophy into your approach to Stakeholder documentation, it becomes clear how best to use diagrams and models. Where you might use a very high-level diagram at one point in a document, you might – later in the same document – use a more detailed version of the same diagram, or a lower-level perspective of a part of the diagram, or an expanded diagram that includes some other functionality integrated into the first diagram. I find that this helps to reinforce concepts and helps to reinforce where each of the various ‘bits’ (deliberate non-technical term!) fit into the overall scheme of things – for everyone, no matter their level of expertise.

Finally, traditionalists might balk at the idea of using different-level perspectives of a diagram or model in different parts of the same document, instead of having one all-encompassing diagram and referring back to it with “as illustrated in Fig.1 on P.10” or whatever. However, by sticking with the philosophy of providing the level of detail that the User needs exactly at the time s/he needs it, it becomes much easier to intersperse sub-sections of diagrams throughout the text of a document. Plus, it makes the document far easier to read. It is much better to see the visual representation on the page that describes it, rather than having to jump back to P.10 and figure out which part of a diagram the text refers to. If you don’t believe me, just check how irritating it is to scroll back up this page when I ask you to re-read the opening quote from www.AgileModeling.com instead of just copy/pasting it in here…

Of course, this is just my opinion and is absolutely guaranteed to be biased by my own experiences, pet-hates and preferences… and I’m open to being contradicted and having my perspective challenged – just like any good Business Analyst!