Agile

Agile experience design video

Doesn’t time fly! It’s been seven months since I last blogged. Since then I’ve moved on, living in a world of car insurance and credit cards. I’ve got loads of ideas for new blog posts brewing, but just no time to get them down. Writing the book took a lot of of me last year!

Anyway, until I write something fresh, here’s a video of me waxing lyrical about agile experience design at the excellent Scan Agile conference in Helsinki earlier this year.

How the retail banks are addressing customer experience

A few weeks ago I attended the Customer Experience Management for Banking and Financial Services conference, presenting on driving agility into your customer experience.  There were some great presentations, it is great to see the banks taking customer experience seriously. From my notes, what follows are some of the presentations and ideas that resonated with me.

Anthony Thomson, Metrobank

Anthony Thomson, chairman of Metro Bank was inspiring. Everything they do is from the customer perspective.

For everything Metro Bank do, they ask ‘why are we doing this?’ Is it going to make our lives easier, or is it going to give our customers a better experience? The second trumps the first every time.

Metrobank see that they (like all banks) are essentially a money shop who sell the same products as their competitors. The only real differentiator is experience and service. With the Vickers Report recommending “the early introduction” of a system that makes it easier to move accounts and that is “free of risk and cost to customers”, this is going to become increasingly more important.

Retail is detail is the old adage. Think about something as small as the pen on the counter. Chaining it down may suggest security, until you see a chain with no pen attached. Anthony questioned what is the cost of a pen? What is the value of having your branded pen in your customers’ kitchen? Talking of branding he showed a picture of a Metrobank van. Banks use vans all the time to transport the pens and stationary to the branches, but they are never branded. Is this security trumping marketing? A lack of joined up thinking? He commented on the press comments on Metrobank attitude towards dogs. Focussing upon the dog misses the point. Customers love their dogs, why shouldn’t they be allowed in the stores and be positively welcomed! By saying “no dogs” are you saying we care more about our carpets than our customers?

Another detail thing – how often have you waited outside a bank to open in the morning, or be hassled out because it’s the end of the day and is now closed. Metrobank have flexibility, they’ll open a little earlier if people are waiting outside and stay open till the last customer leaves.

A theme through Anthony’s presentation was of empowerment. Empowering staff, removing pedantic rules that get in the way of delivering a compelling customer experience. He told a story of how a customer had to wait longer for assistance than expected and incurred an £8 parking ticket. A member of staff wanted to refund the customer and suggested giving them £4. To which Anthony commented “and only half piss them off?”

Empowerment starts with recruiting good people. Only a fraction of the people who apply get to work for Metrobank. They understand that skills can be trained so they recruit for attitude. If someone whose job is to interact with customers on a daily basis doesn’t smile, they don’t get the job. When it comes to targets, they ‘measure what matters’. They incentivise on service not sales because with good service comes sales.

Rob Hawthorn, Barclays

Empowerment was a theme that ran through the presentation that Rob Hawthorne from Barclays gave. He’s taken a leaf out of the hospitality industry and borrowed from Ritz Carlton with their Credo Card, a single sided card that reminds their staff of the levels of service they should provide. Barclays corporate staff are empowered to fix the problem. Like Metrobank they strive for no stupid rules and put the customer first. For example a customer pays in £230.60 and only £230.20 is credited to the account. They now refund then investigate. By introducing this policy change they say a 65% reduction in customer complaints.

Everyday, in every Ritz Carlton hotel they have The Line-up. This is a fifteen minute meeting to review guest experiences, address issues and identify how they can improve service. It is an opportunity to tell stories, both top down (what’s going on in the company overall) and bottom up (what can we learn from individuals and their interactions with customers). Barclays corporate do this across the organisation. From the top down they have one version of the truth; what is happening in Barclays world, what is important and what are customers saying today?”

The fifteen minute meeting is a familiar concept within agile, known as the standup it’s a brief meeting where the team review what they did yesterday, what they are doing today and any issues or blockers they are facing.

“How often do you see your complaints data?” Asked Rob. What use is seeing it once a month? You should be seeing it every day. Better still (and this is something that I alluded to as well), walk in the shoes of your customer. Get out into the branches, into the call centre and see what is going on for yourself.

Richard Brimble, Veolia Water

