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

Integrated Usability in Agile teams from the trenches :)

Expand Messages
  • Robin Dymond
    I recently replied to someone on linked in who was having trouble integrating UX people into an Agile team. Below is my step by step reply on how to do UX in
    Message 1 of 10 , Feb 2, 2011
    View Source
    • 0 Attachment
      I recently replied to someone on linked in who was having trouble integrating UX people into an Agile team. Below is my step by step reply on how to do UX in an Agile manner. I'd be interested in hearing your thoughts on this pattern.

      I was a technology Director in a large web design company 6 years ago, and they failed at adopting Agile for the reasons you mention. Primarily it was a case of not wanting reality to hinder the pretty designs they were making in photoshop or Illustrator. Of course there were huge issues when these artifacts met the reality of enterprise architectures on the development floor. This resulted in missed deadlines, high stress, low code quality, and 40% annual turnover in IT staff. Being at this company spurred my interest in UX and Agile, and I have since found basic solutions that work when people want to do Agile. However I would say that of all the disciplines in creating software and especially web sites, UX people are the slowest and most resistant to adopting Agile principles and practices.

      Here is the way I work with UI designers and Information architects who want to work Agile:
      1. Product backlog and its priorities drives all the work. So we work from business priorities not UI priorities.
      2. Sketch the highest level level UI for the site. no drill downs into buy flows, just top level.
      3. Look at the backlog and start thinking about what the team will need for UI 1/2 an iteration ahead.
      4. Make paper prototypes (sketches, paper menus, paper buttons) to support upcoming user stories for next sprint. Don't embellish with new features UX thinks would be cool. KISS. Include validation and other acceptance criteria for fields. Reference style guide as required. Reference page templates as required. I call this a 1 page design spec.
      5. Review prototypes with PO, QA and lead dev a few days before sprint planning, ensure they think it is good enough and it is testable. Keep notes regarding potential trade offs.
      5a. Check in design docs, version them.
      6. Participate in sprint planing with rest of team.
      7. Work with team on implementation, clarify details of design (dimensions, locations, behavior, etc.). Work with QA on test plans for new UI. Help build UI (HMTL/CSS/PHP/etc) in dev IDE, pair with dev as they wire it up. Pair with QA to run test cases and implement automated UI testing (Ruby/WATIR, etc).
      8. repeat for every sprint.

      Additional stuff I think is needed.
      - Create a style guide for the team and have them read it, listen to their feedback and improve it.
      - Create templates: every page is not a unique creation. Refer to those templates in prototypes and design spec.
      - Test your paper prototypes with users by asking them to do certain operations and then observing the resulting actions. Don't worry about big usability testing at end, do it often and informally with people who are easy to access and know enough about that business.
      - Break dependencies between UI/layout and business logic. agree on data/fields/controls at beginning so business logic can be rendered to a very simple layout free page.

      An unstable UI design is usually driven by a lack of knowledge about the customer requirements and technical limitations. The product backlog is probably not in very good shape so the UI person has to go find out a lot of detail to create the design. The UI designer is likely having to make up for lack knowledge in the PO.

      ...and avoid iRise and its ilk!!!

      I hope this helps,
      Robin Dymond. CST

    • Robin Dymond
      I recently replied to someone on a Linkedin group who was having trouble integrating UX people into an Agile team. Below is my step by step reply on how to do
      Message 2 of 10 , Feb 2, 2011
      View Source
      • 0 Attachment
        I recently replied to someone on a Linkedin group who was having trouble integrating UX people into an Agile team. Below is my step by step reply on how to do UX in an Agile manner. I'd be interested in hearing your thoughts on this pattern.

        I was a technology Director in a large web design company 6 years ago, and they failed at adopting Agile for the reasons you mention. Primarily it was a case of not wanting reality to hinder the pretty designs they were making in photoshop or Illustrator. Of course there were huge issues when these artifacts met the reality of enterprise architectures on the development floor. This resulted in missed deadlines, high stress, low code quality, and 40% annual turnover in IT staff. Being at this company spurred my interest in UX and Agile, and I have since found basic solutions that work when people want to do Agile. However I would say that of all the disciplines in creating software and especially web sites, UX people are the slowest and most resistant to adopting Agile principles and practices.

        Here is the way I work with UI designers and Information architects who want to work Agile:
        1. Product backlog and its priorities drives all the work. So we work from business priorities not UI priorities.
        2. Sketch the highest level level UI for the site. no drill downs into buy flows, just top level.
        3. Look at the backlog and start thinking about what the team will need for UI 1/2 an iteration ahead.
        4. Make paper prototypes (sketches, paper menus, paper buttons) to support upcoming user stories for next sprint. Don't embellish with new features UX thinks would be cool. KISS. Include validation and other acceptance criteria for fields. Reference style guide as required. Reference page templates as required. I call this a 1 page design spec.
        5. Review prototypes with PO, QA and lead dev a few days before sprint planning, ensure they think it is good enough and it is testable. Keep notes regarding potential trade offs.
        5a. Check in design docs, version them.
        6. Participate in sprint planing with rest of team.
        7. Work with team on implementation, clarify details of design (dimensions, locations, behavior, etc.). Work with QA on test plans for new UI. Help build UI (HMTL/CSS/PHP/etc) in dev IDE, pair with dev as they wire it up. Pair with QA to run test cases and implement automated UI testing (Ruby/WATIR, etc).
        8. repeat for every sprint.

        Additional stuff I think is needed.
        - Create a style guide for the team and have them read it, listen to their feedback and improve it.
        - Create templates: every page is not a unique creation. Refer to those templates in prototypes and design spec.
        - Test your paper prototypes with users by asking them to do certain operations and then observing the resulting actions. Don't worry about big usability testing at end, do it often and informally with people who are easy to access and know enough about that business.
        - Break dependencies between UI/layout and business logic. agree on data/fields/controls at beginning so business logic can be rendered to a very simple layout free page.

        An unstable UI design is usually driven by a lack of knowledge about the customer requirements and technical limitations. The product backlog is probably not in very good shape so the UI person has to go find out a lot of detail to create the design. The UI designer is likely having to make up for lack knowledge in the PO.

        ...and avoid iRise and its ilk!!!

        I hope this helps,
        Robin Dymond. CST


      • SvetlanaTsikoza
        Thank you very much for sharing your experience. It is very useful. The comment about iRise made me smile :-) Let me shake your hand, comrade.
        Message 3 of 10 , Feb 3, 2011
        View Source
        • 0 Attachment
          Thank you very much for sharing your experience. It is very useful. The comment about iRise made me smile :-) Let me shake your hand, comrade.

          --- In agile-usability@yahoogroups.com, Robin Dymond <robin.dymond@...> wrote:
          >
          > I recently replied to someone on linked in who was having trouble
          > integrating UX people into an Agile team. Below is my step by step reply on
          > how to do UX in an Agile manner. I'd be interested in hearing your thoughts
          > on this pattern.
          >
          > I was a technology Director in a large web design company 6 years ago, and
          > they failed at adopting Agile for the reasons you mention. Primarily it was
          > a case of not wanting reality to hinder the pretty designs they were making
          > in photoshop or Illustrator. Of course there were huge issues when these
          > artifacts met the reality of enterprise architectures on the development
          > floor. This resulted in missed deadlines, high stress, low code quality, and
          > 40% annual turnover in IT staff. Being at this company spurred my interest
          > in UX and Agile, and I have since found basic solutions that work when
          > people want to do Agile. However I would say that of all the disciplines in
          > creating software and especially web sites, UX people are the slowest and
          > most resistant to adopting Agile principles and practices.
          >
          > Here is the way I work with UI designers and Information architects who want
          > to work Agile:
          > 1. Product backlog and its priorities drives all the work. So we work from
          > business priorities not UI priorities.
          > 2. Sketch the highest level level UI for the site. no drill downs into buy
          > flows, just top level.
          > 3. Look at the backlog and start thinking about what the team will need for
          > UI 1/2 an iteration ahead.
          > 4. Make paper prototypes (sketches, paper menus, paper buttons) to support
          > upcoming user stories for next sprint. Don't embellish with new features UX
          > thinks would be cool. KISS. Include validation and other acceptance criteria
          > for fields. Reference style guide as required. Reference page templates as
          > required. I call this a 1 page design spec.
          > 5. Review prototypes with PO, QA and lead dev a few days before sprint
          > planning, ensure they think it is good enough and it is testable. Keep notes
          > regarding potential trade offs.
          > 5a. Check in design docs, version them.
          > 6. Participate in sprint planing with rest of team.
          > 7. Work with team on implementation, clarify details of design (dimensions,
          > locations, behavior, etc.). Work with QA on test plans for new UI. Help
          > build UI (HMTL/CSS/PHP/etc) in dev IDE, pair with dev as they wire it up.
          > Pair with QA to run test cases and implement automated UI testing
          > (Ruby/WATIR, etc).
          > 8. repeat for every sprint.
          >
          > Additional stuff I think is needed.
          > - Create a style guide for the team and have them read it, listen to their
          > feedback and improve it.
          > - Create templates: every page is not a unique creation. Refer to those
          > templates in prototypes and design spec.
          > - Test your paper prototypes with users by asking them to do certain
          > operations and then observing the resulting actions. Don't worry about big
          > usability testing at end, do it often and informally with people who are
          > easy to access and know enough about that business.
          > - Break dependencies between UI/layout and business logic. agree on
          > data/fields/controls at beginning so business logic can be rendered to a
          > very simple layout free page.
          >
          > An unstable UI design is usually driven by a lack of knowledge about the
          > customer requirements and technical limitations. The product backlog is
          > probably not in very good shape so the UI person has to go find out a lot of
          > detail to create the design. The UI designer is likely having to make up for
          > lack knowledge in the PO.
          >
          > ...and avoid iRise and its ilk!!!
          >
          > I hope this helps,
          > Robin Dymond. CST
          >
        • unbreakablepo
          Can you (or others) comment more about iRise and other interaction design tools? We are considering a very similar process to the one you described with paper
          Message 4 of 10 , Feb 5, 2011
          View Source
          • 0 Attachment
            Can you (or others) comment more about iRise and other interaction design tools? We are considering a very similar process to the one you described with paper prototypes, etc but are also thinking about using light weight "click-throughs" using Adobe Fireworks / Flash Catalyst to get feedback without needing to use our limited development team time.

            My assumption is that we must include developers in discussions of feasibility etc. Have people run into major problems with this?
          • William Pietri
            ... I have no idea if our situation applies to anybody else, but my (non-technical) partner will whip together clickable mockups in OmniGraffle for certain
            Message 5 of 10 , Feb 6, 2011
            View Source
            • 0 Attachment
              On 02/05/2011 02:07 PM, unbreakablepo wrote:
              Can you (or others) comment more about iRise and other interaction design tools?  We are considering a very similar process to the one you described with paper prototypes, etc but are also thinking about using light weight "click-throughs" using Adobe Fireworks / Flash Catalyst to get feedback without needing to use our limited development team time.
              
              My assumption is that we must include developers in discussions of feasibility etc.  Have people run into major problems with this?
              
              

              I have no idea if our situation applies to anybody else, but my (non-technical) partner will whip together clickable mockups in OmniGraffle for certain sorts of user testing. In cases where we need a little more functionality we'll go straight from whiteboard sketches or handwaving to simple HTML/CSS/JS mockups, often with an assist from a visual designer. If we need to mutate an existing site, we'll sometimes use Greasemonkey.

              All of these happen only when we need to test some particular interface hypothesis with live people in controlled conditions. For testing more complicated things, we build simple fakes or prototypes and run real traffic against them (sometimes from ads, sometimes user testers, sometimes known people).

              To me as a developer, the main advantage of OmniGraffle is that it lets my partner noodle with an idea without me being a bottleneck. But I've worked hard to become better at just banging out throw-away test prototypes, because I think we get more interesting data out of them. Thanks to the rise of CSS and tools like jQuery and Rails, I think the cost of those prototypes has declined a lot, and when it comes time to build more real things, I definitely appreciate the insight I've gained from working on the research.

              So as we grow, I'm going to try to find ways to keep design and development as tightly integrated as they are now.

              William

            • mattspost77
              I have a number of strong reservations regarding this article, especially about the apparent lack of understanding for the UI and UX aspects of any design work
              Message 6 of 10 , Feb 10, 2011
              View Source
              • 0 Attachment
                I have a number of strong reservations regarding this article, especially about the apparent lack of understanding for the UI and UX aspects of any design work within a project, when it is involved in the Agile process.

                To just pull out a few lines from the article:

                "Primarily it was a case of not wanting reality to hinder the pretty designs they were making in photoshop or Illustrator"

                I think this is a facetious statement by Robin Dymond who misses the point of the design and UI role. His stand point seems to be one that values code and speed of work over design without, it seems, understanding or appreciating the value that design has both for the customer and the business.

                A customer/user goes to a website and within 3 seconds makes up their mind that the site is trustworthy, of quality, aspirational or best in class because of the visual impression the site gives them. A website / 'Shop front' is reliant on design (UI and UX) to draw those feelings and emotions from a person, lead them to purchase and ultimately reassure them that what they are purchasing and who they are purchasing from is of the best quality.
                'Product personality' influences and affects our perceptions. You get drawn into a shop on the high street or mall as what it's showing you is appealing and is stimulating your senses, the shop front / window is working hard selling you the product before you even enter the store, at the same time it has to convince and reassure you that it is better than the other shop selling near enough the same product just next door. It really isn't because you think it has amazing cash registers or the best 'chip and pin' machines..
                Is it possible to imagine a car manufacturer designing an amazing engine and chassis, best in class even, only then to put a second rate body on it or the controls in an awkward place for the driver.. And then still expect people to buy it or aspire to own it just because it has an amazing engine and chassis? No probably not. So attention to detail and good design is by no means a hinderance to the process, its an important and integral part of the business, user experience and emotion / reassurance felt by the customer.

                Lets take the term 'pretty' and replace it with Aesthetics. Now it has nothing to do with 'pretty' - It has everything to do with aesthetics. Stephen P. Anderson wrote in the article "In Defense of Eye Candy" that "Aesthetics is not just about artistic merit of web buttons or other visual effects, but about how people respond to these elements. The question becomes: how do aesthetic design choices influence understanding and emotions, and how do understanding and emotions influence behaviour?" For the answer I would suggest you read his article: http://www.alistapart.com/articles/indefenseofeyecandy
                What we need to understand is that its not about something being 'pretty', but as user experience professionals, we must consider every stimulus that influences interactions, so it has everything to do with appeal, trust, quality, reassurance, aspiration and more. Without which, products wouldn't sell, people would choose an alternative 'shop front' and ultimately become loyal customers elsewhere.

                - I would like to add, that design isn't something that just 'happens', it takes time. It is something that has to be thought about, researched, understood, created and designed. None of these parts are done in an instant, they all take time to get right. - This is something that this article ignores.


                "UX people are the slowest and most resistant to adopting Agile principles and practices"
                - 'UX people' are probably the slowest and most resistant because they are constantly seeing and thinking about things from the customer / user perspective, and anything that is unproven in their eyes or introduced that is radically different, potentially lessening the quality of the UX, at the expense of getting something out quicker, will not be greeted with open arms, unless it is clear that it is at least as good as the process currently in place.


                "Don't embellish with new features UX thinks would be cool"
                - Robin Dymond's negative attitude towards UX improvements is really un-constructive. 'New features' are always going to be introduced, not because they are considered 'cool' but because they improve the experience for the user / customer! If new features weren't introduced, then websites would be stuck in the 1990's with left aligned, vertical sidebar navigation and no real thought about what is best for the customer / user.


                "An unstable UI design is usually driven by a lack of knowledge about the customer requirements and technical limitations."

                - Could the 'lack of knowledge about the customer requirements' be due to rushing through the process, without being able to thoroughly research or think about the UI (or even UX) from a customer perspective? Anyone (hopefully) who designs for the user would have the knowledge and understanding of what 'ingredients' are needed to create an easy to use UI, whilst giving it the look and feel that reassures the customer that the site is one of quality.


                My final thought about this article is this… "Designing a product is designing a relationship"

                "Designing a product is designing a relationship" - The product in this situation is our website – our "Shop front". That is what our customers and potential customers base their initial feelings / emotions on, feelings of trust, quality, reassurance. If they don't get those emotions then our 'audience' is harder to convince that we are the right business insurance place for them.


                I'm open and accepting to the Agile process, though my concern as both a web and UX designer is that if we're not careful we will end up with a 'patchwork quilt' of a website, which lacks consistency and has a poor customer / user experience.
              • William Pietri
                Hi, Matt! Welcome to the group. I get the impression that you have misunderstood Robin s intent. I think his concerns about behaviors that some UX people have
                Message 7 of 10 , Feb 11, 2011
                View Source
                • 0 Attachment
                  Hi, Matt! Welcome to the group.

                  I get the impression that you have misunderstood Robin's intent. I think his concerns about behaviors that some UX people have when confronted with Agile approaches is reasonable. Perhaps you could suppose that he values UX as much as you but still said the things he did? He's been participating here since 2004, so I figure he has to care about the UX.

                  My startup does consumer web stuff, and these days that lives and dies by the user experience. Two hours ago we finished some user tests on particular bits of the UI. One hour ago I was revising the UI based on the feedback. Shortly I'll release it into production, and Monday morning we'll do user tests on the new UI. To people from a traditional waterfall design background I'm sure that sounds insane, but in our view, it's far more effective at creating good experiences. My concern about Robin's approach isn't that it's too fast; it's that it's too slow.

                  William



                  On 02/10/2011 05:05 AM, mattspost77 wrote:
                  
                  I have a number of strong reservations regarding this article, especially about the apparent lack of understanding for the UI and UX aspects of any design work within a project, when it is involved in the Agile process.
                   
                  To just pull out a few lines from the article:
                   
                  "Primarily it was a case of not wanting reality to hinder the pretty designs they were making in photoshop or Illustrator"
                   
                  I think this is a facetious statement by Robin Dymond who misses the point of the design and UI role. His stand point seems to be one that values code and speed of work over design without, it seems, understanding or appreciating the value that design has both for the customer and the business.
                   
                  A customer/user goes to a website and within 3 seconds makes up their mind that the site is trustworthy, of quality, aspirational or best in class because of the visual impression the site gives them. A website / 'Shop front' is reliant on design (UI and UX) to draw those feelings and emotions from a person, lead them to purchase and ultimately reassure them that what they are purchasing and who they are purchasing from is of the best quality.
                  'Product personality' influences and affects our perceptions. You get drawn into a shop on the high street or mall as what it's showing you is appealing and is stimulating your senses, the shop front / window is working hard selling you the product before you even enter the store, at the same time it has to convince and reassure you that it is better than the other shop selling near enough the same product just next door. It really isn't because you think it has amazing cash registers or the best 'chip and pin' machines..
                  Is it possible to imagine a car manufacturer designing an amazing engine and chassis, best in class even, only then to put a second rate body on it or the controls in an awkward place for the driver.. And then still expect people to buy it or aspire to own it just because it has an amazing engine and chassis? No probably not. So attention to detail and good design is by no means a hinderance to the process, its an important and integral part of the business, user experience and emotion / reassurance felt by the customer.
                   
                  Lets take the term 'pretty' and replace it with Aesthetics. Now it has nothing to do with 'pretty' - It has everything to do with aesthetics. Stephen P. Anderson wrote in the article "In Defense of Eye Candy" that "Aesthetics is not just about artistic merit of web buttons or other visual effects, but about how people respond to these elements. The question becomes: how do aesthetic design choices influence understanding and emotions, and how do understanding and emotions influence behaviour?" For the answer I would suggest you read his article: http://www.alistapart.com/articles/indefenseofeyecandy
                  What we need to understand is that its not about something being 'pretty', but as user experience professionals, we must consider every stimulus that influences interactions, so it has everything to do with appeal, trust, quality, reassurance, aspiration and more. Without which, products wouldn't sell, people would choose an alternative 'shop front' and ultimately become loyal customers elsewhere.
                   
                  - I would like to add, that design isn't something that just 'happens', it takes time. It is something that has to be thought about, researched, understood, created and designed. None of these parts are done in an instant, they all take time to get right. - This is something that this article ignores.
                   
                   
                  "UX people are the slowest and most resistant to adopting Agile principles and practices"
                  - 'UX people' are probably the slowest and most resistant because they are constantly seeing and thinking about things from the customer / user perspective, and anything that is unproven in their eyes or introduced that is radically different, potentially lessening the quality of the UX, at the expense of getting something out quicker, will not be greeted with open arms, unless it is clear that it is at least as good as the process currently in place. 
                   
                   
                  "Don't embellish with new features UX thinks would be cool"
                  -  Robin Dymond's negative attitude towards UX improvements is really un-constructive. 'New features' are always going to be introduced, not because they are considered 'cool' but because they improve the experience for the user / customer! If new features weren't introduced, then websites would be stuck in the 1990's with left aligned, vertical sidebar navigation and no real thought about what is best for the customer / user.
                   
                   
                  "An unstable UI design is usually driven by a lack of knowledge about the customer requirements and technical limitations."
                   
                  - Could the 'lack of knowledge about the customer requirements' be due to rushing through the process, without being able to thoroughly research or think about the UI (or even UX) from a customer perspective? Anyone (hopefully) who designs for the user would have the knowledge and understanding of what 'ingredients' are needed to create an easy to use UI, whilst giving it the look and feel that reassures the customer that the site is one of quality.
                   
                   
                  My final thought about this article is this…  "Designing a product is designing a relationship"
                   
                  "Designing a product is designing a relationship" - The product in this situation is our website – our "Shop front". That is what our customers and potential customers base their initial feelings / emotions on, feelings of trust, quality, reassurance. If they don't get those emotions then our 'audience' is harder to convince that we are the right business insurance place for them.
                   
                   
                  I'm open and accepting to the Agile process, though my concern as both a web and UX designer is that if we're not careful we will end up with a 'patchwork quilt' of a website, which lacks consistency and has a poor customer / user experience.
                  
                  
                  
                  
                  ------------------------------------
                  
                  Yahoo! Groups Links
                  
                  <*> To visit your group on the web, go to:
                      http://groups.yahoo.com/group/agile-usability/
                  
                  <*> Your email settings:
                      Individual Email | Traditional
                  
                  <*> To change settings online go to:
                      http://groups.yahoo.com/group/agile-usability/join
                      (Yahoo! ID required)
                  
                  <*> To change settings via email:
                      agile-usability-digest@yahoogroups.com 
                      agile-usability-fullfeatured@yahoogroups.com
                  
                  <*> To unsubscribe from this group, send an email to:
                      agile-usability-unsubscribe@yahoogroups.com
                  
                  <*> Your use of Yahoo! Groups is subject to:
                      http://docs.yahoo.com/info/terms/
                  
                  

                • Austin Govella
                  ... I would love to see an article on his concerns about behaviors that some developers have when confronted with UX. -- Austin Govella User Experience Work:
                  Message 8 of 10 , Feb 11, 2011
                  View Source
                  • 0 Attachment
                    On Fri, Feb 11, 2011 at 8:08 PM, William Pietri <william@...> wrote:
                    > I get the impression that you have misunderstood Robin's intent. I think his
                    > concerns about behaviors that some UX people have when confronted with
                    > Agile approaches is reasonable.

                    I would love to see an article on his concerns about behaviors that
                    some developers have when confronted with UX.





                    --
                    Austin Govella
                    User Experience

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

                    austin@...
                    215-240-1265
                  • Robin Dymond
                    Hi Matt, (Warning long post, no time to shorten) I simply don t see a difference between the contributions of UI, dev, test, db, etc. I could make persuasive
                    Message 9 of 10 , Feb 16, 2011
                    View Source
                    • 0 Attachment
                      Hi Matt,

                      (Warning long post, no time to shorten)

                      I simply don't see a difference between the contributions of UI, dev,
                      test, db, etc. I could make persuasive arguments that would emphasize
                      the importance of any of these activities over the others. The reality
                      is we need all of these activities together to deliver excellent
                      products. The higher the level of understanding in the team of each
                      other's contributions the more effective the team. I am critiquing the
                      common misconception that it is only possible to do UI in one way,
                      before development. Its not true, and the result is a less effective
                      development process. The arguments you make are the same arguments
                      traditional QA managers make to keep testing at the end of the
                      project. They are the arguments Database developers use to justify for
                      building and optimizing the whole data model before developers start
                      on the server.
                      A high res UI in irise is about as useful as an L1 normed database
                      model. Both are local optimizations, and neither are useful to a
                      customer. Both contain major assumptions and do not consider the
                      constraints imposed by the operational context of the system. Worse,
                      because both appear "done" they cause problems managing stake holder
                      expectations.

                      True story: A Bank I consulted on Agile hired a Boston Consulting guy
                      to help them with their web presence. He baffled many VPs with his
                      ideas on users, terms like user anthropology and ethnocentric bla bla
                      were bandied about. He convinced management that a UI team was needed
                      to create the user experience. I warned the scrummaster of the issues,
                      but she didn't have the clout and I was in another group. They used
                      Scrum and every 2 weeks they delivered screens in irise. They ran for
                      around 10 sprints before they declared that they were done. They
                      demoed their UI concept to many high level managers who then offered
                      lots of opinions on the colors that needed to be changed and things
                      that needed to be re-arranged.

                      4 months later the same managers were wondering why the new UI wasn't
                      up. They had been told that there was no backend, however they had
                      seen the UI.

                      The backend reality was many disparate systems for loans, savings,
                      credit cards, mortgage, investments, etc. The reality was that large
                      data warehouses needed to be created to isolate the web from the
                      backend complexity. The reality is syncing warehouses and systems
                      created constraints that were not accounted for in the UI. When the
                      first version of the site was released many of the stakeholders were
                      disappointed. The reality was a major feat had been accomplished,
                      however the stakeholders had approved a UI concept, and the first
                      release needed a different UI solution that took into account the
                      constraints of the bank's operations.

                      Was there some value in the 3 months of UI design? Sure. However that
                      value could have been captured with much less investment, much
                      quicker, and with a better result if the teams had been delivering
                      working tested software every sprint. stakeholders and VPs would have
                      had better insight and could have contributed more effectively if they
                      had seen the system evolve instead of seeing only a completed UI
                      concept.

                      Cheers,
                      Robin.

                      On 2/12/11, Austin Govella <austin.govella@...> wrote:
                      > On Fri, Feb 11, 2011 at 8:08 PM, William Pietri <william@...> wrote:
                      >> I get the impression that you have misunderstood Robin's intent. I think
                      >> his
                      >> concerns about behaviors that some UX people have when confronted with
                      >> Agile approaches is reasonable.
                      >
                      > I would love to see an article on his concerns about behaviors that
                      > some developers have when confronted with UX.
                      >
                      >
                      >
                      >
                      >
                      > --
                      > Austin Govella
                      > User Experience
                      >
                      > Work: http://www.grafofini.com
                      > Blog: http://www.thinkingandmaking.com
                      >
                      > austin@...
                      > 215-240-1265
                      >

                      --
                      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
                    • William Pietri
                      ... Yes! I used to have a collection of diagrams that showed the proper relationship between different specialties on a software project. They were made by all
                      Message 10 of 10 , Feb 17, 2011
                      View Source
                      • 0 Attachment
                        On 02/16/2011 05:38 AM, Robin Dymond wrote:
                        I simply don't see a difference between the contributions of UI, dev,
                        test, db, etc. I could make persuasive arguments that would emphasize
                        the importance of any of these activities over the others. The reality
                        is we need all of these activities together to deliver excellent
                        products.

                        Yes!

                        I used to have a collection of diagrams that showed the proper relationship between different specialties on a software project. They were made by all sorts of people.

                        As you would expect, the diagrams varied wildly. But they had one thing in common: the author's specialty was the most special. Maybe they were central. Maybe they came first. Maybe they got final approval. Maybe all of those! But their basic point was that if only they were in charge, everything would go swimmingly.

                        I say it's all bunk, and that whole projects require whole teams.

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