Is all this Health Tech just another fad?

Technology currently has it's big laser pointed at the health sector. The major players like Apple, Google and Microsoft (I’m sure they will turn up to the party at some point) are all rapidly producing devices and web services in the health space, keen to capitalise on the growing desire of people suffering the excesses of modern life to use technology to get them fitter and better looking.

While this is all great and I'm sure it is going to be the next Big Thing, I can't help feel a pang of cynicism around Health-Tech.

Here is why:

Let's drop ‘Responsive’ from Responsive Design

In a meeting a while back, a client who had their web site built on a shoestring asked me with a slightly panicked expression: is my web site ‘Responsive’? I looked at the site and squished the browser around some and saw rudimentary things happen to the layout. It didn't look great. The only answer I could give to try and appease the anxiety of said client was 'a bit’.

It did make me start to question what Responsive Design was and question all the current 'attempted' classifications around fluid, reactive and adaptive, etc. I won’t go into the detail here, but you can use the interweb to find out more :

The truth is that there is no one answer and the lines between fluid, responsive and adaptive design are blurred and ever changing in a world which is producing devices of varying dimensions and capabilities faster than people can pour buckets of ice over their heads.

Responsive Design is not an end state, it is a process which tries to deal with many challenges of building web applications that can be viewed from your phone through to your TV through to gigantic projections on one side of the Grand Canyon (should it be so lucky).

The challenges are centered around these areas:

Eight reasons never to hire a Unicorn

If you work in the Digital Advertising industry you most likely have come across the term 'Unicorn'. If you don't or haven't, here is a short background.

Unicorns are mythical creatures which have a large, spirally, pointy horn mounted to their forehead. Popular culture - predominantly little girls and pagans - have long since had a fascination with these creatures who are purported to have special healing powers and are symbols of grace and beauty.

Legend also suggests that only virgins can catch unicorns which, in this age of sin, perhaps explains why sightings are very scarce.

In short, Unicorns are rare, special creatures that are difficult to catch.

Drawing back to the Digital Advertising Industry which sometimes thrives on mythology, legend and magic, the notion of 'Unicorn' has been adopted into its lingo as a rare and special person who simply must be snared and put immediately to work dreaming up the next wearable tech idea to promote mouthwash and, in the process, make the world a better place.

Happy First Birthday 'This is Lean'!

Happy First Birthday to the Tumblr Blog, http://thisislean.tumblr.com/ !

The blog is dedicated to something called 'Lean' which is really big (ironically) right now. If you don't know what 'Lean' is then you probably aren't doing it and your output is all flabby, bloated and struggling to fit into its favorite pair of jeans. If your output suffers in this way, I urge you to read this blog and discover how to become Really Really Lean.

It is a crowd sourced web site so if you have any Lean Thinking that the world needs to know about, submit it here.

Distributed Development : Avoiding The Fog

I've written about the challenges of distributed development as have many others, so I'm not going to bore you with another spin on the types of problems which crop up and new and improved ways of fixing them. What I am going to do is make a controversial statement and then try and pull a Houdini and explain myself out of it.

Communication can make for an opaque development process.

Ok, here I go.

Can User Stories be used in Waterfall Development?

If you work in the business of software development you most likely have come across User Stories. If you aren’t familiar with them, or are all of a sudden being asked to write them or deliver them and aren’t quite sure what they are, here is a brief background.

User Stories are born from Extreme Programming (XP) and Agile Development Methodologies. XP and Agile development is essentially a set of principles and practices which have emerged over the years (XP was first coined in 1999) to address with the challenges of software development and fulfill a goal of delivering working software as early as possible.

User Stories fit mainly into the requirements gathering and definition phase of software development. They are Agile’s answer to transforming what is often an onerous, expensive, confusing, obscure and inefficient process to one that is lightweight and effective, and drives the software development process towards delivering valuable software features early.

Like many other aspects of Agile Development, User Stories are becoming adopted as an industry standard way of describing software requirements.

The benefits behind writing requirements in this way include:

• Writing requirements as User Stories makes them easy to understand i.e. they eliminate technical or domain jargon 
• Writing requirements as User Stories helps validate their value to the users of the application 
• User Stories can be delivered independently and in short iterations, allowing the ROI from working software to be realised earlier 

However, because User Stories are being appropriated by different organisations who deliver software in less agile and more waterfall ways (wagile, scrumafall, etc) and don’t have all the other Agile practices in place, there is often confusion around what a User Story is and how they can be used to describe, specify and deliver a solution.

In my experience, this is often the case where an Agency or Software House (Delivery Partner) is tasked to define, cost and deliver a new build for a Client.

In this scenario, the following constraints often apply:

• The Client has a maximum budget to get the solution built 
• The Client has a massive wish list of requirements 
• The list of requirements exceed the budget
• The Client wants to know what they are going to get for their budget at the beginning of the project 

Given this starting position, the Delivery Partner has the challenge of defining and delivering a solution which has as many of the items from the wishlist within the budget constraint. So faced with this challenge, can User Stories be used to define and cost a fix priced build?

The short answer, I put forward, is yes with a caveat that User Stories go through the following steps to turn them into a scope of work that can be delivered within a budget.