Not FS, but Richard gave a view on customer experience from a different viewpoint.  He gave an engaging presentation that started by asking if you are a blue tit or a robin. Blank states from the audience, so he elaborated. After the first world war milk companies started sealing milk bottles with foil tops. Until then the bottles had open tops and both robins and blue tits would drink the cream from the top. With the foil tops the birds had to learn to peck through them. By the 1950s the entire blue tit population had learned this. Robins never did. Robins are territorial and solitary creatures, whilst blue tits are social. They may be scruffy compared to the elegance of the robin, but they are innate communicators. They share their learnings and copy each others successes. As an organisation are you a robin or a blue tit?!

Sean Gilchrist, Barclays

Is Barclays going all Lean Startup? Sean Gilchrist from Barclays told a story of their lean customer development approach to developing their mobile bank Barclays.mobi. The journey started in data; a significant minority of customers were accessing internet banking using mobile devices. A clunky experience at best. Rather than going the Big IT route they went lean and did some customer discovery. “What’s important to you?” they asked customers.  “Checking balance” they were told. “How about paying bills on your mobile?” they asked, “No, we just want to check balances” was the response. “How about a branch location finder?” to be told  “No, we just want to check balances”. In eight weeks and on a shoestring they built and launched their minimum viable product, Barclays.mobi. The product was instantly successful and gave the team leverage to continue development.

Sean told another story about the perils of just pushing something into production without thinking about how people behave on-line. To access account information on on-line banking the customer has to use a security device that displays digits that are then entered into the application. The digits were displayed in two blocks of four:

1234 5678

A decision was taken to replace the single field on the application where this number was entered into two fields that better represented the way the number was presented on the screen, i.e.

|1234| |5678|

The week they made this change they received over thirty thousand complaints about this change. When I’ve recounted this story to Barclays customers they can remember when this happened and what a pain it was. People who don’t touch type look at their keyboard, not the screen. They entered the number as one continuum, not in two blocks. Tabbing between fields is an ‘advanced’ technique. Suddenly the customer was unable to enter the number without having to use their mouse to move to the next field. A change that was suppose to reduce errors ended up causing more. The issue was fixed by have an auto-tab between the fields, but not before customer complaints. Usability testing (oe even having an experienced usability expert on the team) before going live would have picked this issue up.

Trent Fulcher, RBS

Finally Trent Fulcher from RBS presented on the customer experience and innovation work he has been doing at RBS. A key takeaway from his presentation was that at RBS they demonstrated a positive correlation between advocacy and revenue per customer. Not only are advocates more profitable, they also bring new customers to brand. RBS accepted that they will always have detractors to the brand and are happy to take a calculated decision not to focus upon changing their perceptions, rather focus on ‘passives’ and move them to advocates. He demonstrated how RBS modelled their customer journeys, understanding what customers value and expect from every touch point. What they discovered is that for some touchpoints they were overreaching on these expectations, enabling them to understand if they were focussing effort on the parts of the journey that Make A Difference.

Lean startup machine and the problem with parallel dating

Can you build a business in a weekend?  Can you take an idea, validate it through customer research and launch it to market in forty-eight hours?  Can you pivot in the process- realise that your proposition isn’t as compelling as you thought to your target market and either fail fast or change direction and build something even better?

Eric Reis has written about Lean Startup Machine in a blog that suggests you can.

Inspired, I travelled to NYC over the weekend to experience what Lean Startup machine is all about. I was blown away.

Here’s what happened.

The event kicked off at 6pm with networking then presentations on Lean startup and what it is all about.  Anyone who had an idea was given a minute to pitch to the group.  These were voted on and the best 12 ideas were selected.  People self selected the team they wanted to join – six per team.  The team I wanted to join had seven people, rather jet lagged I agreed to leave and move to an under-resourced team – at the time not my first choice of product to start up, but oh what fun it was to be.

First step was to document our hypothesis and assumptions. Our hypothesis was that men and woman who are active daters have problems with remembering / keeping track of their dates.  The customer value proposition was essentially a dating CRM system.  So I’m happily married so not the most obvious of product choices for me, but this is what the weekend was all about; coming up with a proposition and challenging it.  With a clear hypothesis, at midnight we hit the streets of New York to test it on our target market.  Interviewing people in the lines outside clubs and on the streets around we sought to understand whether there is in fact a problem.  We assumed that people date many partners at the same time and that they would be open to a system to help them manage their relationships.  Our hypothesis was partly proven, there’s clearly problem that is felt more by men than women.  Any solution would be targeted at men.   There are workarounds that men use, for example using fields in their phone address book to capture data such as place met, key features.  And the more ‘advanced’ parallel dater does indeed have a “little black book”.

