Agile: it’s not for the Fragile…

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.

Advertisements

Agile Outside the Development Team

Updated with link to download the Issue (free).

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…

Download Free copy.

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.

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!

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

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