The Lean Event – A review

Last week I spent two great days in Brighton at the The Lean Event and here is what I learned. Lean is a strategic system that combines principles, activities and artifacts to make better decisions about how to create customer value. The Lean Event provided a pocket guide to creating and operating within such a system.

Complex adaptive systems
Lean strategy views business in a different light from what was common in previous centuries. The world should no longer be thought of as a machine that can be known, optimised and planned for, but instead we should think about it as a complex adaptive system. This new world is forever in motion and demands constant exploration and adaptation. Lean strategy aims to be what Ed Catmull (quoted by Melissa Perri) called ‘a balance between clear leadership and chaos’.

Strategy is a bet on the future, a hypothesis about how the consumer landscape is going to evolve — Roger L. Martin

Principles
One way to provide clarity without rigidity are principles. A foundational principle of Lean is that every statement about the future should be seen as a hypothesis. Creating hypotheses allows us to move away from spending many weeks designing a product before we reveal it to the customer, and encourages the creation of prototypes and experiments to find out if the customer actually values what we are planning to make.

A principle that Jeff Gothelf discussed was that business value equals customer value (or in the words of Peter Drucker: ‘The purpose of business is to create and keep a customer.’). Any activity in a business that does not contribute to more and happier customers, either in the short or long term, should be questioned.

From this followed Jeff’s next principle: prioritise learning over delivery. It’s more important to learn about what customers value than to ship more stuff more efficiently. We first need to find out what people value enough to pay for, before we invest our time into building products that might end up on the shelf. This ties back to the idea of a complex adaptive systems, where the outcomes of your actions cannot be known in advance, which forces us to continuously check if our current offering still meets customer needs and if there are other ways we can provide value.

Themes and metrics
One benefit of the machine-age system is that it provides clarity about what should be done and what success looks like, but this clarity is deceptive, because it is based on overestimating the amount of certainty we can have about the future. Lean aims to move beyond these clear but flawed commands and yet avoid chaos by providing themes and metrics.

Themes, argued Jared Spool are much better than features to create focus around what should be done in the future. Because themes are descriptive and not prescriptive, they make it clear what is expected as an outcome, but don’t limit people in how this outcome should be achieved. For example, instead of stating that next quarter we will build a chat function on the homepage, we can state that we want to focus on the theme of creating more conversations with potential customers. Themes can be found through customer interviews, analytics and usability testing; they are areas where there’s often a clear opportunity to provide more customer value. They allow management to set directions while at the same time encourage experimentation by the individuals who have to deliver the work.

Metrics, as they were promoted by Ben Yoskovitz and Chris Matts, provide another way to create alignment on what matters. Ben promoted the idea of an OMTM: one metric that matters. Sticking to one metric allows everyone to focus on the same thing. Chris argued that we should choose the metric but not the expected value of this metric (a KPI). For example, do say ‘this quarter we want profit to go up’, but do not state by how much. A metric creates freedom for experimentation, since individuals can decide what they want to do and how to do it as long as they focus on the metric. A fixed KPI, on the other hand, encourages people to become risk averse. One easy way to make profits go up, for example, is to cut costs and delay investments. However, this would make them hit the short term goals, but wreck the business in the long term. Metrics connect well with themes; they create clarity of direction and enable freedom of execution.

The more I empower my staff, the better my results were — Raffi Krikorian

Values
To make use of principles, themes and metrics you need a shared set of values, a framework that defines how you will play. Jane Austin delivered a great talk on how to create an environment that works around openness, autonomy and empowerment. Interestingly, these are very much aligned with themes that make people happy at work. Freedom on the one hand and clarity of themes and metrics on the other hand make it possible to work autonomously while still adhering to the larger organisational aims. Jane echoed Ben Yoskovitz’s statement that Lean allows business leaders to move from providing the right answers to asking the right questions (preferably early and often).

Activities
Jeff Gothelf furthermore suggested that to make values such as transparency, autonomy and empowerment meaningful they need to be tied to rituals — activities that take place with regular intervals — such as daily stand ups, weekly sprint planning and retrospectives and quarterly away days. Other important activities can be regular access to customers to interview and test ideas with, and access to analytics for everyone.

Artefacts
Artefacts connect people and provide visibility over time. Lean uses some well known artefacts such as personas and prototypes, but The Lean Event especially highlighted maps.

Jared Spool and Roman Pichler both discussed the idea of roadmaps filled with themes as a way to bridge the gap between the clarity of planning features and the wide ocean of providing customer value. Roman further argued that roadmaps provide a continuity of purpose, facilitate stakeholder collaborations and help with prioritisation. Even though theme-based roadmaps don’t appear to be very precise Roman jokingly quoted Keynes by stating ‘it’s better to be roughly right, than precisely wrong’.

It is better to be roughly right than precisely wrongJohn Maynard Keynes

