Lean & User Experience, again

Posted on 21 Feb 2013 in anthropology, me at work, workplace | 0 comments

Over the years I’ve written a few posts about the relationship between Lean and User Experience.  But in looking back on those, I don’t feel like I ever did as thorough of a job as I would like in connecting the two domains.  So when I was asked last year to contribute to a new book called The Handbook of Business Anthropology, edited by Rita Denny and Patty Sunderland (who also wrote Doing Anthropology in Consumer Research).  I proposed a chapter about Lean and Agile, because I feel that these are two critical trends for user experience professionals to understand.  As I wrote in my chapter:

Lean is a set of principles and practices developed with the goal of making businesses more effective. [...] Agile software development practices (in which the focus is market-focused, incrementally-shippable software capabilities) complement Lean in numerous ways.  Both are ways of thinking about improving a company or a team in relationship to stakeholders and customers.  Each also focuses on iterative improvements, and empowering people executing the work to make it better.  However, Lean is bigger in focus than daily work processes, and provides a framework for organizational change that is not the focus of Agile.  Of course, in a small organization like a high-tech start-up, they might feel like one and the same thing.  But in a large enterprise, Lean will help to drive change in areas well beyond software development (customer support, marketing, etc.).

After a lot of discussion (and heartache from me), I eventually dropped the Agile portion from the chapter in favor of a clear message I could deliver well in under 6500 words.  I will find a way to get my story about Agile (and about the synergies between Lean and Agile) out in the world at some point – maybe here!  But now that I’m done grieving the Agile portion, I can say with enthusiasm that I think the revised chapter focused on Lean is much stronger, and I’m thrilled to have a piece on it’s way to publication.

lean-loop

As a sneak preview to the chapter, I’d like to share an earlier incarnation of the methods part of the chapter.  I hope will be of use to those who find themselves in a context where Lean ways of thinking and working are present!

Lean Principles

The five principles of Lean have been documented in numerous places, including the Lean Enterprise Institute and others.  Here they are:

  • Describe value from the end customer’s point of view.
  • Document the value stream.  Identify and eliminate activities (waste) that don’t create value for the customer.
  • Ensure the process flows smoothly towards the customer.
  • Enable customers to pull value from the next activity.
  • Pursue perfection.

These simple guidelines have led to a wealth of practices that in many ways are consistent with a user-centered approach to research in a business setting.   In the next section, I outline a few of those practices, with a focus on those that are the most relevant to user experience and user research professionals.

Lean Practices

Although I have spent my career in the business world, I bring my anthropology training to bear on my work all the time.  I’ve always been a fan of diving into the deep end, watching and learning what people are doing before making recommendations of any kind.  I first came to appreciate Lean methodologies when I heard that managers are encouraged to genchi gembutsu, or ‘go see for yourself’.  This has also been described at ‘walking the shop floor’, which has a very manufacturing feel to it.

The focus here is on observation, not participant observation in the traditional ethnographic sense.  But there is also no reason why a more engaged methodology could not be used.  This commitment to understand the daily lived experience of employees is so powerful, and absolutely aligned with a user-centered approach to evaluating problems and designing solutions!

In reality, in large companies with a diverse range of work being done all over the world, it’s unlikely that a senior executive can effectively walk the shop floor of all his/her organizations on a regular basis.  Ethnographic researchers can serve as a proxy and an advisor to those executives, visiting various locations, sharing compelling or poignant research insights through various media, and recommending areas for possible improvement.  However in an environment where a Lean approach is pervasive, the role of a researcher is most effective if they are able to share package those insights using the language of Lean – for example, describing the findings in terms of flow, the seven types of waste, etc.

Many teams practicing Lean have borrowed the Voice of the Customer methodology from Six Sigma.  This exercise involves articulating who the customers are for a given process or outcome, and then thinking through what would be the most valuable for them.

In manufacturing terms, the value might be to deliver an item that was ordered on the date specified.  This may seem almost too obvious, but it’s extremely surprising how few people in the business world actually think about their day-to-day work in this way!  Many years ago I worked on a large-scale knowledge management project.  The team was struggling to define clear goals and plans.  With the help of a Lean coach, the team did a Voice of the Customer exercise and realized that they had three very different customer groups with different needs and expectations.  That exercise finally allowed the team to move forward with clarity and confidence in planning and communicating their work.

This is not market or customer research per se.  Rather, the team uses their existing knowledge to focus improvement efforts.  However, their understanding could benefit from further refinement based on ethnographic or other research methods.  Even if the insights aren’t available at the outset of an improvement effort, the iterative nature of lean methodologies should enable insights to be incorporated as they become available.

Value Stream Mapping (VSM) is another powerful tool in the Lean toolkit.  Do you know a qualitative researcher that doesn’t like whiteboard sessions or Post-its?  VSM is essentially a participatory design method, in which individuals engaged in a particular business process use a whiteboard or sticky notes to describe the steps of their process, and then identify and discuss areas of waste and possible improvement together.  This collaborative approach enables the team members to develop a common understanding of the challenges and opportunities they face in improving their work processes.

In order to give the team focus and a sense of accomplishment, a Lean coach may the team focused on the problems that they can address on their own.  For example, they can’t change their management team!  In this case, what is not addressed during a VSM exercise may be just as valuable to a researcher for understanding the challenges at hand.  So for example, in one VSM exercise with an Operations team in India, all issues with the software they use were black-boxed, which is to say they were acknowledged but put aside, so that the team could focus on areas where they were able to effectuate change.  Although it might not be the right focus for a VSM working session, a researcher with a broader scope might be able to explore those issues in another way.

The 5 Whys is a methodology in which the team seeks the root cause of a particular problem by asking a series of five increasingly penetrating questions.  Although you might feel like you have regressed to your days as a toddler by continually asking why, this is a very simple and powerful way to help a project team arrive at a root cause analysis, so that the team can understand and solve for the right problem(s).

An example might be (1) Why are the managers in this department quitting at an usually high rate?  Because of work-life balance issues. (2) Why? Because in their exit interviews they complain of excessive evening work.  (3) Why? Because they are not able to complete their core work during business hours. (4) Why? Because they are constantly interrupted to generate specialized reports. (5) Why? Because they are the only ones with the system access and knowledge to run reports that are needed by other departments. At the end of this sequence, the team has arrived at a specific, solvable problem, making the reporting process more efficient.

Although there are many other tools in the Lean toolkit, I did want to mention one last area that may of interest to researchers who find themselves in this context.  This is the idea of a 5S Visual Workplace.  The 5Ss once again come from the Japanese ( Seiri, Seiton, Seiso, Seiketsu, and Shitsuke), which are often translated as Sort, Straighten or Set-in-Order, Sweep or Shine, Standardize, and Sustain.  These are principles for making sense of and organizing the physical workspace.  Getting a walkthrough of such a space – or helping to create one – would be a powerful vehicle for understanding what is expected of workers in a given setting.

In Closing

I hope that you’ll have a look at The Handbook of Business Anthropology (and my chapter of course!) when it comes out.  In the complete version of the chapter you’ll learn more about the ways in which social scientists have contributed to an understanding of organizations, a brief history of the origins of Lean, two short case studies (that bring Lean and ethnographic methods together) from my tenure at SAP.

In the meantime, though, I hope that this excerpt will help you understand the synergies that I’ve seen between Lean and user experience / user research / user-centered design!  I look forward to your questions and feedback in the comments.

No Comments

Trackbacks/Pingbacks

  1. Putting people first » Lean and user experience, again - [...] As a sneak preview to the chapter, she shares (an earlier incarnation of) the methods part of the chapter. …

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>