To back up the qualitative data we built a surveymonkey questionnaire.  This would further validate the concept and capture insights into what data parallel daters need to remember their dates.  To drive traffic to the survey we planned on using Amazon Mechanical Turk to place ads on Craigslist personals through the night.  Unfortunately on Saturday morning both services had rejected us so the survey didn’t get as many responses as we’d have liked.

Our first Minimum Viable Product was a landing page using unbounce. A little more than twelve hours after the initial concept being pitched we had a product, live in the market.  BeBop was born (another variant was datingCRM was also launched to test the URLs and the effectiveness of the calls to action).

Landing page created using unbounce

At this stage the product was a landing page and a call to action “I’m interested”.  Clicking on that took the user to a form that included an email capture address and an option to sign up to the free version and to be notified of the paid-for ‘pro’ version when it comes available.  This way we could judge if the idea would easily generate revenue.  (All the people who completed the form indicated an interest in the $5 a month version).  The idea was to drive traffic to the landing page using Google adwords, but google didn’t like us and this was denied as well.

With our learnings from the previous evening’s customer research we did some design thinking.  The team sketched up ideas of how we could solve the problem.  This exercise was repeated six times – people are precious of their first design, by the sixth they are clutching at straws and this is when left-field ideas can brew up.  And it did.  Why did the product have to be an application?  We’d seen some non-smart phones the night before; an iPhone on Android app would be of little utility to some of target market.  What about an SMS texting service.

Pivot.

The afternoon was spent building a texting service based upon the Twillio platform.  Customers could text their name to a number and they were signed up.  All they they need do is text the contact details of their date to the service and it would be stored.  They could retrieve it by sending a message “info: name” to get that contact texted back to them.  We included some gamification to encourage usage.

The phone texting interface

Saturday night and we hit the clubs and bars again.  This time putting the concept into the hands of potential customers as well as handing out cards with the telephone number.  More customer research.  More often than not our target market was with women, so it was hard to gauge interest.  One guy pretended to throw away the card when the girl he was with expressed shock at the concept – with a slight of hand he tucked it into his shirt pocket as he brought his hand back.

Sunday morning and we reviewed the results.  Some vanity metrics – 150 cards handed out, around 50 meaningful conversations with more customer validation, 15 sign-ups and 7 messages sent.  Was this success?  Hard to tell.  We’d also built a basic MVP android app that we launched Sunday morning and the next step is to test this MVP with customers (the issue we had is that our target market is best found at night so customer testing in the daytime would be hard).  We talked about pivoting again and exploring taking the product to a wider market – do people with non-smart phones have problems managing richer contact details other than just a name and number?  One girl who’d seen the datingCRM product said that she’d use it for that.  But by now time had run out to test this new idea.

Three thirty on Sunday afternoon and each team had six minutes to present with three minutes of questions.  We were first.  It went well.  But how did we do?  We came third overall and joint best MVP.  But it wasn’t the competition it was about, it was more the experience.  It was a real privilege to work with such talented and smart people.  David Young-Chan Kay, Yan Tsirklin, James Washington and Mikhail A. Naumov were an awesome team to work with.  More than that, the whole NYC startup movement is infectious and inspiring.

It didn’t end with our presentation.  There were some other, awesome startups with even better stories that were hatched over the weekend.

One team started with a hypothesis around supporting people hook up with mentors to help them choose the right career path when they were starting out or unsure of the path they are on.  The concept bombed with both the target market and mentors.  In an hour of desperation they realised there was a common theme they were hearing.  People love to bitch and moan.  And thus on Saturday night jobstipation was born, an anonymous place to vent fury and angry about your workplace.  When they presented, ideas of monetisation and tying the concept back to their original ideas were suggested.

Screen shot of jobstipation

