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

Re: [agile-usability] Scrum and UCD

Expand Messages
  • Marjorie H Pries
    Linda, To clarify, SCRUM is a method for delivering working software, UCD is not a method but a collection of techniques to determine software requirements and
    Message 1 of 9 , Mar 4, 2009
    • 0 Attachment

      Linda,

      To clarify, SCRUM is a method for delivering working software, UCD is not a method but a collection of techniques to determine software requirements and the human interaction aspects of the design -- unless you're going to some school that has cooked up some method they call UCD :-)  .

      You can do SCRUM with UCD included in the activities as long as you have stories for the UCD tasks, you plan the stories into each sprint,  and your UCD people participate in the daily stand-ups and report their status. The outsomes of the UCD stories become new stories for the developers in a subsequent iteration / sprint.

      Marjorie H. Pries
      Lead Consultant / Utility Infielder

      ThoughtWorks, Inc.
      http://www.thoughtworks.com


      "Don't believe everything you think."
          --seen on a bumpersticker



      "linda.hellman" <linda.hellman@...>
      Sent by: agile-usability@yahoogroups.com

      03/04/2009 06:03 AM

      Please respond to
      agile-usability@yahoogroups.com

      To
      agile-usability@yahoogroups.com
      cc
      Subject
      [agile-usability] Scrum and UCD






      Hi,
      I'm writing my Master's Thesis at the moment and in my Thesis I'm trying to find the biggest problems between the two methods and then to integrate Scrum and UCD and create new user-centered Scrum.
      My Thesis is based on literature about integrating user-centered design and agile methods. My Thesis is almost ready and at the moment I am starting to introduce my process to one software project where I am the UE designer.

      I would like hear from You, what kind of actual troubles and problems You have had when using both Scrum and User-Centered Design?
      And what advantages has the use of both methods brought to the project?

      Waiting for your opinions,
      Linda.


    • Daniel Naumann
      Hi Linda, One of the bigger issues that I see and read about is the How much up-front design? issue. UCD likes a lot of up-front design and Scrum/Agile only
      Message 2 of 9 , Mar 4, 2009
      • 0 Attachment
        Hi Linda,

        One of the bigger issues that I see and read about is the 'How much
        up-front design?' issue. UCD likes a lot of up-front design and
        Scrum/Agile only wants the minimum done. I think it's a semantic
        problem around the term 'design'.

        I think when Scrum/Agile talk about up-front design they mean
        designing an actual solution, ie. sketches, viso, UI code, etc. But
        when UCD talks about up-front design, they really mean 'problem
        definition'. The first stage in UCD is to really work out what
        problem you're trying to solve and who you're solving it for. Once
        you have that, then you can start on a solution. I think Agile call
        this analysis rather than design (but I might be wrong on that as I'm
        still learning about Agile).

        So it's something i see people clash over, but I think it's just a
        semantic problem.

        Cheers,
        Dan.

        2009/3/4 linda.hellman <linda.hellman@...>:
        > Hi,
        > I'm writing my Master's Thesis at the moment and in my Thesis I'm trying to
        > find the biggest problems between the two methods and then to integrate
        > Scrum and UCD and create new user-centered Scrum.
        > My Thesis is based on literature about integrating user-centered design and
        > agile methods. My Thesis is almost ready and at the moment I am starting to
        > introduce my process to one software project where I am the UE designer.
        >
        > I would like hear from You, what kind of actual troubles and problems You
        > have had when using both Scrum and User-Centered Design?
        > And what advantages has the use of both methods brought to the project?
        >
        > Waiting for your opinions,
        > Linda.
        >
        >
      • Robert Biddle
        There are a number of ways the UCD-Agile connection is being made, and I guess Linda wanted to hear reports of experience in the various approaches. I haven t
        Message 3 of 9 , Mar 5, 2009
        • 0 Attachment
          There are a number of ways the UCD-Agile connection is being made, and I
          guess Linda
          wanted to hear reports of experience in the various approaches.

          I haven't actually seen the one that you describe, and I would like to
          hear more details.

          For example:
          * are the UI designers and programmers within the same team but do
          different kinds of tasks,
          or do they do both?
          * what are the UI stories (or backlog items) like, especially for user
          research?
          * do the UI stories count as "done", even when no software has been written?

          I've love to hear more about what you've seen.

          Cheers
          Robert Biddle




          Marjorie H Pries wrote:
          >
          >
          > Linda,
          >
          > To clarify, SCRUM is a method for delivering working software, UCD is
          > not a method but a collection of techniques to determine software
          > requirements and the human interaction aspects of the design -- unless
          > you're going to some school that has cooked up some method they call
          > UCD :-) .
          >
          > You can do SCRUM with UCD included in the activities as long as you
          > have stories for the UCD tasks, you plan the stories into each sprint,
          > and your UCD people participate in the daily stand-ups and report
          > their status. The outsomes of the UCD stories become new stories for
          > the developers in a subsequent iteration / sprint.
          >
          > Marjorie H. Pries
          > Lead Consultant / Utility Infielder
          >
          > ThoughtWorks, Inc.
          > http://www.thoughtw orks.com
          >
          >
          > "Don't believe everything you think."
          > --seen on a bumpersticker
          >
          >
          > *"linda.hellman" <linda.hellman@ yahoo.com>*
          > Sent by: agile-usability@ yahoogroups. com
          >
          > 03/04/2009 06:03 AM
          >
          > Please respond to
          > agile-usability@ yahoogroups. com
          >
          >
          >
          > To
          > agile-usability@ yahoogroups. com
          > cc
          >
          > Subject
          > [agile-usability] Scrum and UCD
          >
          >
          >
          >
          >
          >
          >
          >
          >
          >
          > Hi,
          > I'm writing my Master's Thesis at the moment and in my Thesis I'm
          > trying to find the biggest problems between the two methods and then
          > to integrate Scrum and UCD and create new user-centered Scrum.
          > My Thesis is based on literature about integrating user-centered
          > design and agile methods. My Thesis is almost ready and at the moment
          > I am starting to introduce my process to one software project where I
          > am the UE designer.
          >
          > I would like hear from You, what kind of actual troubles and problems
          > You have had when using both Scrum and User-Centered Design?
          > And what advantages has the use of both methods brought to the project?
          >
          > Waiting for your opinions,
          > Linda.
          >
          >
          >
        • sigbackup
          Hi Linda,unfortunately I don t have an answer for you right now. I m still trying to figure out the best way to include UCD within the Agile methodology I use
          Message 4 of 9 , Mar 5, 2009
          • 0 Attachment
            Hi Linda,
            unfortunately I don't have an answer for you right now. I'm still trying to figure out the best way to include UCD within the Agile methodology I use to optimize processes (from my point of view software is not the goal but the mean).
            However I would like to suggest you some interesting websites and articles:

            http://www.uie.com/events/uiconf/2008/seminars/patton/  (on the right column you can find a good article and the inteview with Jeff Patton about this topic)



            Hope this helps.

            PS Let us know how your thesis is going on ...



            Sig






            2009/3/4 linda.hellman <linda.hellman@...>

            Hi,
            I'm writing my Master's Thesis at the moment and in my Thesis I'm trying to find the biggest problems between the two methods and then to integrate Scrum and UCD and create new user-centered Scrum.
            My Thesis is based on literature about integrating user-centered design and agile methods. My Thesis is almost ready and at the moment I am starting to introduce my process to one software project where I am the UE designer.

            I would like hear from You, what kind of actual troubles and problems You have had when using both Scrum and User-Centered Design?
            And what advantages has the use of both methods brought to the project?

            Waiting for your opinions,
            Linda.


          • Marjorie H Pries
            Hi Robert, Yes, I see.. Thanks for pointing that out. I lost track of the writing a Masters thesis bit and went off on my own tangent because I have a lot of
            Message 5 of 9 , Mar 6, 2009
            • 0 Attachment
              Hi Robert,

              Yes, I see.. Thanks for pointing that out. I lost track of the "writing a Masters thesis" bit and went off on my own tangent because I have a lot of concern that people trying to "do Agile" will eventually land at an unhappy place if they don't make a clear distinction between methodologies and values/ philosophy / tactics.  

              On our projects at ThoughtWorks, we don't necessarily do by-the-book Scrum but we do Scrum-like stuff  because we're committed to the Agile Manifesto.  However, every project is different and we shape it according to what works for the situation.  Sometimes, there is no UCD involvement and business analysts and developers just have to make things up based on what they see as making sense and where the client is coming from (often these are applications for the clients internal use ). Sometimes there are projects where the client hired a designer independently of bringing TW in for the implementation and their design is pretty much a static requirement in place at the start or delivered part way through (not very good). And then there are projects where we can have our own UCD person on-board or the outside design firm is committed to working as part of the team through the life of the project. That's when it gets good.

              Ideally, there is one or more UCD-skilled person(s) involved on the team through the life of the project. When you have this, the UCD person is utilizing these skills as they play some combination of roles: product owner/customer, business analyst / SME, developer.  The business analyst is the best model for what I'm talking about.

               A business analyst has to be able to understand the business operationally, grasp the strategic objectives of the stakeholders, interview stakeholders and customers/users to discover and verify requirements, be an advocate on the team for the customer/stakeholders, be an advocate for the strategic objectives (sometimes even stakeholders lose track of the greater goals), know enough about technology to have an intelligent conversation with developers so they can advocate back to the stakeholders when choices get hard, and maybe even sometimes do something technical themselves plus be able to specify and conduct effective acceptance tests so everyone can be assured the story is Done when it's done.

              Given that, the UCD member of the team is just another flavor of business analyst and all of the analysts would collaborate on just-in-time analysis tasks including user research and usability testing. Programmers also pair up with analysts as needed to have conversations, investigate technical issues, or research the business problem.  

              I'm in danger of dragging this out into a long essay, but I want to touch on your three questions because they are very good ones that really get at the heart of how to make agile projects work:

              * are the UI designers and programmers within the same team but do different kinds of tasks, or do they do both?  

              my answer: UI designers and programmers are just another flavor of business analyst or programmer and they would collaborate with the other analysts and programmers on all the tasks that need to be done including user research and usability testing. For example, a team could have a person who has skills in UI design and UI programming. That person would pair up with another analyst to do user research in one iteration, then pair up with a developer to code the UI part of a story(s) in another iteration. A team may also have a person who is a UI designer and experienced in user research but not experienced in UI programming.  That type of person would stay completely in the analyst / customer proxy role doing things like user research, product design, acceptance testing, facilitating showcases with the stakeholders, and also any needed product documentation. And programmers would also pair up with UCD analysts as needed to have conversations, investigate solutions to a problem interface, and conduct or witness research into the user experience.  

              * what are the UI stories (or backlog items) like, especially for user research?

              my answer: Like the term "methodology" we have to be careful with the term "story".  "Story" is a thing that developers implement. "Tasks" are things that have to be done to get stories through the pipeline. Tasks are activities people do to figure out what the story should be; realize the story in code;  or verify the story is done. So while you definitely make the stories visible and track their progress, you may or may not make all the tasks visible. High-level tasks might be treated "as if" they were stories so it is easy for the entire team to be aware of overall progress and activities for the week. In this case, your information radiator / story wall would likely use color or parallel tracks to distinguish implementation stories from other activities.  The development track might show stories 1, 2, and 3 in play and your analysis/UI track might show that story 4 is out for customer and UI review prior to development, detailed requirements discovery is starting for story 5, and user research relevant for backlog stories 6, 8 and 9 is in-progress.

              A lot of  tasks are not made visible because it's just too much noise, but people keep mental checklists and still report in stand-up on any blockages -- I'm going to be late finalizing the requirements for story 5 because I can't get a meeting with Mr. Y; we need to get the XML spec for the interface to system G before we can complete story 3; our user interviews are proceeding on schedule and we have no problems to report.      


              * do the UI stories count as "done", even when no software has been written?

              More hairsplitting!  The purpose of saying a story is Done, is to have a means of measuring the team's velocity -- how much implementation gets done on average per iteration/ sprint.  Thus, in theory, you only really care about Done if the story is a coding story.

              But you still need some way of determining if the flow of stories out of the backlog will impede the team's velocity.  Now we're talking lean.  Are stories getting delivered into the "ready-to-build" backlog fast enough so that the development team can always pull something off the backlog given their average velocity?  Or are they going to sit around with nothing to do because stories aren't ready? Or better yet, can we move one to the next phase early because we're going to blow through / eliminate all the stories originally planned for this sprint/phase?

              It is important to see the status of those higher-level analysis tasks, which includes the big UI tasks that precede the coding stories. If UI work was substantial enough to make visible as a "story" then you have to be able to say if it is not started, in-progress, or done, and have target expected completion dates so the team can get some kind of assurance about how and when the backlog may grow or shrink.

               UI research and the subsequent problem definition and solution finding (design thinking) will either add new stories, provide details for existing stories, or remove stories. Where the research provides new details for existing stories, that information will increase or decrease the stories's complexity.  Likewise, adding and removing stories changes the estimated amount of effort in the backlog.  Being able to see when UI findings are likely to conclude gives the team information about future events that could shift the backlog and helps everyone roadmap the project's progress.

              But, saying that these UI stories are Done, does not count in the velocity equation. The only stories that count for velocity are Done coding stories.   The team needs to be able to see it like this: Our velocity is V. We have 4xV stories in the backlog so the project should complete in 4 sprints BUT, we still have two UI research tasks to complete and our experience so far on this project indicates that those tasks could add as much as 1xV each in changes to the backlog, a total of 2xV potential increase. Therefore, as of today, our best estimate of finishing is 5 sprints but we may need 6.



              Hope you found that useful,

              Marjorie H. Pries
              Lead Consultant / Utility Infielder




              Robert Biddle <robtbiddle@...>
              Sent by: agile-usability@yahoogroups.com

              03/05/2009 06:57 AM

              Please respond to
              agile-usability@yahoogroups.com

              To
              agile-usability@yahoogroups.com
              cc
              Subject
              Re: [agile-usability] Scrum and UCD






              There are a number of ways the UCD-Agile connection is being made, and I
              guess Linda
              wanted to hear reports of experience in the various approaches.

              I haven't actually seen the one that you describe, and I would like to
              hear more details.

              For example:
              * are the UI designers and programmers within the same team but do
              different kinds of tasks,
              or do they do both?
              * what are the UI stories (or backlog items) like, especially for user
              research?
              * do the UI stories count as "done", even when no software has been written?

              I've love to hear more about what you've seen.

              Cheers
              Robert Biddle

              Marjorie H Pries wrote:

              >
              >
              > Linda,
              >
              > To clarify, SCRUM is a method for delivering working software, UCD
              is
              > not a method but a collection of techniques to determine software
              > requirements and the human interaction aspects of the design -- unless
              > you're going to some school that has cooked up some method they call
              > UCD :-) .
              >
              > You can do SCRUM with UCD included in the activities as long as you
              > have stories for the UCD tasks, you plan the stories into each sprint,
              > and your UCD people participate in the daily stand-ups and report
              > their status. The outsomes of the UCD stories become new stories for
              > the developers in a subsequent iteration / sprint.
              >
              > Marjorie H. Pries
              > Lead Consultant / Utility Infielder
              >
              > ThoughtWorks, Inc.
              >
              http://www.thoughtw orks.com
              >
              >
              > "Don't believe everything you think."
              > --seen on a bumpersticker
              >
              >
              > *"linda.hellman" <linda.hellman@ yahoo.com>*
              > Sent by: agile-usability@ yahoogroups. com
              >
              > 03/04/2009 06:03 AM
              >
              > Please respond to
              > agile-usability@ yahoogroups. com
              >
              >
              >
              > To
              > agile-usability@ yahoogroups. com
              > cc
              >
              > Subject
              > [agile-usability] Scrum and UCD
              >
              >
              >
              >
              >
              >
              >
              >
              >
              >
              > Hi,
              > I'm writing my Master's Thesis at the moment and in my Thesis I'm
              > trying to find the biggest problems between the two methods and then
              > to integrate Scrum and UCD and create new user-centered Scrum.
              > My Thesis is based on literature about integrating user-centered
              > design and agile methods. My Thesis is almost ready and at the moment
              > I am starting to introduce my process to one software project where
              I
              > am the UE designer.
              >
              > I would like hear from You, what kind of actual troubles and problems
              > You have had when using both Scrum and User-Centered Design?
              > And what advantages has the use of both methods brought to the project?
              >
              > Waiting for your opinions,
              > Linda.
              >
              >
              >


            • Robert Biddle
              ... Ok, I understand that. I m not in complete agreement, but I think we may be using words differently. For example, I think UI people need skills and
              Message 6 of 9 , Mar 7, 2009
              • 0 Attachment
                > Given that, the UCD member of the team is just another flavor of
                > business analyst and all of the analysts would collaborate on
                > just-in-time analysis tasks including user research and usability
                > testing. Programmers also pair up with analysts as needed to have
                > conversations, investigate technical issues, or research the business
                > problem.

                Ok, I understand that. I'm not in complete agreement, but I think we
                may be using words differently. For example, I think UI people need
                skills and experience that are about human factors and design rather than
                business, but you may mean "business" is some more general way. Also,
                I'm not quite sure about "just in time": I would imagine some user
                research might be done up front, rather than in the context of
                specific story.

                > * are the UI designers and programmers within the same team but do
                > different kinds of tasks, or do they do both?
                >
                > my answer: UI designers and programmers are just another flavor of
                > business analyst or programmer and they would collaborate with the

                Ok, similar to above: I think I understand this, though I'm not sure I
                agree with it.

                > * what are the UI stories (or backlog items) like, especially for user
                > research?
                >
                > my answer: Like the term "methodology" we have to be careful with the
                > term "story". "Story" is a thing that developers implement.

                When you say "developer", are you meaning to exclude UI designer?

                "Tasks"

                > High-level tasks might be treated "as if" they were stories so it is
                > easy for the entire team to be aware of overall progress and
                > activities for the week.

                Ah, this is the kind of thing I was wondering about. So you have
                different kinds of backlog items, some are "stories", which (I think
                you are saying) require full functional implemention. Is that right?
                And others are different, such as user research, usability testing,
                and UI design. Is that right?

                * do the UI stories count as "done", even when no software has been
                written?

                > More hairsplitting!

                Oh? I'm not sure why.

                > The purpose of saying a story is Done, is to have
                > a means of measuring the team's velocity -- how much implementation
                > gets done on average per iteration/ sprint. Thus, in theory, you only
                > really care about Done if the story is a coding story.

                Hmm. I'm not quite understanding this, and it seems different to what
                you said above. It seems to me if a task is big enough to be managed
                as a story, then they should be some similar equivalent to "done".

                I suppose the key thing is that when a story is implemented, there is
                nothing more to do, and hence we use the term "done". But this seems a
                very programmer-centric perspective. For example, if the software was
                beging developed in the context of some broader business product,
                there may be more work to do once the software is fully implemented.
                So I suspect this is becoming tautological: that the software is done
                when the software is done.

                > It is important to see the status of those higher-level analysis
                > tasks, which includes the big UI tasks that precede the coding
                > stories. If UI work was substantial enough to make visible as a
                > "story" then you have to be able to say if it is not started,
                > in-progress, or done, and have target expected completion dates so the
                > team can get some kind of assurance about how and when the backlog may
                > grow or shrink.

                Ok, so this is what I was wondering.

                >...
                > But, saying that these UI stories are Done, does not count in the
                > velocity equation.

                Hmm, ok, but again this is programming-centric. If, for example, the
                programming work was minor compared to UI work or more general
                business product work, then we should be careful.

                Anyway, thanks so much for writing this up. I have not actually seen a
                team working in this way, and will now be on the lookout.

                Cheers
                Robert
              • William Pietri
                ... Hi, Linda. This may be a slightly more philosophical answer than you want, but I think one important set of issues can be summed up by Voltaire s maxim,
                Message 7 of 9 , Mar 7, 2009
                • 0 Attachment
                  linda.hellman wrote:
                  > I would like hear from You, what kind of actual troubles and problems You have had when using both Scrum and User-Centered Design?
                  > And what advantages has the use of both methods brought to the project?
                  >

                  Hi, Linda. This may be a slightly more philosophical answer than you
                  want, but I think one important set of issues can be summed up by
                  Voltaire's maxim, "The perfect is the enemy of the good."

                  In my youth, I was very excited by the design of the internals of a
                  system, what is sometimes called a system's architecture. (Although
                  that's definitely distinct from the sort of design you're thinking of,
                  bear with me a bit.) Every time some problem came up in a live system,
                  the answer to me was obvious. I should have spend more time researching,
                  put more effort into analyzing, drawn just a few more beautiful diagrams.

                  For every new system, I'd redouble my efforts. But that never worked,
                  not like I wanted it to. Every time I'd put my theories into practice,
                  I'd learn something. Every time we'd try to build something, the world
                  would change on us. Every time we released something perfect, the world
                  would show us what we'd missed. I resented that terribly.

                  Agile methods, though, gave me the ability to make that a source of
                  strength, not a source of weakness. Now I start rough, and let the world
                  tell me what it needs. That doesn't mean that I don't put plenty of time
                  and effort into research and planning, as planning is a great way to
                  think things through. But it does mean I rarely have to bet heavily on
                  the perfection of my plans. Instead of a thousand bets being resolved on
                  one roll of the dice, I get to make my bets a few at a time, following
                  up on the wins and learning from the losses.

                  In the end, I get better results with less effort and less stress. I'd
                  never go back. A lot of software architects feel the same way.


                  This relates to your question because I think the world of user-facing
                  design is going through a similar transition that the software
                  architecture world has spent the last decade or so going through.
                  Designers face a lot of the same issues that software architects did,
                  with one added burden: they had to depend on those architects, giving
                  them even less control over both the process and the outcome.

                  It's my firm belief that things will turn out similarly. People will
                  create new approaches, new ways of working, and new techniques that make
                  short cycles and tight feedback loops a source of great power for
                  continuous improvement. In fact, they are creating and using them right
                  now. I've visited quite a number of agile shops over the last few years,
                  and although I've seen my share of disgruntled designers, I've seen many
                  more who say they are very happy, and even a few who say weekly releases
                  are great, but they'd love it to be faster.

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