Jiri Jerabek gave an example of generating a customer experience map as a shared activity over time instead of a reclusive one off activity done by a headphoned researcher at a computer.

Overall the two days showed a broad variety of themes and ideas that all tied together magnificently. Count me in for next year.

LSE Urban Data conference – a review

Adam Greenfield’s LSE symposium ‘Urban data: From fetish object to social object’ set out, as Greenfield stated, to “problematise the area of urban data”. An aim it easily achieved: by the end of the day I collected way more questions than answers. It turns out that once you stop fetishising data and start using it as a social object what you get are keen insights into the functioning of local politics.

Continue reading LSE Urban Data conference – a review

The continuous workshop of future-making: reflections on the UrbanIxD summer school

If the 19th century was about discovery and the 20th century about obtaining efficiency, then the 21st century will be about living with complexity. Complex adaptive systems are so big and interconnected that any interference with their workings causes unpredictable side effects. In these systems (such as a city) you are almost always dealing with situations that need to be addressed and rarely with problems that can be solved. For this new way of working, where every step forwards needs to be taken with caution, we need a new method, a new language and a new approach. The finding and fine-tuning of this way of working with the world was what for me the UrbanIxD summer school was about.

The challenges for cities are many: what should they expect from technology? How will the networked computer change the way we work? What are the possibilities and limits of urban change in a democratic framework? What about our environment and resources, and how can we include other people, legislations and resources in this challenge?

Continue reading The continuous workshop of future-making: reflections on the UrbanIxD summer school

Design of Understanding 2013 – a review

For the third year running, The Design of Understanding dedicates itself to escaping the ruins of the Cartesian project. René’s rules of science that helped kick-start the enlightenment project “to divide each of the difficulties […] encountered into as many parts as possible” [1] enabled humanity to decipher the earth, the universe and the human body at a speed never seen before. Yet as it now slowly starts to dawn upon us, this idea of dividing does not help much when we have to unwrap the complex system of our current world and even less in suggesting what should be done to create positive change in the future. Mapping the old theory of science on the complexity of the world leads to a situation once humorously explained by Borges through a fictional Cartographers Guild:

In that Empire, the Art of Cartography attained such Perfection that the map of a single Province occupied the entirety of a City, and the map of the Empire, the entirety of a Province. In time, those Unconscionable Maps no longer satisfied, and the Cartographers Guilds struck a Map of the Empire whose size was that of the Empire, and which coincided point for point with it  [2]

If Descartes’ rules don’t bring us any closer to understanding our now and building our future, what should we do? Some try to find the answer in ever more data points, others turn to new-age religions and yet others start to play with the information at hand. In this quest for a post-Cartesian understanding of what the world is, could, and should be, the Design of Understanding provides a helping hand.

Luckily, these ‘as many parts as possible’, be it words, atoms, bits or people, behave, although not perfectly predictable, also not entirely at random. The Lorenz system (see image on top) as shown by Beeker Northam is a great visual representation of this.

Matt Cottam tells the story of Tellart, a 21st century industrial design company, who worked with Google to create an installation to make the internet understandable. Moving from the digital to the physical world came with unexpected constraints. Lawyers pointed out that children needed to keep their privacy; how though can you do this whilst also allow them to connect their museum visit with their computer at home? A colourful personal logo-card turned out to be the solution. Physical scale started to play a role too: you might be able to make a hundred thousand facial drawing print-outs for actual visitors, but what about a hundred million web visitors? Suddenly virtual turns out to be not so virtual at all and take lots of material and maintenance. To make sure the Amazon rainforest had any chance of survival they skipped printing on paper and invented a sand-drawing robot and also the world’s first whiteboard eraser robot.

Joe Parry, builder of the network visualisation tool Keylines, mentioned how hard it is to understand networks. We cannot understand a network unless we see it, and even when we see it we cannot understand anything with more than a 1000 nodes. Because of the size and complexity of networks in a remarkable amount of cases the easiest way to gain understanding is by printing everything out and placing it on the wall. His tool Keylines allows users to go through large datasets with more ease and at higher speed. It allows to answer questions such as: who are the network leaders, who are effective communicators, what are the effects when person x leaves the network? Ultimately understanding the network means understanding the place of each node in the network and being able to explain the network in both in and at a high level.

Phil Gyford tells the story of his decade-long project of blogging Samuel Pepys’s diary at the speed of one entry per day, laughingly quoting Steward Brand “A building is not something you finish, it’s something you start”. He also noted the ability of a web-based diary to map the world in time and space, and wondered where do you stop explaining: there are always more maps, paintings and articles –more context– you can add.

Llyod Shepherd, writer of historical fiction goes through his process of note-taking. With better tools and more information at our disposal note-taking has become easier. Choosing which notes to take though has become a lot harder. And the act of sense-making has become an ongoing tour-de-force. To deal with an abundance of data, note-taking ultimately becomes a personal and aesthetic act.