The team that won the weekend worked on the hypothesis that teachers spend a lot of time prepping classes, that they spend a lot of time searching for decent materials on the web and that they’d pay for a service that would provide them with quality teaching materials.  Research with teachers validated the assumption that teachers spend a lot of time (thirty hours a week) preparing for lessons.  But the idea that they display economically rationale behaviour was refuted.  Teachers would not pay for the service.  But their principals might.  Pivot.  The team asked the teachers for examples of lessons they have hassle preparing for – geometry was one example.  So they built an MVP that demonstrated searching for quality geometry resources.  They trawled the web to find the information and on sunday morning called the teachers again and showed them the website they’d built.  It may have been ‘smoke and mirrors’ but it worked.  The teachers loved it sufficiently to recommend the concept to their principals – the people with money who would pay for it.  All this in a weekend.

Guess who? (Kill the Agile Buddha)

Guess who am I now.

I’m in a supermarket, I’m pushing a trolley. I’m putting items into it. I just need some bread and I’ll be going to the checkout. Who am I?
I’m in a bank, queueing up in front a machine for depositing cheques. I’ve got a couple of cheques I need to pay in. Who am I?
I’m in an electronics store. I want a new printer but I’m not sure what’s the best for me, I’m looking for someone to help me. Who am I?

Or maybe what am I?

I am a customer.

Aren’t I?

Business language backs up my assumption. The employee at the supermarket checkout is called a Customer Service Rep, my personal (customer) details are held in the banks Customer Relationship Management system, in the electronics store I’m looking for Customer Support. And after I’ve bought my printer I’ll be asked to complete a Customer Satisfaction Survey.

So everything indicates that I am a customer. Or that is what I thought I was.

Apparently not according to the Scrum zealots.

At Agile 2009 Tom Illmensee presented a paper “5 Users Every Friday: A Case Study in Applied Research”. It describes how an eCommerce division of an electronics retailers introduced agile and how the user experience team adapted to agile. It starts by describing how their initial forays into agile were deemed successful. It was collaborative with the disciplines well integrated; “whiteboard wireframes, minimal documentation, and product demos. Usability tests with paper and semi- functional prototypes were conducted with shoppers each sprint”. More than that, the whole team enjoyed the experience. A decision was made to “take agile to the next level”. The next level was the introduction of a consulting firm who brought in scrum training. The scrum dogma was painful to adopt, but they got there in the end. But there’s a line in the paper that made me angry:

“The peculiar semantics of Scrum were especially confusing at first. In retail customers were people who bought things like stereos and flat-screen TVs. Not anymore. Agile had changed the definition of perhaps the most important word in our business environment: customers were now internal product owners. Customers would now be referred to as shoppers—or users.”

I’ll write that again. Customers (the people who the business depended upon, and “the most important word in [their] business environment”) would now be called shoppers. Or users. Because in agile, customers are internal product owners.

Sorry, these consultants, these agile zealots, these software egos have got too big for their boots. Dan North, pulling to pieces the nonsense of ‘software craftsmanship’ put’s it eloquently:

Software Craftsmanship risks putting the software at the centre rather than the benefit the software is supposed to deliver, mostly because we are romantics with big egos. Programming is about automating work like crunching data, processing and presenting information, or controlling and automating machines.

Software at the centre rather than the benefit the software is supposed to deliver. Software is the means to an end, not the end itself. If a certified scrum master (certified master based on two days training and a multiple choice questionnaire, now there’s a farce) tries to rewrite your business language, tries to tell you that your domain language is wrong, show him or her the door.

There’s a budhist saying “If you see the Buddha on the road, kill him“.

If you see agile in your workplace, kill it.

Why kill the Buddha? because the Buddha becomes an object, your own illusion of what it is. And it this illusion is wrong.  To turn the Buddha into a religious fetish is to miss the essence of what he taught. Killing the Buddha means taking responsibility for yourself.  Same with Agile; to turn agile, to turn software development into a religious fetish is to miss the point of what it is all about.

===

I presented on the customer theme a while ago, here are the slides.

And here’s me narating the slides on google video.

IT chalta hai

“Hearing the words ‘I LOVE this…’ from a client is a magical thing”  So tweeted Graham Smith.

Now how often does “the business” say that that to IT?  Rarely I guess.  Why is that?  Why doesn’t “business” love IT?

I think the Indians have got a phrase for this: Chalta hai.

I’ve recently come back from India.  As always it was a pleasure to read the Indian newspapers and weekly news magazines.  In discussing the Commonwealth Games, several columnists in their English language columns made reference to the hindi ‘Chalta Hai‘.  There is no direct translation (hence the columnists use of Hindi) but “it’s all right” or “it’ll do” comes closest.

