dancingmango - Marc McNeill

Why you should care about twitter

Monday, 17 November, 2008
By: marc

Motrin, a US healthcare company put on their home page a large video advert with the basic premise that mothers who carry their babies are likely to get back ache and their pain killers are right for the job. Nothing wrong with that, however the message was ill-judged “Wearing your baby seems to be in fashion…” going on to “supposedly it’s a real bonding experience”. Oh dear. That ‘s the sort of language that stokes the fire of mothers. There once was a time that they would have complained to each other at the NCT meeting (or whatever the US equivalent is), more recently a few might have blogged about it. But there is overhead in setting up a blog, and you need to think about what you write. Not so for Twitter. Twitter is low cost of entry, instant gossip.

Over the weekend Twitter has been buzzing with mums complaining about Motrin and their ad at #motrinmums. Look at the stats. From nothing to hundreds of negative sentiments in a matter of hours. Over a weekend.

(From Twitscoop)

It will be interesting to see how long before the ad is pulled. Will one person take responsibility, make the right decision (and do the right thing and apologize), or will it be a decision by committee and ultimately hurt the brand?

I started with the title “why you should care about Twitter”. Not so long ago I would talk to people about blogging and its importance to the enterprise and was told it was not relevant to that persons organisation. I’m surprised at how many CxOs I talk with today either don’t know what Twitter is or don’t seem to care. This is a good wake-up call. (Oh, and I picked this story up on Twitter via Jerimiah).

Are you experienced?

Thursday, 13 November, 2008
By: marc

“For you who have had the experience, no explanation is necessary. For you who have not, none is possible.”

I’m going to attribute that saying to Ram Dass, a Harvard professor who via psychedelic experiences ended up a spiritual teacher in the Eastern Tradition.

The problem with too much software/web design is that it is produced by people who have just not had the experience, or do not see the experience as relevant to their organisation or domain. They just don’t “get it”.

(“For you who have an apple product, no explanation is necessary, for you who have not, none is possible?” Cue “it’s an enterprise application we’re buiding, not a ****ing iPhone”).

If we want to build memorable and compelling products, we need to focus upon the experience. To dwell on the feature list or functional requirements is to build mediocrity. Nothing wrong with mediocrity if you don’t want to delight your customers or increase the performance of your workforce. Without considering experience you will miss innovation and added value.

So how to focus upon experience? Get your team to undertake different tasks to get under the skin of what customers go through.

Telco product?
Spend time in a retail outlet and watch different customers buy phones
Go into all the phone shops on the high street and ask the rep “hello, I want a mobile phone”. Suspend all your knowledge about phones and tariffs. How do they sell?
Leave your blackberry at home for a day (how dies it feel? How does it change what you do?)
Download instruction manuals from different phones from manufacturers websites

Travel product?
Go into a travel agents and ask for a holiday “somewhere hot and cheap in February”

Credit card product?
Ask to borrow money from someone you don’t know (how does it feel?)
Apply for a credit card at another bank
Collect all the Credit Card / loan direct mail and emails that you and you get sent over a week, photo / scan all the credit card advertisements you see in a week
Go into a car sales room and look to buy a car on credit

Supermarket product?
Get behind the till for a day (In the UK, at least a few years ago, all senior executives in both Tesco and Sainsburys spent time in the stores over the Christmas period)
Ask a shop assistant to help you find an obscure product that is not in stock
Go into a store with a shopping list and a single bank note, (no credit cards)
Go to the pharmacy when it is busy and ask to buy the morning after pill

Extend your team
Bring in representatives from completely unrelated parts of the business to participate in brainstorming sessions. Building a “youth” social networking website? Get someone from legal or corporate finance to join in. (Get’s you thinking along the lines of extreme characters – here and here [pdf]). Working on a complex exotic financial instruments? Get a few PAs to join in. You may learn something (that your product is too complicated and even you can’t explain what it really is).

I’m sure you can come up with better exercises. The object is that with this collection of experiences and related emotions new ideas can be brought to the table. They can offer insights from another, different perspective, providing more chance of business innovation being realised. More importantly, if you have an emotional attachment to the product you are building through real experience, you are more likely to build a better product that will fullfil the needs of and goals of the target audience in the way they want. The day your enterprise application team all have iPhones will be the day you start building better enterprise applications. For them, no explanation will be necessary. They’ll just “get it”.

Customer or Client?

Monday, 10 November, 2008
By: marc

One of the things that bugs me in IT development is that the business is too often referred to as “the customer”. “Customer” implies a transactional relationship. A customer purchases from a seller; there is little incentive for any meaningful relationship as it will ultimately come down to price. The buyer wants to pay as little as possible, the seller wants to charge as much as possible.

All to often IT is seen as a cost centre rather than a driver of business innovation and profit. Maintaining the transactional language to describe the relationship between IT and the business helps perpetuate this. We need to stop thinking of the Business as our customer. Instead of “customer” we should look to other professional services for our metaphor.

