Don’t say UCD is incompatible with agile

Consultancy is great, you get to see lots of different problems that different organisations and people have. You get to apply the learning’s built up through experience to help solve problems, and sometimes help organisations realise opportunities that they may not have realised possible.

I was recently working with a new client and sat through a presentation by an agile coach from a different consultancy on what agile is. It was great to hear a different slant on the agile proposition and how it delivers business benefit early and regularly. The presenter really honed in on human behaviour. She was suggesting that despite our best efforts and beliefs otherwise, human behaviour is fundamentally unpredictable. The best plans in the world are held hostage by human behaviour…

At the end of her presentation there were a number of great questions from folk more happy in the waterfall space. People who have seen agile and it’s like before – RAD, DSDM etc etc, “yeah, yeah, heard it all before. Agile’s just another passing fad. Then one of the HCI guys asked the question: “in what you have said, it sounds like you would have little time for doing low-fidelity or paper prototypes; a fundamental tool in the interaction designers arsenal of techniques to ensure usability (and acceptability) in design”.

To give her credit, the presenter explained that agile practices are by nature pragmatic and there may be instances where such prototypes may be valid, but in principle she suggested that they should be eschewed.

Something bothers me here. We are quite happy to “spike” technical problems, but possibly the most important part of any software implementation, the user interface, we are happy to let emerge according to the developers’ preference? For it to be refined following feedback from each showcase? What if we call the lo-fi prototype, the wireframes a “spike”. Does that make it acceptable to the agile zealots? What if rather than writing code, testing and refining it, we draw storyboards, test and refine them? Get the UI right quickly and cheaply before a line of (costly) code needs to be developed. It helps you to have a shared vision of how the application will be manifest to the customer. It helps you to show what they will be getting in an iteration, what the goal is for a release.

To say that user-centred design is incompatible with agile (which was certainly the impression the presenter left the UI team I was working with) is nonsense. Which reminds me. I’m supposed to be writing a paper to this effect.

Working software that doesn’t work

Seen recently.  A developer at a broadband provider proudly showcasing functionality that enables customer to perform fault diagnosis on their connection.  Step one “do you have access to the internet?”  Functionally it might work, but did no-one stop to think about the value of this functionality.  You need an internet connection to get it to work…

The agile manifesto champions working software over comprehensive documentation.  Working software does not just mean that it functionally works, to work it must also provide business value and a compelling customer experience.

The product is irrelevent. It’s the customer experience that pays the bills

Why do organisations exist? To make money.  In corporateSpeak “to add shareholder value”.
Where does money come from to deliver shareholder value? Customers.

Many organisations seem to forget this slight detail. It gets lost in the internal machinations and politics.
Why do individual funcitons exisit within an organisation? Marketing, product development, IT, sales, operations… None of these add shareholder value make money in themselves. Yet in all too many organisations these different functions behave as if they exist for themselves, they are entities unto themselves. Each entity may pay lip service to the “customer” but how joined up is the reality?

How familiar is this.

The product team identify the need for something, based on anecdotes from the sales guys, or something they perceive to be wrong with the existing product or a hunch about a potential niche in the market. A niche in the market but is there a market for that niche? A bunch of requirements are written up and an optomistic benefits case is written up. There are x million widget users in the market place. Y% of these would benefit from NewGizmo. We project 10% of these will buy at a price point of £z. The requirements are thrown over the wall to IT to put some development costs on the project. The project has yet to start and a launch date is set in stone. And a project manager has yet to be assigned. Marketing are brought into the picture and tasked with how are we going to sell the product. Development starts (the new project manager is aghast at the scope and timescales he is inheriting). Operations enter the project and throw water on the fire. There a whole bunch of compliance and business as usual considerations that only now come to light. Relationships become tense as the project manager tells the product team that they can’t have what they want by the date they wanted it. The date has been set in stone, so the product team throw out some of the initial requirements, based upon an argumentative workshop on Thursday afternoon (noone bothers to refer back to the initial benefits case, even less any thought of how their decisions impact the overall customer experience). And inevitably a cut down NewGizmo is launched to the market a month late and sales are nowhere near what was projected. What we need is NewGizmo 2.0 and so the cycle starts again…

What if we put the customer at the heart of the organisation.  What if everything we do is motivated by serving the customer?  What if we forget all about our products and focussed upon what our customers’ need and how we can delight them.  What if the products become an enabler to a compelling customer experience, rather than an end in themselves?

Isn’t shareholder value all about generating revenue? Isn’t revenue driven from customers?  Aren’t customers driven by compelling experiences rather than mediocre hassle?

Clarity in objectives

Too many IT projects have vague buzz-word objectives.

  • “Single sign-on”
  • “Legacy refresh”
  • “Migration”
  • “Porting”
  • “Global Tick database”
  • “Unified platform”
  • “Cross channel integration”
  • “Content mashup”
  • “Real-time la-la”
  • “Streamlined processing”

These aren’t objectives. They are recipee for confusion, lack of clarity and focus. Better to think in terms of customer journeys, what is it that an end user want’s to achieve, end to end, and focus on delivering real value to customers, rather than trying to deliver some amorphous, mamouth “implementation” that does a lot of something mediocre, and little of anything great.

The project see-saw

Most organisations have separated their IT function with IT offering their services at a price. There are good reasons for this, but it is not without its issues. Prashant Ghandi has written some good stuff on this. All too often the separation is more a divorce. This manifests itself in the “business” creating projects (hopefully with clearly defined benefits) and throwing them over the fence to IT to deliver. This would not be an issue if the project is founded on a solid benefits case, with benefits matched against project costs. But all too often the relationship is like a see-saw, with benefits and costs bouncing up and down and focus on the business case is lost. Far better to work together in partnership, building the business case together, focussing upon delivering strategic value to customers rather than balancing the project on a fulcrum of mistrust and compromise.

Project in balance

Needs, wants and desires

As a…
I want to…
So that…

The trouble with this story template is that everything is a want. And as I tell my three year old daughter when she says “I want some sweets” I say no! You can’t have them. They’ll rot your teeth!

A story list of “wants” is little more than a feature list. Yes, it may be prioritised, but are we just prioritising “I want a mars bar” over “I want a Twix”?

So how about separating needs out from wants.

When I travelled in Tibet, I needed to go to the toilet. I certainly didn’t want to go… As a junkie, I need a fix. I don’t necessarily want to stick a dirty needle into my arm.

Possibly not the best examples…

I need to login to access my on-line bank account details. I don’t want to log in.

What if we focus upon what our users need to do before including all their low level wants? Imagine the needs are the roots of product that we build, with the wants being the branches. The needs are the outcomes that must be satisfied.

I need to get to Manchester.

As soon as I introduce “wants” I begin to loose sight of my outcome. “I want to fly in an executive jet with Champagne on tap…”

There’s another dimension to consider. Needs and wants may be persona or environment specific.

There’s a half drunk bottle of water lying on the ground.

I’m in the desert. I’m dehydrated. I need to drink it.
I’m on the street. I’ve been to the pub. I certainly don’t want to drink it!

And maybe there’s another expression of volition, that of desire.

I need a drink
I want a glass of wine
I desire a bottle of ’53 Margaux

Maybe there’s something in this…

Customers are not your enemy

Paired programming can be daunting to developers who have not done it before. The thought of some someone else looking over your shoulder whilst you work can be met with resistance. And yet the benefits of the transparency that paired programming brings are well documented.

B2B organisations display similar traits to the developer who is resistant to paired programming. They don’t want anyone looking over their shoulders until they are comfortable with what they are doing. And that includes customers. In my experience, the bigger the “B” and the smaller the “2B” the harder it is to gain access to the people we are developing the product for.

It’s not like this in the B2C world, where organisations understand the need to talk to their customers, to do market research, to test propositions. In the B2B world, organisations become far more protective. There is a fear that if we talk to our customers we will be making promises that we cannot keep. We will be building expectations that will inevitably be broken. In the B2C world you can show what you like to customers, if the final product bears no resemblance to the ideas we’ve tested in focus groups it doesn’t matter. The conversation with the customer is part of the process. We do not assume any “customer memory,” indeed the fact that we have explored different ideas and propositions with customers is seen as a positive; it can feature in the PR associated with the product release. If you release a product to market that looks nothing like what you’d explored in early focus groups it really doesn’t matter. You are selling to a segment that is bigger than a focus group of 12. But what if you customer base is small. What if there is a customer memory, that the people you test propositions with are the people we depend on selling to. The people who will keep us in business. In such a scenario it is understandable why you become protective of your ideas and fear saying anything to your customers until you are confident that you can deliver it. Trouble is, by that stage it may be too late. You are committed to a path of action that can be costly to change. What is required is some transparency and honesty; creating a dialogue as early as possible.

