The Net Promoter Score and the “couldn’t care less” group…

The Net Promoter Score (or NPS) is the ‘darling’ of Sales & Marketing, Customer Success and Product professionals worldwide. While it’s a simple enough score to capture and measure, the NPS can drive various serious and sometimes far-reaching decisions. And, as many of us know, we need to be careful what we measure because ‘what gets measured gets managed‘ …and that is not always good thing.

The Net Promoter Score is one of the main metrics or KPIs used not only to gauge the relative appeal of products or services, but even sometimes to validate their very existence. It is as if a high NPS is required as a raison d’etre for a Product or Service, for some people, rather than the simple (and perhaps subconsciously distasteful?) purpose of generating revenue and staying in business. A high NPS may be the thing that glosses over the fact that businesses generally exist simply to make money and everything after that is secondary, or it may be the metric that User Experience, Marketing and Customer-facing stakeholders literally drive their strategy towards achieving measurable ‘improvement’ of.

Advertisement

Are your experts up for the agile challenge?

Are the Subject Matter Experts in your organisation ready for the agile challenge?

To be clear (because clarity is critical in all-things-agile), I don’t mean “are your experts ready for the challenge of agile”… I mean “are your experts ready to be challenged, as they certainly will be if they work in an agile environment?”

Most people in corporate Organizations defer to the advice of experts:

“Well, Legal said we have to do this, so it’s not my fault if they’re wrong”.

Actually, it is. It’s everyone’s fault. Product stakeholders (i.e. everyone involved in defining and developing a Product) should be prepared – and actively encouraged – to challenge all opinions from any expert in any role. Conversely, SMEs asked for their advice need to be open to being challenged on their advice.

Why?

Their advice might be wrong (Shock! Horror!).

Podcast interview on “The Business of A.I.”

I was very pleased (and a little surprised, if I’m honest!) to be asked to feature on “The Business of A.I.” Podcast.

The interview with Luca Marchesotti of Sparkd AI was a little bit nervy because it was unscripted and the questions were not supplied in advance.

Having said that, I thoroughly enjoyed the conversation and, listening back some weeks later, it doesn’t seem like I said anything too stupid!

The episode is titled “How has AI changed Innovation?” and is available here:

Sparkd.ai – “The Business Of AI: How has AI changed Innovation” (Ron Healy)

Tool to auto-generate User Stories with minimal typing and even less repetition…

• This is an update of an earlier post that I published back in December 2015 (actually, precisely 6 years ago today..!). I’ve updated it to take into account some things I’ve learned since then, and expanded it to include instructions on auto-generating User Stories in the Connextra format, to allow direct importing into Jira and automatic [optional] linking to any pre-existing Epic. I’ve included a downloadable template to get Business Analysts and Product Owners started. The tool is ideal for Business & Customer stakeholder engagement when identifying features and as a tool to facilitate Dev & QA stakeholders’ decomposition of features into bite-sized chunks. There’s even a tip (feedback from a User) on adapting it for anyone in the Project Manager or Coordinator role.

One of the earliest activities carried out in the product & software development lifecycle, and one that then reoccurs regularly throughout the development process, is to define a series of potential features or functions (i.e. ‘”requirements”) and then break them down for estimation, prioritisation, development and testing.

Requirements can range from the obvious and near-ubiquitous (e.g. ‘reset password‘) to the more ‘out there’, but still valid for capturing & documenting (‘split a NFT so it can be shared like a real, physical object‘).

They can range from the very granular and detailed (‘submit username and password in landing page to login to account‘) to the very abstract & aspirational (‘move through a metaverse‘).

Often, trying to get stakeholders to actively contribute to the production of these requirements 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! Read on to find out how to make this task more productive, more interactive (and iterative) and less painful.

Even my wardrobe is Agile…

Let’s start with some principles and definitions…

Agile does not equate directly to Scrum, Kanban or DevOps. Those are just methodologies that follow some Agile principles. Agile does not mean ‘Software Development’, ‘Innovation’ or ‘Technology’. Those are just Sectors and processes to which Agile is adopted (and, to be fair, well suited). While the Agile Manifesto is about software development, Agile as a concept is not limited to that sector.

Agile is a mindset. It encompasses some relatively simple concepts that are usually then complicated and clouded by different implementations, opinions, interpretations and misunderstandings, but at its heart it is a simple overarching principle: make the most valuable thing the next thing you do / use / make / decide.

There are thousands of questions driven by that one simple idea (“What does ‘valuable’ mean?” is the most obvious and difficult of them), and even more answers / opinions, but if you keep that simple idea in mind as a guiding principle you should always be more Agile than not.

Source: ModernAnalyst

Everything in Agile, starting from the Agile Principles, is aimed at making the next most valuable or useful thing available at the earliest opportunity.

The famous ‘Agile Manifesto’ states that Agilists value some things more than some other things (note: this does not mean ‘instead of’, or ‘to the exclusion of’, it just means ‘more than’).

For example, Agilists prefer collaborating with customers and users to adapt and adjust what we’re delivering based on feedback, more than (but not to the exclusion of) having scope and costs. We also prefer changing direction when we realise we’re no longer on track, rather than sticking to a plan that will keep us on time and on budget… but ending up at the wrong place.

The invisible cost of double jobbing for shared resources in Agile

