Andy Yates

Dat New New shopping experience

2011-07-16T22:20:00.001+08:00

In this recent article written by my colleague Marc McNeill, he outlines some of the issues faced by high street retailers, given the current economic climate. He puts forward the recommendation that a focus on the customer experience is key to an effective online retail strategy. Further, he argues that this should extend beyond the boundaries of the website, to create a joined-up experience whether on the website or in-store.

The article got me thinking more generally about the retail industry, and - in a world where supply chain efficiencies place an ever increasing pressure on margins, and more and more sales are shifting online - wondering what role the bricks-and-mortar store could or should be playing? Already (and in some cases for more than a few years now), there are stores that aim to shift from shopping to experience - but could that be taken to the limit? Are we moving to a place where the act of buying something and taking it with you is no longer an in-store activity?

Of course, for many, the act of shopping is already in and of itself a recreational activity - most often undertaken as part of a couple or small group - and furthermore, we can see that a large part of that activity is actually an act of (mutual) identity creation. Identity creation is the bread and butter of consumer brands - you are what you own - particularly when it comes to clothes - but equally with music, books, electronics, furniture - you pick things up, try things on, and ask: "is this really me?"

The first wave of experience shopping has largely focused on identity as product customisation activities - used as a means to entice you into a store to purchase, or to purchase more once you are there. And what we're now starting to see with some retailers (Apple most readily springs to mind) is the creation of spaces specifically dedicated to recreational activity - with the expectation that your experience and identification with the brand will lead to purchases at some point. Even here, whilst there is a connection between the experience of participation in these activities and the creation of identity, I think we are only scratching at the surface of what is possible. A combination of technology (RFID and mobile internet, sure - but simple things like store cards too) and online social media paradigms (noting that social media is also about identity creation) opens up new possibilities - and I suspect that we'll begin to see individual or small-group customisation of these brand-related recreational activities, where increasingly the real thing being sold is identity itself. So what kinds of activities might we expect to see?

identification of items carried that have previously been purchased from this brand - leading to status within a store environment
'checking in' - attaching an identity to your presence - using a store card, or an application - could allow access to customise the store environment - for regular visitors, they get to choose or influence the music that is playing, displays that are projected, etc.
further purchases (on or offline) could result in differentiated levels of service or rewards - not necessarily related directly to the products, but more closely tied to the brand. The retail brand equivalent of 10 million airmiles
the gamification of visits - unlocking online content only after visits to certain locations, multiple stores etc - or limiting content so that you have to be in store to use it (albeit visible to others online)
in time, the stores become the nexus of identity creation activities - hosting meetups and connecting people - utilising a combination of profile information, activity history - and location / presence data - creating physical communities that are centered around the brand

To be clear, I don't think that physical products are necessarily going to go away any time soon (books and music aside - you can't wear digital clothes, or sit on virtual furniture) - but as the sales process becomes more and more direct, I see store space freed up to better enable the recreational 'shopping' experience. For the designers of these new experiences, there needs to be a shift from customising and streamlining the transaction process, to providing brand-centric identity-creating activities. And to Marc's point (but in reverse) - in building such services - the combination of online (purchasing) and offline (activity) experience needs to join up seamlessly.

Andy's Session

2011-07-04T19:08:00.001+08:00

Andy's Session, a set by sahana2802 on Flickr.

From my talk in Pune - a short history of the ThoughtWorks website, where we are now, and where we are going ...

Moving forward, standing still

2011-06-21T18:23:00.001+08:00

Hopefully, it will have been transparent to most folks - but blogs.thoughtworks.com has moved home ...

For a couple of months now, we've been running two aggregators in parallel - the existing Planet one, and a second aggregator that has been built into the ThoughtWorks website. As of this morning, we've put a set of redirects in place, so that we are now only using the built-in aggregator.

We've done this for a few reasons:

to align the sites in terms of branding (and, to help them stay aligned)
to make each set of content more discoverable from the other (it's now pretty straightforward to navigate from blogs to the main site, and vice versa)
to allow us to start putting relevant blog content alongside other articles, events, etc

additionally, we are hoping that we can build on this set-up so that adding and updating bloggers to the lists is a matter of self-maintenance ...

As I mentioned, we're hopeful that this will be transparent to most folks who are subscribed to the feeds - but, should you encounter any difficulties, please do drop me a line. The redirects that we've put in place are as follows:

http://blogs.thoughtworks.com => http://www.thoughtworks.com/blogs

Visible URL remains "unchanged"

http://blogs.thoughtworks.com/rss20.xml => http://www.thoughtworks.com/blogs/rss/current

URL changes to http://blogs.thoughtworks.com/rss/current

http://blogs.thoughtworks.com/atom.xml => http://www.thoughtworks.com/blogs/atom.xml => http://feeds.feedburner.com/thoughtworks-blogs

http://blogs.thoughtworks.com/alumni => http://www.thoughtworks.com/blogs/alumni

Visible URL remains "unchanged"

http://blogs.thoughtworks.com/alumni/rss20.xml => http://www.thoughtworks.com/blogs/rss/alumni

URL changes to http://blogs.thoughtworks.com/rss/alumni

http://blogs.thoughtworks.com/alumni/atom.xml => http://www.thoughtworks.com/blogs/alumni/atom.xml => http://feeds.feedburner.com/thoughtworks-alumni

If you are a ThoughtWorker, or an Alumnus, and you'd like your blog added or amended, please let me know, or create an 8600 ticket.

Notes from #leancamp - Marc McNeill

2010-05-25T07:18:00.001+08:00

Marc McNeill

Luke Hohmann - innovation games - product-in-a-box
Create customer personas; empathy
Ideation; Insight (looking in/out); Intentions; Implementation
4 key goals - put them up on the walls (c.f. mood boards, etc.)
Get development team involved / whole team
Get them out in the world - observe users
Start with interface; create a common 'vocabulary'
http://www.usertesting.com/
User requirements -> User assumptions
Optimise vs. Avoidance behaviours (eg. when booking a hotel - doesn't have to be the best, but must not be below a certain standard)

Notes from #leancamp - Patrick Van der Pijl

2010-05-25T07:11:00.002+08:00

Patrick Van der Pijl: Business Models Inc.

Business Model Generation
Business Model Innovation Hub
Beyond Profit presentation by Alex Osterwalder

Citizen M hotels -> global travellers
Lego Serious Play -> Management Strategy
Lego Factory -> Design your own models
Lego Design By Me -> Design your own models

Beyond Profit magazine
Business Models Beyond Profit
MYC4 Mads Kjaer
Shine Unconference for social entrepreneurs

Notes from #leancamp - Christian Heilmann interviews DHH

2010-05-25T07:09:00.001+08:00

DHH was interviewed by Christian Heilmann (also known as @codepo8). Christian was wearing a yahoo t-shirt that caught my eye - it said: 'code like a girl' / be a better tech goddess / careers.yahoo.com. You can also check out his book 'Developer Evangelism' - available on Lulu).

The interview was recorded - you can see it here: http://vimeo.com/11670924 (along with some of the other DHH talks that I missed) - some of the things he said that I thought interesting enough to write down at the time:

"it is important to not allow plugins to damage your brand"
"providing APIs can help to 'firewall' / show the boundary"
"opensource as much of your infrastructure as possible"
"only opensource products if you plan to sell consulting"
"managers and lawyers have no sense of probability" (re: getting legal ok for open source use)

Notes from #leancamp - Reshma Sohini

2010-05-25T07:08:00.002+08:00

Reshma Sohini: Seedcamp (slides here)

Seedcamp connects mentors with (tech) startups (e.g. mybuilder.com)

Get users before you build
Growing the business should be a consultative process - stop selling, start listening
When talking to them, make sure you are not just asking, but understanding
"Continuous deployment" - deploying a demo, and then getting feedback from customers
Don't feel you have to stick to your vision ...
Don't just build your ideas, you also need to build relationships
Current / future business models - avoid models that only work at scale
Small customers have the ability to make decisions faster - this allows you to build out your business whilst waiting for the larger customers to make decisions
Lean startup is an approach that addresses risk (through learning and feedback)

Links:

Notes from #leancamp

2010-05-25T07:06:00.011+08:00

Leancamp was an unconference - held in the very cool Great Western Studios space - bringing together Lean, Agile, and Design-led business folks. At the end of the day, I jotted down a few key themes and ideas:

Design thinking
Prototyping of ideas

Visually and conceptually
Using tools / games

Visualising ideas

Using infographics
Prototypes (as above)

The one thing that surprised me was that there seemed to be a lot of attendees interested in finding the next business idea, and maybe even using techniques from agile to explore a problem space and refine it - but there wasn't quite so much obvious interest in strategies for executing on those ideas. It's not to say that people didn't care about the execution, but more that there seemed to be a belief that with the right idea, and enough passion, the execution would just happen. In general, I think that I tended to gravitate towards the talks that were more execution-focused.

The following posts contain notes and links from the talks I attended:

Reshma Sohini
Patrick Van der Pijl
Nikki Smyth (forthcoming)
Marc McNeill
Christian Heilmann interviews DHH
David Gray (forthcoming)

Google as a guerilla usability testing tool

2010-01-10T20:31:00.004+08:00

Dan Ariely's latest post suggests using Google's predictive search capabilities as a source of data on peoples behaviours and opinions on a variety of topics. This got me thinking about how we might be able to utilise this data when building software.

With a little thought, we could probably craft some question roots that allow us to discover which areas people are curious about, or finding difficult to use:

"Facebook how do i ...", and 'Twitter how do i ..." seem to work pretty well gives results that provide some interesting insight (deleting lists in Twitter appears to be a bit tricky). Obviously it does depend to some extent on the scale of the project and how well known the company is (otherwise, Google's data might be quite sparse) - but this is a very quick and low cost way to track opinions across a large user base.