Professions that involve a more personal, relationship driven approach to their business use “client” rather than “customer”. Whilst retail banking has customers, wealth management talks about clients. I think it is a subtle but important difference. The relationship between IT and the business should not be seen as transactional, it is more consultative in its approach. Structuring our relationship as consultant-client is a small but important first step to redressing the perception of IT as a commodity.

A new page

Tuesday, 4 November, 2008
By: marc

This blog was getting tired in its design so I’ve given it an overhaul, including introducing some widgets. (What an awesome piece of software WordPress is). I’ve also added a new page with a bunch of published papers. some classics in there (if I do say so myself) such as “Heat stress in night clubs” and “Occupational disorders in Ghanaian Subsistence farmers” !!. The rest of the dancingmango site was not built using wordpress, so to update it all in one go would be time consuming and of little value. OK, so there is inconsistency across the site and as a UI guy that hurts, but it is one of the trade-offs that needs to be made.

Innovation and funding in lean times

Monday, 3 November, 2008
By: marc

It’s budgeting time with many organisations putting together their budets for 2009. In the current climate IT is an easy target for cutting costs. Stories such as “no new non-core projects till 2010” and “no project that can’t demonstrate a postive ROI in 12 months” are abound. There is a risk that only focusing upon projects that keep the lights on will do longer term damage to the company. Seth Godin writes:

Wealth is created by productivity. Productive communities generate more of value.
Productivity comes from innovation.
Innovation comes from investment and change.

Annual budgeting cycles combined with inflexible development approaches preclude real innovation. It is hard to justify any cost, especially untested products that brings a burden of risk to the organisation.

There are two solutions that go hand in hand. Agile software development enables IT to release value from production earlier and more often than waterfall development. Rather than significant sunk cost in risky product innovation, it removes waste from the process and focuses upon delivery of working software that is of value to the business, taking the product to market at the earliest possible time.

This is a challenge to the annual budgeting charade where line item projects compete for guessed amounts in return for notional value. (IT put crude guesses – not even estimates- against even cruder descriptions of required features from the business). A better model would be to take that of the venture capitalist, with different rounds of funding. Rather than allocating specific funds to specific projects, far better to ring fence budget for ‘product innovation’. Within this pool of cash projects compete with each other with a pitch for seed funding. Those that are successful go straight into agile development with sufficient funding for a first release (say three to four months). Getting to production (and to market- internal or external) will validate further funding or equally enable the business to make an informed decision and kill the idea – fail fast, fast cheap.

Sounds like a case for agile

Tuesday, 21 October, 2008
By: marc

..CIOs will be expected to become more and more strategic, delivering greater productivity gains while at the same time ruthlessly cutting costs. There will be a heightened debate about the role of IT in the enterprise. (ComputerWorld)

OK, so we can either spend months writing documents before a line of code is written. Do some application development then manually test what we’ve built and fix the bugs before eventually going live (late and over budget and not to the customers satisfaction).

Alternatively we could get more strategic and focus upon what value we can deliver in the shortest period of time. We could better align IT with the enterprise by delivering early and often, enabling us to test and learn from the enterprise as we go. We could adopt a more ‘just in time’ approach to requirements (whilst starting with a clearly defined vision from the outset). We could build testing into the development to lessen the bugs at the end, we could do automated testing (to ruthlessly cut manual testing costs). Downturn sounds like a case for agile.

.

How are you managing the change?

Thursday, 16 October, 2008
By: marc

To the development team ‘change’ relates to scope and requirements within the project, but change runs far deeper than that.

A question that I am often asked is how do you manage business change on agile projects. Release regular and often is an often quoted mantra, but what does that mean to the business where rolling new software across the large, multi-site organisation? How do you manage the piecemeal introduction of new technology, features and functions to hundreds or thousands of people, many levels removed from the project across remote offices and geographical locations? How do you ensure the recipients of the new technology rapidly adopt it and accept the change, even when change is occurring every few months.

What are the financial and human performance implications of each new release in terms of training, productivity and morale? What is the overall burden on people in frequent change?

The reality is that it is not unusual for projects deemed successful by IT and the immediate business team to ultimately fail when released to the broader organisation. Effective change management can be even more important when an organisation adopts agile software delivery.

An analogy as an example. If I expect a screwdriver and you only give me a cross-headed screwdriver when I really want a flat head one I am going to be unhappy. The core team may have prioritised the cross-headed one first for good reason, a flat headed one maybe coming just round the corner, but if you don’t deliver to my expectations I am going to be unhappy. Worse, I am likely to become resistant to future change and less likely willingly cooperate with the uptake of future releases, even if they do start to deliver to my needs.