Chalta Hai is an attitude.  It is mediocrity.  The columnists applied Chalta Hai to service culture and getting things done (or rather the lack of it).  Whilst Chalta Hai may be an Indian affliction, India is not alone.  I’m going to suggest that corporate IT suffers from Chalta Hai.  There’s an industry mindset that success is just getting stuff delivered.  Success is  “it’ll do”.  Mediocrity is a sufficient goal.  To hell with the experience; who cares what the users think, it’s all about delivering functionality and features.  We’re happy if “it’s all right”.  No-one has the desire to hear the business say “I love this!”

Let’s bring some magic into the enterprise.  Let’s introduce a new acceptance criteria to our requirements; that the stakeholder who signs it off says “I love this”.

The tyranny of nice

My first English lesson with Mrs Sullivan aged nine. She was one of those teachers you remember. An awesome teacher.

Nice” she told the class, “nice is a word you will not use”.

The word “nice” was forbidden in her classes. And woe betide anyone who described their weekend as nice, or their birthday present as nice (probably an Action Man or Scalextrix or if you were really lucky a Raleigh Chopper or Grifter).

It is a lesson I learned and kept close to my heart today:  Nice is mediocre, saccharine, inoffensive, meaningless, ordinary, without passion, expression or meaning. “Nice” is a faceless word. “Nice” is something that the left brain aspires to and the right brain shuns. Nice is an anathema to the artist, to the designer. Nice doesn’t provoke, it doesn’t inspire. Nice is instantly forgettable.

“Have a nice day”.

Shit NO! (this deserves swearing – see the passion that Mrs Sullivan infected in me; what a teacher!) That’s “have an ordinary day”. It’s not a differentiated day. I don’t want to just have a nice day. I want to have an awesome day, a magical day, a memorable day!!

And the same with experiences and products.

Disneyland isn’t nice; it’s memorable and magical (despite the fact that you spend most of your day there queuing). Do you think that Steve Jobs would be happy if someone called the iPhone ‘nice’?

Nice is for Microsoft. It is for engineers to aspire to. Nice is not art, nice is not design, elegance, simplicity or beauty. Nice is dull mediocrity.

And yet nice is something that corporate software doesn’t even begins to strive for. There’s no place for nice in software methodology. Think Scrum; nice is rarely even a nice to have (it’s gold plating). Tell me Scrum Masters, in your zeal to deliver “business value”, ship the “minimal viable product”, I bet you’d be happy with what you deliver being considered nice.  F@@k that. Your projects fester in a world of mediocrity,  in a quagmire of backlog; picking off stuff to do, focussed on features and functions rather than customers goals and a desire to delight.

Bring it on Mrs Sullivan. Nice has no place in the English Language. Bring it on, Agile + Experience Design. Nice has no place in software development.

Can you banish nice from your lexicon; go beyond nice and seek delight?

I don’t want to have a nice day, I want to have a memorable day.

I don’t want to have a nice product, I want to have an awesome product.

I don’t want to have a nice experience. I want to have a memorable experience.

…And if I’ve designed an experience and the only word you can use to describe it is ‘nice’ then I consider myself a failure.

The Dumbo ride at Disneyland; it delights, people will queue up for it, even though there is nothing special about the ride itself.  Carousel rides are nice enough but forgettable, the Dumbo ride is memorable and an experience to enjoy

Thinking inspired by the Agile UX retreat

In the quest to get agile and UX to get along better, and following successful retreats in the US, last weekend Johanna Kollmann brought together a bunch of agile and UX folk for an Agile UX retreat in London sponsored by.  Giving up a weekend was hard, but was worth it, meeting a great bunch of people and sharing thoughts and experiences from the agile and UX camps.  So what did I learn.

Rethink what we do

Coming out of the retreat it is clear that the way we do UX today needs a fundamental rethink.  As UX professionals we have fought long and hard to gain credibility and traction in organisations for what we do, but we need to be ready to evolve and embrace the changing world around us.  A world where IT no longer needs to have detailed specifications signed off before development start.  We no longer have the need (or the luxury) to do the up-front research that we are used to doing.  We no longer need to sign-off detailed wireframes before handing them over the fence to the developers to implement.  Software today really is soft.  It is more about creativity than engineering (see below).  The serialisation of activities is inefficient and wasteful.  It is time to ask how do we focus upon doing what is needed and when, working in parallel and infecting the whole system with user-centric thinking rather than siloing it into the upfront design.  This after all is what systems ergonomics is about; a forerunner to UCD that we know today, thinking about the macro (a broad system view of design, examining organizational environments, culture, history, and work goals) as well as the micro (fitting the task to the human).

