InfoQ

InfoQ

News

My Bookmarks

Login or Register to enable bookmarks for unlimited time.

The content has been bookmarked!

There was an error bookmarking this content! Please retry.

Human Computer Interaction (HCI) and Agile compatibility

Posted by Amr Elssamadisy on Jun 19, 2007

Sections
Process & Practices,
Architecture & Design
Topics
Delivering Value ,
Customers & Requirements ,
Delivering Quality ,
Methodologies ,
Agile
Tags
UX ,
Useability ,
HCI ,
Complementary Practices ,
Diversity in Teams

"Design" in the Human Computer Interaction (HCI) world involves working with the user to understand the problem and come up with a user interface – typically on paper - of the entire system before turning it over, in Big Design Upfront (BDUF) manner, to the rest of the development team to build. So how can Robert Biddle claim that HCI has home-grown practices that are very similar to those of Agile?

In a workshop at XP2007, Frank Maurer, Jeff Patton, and Robert Biddle, presented three different views of how HCI and Agile can work together.

Jeff Patton described how his teams ran week-long workshops at the beginning of the release cycle. The goals of these workshops were to elucidate the typical workflow of the user community and produce paper mock-ups of user interfaces. The typical iterative development cycle followed this initial setup. This technique has allowed them to satisfy the end-user as well as the customer/product-owner - which isn't necessarily the case in a classic Agile team.

Frank Maur pointed out that business value does not always equal usability - the Agile notion of "customer/ product owner" is not necessarily the "end-user" of HCI. The Agile customer has the responsibility (and hopefully the ability) to make prioritization decisions and compromises when scheduling the requirements on a backlog and then building them incrementally. The HCI end-user is the person(s) that actually uses the software - HCI professionals work with them by showing them paper mock-ups of the user interface and studying their responses. So although both Agile and HCI are focused on building value, Agile focuses on "business value" while HCI focuses on "end-user usability".

Maur also compared and contrasted several practices between HCI and Agile:

  • HCI experts represent the users in a development team while Agile includes a customer from the business as part of the team.
  • HCI experts are specialists while Agile methods prefer generalists.
  • HCI has upfront UI design, while Agile methods discourage upfront work.
  • Usability comes from the "UI designer" in HCI, while quality is a "whole team" responsibility in Agile.
  • HCI relies on usability testing and collecting metrics, while Agile relies on demonstrating working software.

Robert Biddle and his students have studied several Agile teams where HCI was a component. They found that the UI design produced by the HCI group was done iteratively with feedback from the users. The iterations used many paper mock-ups at a time (set-based development) and resulted in a final set of UI specifications that were handed over to the development team. The development team proceeded to develop the work using Agile practices while the HCI experts were available for conversations on an as-need basis. They were open to technical feedback from the development team and alternative suggestions. So, although the main UI design was BDUF, it was not set-in-stone. These were observations of how work is done today. Biddle sees a large opportunity for the HCI and Agile worlds to come together. They are both user-focused. They are both iterative and responsive to feedback from the iterations.

So there are many differences and mismatches between HCI and Agile practices, yet they share the values of user-focus and iterative inspect-and-adapt cycles. Agile methods might benefit from including HCI experts as part of the "whole team", but there are many challenges that must be overcome.

  • This article is part of a featured topic series on Agile

Related Sponsor

In today’s hyper-competitive world, later may be too late to adopt Agile development and this Roadmap for Success will help you get started. Download "Agile Development: A Manager's Roadmap for Success" now!

