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

Agile & UX - interview with VP of Engineering at Mindflash

Expand Messages
  • Peter Boersma
    Hi, In preparation for our Managing Experiences conference, I interviewed Cameron Gray, VP of Engineering at Mindflash and avid agile follower, about the topic
    Message 1 of 9 , Feb 18, 2011
      Agile & UX - interview with VP of Engineering at Mindflash

      Hi,

      In preparation for our Managing Experiences conference, I interviewed Cameron Gray, VP of Engineering at Mindflash and avid agile follower, about the topic of Agile and UX. The result can be found here:

      The Awesomeness Factor: Cameron Gray on Agile and UX
      http://www.adaptivepath.com/blog/2011/02/18/the-awesomeness-factor-cameron-gray-on-agile-and-ux/

      The article has a comment section, but feel free to contact me off-list and of course I encourage you to discuss right here!

      Peter
      --
      Peter Boersma | Experience Designer | Adaptive Path
      peter@... | peter.boersma@...

    • Robin Dymond
      Great quote from the interview: We typically do just enough up front design that a user story can be estimated by the development team and evaluated, for
      Message 2 of 9 , Feb 20, 2011
        Great quote from the interview:

        "We typically do just enough up front design that a user story can be
        estimated by the development team and evaluated, for relative
        priority, by the stakeholders. I have found that letting design evolve
        simultaneously with code being written is extremely useful because the
        two exercises give each other context."

        In my opinion 1 month sprints are too long. Industry has moved to 2-3
        weeks on average. Too much can change in a month, it is more difficult
        to plan, the amount of work done near the end of the sprint is much
        more than the first week -student syndrome. Why IX (the designer) has
        nothing to report in last 1/2 of sprints is odd. Could he/she help
        with testing the new features?

        One other telling comment from the interview:
        "As for the future, our process is fairly mature at this point so I am
        really not looking to make any radical changes."

        This is a mindset that may well lead to mediocrity. There are always
        many things to improve. No one has a perfect process. The reason Scrum
        has a retrospective is to find improvements, and then implement the
        most important ones the next sprint. From only this interview I can
        see the following potential improvements:
        QA needs to be fully integrated into the team
        Product people need to be involved with testing
        Shorter sprints to speed up learning cycles
        Pair programming needs to be fully implemented for faster higher quality code
        More input from users, needs a system to provide continuous feedback.
        More and better test automation is needed.

        I'd bet spending a couple days there we'd find a year's worth of improvements.

        I'll go out on a short limb and suggest this process can be twice as
        effective as it is today. I think that is good news for Cameron Gray
        and Mindflash.

        Cheers,
        Robin.


        On 2/18/11, Peter Boersma <peter@...> wrote:
        > Hi,
        >
        > In preparation for our Managing Experiences conference, I interviewed
        > Cameron Gray, VP of Engineering at Mindflash and avid agile follower, about
        > the topic of Agile and UX. The result can be found here:
        >
        > The Awesomeness Factor: Cameron Gray on Agile and UX
        > http://www.adaptivepath.com/blog/2011/02/18/the-awesomeness-factor-cameron-gray-on-agile-and-ux/
        >
        > The article has a comment section, but feel free to contact me off-list and
        > of course I encourage you to discuss right here!
        >
        > Peter
        > --
        > Peter Boersma | Experience Designer | Adaptive Path
        > peter@... | peter.boersma@...
        >

        --
        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
        ... It s only too long if you don t do three full days of RITE testing two weeks in. The planning is easy: do less. One week to collaboratively design the
        Message 3 of 9 , Feb 22, 2011
          On Sun, Feb 20, 2011 at 4:23 AM, Robin Dymond <robin.dymond@...> wrote:
          > In my opinion 1 month sprints are too long. Industry has moved to 2-3
          > weeks on average. Too much can change in a month, it is more difficult
          > to plan, the amount of work done near the end of the sprint is much
          > more than the first week -student syndrome.

          It's only too long if you don't do three full days of RITE testing two weeks in.

          The planning is easy: do less. One week to collaboratively design the
          system. One week for people to build their pieces. One week to RITE
          test, and one week to finish bugs. It's breezy, low-stress,
          high-quality, and everything gets done. Very few tasks slip.

          If you're fear is that too much can change, then you're moving too
          quickly. If you don't have a couple of months to build, launch, and
          measure a feature, then that feature isn't worthwhile. Why are you
          building it?



          > Why IX (the designer) has
          > nothing to report in last 1/2 of sprints is odd. Could he/she help
          > with testing the new features?

          I've done this lots and I usually have nothing to report to *that*
          scrum *that* day, but I am busy working on backlog items. Reviewing
          ongoing work isn't a full-time job. Even if you're really unlucky and
          supporting more than 3-6 engineers.





          --
          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
          ... You should naturally work however you please, but I read the last paragraph as suggesting other ways of working are ridiculous to you, which is faintly
          Message 4 of 9 , Feb 22, 2011
            On 02/22/2011 09:52 AM, Austin Govella wrote:
            On Sun, Feb 20, 2011 at 4:23 AM, Robin Dymond <robin.dymond@...> wrote:
            
            In my opinion 1 month sprints are too long.[...]
            
            It's only too long if you don't do three full days of RITE testing two weeks in.
            
            The planning is easy: do less. One week to collaboratively design the
            system. One week for people to build their pieces. One week to RITE
            test, and one week to finish bugs. It's breezy, low-stress,
            high-quality, and everything gets done. Very few tasks slip.
            
            If you're fear is that too much can change, then you're moving too
            quickly. If you don't have a couple of months to build, launch, and
            measure a feature, then that feature isn't worthwhile. Why are you
            building it?
            


            You should naturally work however you please, but I read the last paragraph as suggesting other ways of working are ridiculous to you, which is faintly insulting. Also, your conflation of cost and value is disappointing.

            I visited one very successful team that was doing daily releases and brought me in to figure out how to release more often. At the time of my visit, they had circa 30 ongoing experiments. Some would last days, some months. Rather than spending 1 week of 4 getting data, they did it every week. Even going back to weekly iterations would have been a severe blow to the product managers and designers.

            I like the spirit of the RITE method in that it clearly recognizes that shorter feedback loops lead to faster learning. But it's exactly that insight that has pushed me to shift first to weekly iterations and then to a clockless, kanban-style process.

            I should also add that any team that needs to spend 1 week taking out bugs that they spent the last 3 weeks creating probably has a lot of opportunity to improve productivity though quality-focused technical practices.

            William

          • Jon Innes
            I d have to ask if they were moving the needle on adding value to customers working at that rate, or just doing a bunch of stuff to feel really busy. If they
            Message 5 of 9 , Feb 22, 2011

              I'd have to ask if they were moving the needle on adding value to customers working at that rate, or just doing a bunch of stuff to feel really busy.

              If they could actually create measurable value at a release a day, while maintaining quality, and not incurring technical or UX debt, then I'd like to invest in them!

              Jon

              On Feb 22, 2011, at 2:21 PM, William Pietri wrote:

               

              On 02/22/2011 09:52 AM, Austin Govella wrote:

              On Sun, Feb 20, 2011 at 4:23 AM, Robin Dymond <robin.dymond@...> wrote:
              
              In my opinion 1 month sprints are too long.[...]
              
              It's only too long if you don't do three full days of RITE testing two weeks in.
              
              The planning is easy: do less. One week to collaboratively design the
              system. One week for people to build their pieces. One week to RITE
              test, and one week to finish bugs. It's breezy, low-stress,
              high-quality, and everything gets done. Very few tasks slip.
              
              If you're fear is that too much can change, then you're moving too
              quickly. If you don't have a couple of months to build, launch, and
              measure a feature, then that feature isn't worthwhile. Why are you
              building it?
              


              You should naturally work however you please, but I read the last paragraph as suggesting other ways of working are ridiculous to you, which is faintly insulting. Also, your conflation of cost and value is disappointing.

              I visited one very successful team that was doing daily releases and brought me in to figure out how to release more often. At the time of my visit, they had circa 30 ongoing experiments. Some would last days, some months. Rather than spending 1 week of 4 getting data, they did it every week. Even going back to weekly iterations would have been a severe blow to the product managers and designers.

              I like the spirit of the RITE method in that it clearly recognizes that shorter feedback loops lead to faster learning. But it's exactly that insight that has pushed me to shift first to weekly iterations and then to a clockless, kanban-style process.

              I should also add that any team that needs to spend 1 week taking out bugs that they spent the last 3 weeks creating probably has a lot of opportunity to improve productivity though quality-focused technical practices.

              William



            • Austin Govella
              ... I apologize for insulting. That wasn t my intent, and I ll try to be more clear in the future. Certainly, other ways of working are not ridiculous to me,
              Message 6 of 9 , Feb 22, 2011
                On Tue, Feb 22, 2011 at 4:21 PM, William Pietri <william@...> wrote:
                >
                >> On 02/22/2011 09:52 AM, Austin Govella wrote:
                >>
                >> If you're fear is that too much can change, then you're moving too
                >> quickly. If you don't have a couple of months to build, launch, and
                >> measure a feature, then that feature isn't worthwhile. Why are you
                >> building it?
                >
                > You should naturally work however you please, but I read the last paragraph
                > as suggesting other ways of working are ridiculous to you, which is faintly
                > insulting. Also, your conflation of cost and value is disappointing.

                I apologize for insulting. That wasn't my intent, and I'll try to be
                more clear in the future.

                Certainly, other ways of working are not ridiculous to me, but the
                rhetorical strategy I used definitely inferred that idea.

                What I was really trying to say:

                What is so important that it can change in less than a month and
                invalidate your work? Also, how often does this type of event happen
                and why? My gut was that the more frequent the change, the less
                significant it likely is, so that specific objection to month-long
                sprints would be a sort of cultural red herring.



                > I visited one very successful team that was doing daily releases and
                > brought me in to figure out how to release more often.... Rather than
                > spending 1 week of 4 getting data, they did it every week.

                In my experience, we needed several days to build the system, several
                days to RITE test, and then several days to build any fixes that were
                not small enough to have already fixed. How does that timeline match
                up with your experience with RITE testing?



                > I should also add that any team that needs to spend 1 week taking
                > out bugs that they spent the last 3 weeks creating probably has a
                > lot of opportunity to improve productivity though quality-focused
                > technical practices.

                I think it was more like three days of scrubbing and then a day
                getting ready for review and retro.

                And these included "polish" bugs like tweaking spacing, colors, event
                durations, labels, as well as any bugs (usually edge cases) and
                performance issues that may have been lingering.

                Again, this was a description of the best teams I'd worked with, and
                the last few days of polish applied really helped move the bar from
                good to great. I would be curious to know whether others have
                dedicated time for "experience polish" like this, and if so, how?



                --
                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
                ... Sorry I misunderstood! ... I can t speak for everybody, but in our case, a lot of that change comes from learning, and we try to force the pace of that as
                Message 7 of 9 , Feb 22, 2011
                  On 02/22/2011 06:25 PM, Austin Govella wrote:
                  I apologize for insulting. That wasn't my intent, and I'll try to be
                  more clear in the future.
                  
                  Certainly, other ways of working are not ridiculous to me, but the
                  rhetorical strategy I used definitely inferred that idea.
                  

                  Sorry I misunderstood!

                  What I was really trying to say:
                  
                  What is so important that it can change in less than a month and
                  invalidate your work? Also, how often does this type of event happen
                  and why? My gut was that the more frequent the change, the less
                  significant it likely is, so that specific objection to month-long
                  sprints would be a sort of cultural red herring.
                  

                  I can't speak for everybody, but in our case, a lot of that change comes from learning, and we try to force the pace of that as much as possible.

                  A good example is YouTube. They can afford to do whatever they want, and they do a variety of traditional user testing. (Last I visited they had not one but two of those fancy one-way mirror rooms for user testing. Plus one or two eye-tracking cameras. I was envious!) They also have a lot of data on existing behavior. But what they really use to make a feature shine is data from actual use of new code.

                  When designing something, they'll say what they expect the results to be in production, and they'll say it numerically. They'll release it to a small fraction of users (say, 1%) and then see what happens. Typically, they will learn something, make changes in response to that, and release again. At least weekly, but more often if they can. (The designers would have released much more frequently, but I gathered infrastructural issues made that hard. ) They keep doing that until they like what they see, at which point they'll bump the traffic and measure again. A given team would have few of these balls in the air at once.


                  So one thing that changes is the data you have, and that's because you go looking for it.

                  Other things I've seen change enough to make month-long iterations painful: competitor behavior, partner behavior, market behavior.

                  Again, this was a description of the best teams I'd worked with, and
                  the last few days of polish applied really helped move the bar from
                  good to great. I would be curious to know whether others have
                  dedicated time for "experience polish" like this, and if so, how?
                  

                  The short-cycle teams I saw doing the best consider polish just a normal part of things. The only time I've seen splitting that out work well is when more data is needed to polish. E.g., user testing, field experience.

                  William
                • William Pietri
                  Hi, Jon! Excellent question. They were indeed adding value. A big reason they were releasing daily was that the product managers were very interested in
                  Message 8 of 9 , Feb 23, 2011
                    Hi, Jon! Excellent question. They were indeed adding value.

                    A big reason they were releasing daily was that the product managers were very interested in whether their improvements actually delivered value to users and to the business. The sooner something was out, the sooner they could start getting data on what it did (or didn't do) for users. Their A/B test dashboard, all built locally, was fantastic.

                    The day I went by they had an all-company meeting (which was maybe 40 people) to present a major improvement in their ability to get user feedback and longitudinal metrics. At a lot of places that'd be a snooze for developers, but that wasn't true there. I think it was because releasing that frequently and working so closely with people who eagerly studied the impact of their work got them similarly interested. Rather than being builders of arbitrary stuff, they were active participants in having an impact on the world.

                    William

                    On 02/22/2011 05:00 PM, Jon Innes wrote:

                    I'd have to ask if they were moving the needle on adding value to customers working at that rate, or just doing a bunch of stuff to feel really busy.

                    If they could actually create measurable value at a release a day, while maintaining quality, and not incurring technical or UX debt, then I'd like to invest in them!

                    Jon

                    On Feb 22, 2011, at 2:21 PM, William Pietri wrote:

                     

                    On 02/22/2011 09:52 AM, Austin Govella wrote:

                    On Sun, Feb 20, 2011 at 4:23 AM, Robin Dymond <robin.dymond@...> wrote:
                    
                    In my opinion 1 month sprints are too long.[...]
                    
                    It's only too long if you don't do three full days of RITE testing two weeks in.
                    
                    The planning is easy: do less. One week to collaboratively design the
                    system. One week for people to build their pieces. One week to RITE
                    test, and one week to finish bugs. It's breezy, low-stress,
                    high-quality, and everything gets done. Very few tasks slip.
                    
                    If you're fear is that too much can change, then you're moving too
                    quickly. If you don't have a couple of months to build, launch, and
                    measure a feature, then that feature isn't worthwhile. Why are you
                    building it?
                    


                    You should naturally work however you please, but I read the last paragraph as suggesting other ways of working are ridiculous to you, which is faintly insulting. Also, your conflation of cost and value is disappointing.

                    I visited one very successful team that was doing daily releases and brought me in to figure out how to release more often. At the time of my visit, they had circa 30 ongoing experiments. Some would last days, some months. Rather than spending 1 week of 4 getting data, they did it every week. Even going back to weekly iterations would have been a severe blow to the product managers and designers.

                    I like the spirit of the RITE method in that it clearly recognizes that shorter feedback loops lead to faster learning. But it's exactly that insight that has pushed me to shift first to weekly iterations and then to a clockless, kanban-style process.

                    I should also add that any team that needs to spend 1 week taking out bugs that they spent the last 3 weeks creating probably has a lot of opportunity to improve productivity though quality-focused technical practices.

                    William




                • Robin Dymond
                  Awesome statement: I think it was because releasing that frequently and working so closely with people who eagerly studied the impact of their work got them
                  Message 9 of 9 , Mar 4, 2011
                    Awesome statement:
                    "I think it was because releasing that frequently and working so closely with people who eagerly studied the impact of their work got them similarly interested. Rather than being builders of arbitrary stuff, they were active participants in having an impact on the world."

                    This is why I care so much about UX, but it seems William and I have very different opinions from many on this list. The value in programming, testing, and UX is in having an impact on the world. The sooner you understand and the better you can measure that impact is THE REASON why short cycles, tight collaboration and speed trump long cycles, silos of UX/dev/test, and long release cycles.

                    Great to hear about You Tube's process. Big names have lots of influence.

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


                    On Wed, Feb 23, 2011 at 11:44 AM, William Pietri <william@...> wrote:
                     

                    Hi, Jon! Excellent question. They were indeed adding value.

                    A big reason they were releasing daily was that the product managers were very interested in whether their improvements actually delivered value to users and to the business. The sooner something was out, the sooner they could start getting data on what it did (or didn't do) for users. Their A/B test dashboard, all built locally, was fantastic.

                    The day I went by they had an all-company meeting (which was maybe 40 people) to present a major improvement in their ability to get user feedback and longitudinal metrics. At a lot of places that'd be a snooze for developers, but that wasn't true there. I think it was because releasing that frequently and working so closely with people who eagerly studied the impact of their work got them similarly interested. Rather than being builders of arbitrary stuff, they were active participants in having an impact on the world.

                    William



                    On 02/22/2011 05:00 PM, Jon Innes wrote:

                    I'd have to ask if they were moving the needle on adding value to customers working at that rate, or just doing a bunch of stuff to feel really busy.

                    If they could actually create measurable value at a release a day, while maintaining quality, and not incurring technical or UX debt, then I'd like to invest in them!

                    Jon

                    On Feb 22, 2011, at 2:21 PM, William Pietri wrote:

                     

                    On 02/22/2011 09:52 AM, Austin Govella wrote:

                    On Sun, Feb 20, 2011 at 4:23 AM, Robin Dymond <robin.dymond@...> wrote:
                    
                    In my opinion 1 month sprints are too long.[...]
                    
                    It's only too long if you don't do three full days of RITE testing two weeks in.
                    
                    The planning is easy: do less. One week to collaboratively design the
                    system. One week for people to build their pieces. One week to RITE
                    test, and one week to finish bugs. It's breezy, low-stress,
                    high-quality, and everything gets done. Very few tasks slip.
                    
                    If you're fear is that too much can change, then you're moving too
                    quickly. If you don't have a couple of months to build, launch, and
                    measure a feature, then that feature isn't worthwhile. Why are you
                    building it?
                    


                    You should naturally work however you please, but I read the last paragraph as suggesting other ways of working are ridiculous to you, which is faintly insulting. Also, your conflation of cost and value is disappointing.

                    I visited one very successful team that was doing daily releases and brought me in to figure out how to release more often. At the time of my visit, they had circa 30 ongoing experiments. Some would last days, some months. Rather than spending 1 week of 4 getting data, they did it every week. Even going back to weekly iterations would have been a severe blow to the product managers and designers.

                    I like the spirit of the RITE method in that it clearly recognizes that shorter feedback loops lead to faster learning. But it's exactly that insight that has pushed me to shift first to weekly iterations and then to a clockless, kanban-style process.

                    I should also add that any team that needs to spend 1 week taking out bugs that they spent the last 3 weeks creating probably has a lot of opportunity to improve productivity though quality-focused technical practices.

                    William





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