But I am digressing from what I wanted to blog about, the Agile UX retreat.  Some key takeaways for me included Anders Ramsey‘s analogies to the restaurant and the theatre.

Thinking analogies

Think of a restaurant.  We have the kitchen, the back room world that is focussed upon delivering consistency of servings.  Everything in the kitchen is utilitarian, serving the purpose to meet this goal.  At the front of the restaurant we have the dining room where the dishes (of consistent(ly good) quality) made in the kitchen are served.  The dining room is all about the ambiance.  Quality here is far more subjective, but a successful restauranteur will be as passionate about the dining room as she is about the food that is cooked in the kitchen.  This is the way that software is all too often built, with the kitchen and dining room being separate entities, however the way they are organised, paid for and owned, there’s little communication between the two.  To quote another Ramsey, Gordon, it is a Kitchen Nightmare.

Anders’ second analogy to consider was the Theatre.  An overly simplistic representation is that the director starts with a script.  From the script he iterates the production.  The producer’s role is to provide the director with what he needs to make the production successful.  Just be ready for the premiere which is on a fixed date.  In the lead up to the premiere the director assembles the cast, the crew and they rehearse.  They’ve got a strawman plan to work from – MacBeth, but how they implement it will evolve according to the stage, actors and artistic direction the director wants to take.  The producer does not care how or when they rehearse, she is only concerned with the success of the end goal.  As they rehearse they increase the fidelity of their performance until they premiere (go live).  but even then they are not done.  They are happy to accommodate changes to the performance, and if something different happens that clearly delights the audience they will happliy incorporate that into future performances (releases).  Sure, the audience is seeing a performance of Shakespere’s MacBeth, but it is a unique performance that has taken the initial plan and evolved as it has been created.

And so should we approach software development.  Not as an exercise in engineering, where our raw materials are fixed and highly stable, but as a creative artform, where our iterations are rehearsals for the premier and ongoing performances.

Thinking tensions

I’m sure there are more, but some examples of tensions that emerge when we try to work together:

AUX promotes rapid open communication and sharing but designers fear sharing.  (They worry early designs will be seized upon before they are ready)
AUX promotes visualisation and use of walls but corporate policies prevent this
AUX promptes doing just enough, just in time but a legacy of deliverable expectations gets in the way (research is rarely bought by the developers who will ultimately consume it).

Thinking people

At the end of the day, success comes down to people.  Agile zealots have done Agile no favours when they bang on about business value and see anything other than code as waste.  Good product design needs vision, it needs research to ensure you are building the right thing for the right people.  No one has the right to tell a UXer that testing ideas or building a prototype or undertaking research is waste if it is right for their context.  But it doesn’t need to take the time it does today.  The UX community needs to get out and spend time with the development community and understand how software is built today.  UXers need to start seeing developers as partners rather than consumers of what they do.  What if we aligned our teams around the products we build rather than the functional silos that the roles describe?  Bringing agile and UX together is more fundamental than arguing about the process (one iteration in front, washing machine cycles etc), it is about fundamentally changing the way we build software; see it as a team activity that works collaboratively rather than a factory production line with process gates and separation of responsibility.

More on the #auxretreat twitter feed

Vision, passion and personal investment

Something that is common with the start-ups I’ve been involved with, and stories of entrepreneurialism you can read is the passion of those involved.  They have a drive and desire to succeed, backed by enthusiasm and belief for the product they are building.   More often than not, they are personally invested in the project; maybe it is a problem that they feel needs addressing (Dyson), or an opportunity in an industry they are familiar with. It almost always it goes beyond just a job, it is a hunger to bring change and make a difference.  They have a vision, it what drives them, yet they are willing adapt the original vision and move with agility as circumstances dictate.

FlickR started its life as a tool in a role playing game.  The game was not successful and ultimately shelved (fail fast) with the photo sharing capability being developed; the team realised where the value was rather than sticking to a failed big up front plan.  If you go back in time to 1999 and look at how google described itself:

Google Inc. was founded in 1998 by Sergey Brin and Larry Page to make it easier to find high-quality information on the web.

