Updated in February 2016 after I discovered the recently-launched ‘Textografo’ (here). It’s an excellent, intuitive online tool for generating quick flow charts (other diagrams are apparently on the way). I recommend it even for non-technical people because it makes flowchart-creation so quick it can easily be done on the fly in meetings etc. almost as quick as pen-and-paper diagrams (but without the hassle of turning them into digital diagrams later). There is a free version (limited to 5 diagrams at any one time but otherwise fully-featured) and the Pro sunscription is not particularly expensive. I also can’t wait until there’s a Mobile version, maybe with shape rec0gnition and stylus support (maybe that’s just being greedy!)

—-

In recent times I’ve been involved in a number of conversations in various contexts where the subject of minimalist visual representations of simple concepts has been discussed and it often appears that some Business Analysts think they are… well, too simple to be valuable.

I disagree.

If the purpose of communication is to present information to others in such a way that they understand it, and this can be achieved in a given context (but not always, of course) with a simple graphic, then why would you want to make it any more complicated than that…?

Any idiot can make something complicated (just look at Politicians and Lawyers!). It takes real skill to make a complicated concept simple (while remaining appropriately useful). It also takes real self-confidence to produce simple & simplistic artifacts. We often over-complicate the artifacts we create in our work simply to show others that we know what we’re doing. Usually, it’s unnecessary – and it can often make others wonder if we do actually know what we’re doing 🙂

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

“There is significant evidence that the worst way to communicate information between people is via documentation” (http://www.agilemodeling.com/essays/productOwner.htm).

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 the same way as everyone else did (whether due to organisational terminology or the age-old “That’s the way we do it and we expect you to know that“)…? Or, having read something that made perfect sense, you realise that it wasn’t what was intended by the content’s creator?

In fact, even the quote above illustrates the problem of agreement via misunderstanding. I’m assuming you understand that 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… and therein lies one of the problems!

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’.

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 “Naomi Campbell” or “Gordon Ramsay“!). The most common diagram I produce in my work is a flowchart (or multi-function flowchart, aka ‘Swimlane’), whether this is a quick-and-dirty diagram to illustrate a concrept in a meeting or a fully detailed diagram designed to be understood and followed by stakeholders at all levels of a Project.

The recently-released Textografo (here) allows these diagrams to be generated very, very quickly, using just a handful of text characters that auto-generate, auto-position, auto-connect and auto-update flowcharts. For example, simply typing <> in the online editor results in a ‘decisi0n’ shape being added in-flow. Alternatively, there are keywords (aka tags) that can be used to generate shapes. The decision shape can be inserted simply by typing #decision.

To illustrate how simple it is to understand, here’s an example. Look at the text in the text editor. It’s almost just English. Everything else is automatic.

I have always liked the idea of ‘Agile Modelling’ and it is something I do all the time (even before I’d ever heard of the ‘Agile manifesto’), mostly for my own benefit because other Stakeholders usually want to see the complete / complex picture in one diagram – even if they can’t make sense of it due to the complexity.

Nore, for the sake of clarification, in this context:

Agile Modelling means ‘Creating diagrams and models in the Agile philosophy so they only contain only as much detail as needed at a given time‘.

Agile Modelling does not mean: ‘Strutting up and down the Catwalk on tip-toes, backwards, 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 & stakeholders don’t assume everything has already been correctly worked out.

Often, the discussion that follows from introduction of these ‘sketches’ will allow 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 reader’s understanding of the ‘big picture’ by starting with ‘bite-sized chunks’ and building on them.

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

The purpose of drawings like this is not to illustrate a system or process. There is no real detail to explain anything. This also means there is nothing in the diagram to clog it up or, more importantly, that might bias the discussion. It is 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 other 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 tool 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 / are not permitted 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.

Note: while I’m leaving the above paragraph in (because www.YUML.me is still an excellent little tool), I’m going to switch to using Textografo from now on because it’s just as quick and easy to learn and use, it’s slightly easier to understand (especially the keywords) and it  has features that YUML does not (e.g ability to save & return to diagrams, export diagrams etc).

I’m sure there are Business Analysts the world over thinking “Aaaghhh!!! Where would I be without my diagrams and how could I model everything?” and I understand that mind-set totally. If you are using diagrams & models to communicate useful information to Stakeholders, they are definitely preferable to using text alone (although text may be better for some purposes). However, there is no law that says every diagram must include every bit of available information. With an Agile mindset (even in a ‘waterfall’ environment, or outside the technology world altogether!), the information provided should be whatever is required – nothing more, nothing less – for a given purpose at a given time or in a given context.

For example, I found myself recently having to design a set of “classroom” training sessions for a very specific set of concepts, and suitable for participants every level of Technical knowledge (and none). Among the concepts discussed, buried among all of the other material I presented during this 6 hours of classroom-based training over 2 days, was the idea of modeling transitions between states. Now, most of us know there are numerous ways we can model transitions between states but, for me, the fundamental questions are always the same:

• what states can a system be in?
• what states can the system transition to & from?
• what is it that causes the system to transition from one state to another…?

The simplest metaphor I can think of for a state transition is the light-switch. We can, of course, explain in text:

1. The light may be in either – but not both – of the ON or OFF states.
2. The light can be switched from one state to the other but cannot be switched from a state to the same state, without transition to the other state first.
3. If the switch is [flipped] down, the light is [turned] on.
4. If the switch is [flipped] up, the light is [turned] off.

Of course, this omits assumptions about the environmental factors (is there electricity running to the switch & the light? Is the bulb functional? Is the switch fitted the correct way up? Is the wiring correctly installed) but that’s OK for the given context – we have to make some assumptions… 🙂

Personally, I find it easier to show (and read) all of the information above in a very, very simple diagram (which, by the way, is also much easier to create on-the-fly on a whiteboard!):

This image, using 2 circles, 2 arrows and 6 words, conveys pretty much exactly the same information as the 60+ words above – and is probably more useful in communicating, particularly where language / translation might be an issue.

So, 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 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 captions like “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 for your convenience…

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!

Feel free to comment…