Close

What, exactly, is an MVP and who decides?

What makes an MVP an MVP…? Do you prioritize the ‘M’, the ‘V’ or the ‘P’…? Who should be the final judge of what an acceptable MVP looks like?

These might seem like strange questions but, like most things a Business Analyst has to consider, each is a simple question behind which lies a very complicated and very, very important relationship between all Stakeholders on a given Project.

For the record, and to prevent Sports fans having to read any further, MVP in this context stands for Minimum Viable Product, rather than Most Valuable Player!

NB: additional paragraph below marked with *  added as a result of feedback.

So, which is more important in a software product development environment: Minimum, Viable or Product…?

Well, that sort of depends on who you are.

Read More »

Turbo-charge Requirements Elicitation for features & user privileges.

One of the most common things I have to do on software development or Application selection projects, at one point or another, is to define a series of potential features or functions. They can range from obvious and nearly mandatory (e.g. ‘reset password’) to the more ‘out there’ features. Often, trying to get stakeholders to contribute to the production of these feature sets (note: they are not requirements yet!) is a pain in the proverbial backside. Everyone is too busy to tell you what they want their shiny new toy to do – although they’ll be quick enough to tell you if you get it wrong!

So, over many years & many projects, I have developed (and continue to develop) a quick and easy process to get the obvious features into a list early in the engagement _ but in a way that cries out for stakeholders to get stuck in and evolve it. Feel free to adapt it to your needs – you can use it to impress stakeholders with your speed of delivery!

Read More »

Tip for BAs: make a portable whiteboard

I’m often asked to recommend simple tools for aspiring BAs to use and I can’t think of anything more simple – or more useful – than pen & paper or, where available, a whiteboard.

temp

For those of you who like to work with pen & paper or with whiteboard & marker, here’s a simple tip: Get a sheet of A4 paper & laminate it. Then get some fine-tip whiteboard markers. You now have a portable whiteboard.

Make an A3 version too, if you wish. Don’t roll them up, though… it’s a nightmare to unroll them when needed. If you want something a bit more robust, laminate a piece of white card instead of paper.
Read More »

Conducting and facilitating virtual meetings.

Warning: this is a lonnnng post so please excercise due discretion – or read it in your spare time! I wouldn’t want you to get in trouble for reading it in work… although you could at least argue that it has some workplace relevance 😉

First, this video will give you a giggle if you’ve attended many virtual meetings… but don’t forget to read on afterwards..!

Click to view on YouTube

At this stage in the evolution of business technology, virtual meetings are an integral part of the day-to-day activities of a huge number of Organisations and work forces. Many Organisations would simply not be able to continue to exist (or would need to adapt radically) if virtual meetings were no longer possible.

image

At least the technology (whether video or voice-only) is better than it was way back when multi-location meetings started to become common. I agree that they are not as easy in some ways as face-to-face meetings when it comes to the non-verbal stuff like body language, attempts to contribute, noticing lack of participation etc. However, virtual meetings can also be better, especially when they involve remote / offshore participants.

Read More »

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 »

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 »

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!

Back to top
%d bloggers like this: