Agile

Ditch the feature shopping list. Think customer journeys.

  • Thursday, 19 October, 2006
  • By:

Let’s imagine a mobile phone provider that that has an on-line presence as well as a high street retail network. Their current website was built several years back on legacy technology; it is slow and has a conversion rate lower than industry norms. Along with having poor usability, the current shopping cart functionality does not support the concurrent usage figures that are hitting the site. The business takes the output from their web metrics and throw these at IT and demand improvements. And a new IT project is born. Rebuild the existing site on a new platform. They get a design agency to handle the look and feel. The functional requirements are built upon the existing functionality and chunked into functional silos:

  • Content managed brochureware site
  • Phone selection
  • Tariff selection
  • Shopping cart
  • Order management

A typical project process. That is flawed. It is starting with a functional premise. An alternative is to think in terms of the customer and customer journeys.

We can start by asking who the customers are. Almost certainly the marketing department has a customer segmentation model – this is a good place to start. That may give us basic attitudinal and behavioural details on customers, but we need richer data. How do customers shop for phones? So we go and spend time in the stores and observe how people buy them. It soon becomes clear that the choose phone – choose tariff buy model is a journey that is only taken by a certain number of customers. Other customers come into the store with intentions – they don’t know what phone or tariff they want, but they know what they want a mobile phone for. Other customers come into the store asking lots of questions, they are doing research; they leave the store with the sales guy’s number, and costs for a couple of phones and tariffs. We look at the competition and see how they sell phones. We look at Amazon and eBay and expedia and see how other retailers sell products and experiences on the web. We synthesise our research and suddenly we have a whole bunch of new requirements. Gasp! Scope creep. Indeed if we list them out into functional silos again:

  • Content managed brochureware site
  • Lifestyler phone selection wizard
  • Save a quote
  • In-store quote save for on-line fulfilment
  • On-line purchase for store fulfilment
  • Phone selection
  • Tariff selection
  • Shopping cart
  • Order management
  • Etc

The business is excited and IT is despondent. When the business announce the date all this must go live by, the letters of resignation land on the IT directors desk and they start looking for contractors. It does have to be this way. You can have your cake and eat it.
Rather than thinking about vertical functional silos, we should think about horizontal slices through the functionality. Slices that support customer journeys. We can start with simple journeys to start and build complexity as we prove our process and new platform, mitigating technical risk as we progress.

don't functionally silo, slice by customer journey

The first release probably needs to demonstrate the new platform works: we can deliver on time; that a new shopping cart interfaces with our legacy warehouse order management system; etc. What’s the bare minimum we can do that does this and delivers business value. How about a microsite that sells a single product. Customers are directed to the microsite via a URL published on a flyer handed out in the stores.

As a customer who has picked up a special offer N80 deal flyer, I want to buy a Nokia N80 on a pay as you go contract

Our acceptance criteria:

Given I enter my personal details and credit card details When my credit card details are validated Then send order to warehouse to dispatch phone and activate contract.

We can decompose this requirement into discrete requirements, “stories” of sufficiently small size and estimate them. We’ll soon get a project velocity and because it is only a small release expectations, risks and dependencies will be easy to manage. We’ve not had to wait for months to get something out, everybody is happy.

We identify that a profitable segment of the market are the aspirationally clueless. People who want a mobile phone, realise they are a minority who don’t have one but are too afraid to admit they have no idea what they want. So we build a new customer journey.

As an aspirationally clueless I want say what I do and how I live my life and have a suitable phone selected for me.

OK, not the finest story, but you get the point. This story might take elements of the phone selection and tariff selection functional silos, but just enough to realise the required functionality. Because we are building around customer journeys, just enough to realise customer intentions that support those journeys we build only what is required. We are not building by feature list. We don’t over promise and under-deliver. We are building trust with all stakeholders. Surely this is the better way to build software, thinking about customer intentions and incrementally delivering to support more complex customer goals. Sadly, people all too often get fixated by feature lists. Because that is what they are used to. Because that is how products are sold. But isn’t there a marketing 2.0 where we sell experiences and go beyond the product. Isn’t that what Virgin does? But I’m probably off on a tangent.

Getting attached to stories

  • Monday, 16 October, 2006
  • By:

The physical manifestation of agile stories are a description of the requirement (in the form “as a [user], I want to [goal], so that [reason]”) written on an index cards with the acceptance critiera written on the reverse. The developer can pick up the card and work with it. Once the acceptance critiera are met it can be put in the pile of completed cards. If at any stage of the process we are not happy with the card, given that it is only a “promise for a conversation,” it can easily be torn up and rewritten. Tearing up cards is a powerful statement. We don’t like what we’ve written? That doesn’t matter, rip it up and start again. That works well in the opening stages of a project, but sooner or later the cards will be copied into a spreadsheet and this is where the problems start. We become attached to the story; good project management discipline demands we keep an audit trail of what we do. Suddenly it is not so easy to rip up the card. Maybe the initial story did not truly represent the requirement. More often than not the story title, and detail will remain the same, but a notes column will be spawned in the spreadsheet and the change to the story will be entered as narative in this column.