Justin McGuirk shows various Latin American architecture projects, demonstrating that designing houses is the easy part. For architects the hardest part and the part where they can make the biggest difference is in influencing the system: talking to politicians, to neighbourhood committees, to lawyers and the police to make it possible to not only build new housing but to change the infrastructure and the way the city functions. He shows an example of a project where instead of building the conventional solution of a road to connect the suburbs to the center, the architects managed to build a cable car cutting down the transport time from two hours to nine minutes, all without massive physical changes to the urban environment. He ends with a set of guidelines that are as true for architects as they are for designers: to achieve the impossible you have to focus on redesigning the system by being an extrovert, a catalyst, a connector of the informal with the formal and a performer in a show of policies, laws, developers and inhabitants. What you design is not so much the object as the system in which this object can exist.

More reviews:
Design of Understanding 2013 — Aden Davies
Design of Understanding 2013 — Rodcorp
Design of Understanding 2013 – Mark Barratt
Sketchnotes — Eva-Lotta Lamm
Sketchnotes — Boon Yew Chew
Lanyrd page
Last year’s review

dConstruct 2012 – a review

The digital world has no shortage of big ideas: the social revolution, ubiquitous computing, exponential growth until we hit singularity, to name a few. In his talk Jason Scott warns programmers not to be too light-hearted with their creations. Although the twenty-something creators of Facebook might think that time is of no consequence, and take no particular interest in the history of their site, by being the world’s largest photo archive they have a responsibility to their users to care for this data. It’s not just a cost on the balance sheet that has to be kept under control, it is real memories of real people that we are talking about. And although start-up fans might admire the phenomenal success of a certain gaming start-up, when you build a game that “scoops the brain right out of little children” that doesn’t make it OK. Furthermore, if you create a service that allows users to save things, they give you their trust. Respect this trust and treat them and their data with respect.

James Burke warns about the opposite problem, too much focus on the details. In the centuries since Descartes wrote down his second rule of science “to divide each of the difficulties […] encountered into as many parts as possible” science is now broken up into ever smaller compartments knowing less and less about the world as a whole. This approach brought the Western world a living standard previously unimagined, but, Burke believes, has run its course. We can no longer expect radical innovation by devoting ourselves to even smaller areas, even smaller tasks. We need to go broader, higher and wider, “innovation will come from the no man’s land between the divisions.

It seems to be a human tendency, that, in our aim to be as exact as possible we either go too abstract or too detailed. Italo Calvino wrote about this quest: “[it] was branching out in two directions: on the one side, the reduction of secondary events to abstract patterns according to which one can carry out operations and demonstrate theorems; and on the other, the effort made by words to present the tangible aspect for things as precisely as possible. […] I continuously switch back and forth between those two paths, and when I feel I have fully explored the possibilities of one, I rush across to the other, and vice versa.”

By connecting the tangible aspect of playing with the abstraction needed for toymaking, Tom Armitage, proposes a solution of understanding through discovery. Each toy is a little pocket universe, a small concept that can be played with, a way that allows you explore abstraction through play. His idea sounds similar to the idea of the hermeneutic circle, a reading concept where the reader admits that: “neither the whole text nor any individual part can be understood without reference to one another.” Armitage continues: “Toys are a fertile ground for creators to work in. They offer a playful space to experiment and explore. They are a safe ground to experiment with new techniques, skills, or ideas. […] Toymaking ranges from making realistic simulations of life to producing highly abstract playthings.” Just like design challenges, toys are both defined by that what they highlight and that what they leave out. We cannot understand the world through abstract theories, nor through an endless series of tangible details. The only way is to understand is to take all that is abstract and all that is tangible and mix it in a never-ending process of creation, discovery and reflection. As Armitage ends “through toy making you end up playing yourself” and that might be the biggest opportunity we have.

Jeff Gothelf at London IA February 2012

This post originally appeared on London-IA.com in February 2012

Lean UX – getting out of the deliverable business by Jeff Gothelf

Jeff Gothelf, formerlly director of UX at the Ladders and currently principal at Proof, an innovation studio in New York, has already made some furor with his concept of Lean UX. In the past we had only his slide deckto rely on, but last Tuesday Jeff finally made his UK debut at London IA.

Jeff’s Lean UX story starts with a retrospective. If Lean UX is such a good thing, then why aren’t we all practising it? Jeff states that long, long ago, there was a world with very young information architects, where every trade had their own deliverables –some had reports, some had code and others had excel sheets– but the young discipline of IA had nothing, nothing but wireframes. In order for IA to claim a seat at the table, the wireframes were used to represent IA. For a while this approach was successful but the good times didn’t last. Web projects became more complex, and in line documentation kept on growing and growing. We now have reached a point where projects are so complex and situations so unpredictable that it becomes impossible to describe them with documentation. Something has to be done.