There's interest in harmonizing the two worlds, for sure by Deborah Hartmann Posted
More Agile for HCI experts to be in the development team from day one by Angus McDonald Posted
Re: More Agile for HCI experts to be in the development team from day one by Gudlaugur Egilsson Posted
Re: More Agile for HCI experts to be in the development team from day one by Amr Elssamadisy Posted
Re: More Agile for HCI experts to be in the development team from day one by Amr Elssamadisy Posted
Alan Cooper? by Steven Devijver Posted
Re: Alan Cooper? by Amr Elssamadisy Posted
  1. Back to top

    There's interest in harmonizing the two worlds, for sure

    by Deborah Hartmann

    "Agile & Usability" was a popular topic when I ran a session to discuss it recently at InteractionCamp in Toronto (BarCamp for the UX crowd). In the short time we had, there were no answers, just lots and lots of questions... and I hear echoes of this elsewhere regularly, notably at Qcon, but also in the Web 2.0 crowd's blogs etc.

  2. Back to top

    More Agile for HCI experts to be in the development team from day one

    by Angus McDonald

    Wouldn't it be closer to good Agile principles for the HCI experts to be part of the development team all the way through? They might need to be multi-skilled so that HCI wasn't the only thing they do (testing comes to mind), but that would prevent the handoff problems that arise from a "final set of UI specifications that were handed over to the development team."

    Surely one of the lessons of Agile development is that the team should not be separated into silos by specialty, but should instead be allowed as a group to find the best way to provide the solution?

    Either HCI people should be used to train the development team in HCI considerations, or HCI specialists should acquire more general development skills so as to be more useful in the development team.

  3. Back to top

    Re: More Agile for HCI experts to be in the development team from day one

    by Gudlaugur Egilsson

    Lean ideas come in strong here. The scenario described above is very lean in many ways, defer committment on UI and set based development for instance. I believe this is also very compatible with TDD practices using tools like Fitnesse, where you don't implement an actual user interface, but an automated test interface with fixed inputs/outputs instead. This would allow a HCI design to take place, preferrably in a set based manner, and only implement a real UI relatively late in the process, but then against a thoroughly tested API.

    The tough decision here is obviously how long you can defer commitment to a UI. Delivering value is paramount for agile/lean processes, and must not be deferred for long, as that too is expensive. So the value of an optimal UI design must be weighted against the cost of unused software in development.

    Regarding specialties, when given two good choices, take both. The role of specialists on an agile team is to raise the bar in their area of expertise. But specialists who can't cross the bar in other areas have no place on an agile team.

  4. Back to top

    Re: More Agile for HCI experts to be in the development team from day one

    by Amr Elssamadisy


    Wouldn't it be closer to good Agile principles for the HCI experts to be part of the development team all the way through?


    It would from an Agile perspective. I am no HCI expert, so I will relate the information that was related in the session:

    1)Robert Biddle's group studied how teams currently work - they do not work that way. But, it is not a 'throw over the fence' mentality. They stay with the team and evolve the design as the team learns.

    2) Jeff Patton's teams do exactly as you suggest. The paper exercise is only in the beginning.

    3) I know about other teams that have an HCI member and they periodically (every several iteration) bring in users and run experiments in true HCI form.

  5. Back to top

    Re: More Agile for HCI experts to be in the development team from day one

    by Amr Elssamadisy


    Wouldn't it be closer to good Agile principles for the HCI experts to be part of the development team all the way through?


    AMEN!

  6. Back to top

    Alan Cooper?

    by Steven Devijver

    I suggest to consider what Alan Cooper has to say about developing user interface software. I'm not saying he's god and always right. On the contrary.

    He has so many interesting things to say however that not taking at least some of them into account - for example by refuting them - doesn't seem to feel right.

  7. Back to top

    Re: Alan Cooper?

    by Amr Elssamadisy

    If it cam out that I was dismissing Alan Cooper, then I apologize. Alan Cooper is considered the father of Interaction Design much like Kent Beck is considered the father of XP. They had an interesting debate a while back here www.ftponline.com/interviews/beck_cooper/ .

    The point that impressed me in attending this workshop was that HCI and Agile really have much in common in terms of goals and that some in the field are trying to bring the two together for more 'value to the customer'.

Educational Content

New-age Transactional Systems - Not Your Grandpa's OLTP

John Hugg discusses high volume transaction processing applications with high and low frequency profiles, and how VoltDB can be used for that purpose.

Cool Code

Kevlin Henney examines code samples to see what can be learned from them starting from the premise that one won’t write great code unless he knows how to read it.

Collaboration: At the Extremities of Extreme

Jason Ayers share the observations he made watching a team of developers collaborating in real time on the same code base, pushing XP, pair programming and continuous integration to their extremes.

Yesod Web Framework

Michael Snoyman presents Yesod, a web framework written in Haskell and containing a web server, templating, ORM, libraries (templating, gravatar, etc.).

Transactions without Transactions

Richard Kreuter and Kyle Banker on how to avoid classical RDBMS transactional systems by using compensation mechanisms, transactional messaging or transactional procedures.

Attila Szegedi on JVM and GC Performance Tuning at Twitter

Attila Szegedi talks about performance tuning Java and Scala programs at Twitter: how to approach GC problems, the importance of asynchronous I/O, when to use MySQL/Cassandra/Redis, and much more.

10 tips on how to prevent business value risk

One category of risk that project teams need to ensure they address is business value failure – delivering a product that fails to provide value for the business investor.

Interview: Software Systems Architecture: Working With Stakeholders Using Viewpoints and Perspectives

InfoQ spoke to the authors of Software Systems Architecture on a couple of new topics, the System Context viewpoint and Agile, which have been added to the second edition.