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

Re: Integrated Usability in Agile teams from the trenches :)

Expand Messages
  • 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 1 of 10 , Feb 16 5:38 AM
    • 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 2 of 10 , Feb 17 12:02 PM
      • 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.