Uncategorized

Goodbye Luke

The cruel hand of death has plucked a good friend, mentor and inspiration from us. I wouldn’t be where I am today without Luke Barrett; he shone a light for me to follow. For someone with so much energy, so much more to give the world, with a young family and a life ahead of him, his death is truly tragic.

I first met Luke at Accenture, or Andersen Consulting as it was at the time. He was doing some interactive stuff and was looking to do some usability testing on Digital TV.  Our paths crossed and we started usability testing our clients products. This was in 1999 and ‘design evaluation’ as we called it was quite an innovation at the time.

We worked together on Barclays iBank, rigorously validating our designs with customers, helping the bank transform their first generation, clunky IT-centric on-line banking application into something friendly and usable. Ahead of its time, Luke championed the Rapid Proposition Development offering – you’d call it Lean Startup today.  His creativity, work rate and energy were both inspiring and infectious. Working weekends with him, building interactive prototypes to validate assumptions wasn’t work; it was a fun thing to do. We worked with an overseas bank who were looking to enter the UK market. Undoubtedly we saved them millions of pounds by demonstrating that their idea, when presented to potential customers was worthless.

Luke was a rare breed, truly creative, with an eye for design (visual and interactive), and a keen technologist as well. On one project we worked on together, a contractor was brought in to build a Flash investment calculator. The contractor was unable to deliver on Luke’s vision, so he taught himself Flash and over a weekend built something awesome.

Luke left Accenture to pursue other opportunities, but still came back from time to time to run training sessions on Photoshop and Illustrator.  Our paths crossed again shortly after he joined ThoughtWorks. A consultancy full of uber-geek developers who at the time had little idea of the importance of user centred design. Luke persuaded me to join him on a mission to fuse agile with user experience. Taking a pay cut to join Luke again was a no-brainer. He’d just completed a two week gig at a Building Society where not a line of code was written (but the client had a vision of what needed to be built). This had demonstrated to the ThoughtWorks team that their may be legs in this UCD stuff. And from that we started doing “Quickstarts,” which later became project inceptions -understanding the what before the how.  Curious, he was always looking to learn and had an idea or balanced opinion on most things.

Always a quiet man, not one to seek fanfare or acclaim, I’m certain that in a small way Luke has helped influence the way we build software. Not long ago was I talking to Geoff Patton and he was telling me how Luke influenced much of his thinking.  There are many products that people use and love that are just that much better from his hand.

After seven great years at ThoughtWorks I decided to leave.  We kept in touch, Luke helping shape ThoughtWorks out of its London base to a European presence.  We met up every few months, he’d always ask when I was going to come back to ThoughtWorks. It was this time last year that he mentioned Auto Trader to me and once again he had a hand in my fate.

Whatever he did, wherever he went, Luke applied his passion and drive. Whether it be on the dance floor, mentoring team members, managing prickly client relationships or dealing with prima-donna developers, Luke gave 100%.

Luke. You are gone but never forgotten.

On doing business in Hong Kong…

…there are two things that are essential, the business card and the company chop. Every business meeting starts with the customary exchange of business cards, after a year in Hong Kong I have amassed a mountain of them that lined up end to end would get me a fair distance. And no official document is official without a company chop – ink stamp in any other language. Probably a remnant from British bureaucracy, a signature is not sufficient, no document is complete without a chop. The fact that you can get a chop made up at any stationers doesn’t seem to matter. In fact you’d probably get away with a potato print as a chop if you were that was your thing. The chop and the card are de rigueur, if there was something else I might add it would be the fax machine. It is not unusual to suggest correspondence via email to be told to send a fax instead.


How are you managing the change?

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.

When google fails…

…I’ll see if I can get an answer on the blog. My two year old daughter has managed to put two DVDs into the Mac Mini and I can’t get them out. Tried all the usual suspects for ejecting – eject button, F12, Cmd-E, rebooting with mouse key pressed, disc utility, terminal and drutil tray eject plus turning it upside down and no joy. Does this mean a trip to the Apple Doctor?