Re: Integrated Usability in Agile teams from the trenches :)
- 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
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
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
>> 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
Sent from my mobile device
Robin Dymond, CST
Managing Partner, Innovel, LLC.
Americas: (804) 239-4329
Europe: +32 489 674 366
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.
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.