The stated ‘best practise’ of Scrum-flavoured Agile software development (and therefore the target state of many transitioning environments) is a self-organising, cross-functional collection of individual resources capable of delivering whatever they agree to deliver, within a time window and within the resources (including skills) they have available to them, along with someone to coordinate and facilitate their activities and someone to ensure they are working on the next most useful bits of work. All very fine and all generally very achievable. We see this setup everywhere.

In many Agile software development environments, there comes a time when the Team needs the input of specific knowledge, skills or expertise which is otherwise not normally part of the Team.

You can go FAR if you avoid the FOGS

You can go FAR if you avoid the FOGS

---

Agile concepts have permeated a wide variety of Business domains and Sectors for at least 80 years, making a first high-profile appearance in the 1940s when Toyota implemented a Kanban-based workflow planning system to increase efficiency and – in particular – to reduce delays caused by bottlenecks in multi-step manufacturing processes.

In the last 30 years, Agile software development techniques and methodologies have made their way into the mainstream. More recently, even the biggest and most hierarchical organisations in both Corporate and Government sectors have begun to adapt Agile techniques to a wide variety of processes – including outside the obvious Manufacturing and Software Development candidate areas.

One of the most recent – and perhaps the most outwardly unsuitable – area where Agile principles and techniques are being applied is the area of Product Innovation. Kanban, Lean and JIT processes are ideally suited to predictable, repeatable processes like Manufacturing. Product innovation is anything but predictable or repeatable.

Read on…

The Complexities in our Digital Identity

In a recent Documentary on RTÉ TV (the Irish national broadcaster) about Annacarty Barracks and its central role in the Irish path to freedom & independence, Mick Dromm (at least, I think that was his name!), who was one of the primary Archaeologists on the Project, said:

“As a nation, as a people, we are mature enough to be OK with the complexities in our identity”

Now, while that quote relates specifically to the complexity in the modern Irish national identity, it did start me thinking about the whole concept of complexities in our individual personal identities. Every one of us is a unique combination of the different identities we portray to the outside world, to our friends & families, to our work colleagues, to our Customers & Clients, to our most intimate personal connections and – frankly – even to ourselves.

Enough of the Philosophy and Psychology, though: what does this have to do with Digital anything, Online anything or even Business Analysis…?

Well, it’s all about Personas.

Now that you’re ‘working from home’… behaviour and etiquette for Virtual Meetings…

This is an updated version (given the huge explosion in the numbers of people working from home in 2020 as a result of COVID19 / Coronavirus and the likelihood that this will accelerate the Work From Home transition) of a Blog Post published originally in 2015.

Warning: this is a looonnnnggg 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, especially while pretending to pay attention on a Conference Call… although you could at least argue that it has some learning value 😉

---

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 [imagine… this sentence was originally written back in 2015… I should have just predicted the Lottery numbers].

First, to get you in the right frame of mind, this video will give you a giggle if you’ve attended many virtual meetings… but don’t forget to read on afterwards..!

Click here to view on YouTube

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 (or as productive, for some types of activities) as face-to-face meetings, especially when it comes to non-verbal considerations like body language, attempts to contribute, lack of participation etc. However, virtual meetings could also be better, especially when they involve remote / offshore participants.

Unfortunately, as with the evolution of any form of communication, when generations of workers become accustomed to virtual meetings (and may not have much experience of real-world, face-to-face group meeting & workshops), there is a very good chance that they will have developed some bad habits when participating in virtual meetings (usually by copying colleagues’ habits). Given that we are now at the point in the evolution of virtual meetings where multiple generations of modern participants have grown up without ever having any real experience of face-to-face, in-person meetings, current and (increasingly) future generations are unlikely to develop the right etiquette for participating in group meetings unless they are explicitly or implicitly taught them and required (by procedures as well as by example) to behave appropriately.

[read on…]

How (not) to be a Recruiter…

I deal with Recruiters a lot. Some of my best friends are Recruiters. Well, maybe not, but as a Contractor that changes jobs, Clients and even Sectors every five minutes or so, I rely on Recruiters. And they rely on people like me too. So I tend to get on reasonably well with them. Even when there might not appear to be a mutually-beneficial deal on the immediate horizon, the chances are we’ll be discussing something at some point in the future.

I even partnered up with a Recruiter (who originally contacted me about a role I wasn’t ultimately interested in) to set up a Motor Racing Team and have previously posted an article that might be of interest to Recruiters to understand what we (or I, at least) expect from the collaboration (“In response to all the ‘advice’ from Recruiters…”).

So, it’s not as if I’m one of those potential candidates who dislikes being contacted out of the blue by a Recruiter. It happens maybe 30 times a week and I accept its part of my ‘ways of working’. Even if I’m not interested (or available), I usually just ask for details so I can review them in case one or other of my peers might be a suitable match. But, occasionally, a Recruiter comes along with an air of such self-importance or with such an anti-collaborative ‘F**k you” attitude that it just makes me smile.

Below is the thread of a recent conversation with one such individual. After this, I did 5 minutes of research online and discovered that the Recruiter below (let’s call him David… because that’s his name but I’m not including his 2nd name!) appears to be a one-man-operation, based in Ireland – a small Country in terms of interpersonal and Business networks – and not even based in one of the major towns or cities that Recruiters mostly frequent. It’s worth bearing in mind that ‘David’ is a real person, trying to forge a career for himself as a Recruiter… and that we Contractors often exchange notes on the Recruiters we’ve dealt with…