Even when there isn't enough data to check for real, it could be an interesting project inception exercise to ask people 'what would a google predict' search look like for your product? This will get the team thinking in terms of the end user experience, and it would likely help elicit areas of concern; paired with a 'what would you expect it to look like after the project?' we could help clarify potential project goals.

First Principles: 'Analysis Stories' vs. 'User Stories'

2009-11-13T05:17:00.007+08:00

At a recent project, in working to build up a backlog of stories, I was asked why we had been taking what had been created as 'analysis stories', and were splitting the work up and placing it into a number of 'user stories'? Did not a large amount of that analysis work belong together, and would it not all be done by the same person?

In thinking about this, it seemed appropriate to go back to values and principles. One of the twelve agile principles is this: 'working software is the primary measure of progress'.

That is, as a team, we want to get to a point where our progress is understood as, and measured by the implementation of working software - all other work - whilst this may include neccessary intermediary steps - does not in and of itself produce outputs of direct value.* We believe that there are benefits to this approach, in so much as we allow the stakeholders** in the project both real visibility of our progress and the ability to act on this and provide steer to ensure that we are making the best product possible.

One way to split up all the work would be to do all the analysis, then all the design, then all the coding, then all the testing, etc. In such a scenario, we wouldn't know how much progress we'd made (value created) until very late in the cycle - at which point, there may not be enough time left to make any correctional changes that were needed. Instead, what we'd like to do is slice up the work so that we can get to the implementation stage as soon as possible - even if the peice of the application that we've implemented is very small. There is still some analysis work that goes in to understanding that small peice of application, and some design, etc - but this work is 'just enough' to implement that single requirement, and there is an explicit deprioritisation of any contingent requirements, that may later change the implementation of this requirement. We are making a trade-off here - the potential costs of having to rework the early implementation of these small requirements is believed to be less than the benefits that we have gained in getting to implementation that much quicker.