Clearly this is not a satisfactory way of doing things. Part of the agile coaching process has to be around the flexibility of requirements, and this includes refining, rewriting and splitting stories as the project progresses. The underlying scope of the project will remain the same, however inevitably the estimates will change. This is often difficult to accept if you are versed in traditional project methodology. At the beginning of waterfall projects you have certainty, clearly defined requirements and a plan to guide you by. It is towards the end of the project where deadlines slip, scope is managed by change requests and IT is cursed as being unreliable, untrustworthy and the breaker of promises. The reverse is true with agile. There can be a whif of unreliablity in the early stages of the project, particulalry if there is no clear plan. This is excerated with an excel storylist that changes by the day. The difference is that you are more likely to succeed in delivery when going with the agile approach.

Agile Vs Waterfall uncertainty graph

The bottom line has to be an acknowledgement that there will be pain during the opening weeks of a project. Stories will be ripped up – delete them from the spreadsheet and don’t bother to keep an audit trail. Agree that the story list will be in a state of flux for the first few weeks. And once the project is settling down, once we have a better understanding of the project and are happy with stories, only then should we use formal PM tools with confidence.

Chinese whispers in IT projects

  • Tuesday, 10 October, 2006
  • By:

Hello. I’m a developer. I’m going to build your product. I do what the BA tells me.
Hello. I’m a business analyst. I’m going to articulate requirements for the developer. I listen to the product owner.
Hello. I’m the product owner. I’m responsible for what goes in it. I’m going to tell the BA what it should do. I listen to the sales Manager to find out what features the product needs.
Hello. I’m the Sales Manager. I know what features my customer wants, I listen to them.

Hello. I’m Head of Procurement. I’m responsible for selecting the product. I tell the Sales Manager in the product company what we want. I know what we want because I listen to the Division Managers.
Hello. I’m the Division Manager. I want a product that does %%&***£$%£ to drive my sales. Give me a product that does that.

Hello. My name is Sally. I use the product. You know, the thing I really like about it is $%$£$$£^. And here’s a list of what I really hate. Give me a bit of $££%£$”£ and I’d be so much more productive. But noone listens to me.

Hello, I write this blog. I’m an interaction designer. I’ve just sat with Sally for the morning and seen what she’s done. And you know what – we’re getting this wrong. What she really needs is ########. That would really add value.  And it’s is far simpler, quicker and cheaper to deliver than what your guys were proposing.

My life as a BA

  • Monday, 18 September, 2006
  • By:

I recently found myself in the role of “BA” on a project. I’m usually involved in “quick starting” projects; driving out high level requirements, developing project / programme roadmaps and helping clients produce tangible visions of where they want to get to. For me, the story lifecycle ceases at the “as a… / I want to… so that…” It is still a placeholder for a conversation – we’ve not yet started to look at the detail. So It’s been good to drill deeper into the anatomy of a story. and so I found myself with the daunting task of writing “acceptance criteria”.

I’m not really a completer-finisher; I’m more into the big picture, so having to get into test detail has the potential to get painful. But this is where I am grateful to Dan North for his Behaviour Driven Development 101 before commencing the gig, and in particular around testing:

Given…
When…
Then…

Inspired. Suddenly the acceptance criteria are in language that I can understand. It becomes a joy to tease out criteria. And it is easier to say when enough is enough – it is after all about diminishing returns (hey Dan?) The value really shone out when a client was explaining complex rules around how some equity trading functionality would work. It was hard to understand what the requirement was. So I asked him to put himself in the shoes of the developers who will build the functionality. How will they know when they are finished? I scribbled out three columns – given / when / then. He then succinctly articulated the scenarios within this framework. What had been hard for him to explain, and even harder for me to comprehend suddenly became clear. Within a couple of minutes we had the story wrapped up were able to move on to the next story on our pile.

If you give me something, don’t make me work to use it

  • Friday, 15 September, 2006
  • By:

My Nokia N80 came with a bunch of software including Nokia PC suite and Lifeblog. the former is for syncing up the phone with the PC, whilst Lifeblog looks after all the photos I take on the phone. Now you’d of thought that two peices of software on the same CD from the same supplier, packaged with their phone would be compatible with each other. Think again! I’ve got PC suite open and I try to upload photos from the phone using Lifeblog. And I get the below message…

nokia1.gif

I get a message asking me to restart my computer and try again (which won’t rectify the problem because PC suite loads in the system tray). Sorry Nokia. Poor customer experience. You’ve given me a couple of cool peices of software, but haven’t bothered to ensure they are compatible. Or maybe you did but it was a bug that was discovered too late. Now what if they’d been thinking in terms of behaviour driven design:

Given: I have PC suite and Lifeblog open at the same time

When: I choose to upload photos using Lifeblog

Then: the photos will upload and appear in the Timeline view

