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

Lean Kickoff

Expand Messages
  • Dean Morrow
    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
    Message 1 of 11 , Aug 24, 2011
    • 0 Attachment

      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. I'm not talking BUFD, I'm talking understanding the overall context. I'm thinking the phrase "Lean Kickoff" may encapsulate the concept. I've tried to incorporate things like Dennis Steven's Performance-Capability Model and other QuickStart methods.

      How do you quickly get to a well-prioritized backlog for an ill-defined project like "Fix the web site?" In this example, I'm a UX contractor, but am acting as UX architect, consultant, agile coach/champion, and co-lead of the product owner team. I'm trying to look at it holistically: web analytics and metrics; content management; data model; IA/IXD; patterns & components; SEO; accessibility.

      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?

      Even understanding general business goals like "I want to know what are the goals of the site" or "create a prioritized list of users" gets problematic very quickly (multiple stakeholders). Are lean/agile methods and tools (stories, backlog, taskboard) even relevant in this context?

      For example, taking the story/backlog approach, "I want to get visibility into what are the biggest problems on the site" is more of an epic, so I break it down to "get an inventory of what pages are on the site" and "get hit counts for those pages."  These look doable, at least till I start digging into them, and discover a whole host of new issues. Like 90% of the pages aren't HTML (most are pdf). We have Google Analytics, but the tracking has only been implemented on HTML pages that have been developed over the last 4 years, which is about 1% of the site. The more you dig, the more questions you get, and most of the new stories are for infrastructure. Adding GA tracking to a group of pages isn't a traditional user story, but it's the type of work that needs to be done first in order to understand what needs to be done next.

      Does anyone else deal with these type of issues? What kind of solutions have you found?

      Thanks,

      Dean Morrow

       

       

    • Chris Morris
      I just worked on a story at my gig that appeared simple on the surface add foo to this webpage but got a little more complicated as I started working it
      Message 2 of 11 , Aug 24, 2011
      • 0 Attachment
        I just worked on a story at my gig that appeared simple on the surface "add foo to this webpage" but got a little more complicated as I started working it "wait, if that page changes, this other page should change too, otherwise, it won't be consistent" then I sent my 'finished' work to QA and they came back with "um, this makes this 17 other locations inconsistent, too". We backed up, I did some more analysis and started making more tasks within the story - then we decided that some of the tasks had a lower priority, so we made 2 other stories and moved out low priority tasks from the original story to those, I finished the other high priority tasks on the original story, we've deployed that one and marked it done. Unrelated stories currently have a higher priority and we'll come back to the leftovers later.

        While the work you have to do isn't "add foo to this webpage" even add foo work can become complicated in the same way you describe yours, and the point of agile is to react to these scenarios in a more or less organized way that is visible to everyone involved and gives the team options to steer as you go (vs. BDUF which says "we will do this for a long time and not respond to feedback").

        In XP, they even handle this directly with Spikes - which is "we don't know what done looks like, because the very nature of the task is to do some research to gain understanding" - so usually the spike will have some sort of artificial (but flexible) time limit - let's dive into this for 4 hours (or 2 days or whatever) and then come up for air so we don't derail and either keep going or table the issue and move on to something else.

        I think you're doing very well so far, it's just frustrating because of the high percentages of unknowns to start with. 
      • Austin Govella
        Dean, You might be interested in checking out the Balanced Team blog and mailing list. Members come form all over, and they re focused entirely on this exact
        Message 3 of 11 , Aug 24, 2011
        • 0 Attachment
          Dean,

          You might be interested in checking out the Balanced Team blog and mailing list.

          Members come form all over, and they're focused entirely on this exact idea.



          --
          Austin Govella
          User Experience


          215.240.1265 

          On Aug 24, 2011, at 6:48 AM, "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. I'm not talking BUFD, I'm talking understanding the overall context. I'm thinking the phrase "Lean Kickoff" may encapsulate the concept. I've tried to incorporate things like Dennis Steven's Performance-Capability Model and other QuickStart methods.

          How do you quickly get to a well-prioritized backlog for an ill-defined project like "Fix the web site?" In this example, I'm a UX contractor, but am acting as UX architect, consultant, agile coach/champion, and co-lead of the product owner team. I'm trying to look at it holistically: web analytics and metrics; content management; data model; IA/IXD; patterns & components; SEO; accessibility.

          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?

          Even understanding general business goals like "I want to know what are the goals of the site" or "create a prioritized list of users" gets problematic very quickly (multiple stakeholders). Are lean/agile methods and tools (stories, backlog, taskboard) even relevant in this context?

          For example, taking the story/backlog approach, "I want to get visibility into what are the biggest problems on the site" is more of an epic, so I break it down to "get an inventory of what pages are on the site" and "get hit counts for those pages."  These look doable, at least till I start digging into them, and discover a whole host of new issues. Like 90% of the pages aren't HTML (most are pdf). We have Google Analytics, but the tracking has only been implemented on HTML pages that have been developed over the last 4 years, which is about 1% of the site. The more you dig, the more questions you get, and most of the new stories are for infrastructure. Adding GA tracking to a group of pages isn't a traditional user story, but it's the type of work that needs to be done first in order to understand what needs to be done next.

          Does anyone else deal with these type of issues? What kind of solutions have you found?

          Thanks,

          Dean Morrow

           

           

        • Roman Pichler
          Hi Dean, I capture important UI/UX requirements during visioning in my product vision and my product backlog board:
          Message 4 of 11 , Aug 25, 2011
          • 0 Attachment
            Hi Dean,

            I capture important UI/UX requirements during visioning in my product vision and my product backlog board:

            http://www.romanpichler.com/blog/agile-product-innovation/the-product-vision-board/
            http://www.romanpichler.com/blog/product-backlog/product-backlog-board/

            Roman

            --- 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. I'm not talking BUFD, I'm talking understanding
            > the overall context. I'm thinking the phrase "Lean Kickoff" may
            > encapsulate the concept. I've tried to incorporate things like
            > Dennis Steven's Performance-Capability Model
            > <http://www.dennisstevens.com/2011/02/20/deciding-what-to-build/> and
            > other QuickStart methods.
            >
            > How do you quickly get to a well-prioritized backlog for an ill-defined
            > project like "Fix the web site?" In this example, I'm a UX contractor,
            > but am acting as UX architect, consultant, agile coach/champion, and
            > co-lead of the product owner team. I'm trying to look at it
            > holistically: web analytics and metrics; content management; data model;
            > IA/IXD; patterns & components; SEO; accessibility.
            >
            > 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?
            >
            > Even understanding general business goals like "I want to know what are
            > the goals of the site" or "create a prioritized list of users" gets
            > problematic very quickly (multiple stakeholders). Are lean/agile methods
            > and tools (stories, backlog, taskboard) even relevant in this context?
            >
            > For example, taking the story/backlog approach, "I want to get
            > visibility into what are the biggest problems on the site" is more of an
            > epic, so I break it down to "get an inventory of what pages are on the
            > site" and "get hit counts for those pages." These look doable, at least
            > till I start digging into them, and discover a whole host of new issues.
            > Like 90% of the pages aren't HTML (most are pdf). We have Google
            > Analytics, but the tracking has only been implemented on HTML pages that
            > have been developed over the last 4 years, which is about 1% of the
            > site. The more you dig, the more questions you get, and most of the new
            > stories are for infrastructure. Adding GA tracking to a group of pages
            > isn't a traditional user story, but it's the type of work that needs to
            > be done first in order to understand what needs to be done next.
            >
            > Does anyone else deal with these type of issues? What kind of solutions
            > have you found?
            >
            > Thanks,
            >
            > Dean Morrow
            >
          • HRB
            ... 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
            Message 5 of 11 , Aug 28, 2011
            • 0 Attachment
              --- 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
              beyer@...
              twitter: @hughrbeyer
            • Jon Innes
              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
              Message 6 of 11 , Aug 28, 2011
              • 0 Attachment

                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
                beyer@...
                twitter: @hughrbeyer


              • Larry Constantine
                Dean, 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
                Message 7 of 11 , Aug 28, 2011
                • 0 Attachment

                  Dean,

                   

                  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
                  beyer@...
                  twitter: @hughrbeyer

                   

                • George Dinwiddie
                  Dean, I don t understand where you see a conflict with Agile. Isn t it all about learning as you go and maximizing the benefit from that learning? ... First
                  Message 8 of 11 , Aug 28, 2011
                  • 0 Attachment
                    Dean,

                    I don't understand where you see a conflict with Agile. Isn't it all
                    about learning as you go and maximizing the benefit from that learning?

                    On 8/24/11 7:47 AM, Dean Morrow 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. I'm not talking BUFD, I'm talking understanding the
                    > overall context. I'm thinking the phrase "Lean Kickoff" may encapsulate
                    > the concept. I've tried to incorporate things like Dennis Steven's
                    > Performance-Capability Model
                    > <http://www.dennisstevens.com/2011/02/20/deciding-what-to-build/> and
                    > other QuickStart methods.
                    >
                    > How do you quickly get to a well-prioritized backlog for an ill-defined
                    > project like "Fix the web site?"

                    First of all, a "well-prioritized backlog" doesn't have to be longer
                    than one item. Sure, most corporations try to create the entire backlog
                    and then have the development team grind through it, but that limits
                    their ability to learn from the work.

                    > In this example, I'm a UX contractor,
                    > but am acting as UX architect, consultant, agile coach/champion, and
                    > co-lead of the product owner team. I'm trying to look at it
                    > holistically: web analytics and metrics; content management; data model;
                    > IA/IXD; patterns & components; SEO; accessibility.
                    >
                    > 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?

                    The common approach to defining done in a learning context is to set a
                    timebox. At the end of that time, ask yourself if you know enough. Or
                    if setting another timebox would be worthwhile. Or if it might be
                    better to try a different direction. This is what an XP "spike" is all
                    about--answering a question.

                    An important aspect of successful spikes is formulating good questions
                    to which you want the answer. "I want to get visibility into what are
                    the biggest problems on the site" is a bit vague. "I want to know what
                    is on the site" seems disconnected from the goal of fixing the site. It
                    seems like a potential task, but not a question to be answered.

                    > Even understanding general business goals like "I want to know what are
                    > the goals of the site" or "create a prioritized list of users" gets
                    > problematic very quickly (multiple stakeholders). Are lean/agile methods
                    > and tools (stories, backlog, taskboard) even relevant in this context?

                    Don't focus so much on software development tools. Instead focus on the
                    goal(s) and making demonstrable progress. You don't need an exhaustive
                    list of goals or users to make progress. I suspect you can triage the
                    list of stakeholders and start with the ones that are obviously most
                    important.

                    > For example, taking the story/backlog approach, "I want to get
                    > visibility into what are the biggest problems on the site" is more of an
                    > epic, so I break it down to "get an inventory of what pages are on the
                    > site" and "get hit counts for those pages." These look doable, at least
                    > till I start digging into them, and discover a whole host of new issues.

                    I don't understand how those give you the biggest problems.

                    I also don't think that an inventory of pages or hit counts are, in
                    themselves, valuable. A different split might be finding A big problem.
                    It doesn't have to be the biggest. But it would be forward motion in
                    determining what should be done.

                    > Like 90% of the pages aren't HTML (most are pdf). We have Google
                    > Analytics, but the tracking has only been implemented on HTML pages that
                    > have been developed over the last 4 years, which is about 1% of the
                    > site. The more you dig, the more questions you get, and most of the new
                    > stories are for infrastructure. Adding GA tracking to a group of pages
                    > isn't a traditional user story, but it's the type of work that needs to
                    > be done first in order to understand what needs to be done next.

                    Are there no log files for the web server? They'll be more accurate
                    than Google Analytics (which depends on javascript--I'm generally
                    invisible to sites depending on Google Analytics).

                    The thing I find striking in your description is the sense of being a
                    lone wolf in this. I'm reading between the lines, here, but I get a
                    strong sense that /you/ need to do this, and get it right, before others
                    can start working. Am I close?

                    If so, I'd like to invite you to apply the "rule of three." In this
                    context, "If you haven't thought about three ways of beginning this
                    project, you haven't thought about it enough."

                    Right now, I'm hearing
                    1. I need to do this so we start out on track to do the right things.
                    2. If we just start building what seems right, we won't reach a
                    holistic design.

                    This is the classic case of the "one idea I have and it's opposite,
                    which I'm sure is a mistake." Unfortunately, it locks you into that
                    first idea, because the second one is generally chosen to make the first
                    one look good. (Unconsciously, I'm sure. I'm not accusing you of doing
                    that deliberately.) It's when you think of the third idea that you
                    break the logjam, and other ideas start popping out.

                    At least, that's the way it works for me. I've found the "rule of
                    three" to be very helpful in many endeavors.

                    I'll be happy to share a third alternative that comes to my mind, but I
                    suspect that you'll do better if you come up with your own third choice.

                    cheers,
                    George

                    --
                    ----------------------------------------------------------------------
                    * George Dinwiddie * http://blog.gdinwiddie.com
                    Software Development http://www.idiacomputing.com
                    Consultant and Coach http://www.agilemaryland.org
                    ----------------------------------------------------------------------
                  • Jon Innes
                    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
                    Message 9 of 11 , 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:

                       

                      Dean,

                       

                      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
                      beyer@...
                      twitter: @hughrbeyer

                       

                    • Tim Wright
                      I once saw a presentation by Tom and/or Mary Poppendieck and someone in the audience made this exact point (they were both in the country and I can t remember
                      Message 10 of 11 , Aug 31, 2011
                      • 0 Attachment

                        I once saw a presentation by Tom and/or Mary Poppendieck and someone in the audience made this exact point (they were both in the country and I can't remember who actually gave the presentation). Their rebuttal was that they used Lean at 3M to produce patentable inventions. While I know that there is a difference between "creative" and "patentable", I think that their point is a fair and robust rebuttal - Lean and Creative can go together quite nicely.

                        Tim

                        On 29 August 2011 03:44, HRB <beyer@...> 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
                        beyer@...
                        twitter: @hughrbeyer


                      • dina salah
                        Hi, The International Conference on Advanced Information Systems Engineering (CAiSE’12)
                        Message 11 of 11 , Jan 12, 2012
                        • 0 Attachment
                          Hi,
                           The International Conference on Advanced Information
                           Systems Engineering (CAiSE’12)
                          http://www.caise2012.univ.gda.**pl/<http://www.caise2012.univ.gda.pl/>
                           includes a workshop on agility of enterprise systems.
                           http://www.caise2012.univ.gda.**pl/data/WS/IWAES_CFP.pdf<http://www.caise2012.univ.gda.pl/data/WS/IWAES_CFP.pdf>
                           The deadline is 26th of february 2012. 
                          Anyone who has
                          an experience/insight on how to conduct agile and user centred design integration for enterprise systems is welcome to submit. Conveying your experience, touching on problems or lessons learned related to that issue this will be a great contribution to the conference. Cheers,
                          Dina Salah

                        Your message has been successfully submitted and would be delivered to recipients shortly.