Engineering the -ilities iteratively

Delivering the right thing isn’t just about getting customers and stakeholders the functionality they need so they can achieve what they’re trying to do. A feature has function and performance characteristics. Most specifications, design decisions and cost estimates only consider the function bit.

“So it needs to do X.

Right.

How well does it need to do X?”

There are -ilities – reliability, usability, learnability, upgradeability, replaceability, scalability, etc. These are quantifiable characteristics that cost resources – time, hardware, network bandwidth, money, etc.

“How much of this -ility?

How much of that -ility?

What would that cost in terms of x, y, £?”

These are design decisions trading immediate and longer-term economics for the experiences being created. There are multitude options screaming for set-based validation.

Customers trust us to get the -ilities right. If we don’t, customers get a shit experience no matter how shiny the turd – the shiny soon loses its lustre. It’s ok for customers to be wowed by the shiny and not give any consideration to the -ilities they expect. It’s not ok for us to do the same. We’re responsible for working with customers and stakeholders to specify quantified -ilities given the desired experiences we want to cause, the resources we have available, and the investment we’re prepared to make.

When the -ilities are a design-afterthought, chucked in a ‘bucket of miscellaneous’ called ‘non-functional requirements’ and left to the end, you get rework and disappointment.
The shiny gets reworked later on because the -ilities can’t match up, costing extra money and upsetting the customer who signed off on a certain version of shiny way back when. Leave engineering the -ilities out of the design thinking at your peril.

The real capability is to make engineering the -ilities a continuous and intrinsic part of emergent design thinking, iterative development and continuous delivery, based on an investment strategy that believes a system will be carefully crafted that meets today’s demand today, and trusts that it can be re-crafted cost effectively tomorrow to scale and meet tomorrow’s demand.

This entry was posted in Delivering success and tagged , , , , . Bookmark the permalink.

One Response to Engineering the -ilities iteratively

  1. Hi Simon,
    Make the stakeholder value the ‘illity to avoid it dropping to the bottom of the backlog. As Gus talked us through at the “Devs in the ‘ditch” the key to this is: attach a *quantified* value.

    The challenge is how to do that in practice. Gus mentioned a book “Competitvie Engineering” (http://www.amazon.co.uk/Competitive-Engineering-Handbook-Requirements-Planguage/dp/0750665076) which may give some tips and tricks.
    Christian

Leave a comment

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s