In order to help us make that trade off, there are a number of practices, tools and techniques that we can use that will help us reduce both the potential of rework, and the costs that it might incurr. These include the use of user stories and acceptance criteria where the requirement is expressed from an end-user perspective, and independently of any implementation detail - so that, if we later change the implementation, it is easier to verify if the requirement is still met. It also includes a whole host of development practices - an evolutionary architectural approach and a well factored (easily refactorable) codebase mean that we are more able to quickly change an implementation to match both earlier and later requirements; test driven development, automated builds and continuous integration give us confidence that later changes don't introduce regressions; and so on ...

Coming back to the question at hand - I think that, at least the sense that I had was that, the 'analysis stories' that we had were mostly quite large in their scope - and that, if we were to attempt to do all of the analysis, and then all of the development for them as they stood, then we wouldn't have been realising some of the benefits that we were aiming for. If, instead, we could do just a small amount of analysis, and then use the outputs of that to create more finely grained requirements - which would probably still have some part of that analysis work contained within them - as well as being something more readily implementable - then we might get to a place where we had more visiblity, and a better mechanism for steering than before ...

* This is a bit of a simplification, as there may be some documents that we produce that we hand to the customer, that give them confidence in the software - and so it could be argued that this creates value. Even in this case, the value is only contingent on the working software also being there.

** Where by 'stakeholders' I mean, roughly, "people who care" - Dan North's rather lovely definition.

Communication Outward leads to Internal Change

2009-02-12T05:15:00.011+08:00

A couple of interesting posts on China's planned new global television service:

The Challenge for the "Chinese CNN"

A Chinese Al-Jazeera - Five Reasons this is a Good Thing

The following passage in the latter is worth calling out:

"The unspoken secret of the "perception management" process - the part we don't always share with our clients - is that the process changes both sides, not just the audience. This will be especially true as we move out of the Age of Broadcast and into the Age of Conversation."

Many people first approach agile methodologies as merely a grab-bag of tools and techniques, without concerning themselves too much with the underlying values and principles. This is often considered an anti-pattern - and not without good reason - in the absence of an understanding of the underlying philosophies, it becomes hard to effectively monitor and adapt the process to best fit the context in which the team is working. In thinking exemplified in the passage above, however, we can see the possibility of a path from 'practice adoption' toward making the more challenging mental and emotional shifts that are to come.

Concentrating first on those practices that are concerned with the way we as a team communicate with others - things like having big visible charts and frequent showcases - we emphasise to our colleagues the value of open and transparent communication. In making such public statements, we start to find that we've made commitments that we'd now like to meet. Building on this by co-locating our team members, holding stand-up meetings, and starting to hold regular retrospectives, we begin to talk to each other about how we would like to work together - and in using these techniques, we once more start to surface the values that motivate us (and may even be somewhat aspirational). At an individual level, too, the pattern repeats itself - when pair programming or using test-driven development, we are continuously making statements about how we think that good code should be written, which we will subsequently feel a need to uphold.

By no means is practice adoption alone going to result in deep insight, but it needn't necessarily result in cargo cultism either. Where interest in abstract or conceptual theory is lacking, thinking about how we introduce new methods and techniques, and planning which aspects of them we wish to highlight, can still lead to pause and reflection.

As we start to portray ourselves in a certain light, we create a pressure to live up to that description that we are now providing to others - our communications practices can thus become the driver for a more substantial behavioural change.

Snow Days

2009-02-06T20:54:00.009+08:00

The recent snowfall in London had me thinking - rather than bemoaning a lack of preparedness, especially in our transportation system, and evaluating the potential costs of so many folks not making it in to work - it seems that the occasional random day off is probably good for the national psyche. For folks who spent a bonus day with friends or family, the opportunity to enjoy some completely unplanned time - in a playful environment too - was more likely than not a refreshing break from the norm. I wonder if there were equivalent figures estimated in terms of the benefits of such a break in increased productivity of relaxed and happy employees for the rest of the week?

