Over the last 10+ years as a Business Analyst, Product Owner & Product Manager in a wide variety of teams, environments, sectors & projects – and, indeed, as a Customer overseeing my own Product development (see flowdaq if you’re interested in that) – it has become clear that Agile philosophies, concepts and techniques do actually work – at least, when appropriately adapted to the circumstances. However, it is also clear that Agile does not suit some scenarios or some projects. Project professionals (hopefully) adapt the Agile techniques that work for their scenario or project and omit those that don’t.
More importantly, however, Agile does not suit some people. Unfortunately, it is often not possible to adapt people who Agile is suited to, or even to ask unsuitable people to adapt Agile ways of working.
I’m very pleased and proud to have an article commissioned for (90,000-readership) Better Software magazine. My article – ‘Agile Outside the Development Team‘ – is chosen as one of the four ‘featured’ articles and the magazine also includes a wide variety of related material (I’ve been reading it for a few years).
You can subscribe to receive the quarterly magazine – free – or download the latest issue – also free – at the following link and, of course, I’d be happy to read any comments anyone might have on the article so feeel free to comment below…
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.