Keep it on the shelf
The first point is that regular and often does not necessarily mean release to production for the entire organisation or marketplace. Running a number of internal releases, keeping them on the shelf until a complete and marketable product is ready is a strategy often employed. Significant value can be accrued by getting tested and working software into a pre-production environment and held “on the shelf” awaiting a full release. This maybe a UAT environment where a limited number of stakeholders test the functionality in an ‘as-live’ environment. Or it maybe a beta release to a small, selected number of interested people (e.g. a ‘friendly user trail’). This can often pay dividends with usability issues and minor gripes being picked up and addressed before a major roll-out.

Communication
Let’s assume that the team wants to roll out the application early and often to the whole target population. Critical to the success of managing the business change is communication. It is important to manage expectations on a timely and appropriate manner. Explain what the upcoming release will do and more importantly what it will not do (and when it will do it). Keep all stakeholders informed of the project progress (setting up a project blog can be a cheap and easy way of letting interested people know of progress), yammer maybe another way of broadcasting updates and information. Having a release count-down can also prepare stakeholders for the change. The techniques can be googled, the important thing is to communicate and manage the expectations (and be ready for inbound questions and comment after go-live).

Adaptable user interface
It is not unusual for the core team to drive for as much functionality as possible in the first release, considering UI enhancements as ‘nice to haves’ and consigning them to later releases. This is a false economy. Consider the cost of training and lost productivity through a hard to use interface. Now multiply that across multiple releases that focus upon utility before usability. Delivering a first release that is self contained and compelling will go a long way to driving organisational buy-in of the new application and greater acceptance of future change. (Jeff Patton writes some great stuff on using story maps to explain what the system should do. Using these will help focus on complete and useful slices through the application rather than random features that are perceived to be of value but do not make a coherent product).

A new user interface, however well designed will inevitably take time to learn the first time it is used. The challenge is with each subsequent release to introduce funcitonality and interactions that leverages the users existing mental model of the application, building upon what has been already been learned. Starting with the end-state, wireframes that articulate the final application then trimming out features, feields and controls to represent each notional release can be a good way of ensuring a UI that will scale as new functionality is added.

Agile organisation
Ultimately the most successful way of introducing agile is to build a beta culture with everyone as agents of change across the whole organisaiton. More importantly change becomes a cycle of learning and continuous improvement. And here I’ll borrow this most excellent graphic from David Armano. David compares what he calls conventional and unconventional marketing but the parallel with software development is obvious. His iterative cycle is “plan-design-launch-measure” but that is not a million miles away from the lean philosophy of “plan-do-check-act”. And critical to the journey is the learning cycle between iterations.

Better, faster, cheaper…

Wednesday, 15 October, 2008
By: marc

Here’s a presentation I gave a while ago to a bunch of senior execs, introducing the concepts of lean and agile to software development. Many of the slides are taken from a presentation given by Richard Durnall which can be found on the ThoughtWorks website [pdf]. If nothing else, the slides about the problems with conventional development methodologies – that they take time, are not responsive to change and rarely end up satisfying all stakeholders, struck a chord with the audience I presented this to.

[slideshare id=657541&doc=it-forum-presentation1-1223980207243199-8&w=425]

Users is a dirty word

Tuesday, 14 October, 2008
By: marc

Language matters. How you describe something frames your reference. One of the problems with so much software is that it is designed for generic “users” (typically UML stickmen) who may also have roles, but don’t have lives. Why this obsession with users? Everybody “uses” things. Surely the important thing is to understand the nuances of that usage, and that means thinking about real people. Josh Bernoff wrote a while ago,

Nobody talks about users of dishwashers, or users of retail stores, or users of telephones. So why are we talking about “users” of computers, browsers, and software?

Try, just for a day, to stop using this word. You’ll be amazed at how differently you think about the world.

Stop thinking about “users” and start thinking about people. Personas are a good way to start doing this. Get all your stakeholders thinking about the people whose lives will be touched by the product that is being developed.

Jeremiah Owyang updated his model of what web strategy is. It’s a cool model and worth a look. One of the things he has done is changed the word “users” to “community”.

One of the comments from Connie Bensen reads:

“I recently had a discussion about verbiage on our corporate website & heard the phrase ‘those words are industry standards’. Well, customers don’t know them. An analogy from the library world is that I took down the sign saying ‘periodicals’. It now reads magazines. (a shift towards making things customer friendly)”

I like that. It is a subtle change, and when I’ve argued with colleagues in the past about the difference between users and customers and consumers they just don’t see the point. What is wrong with users, after all it is the language of the industry. Yes, that maybe, but it is not the language outside our industry and they are the people that we build applications for.

Where are the missing floors?

Friday, 3 October, 2008
By: marc

It is fairly standard practice in Hong Kong for buildings to have no thirteenth or fourteenth floors. They are considered unlucky numbers. Not sure what happened to the first, second and fifth floor here. And back-to-front button numbering that is neither in the telephone format nor the phone format. There’s a couple of lessons to learn here; when designing human-technology interactions consider cultural norms and existing design stereotypes. (Sorry, its the Human Factors conditioning in me that notices such things).