Loading ...
Sorry, an error occurred while loading the content.

7419Re: [agile-usability] Re: Lean Kickoff

Expand Messages
  • Jon Innes
    Aug 28, 2011
    • 0 Attachment
      Agreed with Larry. My statements below about UX best practices implied what he explicitly called out. 

      It's not the creation of personas and stories based on existing assumptions that gets you in trouble...it's the building products or sites without testing these artifacts and the underlying assumptions that's a problem. 

      Waiting until after you've built something to validate requirements is the worst waterfall practice of all. Sadly most Agile teams don't get that. But any competent UX specialist knows this. 

      Sent from my iPhone

      On Aug 28, 2011, at 5:00 PM, "Larry Constantine" <lconstantine@...> wrote:




      Yes, yes, and yes to Jon and Hugh. However, making up stories and hypothetical pictures about users is absolutely legitimate. It is a way to expose assumptions, tap into latent knowledge, and shape agenda. It’s called exploratory modeling. What is a no-no is then just going ahead as if such speculation were real and valid. Exploratory models need to be checked against real-world sources. That’s called model-driven inquiry. It’s an intrinsically lean/agile process. Build exploratory models thereby identifying questions, ambiguities, and issues to pursue and test, then go get answers--by the simplest and most efficient means that yield acceptable confidence—and use your findings to revise the exploratory models. Bingo.



      ~~Larry Constantine | Lior Samson, novelist | www.liorsamson.com

          Recipient, Rockower Award, Ameerican Jewish Press Association | SFWA Active (Professional) Member

          Author of techno-thrillers Bashert, The Dome, and Web Games




      From: agile-usability@yahoogroups.com [mailto:agile-usability@yahoogroups.com] On Behalf Of Jon Innes
      Sent: Sunday, August 28, 2011 2:03 PM
      To: agile-usability@yahoogroups.com
      Subject: Re: [agile-usability] Re: Lean Kickoff




      I'm not sure I agree totally with Hugh. I think the real issue is that Lean is misunderstood by many in IT. Lean emphasizes defining value and quality from the perspective of the customer. It's certainly about "faster and cheaper" but it was devised within a larger context. 


      When you study the Toyota Production System from which Lean is based (and the writings of Ford & Deming which is what much of TPS is based on),  you realize that it has always been true that defining the "what" was as important as streamlining production, or the "how". Just look up "Genchi Genbutsu" and read how the engineers at Toyota apply this to product design, not just streamlining manufacturing. 


      Dean, I think the real issue you face in defining done is about having enough data to clarify your goals and focus the tasks. The tasks you list are just as important as development tasks, but they are product owner and UX tasks. They are about creating a good product backlog. The challenge is most of the Agile literature assumes you have a product owner that knows what to build, or easy access to users like in an IT project. When building products, especially new ones, those are often false assumptions, hence why UX methods were invented.


      Hugh is absolutely correct that if you make up stories based on hypothetical assumptions about users it won't matter how fast or efficient you are as you build your product or service, as you'll be wasting a lot of time building the wrong stuff. Not very lean...


      @innes_jon on Twitter


      On Aug 28, 2011, at 8:44 AM, HRB wrote:


      --- In agile-usability@yahoogroups.com, "Dean Morrow" <dmorrow6@...> wrote:
      > I've been thinking for some time about how to leverage lean principles
      > from a UX /product development perspective. I'm finding some facets of
      > UX/Prod Dev work… especially those around early stage
      > discovery/research/analysis… aren't lending themselves to standard
      > agile methods and tools...
      > Discovery stories are more about learning and less about doing. My
      > current project is a website restructuring/redesign. Instead of stories
      > like "As a shopper, I want to add an item to my cart" I have something
      > like "I want to get visibility into what are the biggest problems on the
      > site" or "I want to know what is on the site" or "I want to know who
      > uses the site most" or "I want to understand what users can do on the
      > site." Tasks end up things like "meet with business unit X to understand
      > their goals and what they do" or "review the existing style guide." How
      > do you define done in a learning context?
      > ...
      > Dean Morrow

      I congratulate you on your creativity, but this has very much the flavor of a square peg being pounded into a round hole. Lean techniques came from lean *manufacturing* -- making a known product faster with less expense. That's pretty much the antithesis of creativity, invention, design, or anything else UX people have to worry about.

      I'd find a process appropriate for learning about your user community and inventing solutions for them. I wouldn't expect that process to have much to do with Lean (or even classic Agile, come to that). If you come to the point of writing stories and you don't at that point already understand your user and the proposed solution, you're in trouble.

      Hugh Beyer
      InContext Design
      twitter: @hughrbeyer


    • Show all 11 messages in this topic