Nothing there about browsers or phone operating systems or word processors or spreadsheets.  Twelve years to go from a search engine to the Google we know today.  Place that lens over most enterprises and how have they managed to adapt to the changing world?  I know of several enterprise projects that are three plus years in, (that’s a quarter of Google’s life) and have still yet to start delivering value.  You don’t get that with start-ups, or places where vision, passion and personal investment drive the product strategy (thinking Apple and Steve Jobs for example).

I’ll lay the fault at Enterprise Culture.  Silo thinking and career progression through the ranks.  So an individual is personally invested in delivering documentation that specifies the system.  When she delivers these she is done.  What happens next is someone else’s problem.  Reward is rarely for delivering the overall vision, why should it?  How often do all stakeholders involved in a project have a strong grasp of the what’s and why’s of what they are doing?  They are only rewarded on the how they deliver the fragment that they are responsible for.

When IT becomes a supplier rather than a partner, no-one has ultimate responsibility for delivering a coherent holistic vision, it becomes a contractual relationship rather than a passionate obsession.  Funding projects is all to often a charade and a nonsense.  The business submit their funding requests (a line item for a potential project) for the forthcoming financial year in the autumn / winter.  Budgets are finalised in the Spring with the new financial year and months have elapsed due to internal budgetting and accounting formalities rather than the ability to respond to the market.  Contrast that with the start up model with seed funding to get started and if the projects shows viability second round funding follows.  If the project is not viable it is suffocated before wasting cash.  (There are interesting perspectives on this leaner model at Beyond Budgetting).

I wonder if in these lean times we are going to start seeing lean thinking applied to enterprises and a start-up culture being nurtured.  There is certainly a growing interest in agile, beyond the practitioners and from C level executives.  But agility in software development is only the first step.  To be really successful it needs to spread through the whole organisation, not just paying lip-service to the word “agile”, but devolving responsibility to individuals and collaborative, cross-organisation teams who can share the vision, passion and are personally invested in getting the right quality products to market at speed.

Don’t blue-tack the walls

Story wall picture

Agile is messy.  It is untidy; it clutters desks and dirties the walls.  Progress is not hidden in spreadsheets and gant charts in Microsoft Project.  No, it is on the wall.

Walls are central to agile.  Indeed any visual thinking process that uses ‘information radiators’ as central to communicating information (rather than circulating documents) will make use of walls, sticking cards, posters, post-its, stuff up for all to see.  When you start to use walls, good things happen.  Other people become curious, they walk to wall, they look and see.  When you have wireframes stuck to the walls they go arrrr!  that’s what you are building! There is a palpable excitement, a buzz to organisations who start (and continue) to use walls.

That is, until the detractors come along with demands to tear down the wall.

These usally take one of three guises.

The first, predominantly found in financial services is compliance.  Increasingly clear desk policies are being rigorously policed to ensure documents are not leaked between departments and this often finds its way onto the information radiators.

The second is facilities management who seem to think that their clean whitewashed walls are delivering greater value to the business than anything untidy that is stuck on them. Their knee-jerk reaction is to ban the use of blue-tack and get a whiteboard permanently drilled to the wall to hold the cards.

The third and final detractor is the IT manager who is dazzled by technology and insists on using technology to solve the problem.  Out goes the card wall and in comes a plasma screen with an excel spreadsheet displaying the cards.  This completely misses the point of the wall, of the human element.  Richard Durnall tells the story of his experience at Ford where they employed a technology based process for managing inventory at the plant.  “Unfortunately this process had a problem; it was rubbish.”  He contrasts this tech-centric system for that employed by Toyota:

When the guy on the line started a new box of parts, he’d take a card off the top and put it into a letterbox. Every 10 minutes or so another guy would drive around in a little truck and collect up all the cards. He’d then go to an office where he had a card sorter connected to a computer. He’d put the cards through the sorter, which at the same time sent messages on usage to the supplier network, and then he’d go and fill up his truck based on the cards that he had, returning the cards to the boxes.

Managing inventory with cards.  Using paper in a paperless office; not everybody gets it.

Knowing that you will have detractors to the paper walls is a first step in managing expectations and getting everybody on board.  Talk to compliance, facilities, and let them know what you are doing.  Ensure an executive sponsor can override any petty bureaucratic blockers.

And before you know it, the information radiators will have moved out of IT and into the way the business manages its tasks as well.

1 of 10
12345