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

Re: [agile-usability] What does an ass kicking Agile+UX team look like?

Expand Messages
  • Austin Govella
    ... The best teams I ve worked on had a couple of things in common: 1. Month-long sprints 2. Parallel, layered work-streams within the sprint 3. RITE testing
    Message 1 of 9 , Feb 22, 2011
    • 0 Attachment
      On Sun, Feb 20, 2011 at 4:31 AM, Robin Dymond <robin.dymond@...> wrote:
      > I'd love to hear from those who feel they have a GREAT Agile process
      > that fully integrates UX into the sprint, and delivers working tested
      > software that users like/love every sprint.

      The best teams I've worked on had a couple of things in common:

      1. Month-long sprints
      2. Parallel, layered work-streams within the sprint
      3. RITE testing
      4. Collaborative

      1. MONTH-LONG SPRINTS
      The sprints were a month long. You don't need a month for the
      engineering, nor design, but design (for experiences or interfaces)
      often needs some time for thinking and some time for reflection and
      review. The amount of time needed is different every time.

      With month-long sprints, the first week is heavy kickoff and
      collaboration activities and the last week is heavy QA and tweaking
      activities, so the two intervening weeks gives design time to review,
      reflect, and iterate, iterate, iterate.

      2. PARALLEL WORK STREAMS
      Parallel work streams between engineering and design. The
      collaborative kickoff activities identify the technology layers and
      how those layers interact with each other. For example, user interacts
      with data via javascript, so we need this data from the server in this
      format and these changes are possible. This allows the backend
      developer to expose the data in the proper format, allows the
      front-end developer to work on the interactivity, and allows visual
      design to create the visual experience. UX can drop in with any of
      these layers for heuristic reviews to allow for quick iterations
      within a technology layer.

      3. RITE TESTING
      Test, iterate, test is also really only possible with month-long
      sprints. You can have a user-testable piece of software in about two
      weeks and go through several days of RITE testing before you have to
      tighten up and get ready for the end of the sprint. I.e. after about
      two weeks you have a hypothesis that your code is of "shippable"
      quality. Rather than actually ship it, you do some quick tests to
      validate your assumption, and then declare yourself done.

      4. COLLABORATIVE
      Collaborative teams do not view design as a hinderance. The bad teams
      I've worked with have always contained engineers who were more
      concerned with their personal performance than with the product. They
      would rather finish their stories than deliver decent products. Design
      is collaborative by nature, and if anyone in the team (including any
      designers) is more interested in their personal performance than in
      group performance, design -- and the product -- will always suffer.





      --
      Austin Govella
      User Experience

      Catch my presentation at SXSWi:
      * http://schedule.sxsw.com/events/event_IAP7545

      Work: http://www.grafofini.com
      Blog: http://www.thinkingandmaking.com

      austin@...
      215-240-1265
    • Jon Innes
      Let me add a couple of things that I ve seen turn out to be incredibly important. Track user engagement, usability, and satisfaction metrics for every story,
      Message 2 of 9 , Feb 22, 2011
      • 0 Attachment
        Let me add a couple of things that I've seen turn out to be incredibly important.

        Track user engagement, usability, and satisfaction metrics for every story, and for every unique persona targeted. This keeps the team focused on delivering customer value not just shipping/posting code.

        I do this in a modified product backlog I call the UXI Matrix. It solves the "what is done" problem that so often gets neglected by teams. It also avoids the problem Austin mentions below where individuals try to pass off things as done that aren't.

        I'll be going over my method in detail for doing this at UPA this year. I'm also hoping to present it at the Agile 2011 conference. I'd be glad to share with anyone interested who can't attend, just drop me an email at info@... with UXI Matrix in the subject line.

        --- In agile-usability@yahoogroups.com, Austin Govella <austin.govella@...> wrote:
        >
        > On Sun, Feb 20, 2011 at 4:31 AM, Robin Dymond <robin.dymond@...> wrote:
        > > I'd love to hear from those who feel they have a GREAT Agile process
        > > that fully integrates UX into the sprint, and delivers working tested
        > > software that users like/love every sprint.
        >
        > The best teams I've worked on had a couple of things in common:
        >
        > 1. Month-long sprints
        > 2. Parallel, layered work-streams within the sprint
        > 3. RITE testing
        > 4. Collaborative
        >
        > 1. MONTH-LONG SPRINTS
        > The sprints were a month long. You don't need a month for the
        > engineering, nor design, but design (for experiences or interfaces)
        > often needs some time for thinking and some time for reflection and
        > review. The amount of time needed is different every time.
        >
        > With month-long sprints, the first week is heavy kickoff and
        > collaboration activities and the last week is heavy QA and tweaking
        > activities, so the two intervening weeks gives design time to review,
        > reflect, and iterate, iterate, iterate.
        >
        > 2. PARALLEL WORK STREAMS
        > Parallel work streams between engineering and design. The
        > collaborative kickoff activities identify the technology layers and
        > how those layers interact with each other. For example, user interacts
        > with data via javascript, so we need this data from the server in this
        > format and these changes are possible. This allows the backend
        > developer to expose the data in the proper format, allows the
        > front-end developer to work on the interactivity, and allows visual
        > design to create the visual experience. UX can drop in with any of
        > these layers for heuristic reviews to allow for quick iterations
        > within a technology layer.
        >
        > 3. RITE TESTING
        > Test, iterate, test is also really only possible with month-long
        > sprints. You can have a user-testable piece of software in about two
        > weeks and go through several days of RITE testing before you have to
        > tighten up and get ready for the end of the sprint. I.e. after about
        > two weeks you have a hypothesis that your code is of "shippable"
        > quality. Rather than actually ship it, you do some quick tests to
        > validate your assumption, and then declare yourself done.
        >
        > 4. COLLABORATIVE
        > Collaborative teams do not view design as a hinderance. The bad teams
        > I've worked with have always contained engineers who were more
        > concerned with their personal performance than with the product. They
        > would rather finish their stories than deliver decent products. Design
        > is collaborative by nature, and if anyone in the team (including any
        > designers) is more interested in their personal performance than in
        > group performance, design -- and the product -- will always suffer.
        >
        >
        >
        >
        >
        > --
        > Austin Govella
        > User Experience
        >
        > Catch my presentation at SXSWi:
        > * http://schedule.sxsw.com/events/event_IAP7545
        >
        > Work: http://www.grafofini.com
        > Blog: http://www.thinkingandmaking.com
        >
        > austin@...
        > 215-240-1265
        >
      • William Pietri
        ... This suggests that with shorter iterations, designers have no time to think. That s incorrect. What they actually do is think more broadly than iteration
        Message 3 of 9 , Feb 22, 2011
        • 0 Attachment
          On 02/22/2011 09:45 AM, Austin Govella wrote:
          The sprints were a month long. You don't need a month for the
          engineering, nor design, but design (for experiences or interfaces)
          often needs some time for thinking and some time for reflection and
          review. The amount of time needed is different every time.
          

          This suggests that with shorter iterations, designers have no time to think. That's incorrect. What they actually do is think more broadly than iteration to iteration. That becomes even more true when you take release frequency below a week. Indeed, shorter iterations make it easier to honor the way that the need for thinking varies over time.

          William
        • Austin Govella
          ... Actually, just the opposite. It only suggests that with longer iterations, they have longer to think. And I make the assumption that this additional time
          Message 4 of 9 , Feb 22, 2011
          • 0 Attachment
            On Tue, Feb 22, 2011 at 4:24 PM, William Pietri <william@...> wrote:
            >
            > On 02/22/2011 09:45 AM, Austin Govella wrote:
            > The sprints were a month long. You don't need a month for the
            > engineering, nor design, but design (for experiences or interfaces)
            > often needs some time for thinking and some time for reflection and
            > review. The amount of time needed is different every time.
            >
            > This suggests that with shorter iterations, designers have no time to think.

            Actually, just the opposite. It only suggests that with longer
            iterations, they have longer to think. And I make the assumption that
            this additional time is more beneficial than harmful.



            > What they actually do is think more broadly than iteration
            > to iteration. That becomes even more true when you take release frequency
            > below a week. Indeed, shorter iterations make it easier to honor the way
            > that the need for thinking varies over time.

            Can you clarify what you mean here? Are you combining strategic
            thinking and tactical thinking (strategic design vs implementation
            design) when you say "think more broadly"?

            When I mention time to think, I am referring specifically to thinking
            and reflecting on the specific tactical feature they are building in
            the current sprint.



            (Of course, task sizing has a huge influence on how long iterations
            can or should be, but I think it's worth exploring the notion of how
            reflection can improve development.)



            --
            Austin Govella
            User Experience

            Catch my presentation at SXSWi:
            * http://schedule.sxsw.com/events/event_IAP7545

            Work: http://www.grafofini.com
            Blog: http://www.thinkingandmaking.com

            austin@...
            215-240-1265
          • William Pietri
            ... I think your second assumption is correct: time to think makes things better. But I believe it s definitely untrue that longer iterations yield more time
            Message 5 of 9 , Feb 22, 2011
            • 0 Attachment
              On 02/22/2011 06:01 PM, Austin Govella wrote:
              On Tue, Feb 22, 2011 at 4:24 PM, William Pietri <william@...> wrote:
              
              On 02/22/2011 09:45 AM, Austin Govella wrote:
              The sprints were a month long. You don't need a month for the
              engineering, nor design, but design (for experiences or interfaces)
              often needs some time for thinking and some time for reflection and
              review. The amount of time needed is different every time.
              
              This suggests that with shorter iterations, designers have no time to think.
              
              Actually, just the opposite. It only suggests that with longer
              iterations, they have longer to think. And I make the assumption that
              this additional time is more beneficial than harmful.
              

              I think your second assumption is correct: time to think makes things better. But I believe it's definitely untrue that longer iterations yield more time to think.


              What they actually do is think more broadly than iteration
              to iteration. That becomes even more true when you take release frequency
              below a week. Indeed, shorter iterations make it easier to honor the way
              that the need for thinking varies over time.
              
              Can you clarify what you mean here? Are you combining strategic
              thinking and tactical thinking (strategic design vs implementation
              design) when you say "think more broadly"?
              
              When I mention time to think, I am referring specifically to thinking
              and reflecting on the specific tactical feature they are building in
              the current sprint.
              

              I did mean both of those. Consider this diagram:

              http://www.slideshare.net/wpietri/meshing-gears/16

              Time runs along the X axis. Total amount of design investment is on the Y axis.

              It sounds like you're experience is with cases like the red line. Design investment is near zero at the beginning of the iteration, and you finish by the end of the iteration. In between, you're very busy. That works fine for long iterations that are done in the mini-waterfall style you describe.

              However, that's not what happens in teams with, say, weekly iterations. What's more typical for them is the other two lines. Some particular unit of work is thought of and designed sufficiently to decide whether it's worth further investment. As it gets closer to the top of the things to do, more design investment is made. Some design work is left for the iteration itself, but that's the low-risk stuff that people are comfortable will happen safely shortly before or during construction.

              There are a variety of benefits there, but one big one is that it allows people to think as much as they need.

              (Of course, task sizing has a huge influence on how long iterations
              can or should be, but I think it's worth exploring the notion of how
              reflection can improve development.)
              

              I'm all for reflection. However, I don't think task size necessitates any particular iteration length. There are plenty of shops that build large things despite using short iterations. (Some release upwards of 50x/day.) Like eating an elephant, it's done one bite at a time.

              William
            • Robin Dymond
              Anyone else got a process they would like to share here? Robin Dymond, CST Managing Partner, Innovel, LLC. www.innovel.net www.scrumtraining.com Americas:
              Message 6 of 9 , Mar 4, 2011
              • 0 Attachment
                Anyone else got a process they would like to share here?

                Robin Dymond, CST
                Managing Partner, Innovel, LLC.
                www.innovel.net
                www.scrumtraining.com
                Americas: (804) 239-4329
                Europe: +32 489 674 366


                On Sun, Feb 20, 2011 at 5:31 AM, Robin Dymond <rdymond@...> wrote:
                I'd love to hear from those who feel they have a GREAT Agile process
                that fully integrates UX into the sprint, and delivers working tested
                software that users like/love every sprint.

                If you have this nailed, please come blow your horn here! :)

                Robin.

                --
                Sent from my mobile device

                Robin Dymond, CST
                Managing Partner, Innovel, LLC.
                www.innovel.net
                www.scrumtraining.com
                Americas: (804) 239-4329
                Europe: +32 489 674 366

              • Jon Innes
                I ve got a couple of nuggets of a larger process that largely mess with what others here have said. 1. Do a quick design brief up front to kick off each epic,
                Message 7 of 9 , Mar 7, 2011
                • 0 Attachment
                  I've got a couple of nuggets of a larger process that largely mess with what others here have said.

                  1. Do a quick design brief up front to kick off each epic, but keep it to 5 pages
                  2. Track UX work in the product backlog, to do otherwise is a big #fail
                  3. Track UX metrics, and this of course means gathering them
                  4. Treat UX bugs as bugs, first class
                  5. Define a visual style guide so devs work from wireframes when the UI is fairly simple
                  6. Sprint ahead for design, behind for research on short sprints, but test before widely releasing

                  As for the topic of length of sprints mentioned earlier, I've worked in weekly sprints and I never found myself doing my best work. I iterate within sprints, as I believe most designers do. If the sprint is long enough, the design evolves faster because you iterate in design and research phases in the sprint.

                  It's not uncommon for me to radically change something in two days if I get inspired, only to realize it wasn't that good and then rework it again. When we worked in weekly sprints we tended to build something that I still felt was half baked, and we rarely had a chance to go back. In a month sprint that's almost never a problem. Less rework, better quality.

                  Full team sprints are not the same as design cycles in my mind. Too many Agile teams confuse designing and building. The goal should be faster, better product, not just more code for codings sake.

                  Jon

                  --- In agile-usability@yahoogroups.com, Robin Dymond <robin.dymond@...> wrote:
                  >
                  > Anyone else got a process they would like to share here?
                  >
                  > Robin Dymond, CST
                  > Managing Partner, Innovel, LLC.
                  > www.innovel.net
                  > www.scrumtraining.com
                  > Americas: (804) 239-4329
                  > Europe: +32 489 674 366
                  >
                  >
                  > On Sun, Feb 20, 2011 at 5:31 AM, Robin Dymond <rdymond@...> wrote:
                  >
                  > > I'd love to hear from those who feel they have a GREAT Agile process
                  > > that fully integrates UX into the sprint, and delivers working tested
                  > > software that users like/love every sprint.
                  > >
                  > > If you have this nailed, please come blow your horn here! :)
                  > >
                  > > Robin.
                  > >
                  > > --
                  > > Sent from my mobile device
                  > >
                  > > Robin Dymond, CST
                  > > Managing Partner, Innovel, LLC.
                  > > www.innovel.net
                  > > www.scrumtraining.com
                  > > Americas: (804) 239-4329
                  > > Europe: +32 489 674 366
                  > >
                  >
                • patrick.sansom
                  Just a quick question Austin (and sorry if I m being a bit thick): You are talking about design and development working in the same sprint, yes? Rather than
                  Message 8 of 9 , Mar 8, 2011
                  • 0 Attachment
                    Just a quick question Austin (and sorry if I'm being a bit thick):

                    You are talking about design and development working in the same sprint, yes? Rather than design working a sprint ahead (whilst also giving feedback on the current dev sprint, of course)?

                    Thanks, Patrick.

                    --- In agile-usability@yahoogroups.com, Austin Govella <austin.govella@...> wrote:
                    >
                    > On Sun, Feb 20, 2011 at 4:31 AM, Robin Dymond <robin.dymond@...> wrote:
                    > > I'd love to hear from those who feel they have a GREAT Agile process
                    > > that fully integrates UX into the sprint, and delivers working tested
                    > > software that users like/love every sprint.
                    >
                    > The best teams I've worked on had a couple of things in common:
                    >
                    > 1. Month-long sprints
                    > 2. Parallel, layered work-streams within the sprint
                    > 3. RITE testing
                    > 4. Collaborative
                    >
                    > 1. MONTH-LONG SPRINTS
                    > The sprints were a month long. You don't need a month for the
                    > engineering, nor design, but design (for experiences or interfaces)
                    > often needs some time for thinking and some time for reflection and
                    > review. The amount of time needed is different every time.
                    >
                    > With month-long sprints, the first week is heavy kickoff and
                    > collaboration activities and the last week is heavy QA and tweaking
                    > activities, so the two intervening weeks gives design time to review,
                    > reflect, and iterate, iterate, iterate.
                    >
                    > 2. PARALLEL WORK STREAMS
                    > Parallel work streams between engineering and design. The
                    > collaborative kickoff activities identify the technology layers and
                    > how those layers interact with each other. For example, user interacts
                    > with data via javascript, so we need this data from the server in this
                    > format and these changes are possible. This allows the backend
                    > developer to expose the data in the proper format, allows the
                    > front-end developer to work on the interactivity, and allows visual
                    > design to create the visual experience. UX can drop in with any of
                    > these layers for heuristic reviews to allow for quick iterations
                    > within a technology layer.
                    >
                    > 3. RITE TESTING
                    > Test, iterate, test is also really only possible with month-long
                    > sprints. You can have a user-testable piece of software in about two
                    > weeks and go through several days of RITE testing before you have to
                    > tighten up and get ready for the end of the sprint. I.e. after about
                    > two weeks you have a hypothesis that your code is of "shippable"
                    > quality. Rather than actually ship it, you do some quick tests to
                    > validate your assumption, and then declare yourself done.
                    >
                    > 4. COLLABORATIVE
                    > Collaborative teams do not view design as a hinderance. The bad teams
                    > I've worked with have always contained engineers who were more
                    > concerned with their personal performance than with the product. They
                    > would rather finish their stories than deliver decent products. Design
                    > is collaborative by nature, and if anyone in the team (including any
                    > designers) is more interested in their personal performance than in
                    > group performance, design -- and the product -- will always suffer.
                    >
                    >
                    >
                    >
                    >
                    > --
                    > Austin Govella
                    > User Experience
                    >
                    > Catch my presentation at SXSWi:
                    > * http://schedule.sxsw.com/events/event_IAP7545
                    >
                    > Work: http://www.grafofini.com
                    > Blog: http://www.thinkingandmaking.com
                    >
                    > austin@...
                    > 215-240-1265
                    >
                  Your message has been successfully submitted and would be delivered to recipients shortly.