Or is that too obvious?

This agile lark. It’s like build a car right?

  • Wednesday, 13 September, 2006
  • By:

It’s great when your client gets it. He gives us the analogy. It’s like a car. Release planning is all about getting the car out on to the test track. It’s gotta have a chasis, four wheels, an engine and a steering wheel. Iteration planning? What order should we build stuff in. Well we don;t need the wheels until we’ve got the chasis. The engine is a high priority and there are a lot of dependencies associated with it. And we don’t really need the sterring wheel if we are happy to test on the straight strip… But remember, just because the wheels come lower down the plan, the release isn’t complete until they are all on… And also remember that this is just the “bare bones” of the car. It drives. We can’t acutally take it to the motor show until it looks good. And we can’t take it to the market until it is comfortable.

Prioritising stakeholder emotions

  • Monday, 21 August, 2006
  • By:

I was recently involved in a prioritisation exercise. The application included a UI that presented large numbers to users in financial institutions. The business owner (sadly there was never any question of acutally talking to end users) had complained about how easy it is to make mistakes when adding loads of noughts to a sum – and pondered that it would be great if when the user tabs away from the field that long number is entered, that comma seperators should appear:
i.e. he types 1435245001.00 and on tabbing away the number appears as 1,435,245,001.00.

Cool! It’s captured as a requirement and we move on.

When we go through our prioritisation, it is considered to be a “nice to have”. With a bulging requirements list and estimates squeezing the list, this requirement is initially an early one to go. After all, what business value does it add? But this is where the planning process must be iterative.

The effort to implement this requirement is nominal. Whilst the “business value” is considered nominal, the value to the stakeholder who requested it is emotionally signficant.

When we showcase the story that demonstrates the ability to work complex financial algorithms based upon the number the user enters, the stakeholder will nod his head and say “great”. It does what he expects. But how good will he feel when he sees the commas appearing? Little cost to implement, zero identifiable business benefit, but significant stakeholder emotional benefit.

As a project, when the key stakeholder leaves the showcase, how would we prefer him to feel?  “yep, that’s what I want?” or “Gee those guys are good”?!

What do you mean by “the customer”?

  • Thursday, 10 August, 2006
  • By:

As agile practitioners we wax lyrical about “the customer”. But who do we actually mean?

More often than not it is the “business”. A vendor relationship is implied, with IT supplying goods and services to the customer, who is the business. But the business is not really the customer. They are more an intermediary. An intermediary who in turn provides the product or service to the people who will consume them; the real customers. Yet if these real customers or consumers are considered at all, they are relegated to the title of “users”.

Calling the business “the customer” is an artificial construct based upon an arms length relationship between business and IT. Once this boundary is removed the real customer emerges. Moving beyond the vendor relationship between IT and business towards a partnership ensures a common customer. And ultimately it is this customer that fuels an organisation.

(In the CIM marketing glossary, there is no entry for “user”. There are two for “consumer” and six for “customer”. Not all projects will involve retail customers – think of call centre dudes. But I think the point is consistent…).

Organisational convergence

  • Tuesday, 8 August, 2006
  • By:

Success is rarely delivered by one part of the organisation; it requires the collaboration of different departments working together. Yet there is all too often a separation of responsibilities that can hinder the efficient development of ideas. Worse, there is no single owner of the business case resulting in business value being lost.

A crude model illustrates this. The “business” holds the business case. They are focussed upon the benefits case. IT are treated a factory to build the mechanisms that will support proposition and are thus focussed upon the costs. The customers (who ultimately use the proposition) are held at arms length and not involved in the development of the proposition.

business, IT and customers seperated

There can often be a tension between the business benefits case and the IT cost to deliver. The cynical view of the waterfall approach is that Business want it all, IT promise it all and their relationship deteriorates as the project nears its scheduled completion; IT cannot deliver on time or budget, the business has to make unplanned compromises and ultimately the customer suffers. The Agile approach goes some way to mitigating the risk of relationship breakdown. Painful messages about what can or cannot be delivered are communicated early on, enabling informed decisions to be made. However if the organisation is structured with clearly defined boundaries it is far harder to make truly informed decisions. As soon as scope changes, the business case will change. What often happens is that IT adjusts the numbers on the cost side, but the benefits case remains unchanged. If the business has spent many months working on the benefits case it is difficult to make changes on the back of an afternoon’s reprioritisation exercise. There is a solution to this. Taking an inclusive approach to proposition development and delivery; having all parties involved from the outset.

Here’s another crude model. Rather than being separated, the different stakeholders converge. There is a cross-pollination of ideas and understanding. The business case is shared, iteratively and incrementally developed. Customers are engaged in the process; providing market insight and testing the user experience. There is nothing new in this model, although I rarely see it working from the project outset. Often two of the three circles converge; the challenge is to get all three overlapping. I’m pleased to say at ThoughtWorks, increasingly when we initiate projects we are doing this.

Convergence of IT, customers and business
9 of 10
5678910