So here is the challenge for B2B organisations with a small, high value customer base. Open yourselves up. Be honest, open and transparent. Web 2.0 is all about collaboration and social networking. That shouldn’t just be about me sharing my photos on flickr, my videos on YouTube, my bookmarks on delicious. Product managers should be blogging about what is happening on the product they are developing for their customers. Customers should be commenting on the progress that is being made; they should have a direct channel to the development team, not via layers of corporate Chinese whispers. Here’s a challenge to the business in B2B organisations; get blogging. Stop fearing your customers and worrying about failing to meet what you perceive them to expect. Once you are transparent to your customers and proactively manage their expectations you can venture on a more successful and profitable journey as partners, not as adversaries.

Parsimony and the golden plate

A general principle in science is that if there are two feasible explanations for a phenomenon then you will take the most parsimonious, the simplest and most elegant solution. Agile software development takes a similar principle, do just enough focussing upon what is truly needed. Practitioners of the methodology will recount with pride how they have worked on projects were the “customer” required A,B and C. They’d planned for eight iterations, but by the sixth iteration they’d delivered A,B and half of C and the customer was happy; the software met the customers requirements and was delivering business value. There’d be diminishing returns by carrying on any further; any more work would be “gold plating”

“Gold plating” in software development is a concept that is frowned upon. Doing more than is strictly necessary breaks the theory of parsimony; if it is not going to demonstrably deliver value then it is gold plating and is to be given a low priority. More often than not gold plating is seen to be “scope creep”. This is often manifest in agile projects when requirements are deliberately vague at the outset of the project. Why invest time in specifying requirements that will undoubtedly change as the project progresses? The problem is that the developers’ idea of how a solution will be implemented will be the most parsimonious solution whilst the customer has a more complex idea of how a feature will be manifest. The requirement is the same, yet what the customer actually wants is gold plating and scope creep. Let’s explore this with an example outside the software industry.

Imagine a product in development. It’s hi-fi comprising of separate amplifier, CD player and speakers. It is to be sold as a package (yeah, development is iterative and each component could be a release, but that is not the point here…) We are going to need to connect the CD player to the amp. We can express that as a story:

As a customer
I want to connect the CD player to the amplifier
So that I can amplify my music and listen to it through speakers

OK, so we need some interconnect cables. Using our experience of connecting amps to CD players we picture this:


We know what it takes to make one of those cables because we’ve made them before so we can accordingly put an estimate to this requirement. Trouble is, for this scenario it will be wrong.

Return to the opening statement, “imagine a product in development”. There is a whole wealth of information missing in this statement. There is more to the product than it’s physical construct. We need to consider the context in which the product is to exist. In the world of interaction design this is contextual analysis.

Numerous factors may have an influence on the development of features. Start with the competitive landscape it will play in. When placed against competitor products, what is it aiming to do, is it going to meet a need (the CD player just plays CDs); are we looking to achieve competitive parity (we will match other features that are standard on our competitors products) or is the product goal to exceed expectations and become the market leader (it will offer superior sound quality and the ability to play MP3 files).

Who is the target market? In our story we stated “as a customer”, but who is the customer? Is it mass market or niche audiophile?

In addition to the business objectives which are critical to drive forward the project, (i.e. launch the new product to increase market share) the product objectives should also be considered. For our hi-fi this is “great sound for the budget audiophile”. Once we have this we can attribute emotional requirements to the product. How will our target customers expect to feel when they use the product. What emotions should it elicit? For this product let’s assume “high quality” and “simplicity,” rank highest.

With this background, when we return to the interconnect requirement, it is clear that the original assumptions are invalid. Our assumptions were based upon a mass market solution achieving competitor parity. In fact we need to aim a little higher, our customers are more discerning, the product is to be marketed as high quality audio and we are looking for the product to be an award winning design. So those interconnects? We need to gold plate them. The story will actually manifest itself as this:


Mmmm. Gold plated interconnects. Gonna sound good!

Now the real world

Let’s take a requirement from the banking world. It’s a system that allows users to trade equities; to buy and sell shares.

As a user
I want to select a UK equity
So that I can see its current bid / ask price.

At its most parsimonious our acceptance criteria (i.e. how we will know this requirement is complete) are as follows:

Given the user enters the stock RIC code
When the chosen stock is valid and tradable
Then display the bid/ask price of the stock

Given the user enters a stock RIC code
When the RIC code is not recognised, the chosen stock is invalid or untradable
Then display an error message saying “RIC not valid”

But is the most parsimonious solution the right one? We can only answer that once we have carried out some contextual analysis. For professional equity traders, who know RIC codes and speed is of the esscence then the implementation implied in the acceptance criteria is correct. But if the stock look-up is a new feature on a retail banking “portal”, extending the banking offering beyond balance and transaction reporting and making payments, to include share trading for a “mass market” audience then the implementation falls short of what is truly required. In this scenario the feature requires gold plating. This may include

  • Searching on company name in addition to RIC code
  • Meaningful error messages
  • Help text, content managed.

If the requirement is to have a “world class” share trading system we may need even more gold plating:

  • Narrow search results as the user types in letters
  • And so on.

If we turn to business value, it is hard to ascribe business value to the gold plating of individual features. Instead we should explicitly state up-front the emotional requirements that will “bloat” features beyond the most parsimonious implementation and inflate our initial estimates accordingly.

Upfront is good

Let’s get a few things straight.

  • Analysis and documentation are not synonymous.
  • “Big up front design” (the agile zealot’s hell) and analysis are not the same.
  • The holy grail of self documenting code (“the code is the documentation”) means bugger all to people who ask for the software to be built in the first place (people for whom a class is something they went to school in).

The Agile Manifesto states “Working software over comprehensive documentation”. Note the use of the word “comprehensive”. It doesn’t state “working software over documentation”. It also states (and this is all too often forgotten) “That is, while there is value in the items on the right, we value the items on the left more”. It is essentially pragmatic, do just enough that is necessary to allow you to be successful. This is most important in the field of analysis.

On all but the smallest of projects where you have a customer who knows exactly what she wants, is available at a moments notice to the developers and can communicate a clear vision to all involved, you are going to have to invest in some analysis. I’m not talking about writing-a-bunch-of-stories-analysis, I’m talking about understanding the business context, producing a product statement, segmenting customer needs. Maybe it is crafting an aspirational visual representation of the end product, wireframes, an information architecture, an imaginary product “fact-sheet”.

I’m not saying do reams of analysis for the sake of it. I once worked on a government project where I spent three months specifying requirements and designing business processes for a scheme that was inevitably going to change when new legislation came out. That was stupid. Just enough analysis is not only volume and content, but also its timeliness. It would have been sufficient to identify the broad scheme requirement as something in the pipeline with the detail to be fleshed out when it was required. That way we would know about it up front, and act upon it when required.

Developers are smart people, they don’t want to write code for the sake of it. They ask questions, why are we doing this? “Individuals and interactions over processes and tools”. Nothing in that line about not using documentation. Just the right type of documentation to help facilitate the conversation. “Individuals and interactions” lack permanence – the business guy doesn’t want to explain the who’s and why’s to every new developer that comes to the project. They expect to state the project background once and it to persist through the project. (Ask a business guy to repeat this stuff more than once and he’ll soon get annoyed).

Bottom line: Do up front analysis and be proud of it. Make it just-enough in a format that is appropriate (so why is it suddenly OK that it is on the Wiki rather than in a Word document on the corporate LAN?) Get it out there!! Stick it on the walls, let everyone see the business objectives, who the users are (personas), the competition, the wireframes, the product mission statement.

Imagine a customer journey…


I go into a store and a salesperson helpfully shows me the product, but I’m not yet ready to commit. She offers me a great deal, I’m tempted, but I want to check it out on the web. She says “great!” scans the products and prints me of a personal card with a short unique identifier and a unique website URL. I search the competitors, the salesperson was right, she was offering me a really good deal. So I got to their online shop and enter the URL and there is the tailored deal that the salesperson told me about. It has even got her name on it (so I know he’s going to get some credit for the sale). I get through to the checkout screen. I enter my personal details and I’m just about to buy, but I’ve got a question about the terms and conditions so I take a pause in filling out the form. There’s a number on the website and I get through to the call centre. I don’t have broadband so I loose my connection. The voice at the end of the phone knows who I am and where I am up to. I’m ready to commit… but she apologises, she doesn’t have any in stock. I’ll have to wait seven days. But I could pick it up from the store tomorrow if I want (or even a store close to where I work) or I can get the store to deliver if that would be more convenient. I’m delighted. The next day I go to the store and it is waiting to me. The sales person smiles. She didn’t take my money, but she ultimately made the sale and she’ll be rewarded for it.

Fantasy? It shouldn’t be. Thinking in terms of the customer experience and the customer journey is only the first baby step. The giant leap is to get IT bought into it and implement a solution that is not going to cost the earth and take years to (not) deliver.

And that’s where ThoughtWorks comes in. We thrive on getting everybody together and using creative, collaborative and highly visual techniques we quickly get everybody to consensus on the vision we want to move forward on. Because we are an IT company, we understand the opportunities and constraints with technology. But most importantly because we use lean and agile techniques to delivering technical solutions we are responsive to change, flexible with emerging requirements and can focus on getting things done – the baby steps – whilst working towards the giant leap that will win lifetime value for customers. Hmmmm. That’s beginning to sound like marketing blurb.

8 of 10