As a remedy Jeff proposes Lean UX, where real experiences are continuously tested and where people work together towards great experiences in a shared understanding of the problem.

Jeff explains Lean UX in 5 points:

1. Solve problems together. Business, marketing, development and design should start actively collaborating on solving business challenges. Working collaboratively leads to a shared understanding and more motivated and invested people.

2. Sketch. The common language, the thing that everyone gathers around, should no longer be spec documents but sketches. They can become the initial artifacts that spark discussion and create a shared understanding. And because they are easy to make, no-one is too invested in their own ideas, and they can be easily thrown way.

3. Prototype. In line with the Lean Start-up concept, prototypes are seen as a great way to create validated learning. Due to their interactive nature they allow for easy validation, and quick iteration.

4. Pair up. Cross-functional pairing is another pillar to the method. When designers work directly with developers they both start out with a shared understanding of the problem. Developers can start working on the things that are hard for them, whilst designers can focus on the more complex interaction challenges. Pairing creates mutual trust and deeper investment. Jeff mentioned using firebug as a tool that allows developers and designers to work together in an agile way.

5. Style guides. In order to live without massive specs, some documentation cannot be avoided. Jeff opted for the idea of a living, breathing style guide, that allows developers to quickly look up which style comes with ‘main call to action’ and designers to check if there are existing code patterns that could be reused.

Jeff continued by dealing with some of the critiques and challenges of the Lean UX approach. In order for it to work we need to get rid of this idea that designers should get it right the first time and it should be the designers and not the spec document who are in control. To create buy-in and shared understanding it’s important that everything is open and visible. For people who are used to working towards a certain amount of perfection in their deliverables the Lean method will at first feel a little uncomfortable, but as Jeff stated, how can you aim to make the best product when you don’t know if you are working on the right product? It’s successfully solving problems and creating value for our clients (and users) that should be our focus and not the creation of beautiful deliverables.

Q&A and Discussion
The second part of the evening was a panel discussion with Johanna Kollman, Leisa Reichelt, Jeff Gothelf, James O’Brien and Mark Plant, and Jonty Sharples as the host. Based on questions from the audience, they discussed how it’s possible that while everyone agrees with the premises of Lean/Agile –less waste, shared understanding, focus on the end results– a more lean way of working still seems to be far from common practice.
Several reasons were discussed.

London IA crowd

Economical: many of the larger agencies are actually in the deliverables business and get good money for delivering wireframe decks. Also there’s an initial cost of changing to a new method. This might only change after clients themselves become more agile too; to achieve this, Johanna argues, there need to be internal stakeholders or embedded teams.

Trust: to become more agile people have to trust each other, Leisa argues that it’s almost impossible to do Agile in a situation with 3th party developers. If you haven’t build up a relationship with your client they will most likely go with a competitor who claims they can deliver on a fixed deadline and fixed budget, and will see your agile approach as too risky.

Technical: creating a living and breathing wiki style guide takes time and effort. How do you integrate such a thing in your organisation? Jeff suggests choosing someone as the owner of the wiki, and if it also includes code snippets, to co-own it with development and have a dev-owner too. James argues that instead of using a wiki, patterns should be printed out on the wall, and a css-preprocessing language can be used to store all the default styles.

Social: getting agile to work means spending more time talking and explaining things to colleagues, not everyone is up for that. Also here it is possible to start small, make some of your process or some of your team more agile, and let everyone slowly get used to shared responsibility and shared ownership.

Experience: no-one would argue getting agile to work is easy, it’s best done by people who know a rich set of tools and methods to adjust their process to the problem (and not the other way around). Mark argues that it’s impossible to force people into an agile way of working, they must want to work that way, and Johanna wonders if mentoring and show’n’tell is a good way to distribute Agile knowledge.

Psychological: Agile can be a painful process for perfectionists. Visual designers in particular  protest against losing their time and ability to do large pixel-perfect design upfront. James argues that the agile process forgets quiet places and time for reflection. Developers have refactoring time, where they clean up old code, and designers should claim this time for themselves too. Another element that Jeff brought up is that designers are used to being applauded for the beauty they bring into the world. Agile, and its focus on the end product, however, has no room for individual heroes and only works well as a team sport.

Somewhere towards the end, Leisa wonders if we’re just finding endless new ways – Agile, Lean UX, goal directed design – to rename what should be known as good design? And this sentiment also resonates with others, was this evening just another version of our yearly agile versus waterfall debate or is there something new under the sun? What is certain though, is that we are moving towards a more complex and uncertain future, and that we need all the ideas we can get to stay in control of our technology.  This evening at the Sense loft was therefore an evening well spent.

(More photos)