Close

Updated: If a picture paints 1000 words, what if you have only one thing to say?

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…?

Read More »

Advertisements

Business Analysis & the art of Sign Language

What has Sign Language got to do with being a Business Analyst…? In simple terms, both are processes of interpretation, not – and this needs to be stated clearly – ‘just’ processes of translation.

Not that there is anything WRONG with translation – its an important skill in some scenarios – but translation skills alone will not really be enough to be a good BA (in my view, at least. Feel free to disagree!). Translation and interpretation are related but different processes in the same way that Cryptography & Steganography are related but different. Only by knowing which you are supposed to be applying can you hope to do it right! By the way, don’t worry if you don’t know your Steganography from a Stegosaurus… it’s obscure / specialised, which kind of illustrates my point: knowing what they are is only part of the battle.

image

Read More »

In response to all the ‘advice’ from Recruiters…

I was asked recently for my advice on how to approach a face-to-face meeting with Recruiters… I guess I was asked since I never seem to be overly stressed about changing jobs (in fact, I quite like the new environment, new people and new challenges). As a result, this makes it seem like I know what I’m doing (which I probably don’t!) when it comes to dealing with Recruiters.

image

Read More »

Digital Soldiers, Job interviews and Software Testing…

What have Job interviews and Software Testing got in common? In both cases, it’s a GOOD thing to find out (and find out early!) that something is wrong…

image

Some years ago, I lectured in Software Testing (among other things) in Maynooth University. When I was preparing to take over the Software Testing course from another – far more technically capable – Lecturer who was on a one-year Sabbatical, I spent some time researching the various perspectives and approaches that are prevalent in the field of ‘Software Testing’ because it was a relatively new Academic field for me. Incidentally, it’s a surprisingly wider & more diverse field than you might think (and, in fact, is continuously evolving as systems and development techniques evolve).

In the end, since the Undergraduates were already doing practical, code-based testing (jUnit), I decided to focus the course content on more theoretical matters, evaluating & investigating the concepts and philosophies of Testing. It might seem strange to some readers – even those ‘in the business’ – that there ARE such things as ‘philosophy’ in Software Testing, but there are, and they differ quite a bit.

You’ll be pleased to know that I won’t be going into too much detail about that stuff here 🙂

Read More »

How are Agile roles actually implemented in the real world…?

It’s no secret that Organisations differ in their implementation of the various Agile ‘roles’ (where multiple ‘roles’ are often undertaken by the same person or where multiple individuals share a given ‘role’). This variation depends particularly on the type of Organisation – but ‘each to their own’ is almost a Universal Constant.

I get the impression from the various conversations in various BA discussion forums that real-world implementations of Agile structures within Organisations are as variable as the Organisations themselves. There may be no such thing as ‘pure’ Agile, in the same way that ‘pure’ Waterfall is probably only really a theoretical construct. In reality, almost every Organisation will adopt – and adapt – multiple processes & techniques from multiple methodologies as appropriate to their individual needs. In other words, “if it works, it’s right”.image

Read More »

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:

image

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 http://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 http://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!

My word is my Blog…

…I’ve been meaning to do this for years…

Way back in the mists of time, I started adding my tuppence worth to this new-fangled thing called “The Internet” (back when “The Internet” was in quotes and it was treated as a bit of a quirky fad), and I’ve been doing so on-and-off on various Forums and on various subjects since then. 

So, I decided to gather all of these random warblings in one place so that anyone who wanted to find & read them in the future (i.e. me) wouldn’t have to look far. 

If you’re reading this Blog thinking it will feature inspirational, informative or even remotely useful Blog posts, then you obviously haven’t read any of them yet…

Back to top
%d bloggers like this: