Image credit: https://www.newlyswissed.com/swiss-railway-clock/

Prioritising projects and initiatives by ROI (return on investment) seems a sound way to determine the best business opportunities to pursue.

But actually it isn’t — or at least it’s not the whole story. Positive ROI is certainly a pre-requisite for an initiative to be a viable option for economically sound prioritisation, but it is NOT the optimum way to prioritise it against other opportunities competing for scarce team capacity.

𝗪𝗛𝗬?

Consider the following two hypothetical projects, A and B. For simplicity’s sake, let’s assume we have perfect knowledge* of the time/cost required to deliver (both 3 months, same cost)…


Car dashboard

Measuring performance (of e.g. products, services, operations and employee activity) is becoming increasingly popular in the arena of software and product development, and knowledge work more generally.

At the end of the day, you measure particular things because they are important to you in some way. Your weight and average 10km running time might be important to you if you are tying to get or stay fit. The window washer fluid level in your car is important if you want to be able to keep your windscreen clean.

If you are measuring something which doesn’t actually help you achieve your…


Agile is a philosophy which embraces (among other things) incremental delivery and improvement.

Yet some folks treat it as a binary, “you’re either doing it or you’re not”, operating model. They claim a team cannot embrace Agile principles without the whole organisation doing so.

This is a chicken and egg scenario which invariably results in a transformation stalemate.

What’s going on here? Is the effective adoption of agile values and principles being hampered by the very people who are promoting it?

The notion of Agile only working well if it is adopted by ALL people and teams across an organisation…


http://clipart-library.com/free/knife-clipart-png.html

Followers of my work, including those who have attended my recent story slicing webinar or training, will likely know I advocate for (and practice) iterative, incremental and empirical approaches to the majority of software/product development endeavours (and, indeed, work initiatives of pretty much any kind).

Often, when I introduce folks to my story slicing techniques, they are excited about the possibilities, but see roadblocks inherent in the current ways of working in their teams or organisations. …


I started from not being able to run down the road, to running a marathon, in less than a year. I did this by addressing the underlying reasons why I wasn’t doing enough exercise (including eating too much junk food!), then taking small steps toward achievable goals (e.g. being able to complete 4k without stopping, then 5k, then 6k, then 8k, etc.), all the while with a true north of getting fit.

Here is a simple guide (fewer than 10 steps) to making incremental improvements using a scientific approach, whether it be in your personal life or in your workplace.

Through the steps (below), we’ll follow two different examples — one related to an agile transformation, and one related to personal health.

1. Define an objective

2. Define possible root causes* for why you or your team are not where you want to be right now with regard to the objective


I came across this post by prominent Agile expert Mike Cohn. Mike is an extremely knowledgable practitioner and consultant with a massive wealth of experience, and as such he is someone we should most certainly listen to, and from whom we can learn a great deal.

However, I would like to address something in this particular post; a mistruth which I think perpetuates a fundamental misunderstanding in our industry of what “planning” is and should be, particularly in the arena of agile software and product development.

This mistruth is that planning equates to “looking forward a handful (or more) Sprints…


Image credit: http://www.assertselenium.com/atdd/difference-between-tdd-bdd-atdd/

I introduced ATDD (Acceptance Test Driven Development) to a team I was recently working with. It’s been used by agile teams for years (sometimes referred to as BDD — Behaviour Driven Development), but I do not see it used much in the wild nowadays. This is a massive shame because it is a simple yet powerful technique for building quality into a product.

ATDD involves:


Image credit: https://www.meistertask.com/blog/agile-project-management-non-software-projects/

There is a very common trope in the agile community that agile and project management — and by extension project managers — do not mix, or are even in direct conflict with each other. Let’s unpack this.

At its core, project management is about controlling delivery risk in projects such that their objectives are met within acceptable timeframes and cost (aka “on time, on budget”). …


Thanks for following my blog! 😊 Please support my work further by reading this and other articles from my my company blog.

If you have any questions about anything in this article, or need a hand with your lean/agile product development or agile transformation endeavours, please reach out directly to me or my company Hypothesis.

Image credit: https://www.mnn.com/food/healthy-eating/blogs/12-tips-for-kicking-the-refined-sugar-habit

Backlog refinement is an activity carried out by Scrum teams on the Product Backlog, described in the Scrum Guide as:

“… an ongoing process in which the Product Owner and the Development Team collaborate on the details of Product Backlog items. During Product Backlog refinement…

Neil Killick

Software/product coach and leader. Expert in agile product development and product management.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store