The number of Blog posts, articles and discussions that ask or attempt to explain “How to be a BA” is a good indication that nobody really knows the ‘silver bullet’ answer. If you think you’ll find the perfect answer here…. don’t waste any more time reading on: I don’t have a ‘one size fits all’ answer either!
This is not because nobody actually knows what a Business Analyst is or does (although there are many Recruiters and Hiring Managers who obviously don’t!). It is perhaps because there are so many different types of BA, who do different things, in different roles, for different Projects and in different Organisations.
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…?
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!
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.
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 portablewhiteboard.
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 »
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..!
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.
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.
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.
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…?
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.
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…
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 🙂
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”.