Of course, questions about contingency plans were asked too - an occasional day off may or may not be a (balanced out) hit that we can take, but anything more sustained is bound to make people nervous. It is not by accident that most people work in a group environment - some form of collaboration is at the heart of most industries - and it is prudent to examine how effective we can be when our usual means of communication (speaking face-to-face) is not currently possible.

In software development, the last 10+ years has seen an explicit recognition of the benefits of collaborative approaches - particularly noticeable in the increased adoption of 'agile' methods. These methods promote several practices, such as short daily stand-up meetings and pair programming, that aim to make the most of a co-located team working closely together.

What happens, however, when the high-bandwidth communication at the center of many of these practices is suddenly not possible? Does an agile approach break down in conditions where the practices are no longer possible?

Of course, there are a few basics that need to be in place no matter what the development methodology is:

Ensure that the source code repository, build servers, and other project tools are all readily available online

Make sure that the whole team has - and knows about - access; be careful that you aren't excluding people in the wider team - eg, those in other locations, contractors or consultants
Test access by having people work remotely before they need to - remember to fully exercise the remote infrastructure by having real work performed - don't rely on ping tests and browsing a few pages
If network security is a concern, use ssh, vpn, or create a separate network for the project machines
Where attaching 'foreign' machines to a network is an issue, rather than buying whole new machines, I've seen this worked around by purchasing a second drive, and controlling the image on that disk
Treat project tools as production machines, and ensure they are properly backed up
Use of virtualisation can mean that machines can be rapidly re-purposed, if as and when needs arise.

Identify back-up locations

Other offices, rapidly rentable space, even Starbucks and a bunch of laptops (with a suitable budget for coffee and sandwiches)
It might be worth investing in a couple of 3G cards, so that a small network can be set up and connected without relying on 3rd party wireless
If people are willing, it might even be possible for small groups to congregate in homes - done well, with everyone pitching in, this will have the additional benefit of being a true team building exercise.

For team that wishes to maintain their use of agile practices, it is worth considering alternative strategies for carrying these out (note that these strategies will apply in any distributed development effort):

'Stand-up' meetings can be conducted via Instant Message

I've seen this work even when most people are in the office - it's good for situations where the primary team language isn't everyone's first language - and helps keep a record of what was said for people to follow up on
Adding people to IM lists and groups should be done as they join the project, and not just when they first find they are remote and need to contact each other

Remote 'pairing' has a bit of a bad reputation, but don't rule it out

Whilst it can be slow and laggy to do continuously, selective use of VNC, WebEx, or other desktop sharing tools is still one of the quickest ways to share ideas in the code
Open up a continuous voice connection between team members who are working on related bits of code, so that it is easy to chat, and discuss smaller design decisions as they are being made

Put the 'story wall' online

Regular photos posted onto the web are a start; better is using a webcam
Using a tool (such as Mingle) means that remote team members can also update the wall

A richer 'shared context' can be created through the use of webcams, Twitter, other ambient information radiators

Don't just limit this to meetings - have webcams showing the team workspace(s)

Agile approaches are by their nature adaptive, and this still holds in a contingency situation. Where a change in context, such as forced isolation of the team, has led to problems - don't focus on substituting all practices, simply look at introducing new practices that deal just with those specific deficits you are experiencing:

'not being able to pair' is not necessarily a problem

If you are concerned about the quality of the code that individuals are writing, and the team is unable to pair, look to bring in a peer review before check-in
If skills transfer and knowledge sharing seems to be affected by the lack of pairing, perhaps a short technical webinar each day could help out.

Of course, one could argue that there is nothing special about the agile methodologies in most of the above - and in some ways that is kind of the point - in the given situation, there are some things that you can try, to keep you and your team working effectively. The key is how you select among them. Being agile isn't about preparing for every eventuality but, by utilising its system of values and principles, it does provide you with the tools that help to understand what might work. When high-bandwidth communication is suddenly not possible, it shouldn't mean that your entire team should grind to a halt, and - with a bit of preparation - you should have options on how to make the most of your new situation.