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

What does an ass kicking Agile+UX team look like?

Expand Messages
  • Robin Dymond
    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
    Message 1 of 9 , Feb 20, 2011
    View Source
    • 0 Attachment
      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
    • 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 2 of 9 , Feb 22, 2011
      View Source
      • 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 3 of 9 , Feb 22, 2011
        View Source
        • 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 4 of 9 , Feb 22, 2011
          View Source
          • 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 5 of 9 , Feb 22, 2011
            View Source
            • 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 6 of 9 , Feb 22, 2011
              View Source
              • 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 7 of 9 , Mar 4, 2011
                View Source
                • 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 8 of 9 , Mar 7, 2011
                  View Source
                  • 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 9 of 9 , Mar 8, 2011
                    View Source
                    • 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.