agile usability goldfish bowl session
My name is Dina Salah. I am a PhD student at the university of york, UK doing a PhD on agile and user centred design integration.
I am moderating an agile usability goldfish bowl session, on the 15th of Dec at 10:15-11:00 , at the university of York.
I will act as the session moderator and i was wondering if any of you would be interested to be one of the participants.
The ideal participant is as follows:
1) someone with experience in working either as a software developer in agile projects or as a user experience team member in an agile project that was attempting to integrate agile and usability / user experience.
2) Have questions regarding how to achieve agile UCD integration
3) Have answers regarding how to achieve agile UCD integration
The main aim is to discuss agile ucd integration issues, including success stories, failure stories, lessons learned, obstacles, etc.
if u are interested to join us, kindly send me an email dsalah@...
Kindly find below the details related to goldfish bowl sessions
Goldfish bowls provide broad-ranging discussion on a general topic. The session organizer can act as a facilitator, scribe, audience member or active participant in the goldfish bowl.
A goldfish bowl is a bit like a panel discussion, but the people on the panel change during the discussion. The rules are:
- start with a small circle or semi-circle of about 5 chairs in the middle of the room;
- arrange all the other chairs facing towards these, so you have several concentric circles;
- the goldfish bowl has a topic which is usually quite broad, and the organizer usually asks two or three people to get the discussion started and explains the rules to the audience;
- during the discussion, anyone sitting on one of the central chairs can speak, but no-one else can;
- if someone wants to speak, they have to sit on one of the central chairs, even if it’s just to ask a question;
- one of the central chairs is always kept free for this purpose;
- whenever all of the central chairs are occupied, at least one person has to leave to create a new vacant chair.
Unlike a panel, it is usually self-moderating, and most goldfish bowls have a scribe or sound recorder to record the proceedings.
I work at a medium sized company. We have three designers and five developers, all who sit in close confines. From reading the posts lately I wonder if we handle design and development differently.
It seems (and I may be horribly wrong) that the arguments are mainly against big, up front design. I absolutely agree. However, I don't think that having designers do designs prior to development is a bad thing, if done well and there's plenty of communication.
We have one month release cycles, which means we're getting real, working software into our clients hands very quickly, and get feedback quickly as well. We do paired design, so two designers will sit down and shake out most of the design. This can take anywhere from a day to a week and a half depending on the size of the story. During this time we meet with developers several times so they know where the design is going, point out technical road blocks, and yes, give design input. Then we hand it over to get coded, and during this time the designers work closely with the developer who's handling the story to answer questions and work out real time design questions.
So the designers do a bulk of the design (I'd say 95%), but there's no huge outlay of up front design. We do it all 'just in time'. Designs get input from developers, product owners, and other stakeholders. The mock up's may go through three or four iterations before they reach development, all within a few days time.
I'm not saying that developers cannot design, I think many can to varying degrees. We've just found that paired design done just prior to development, and working in close proximity to each other has allowed us to create great designs quickly.
On 12/4/10 4:33 PM, Tref Gare wrote:
Our environment is the opposite – we huddle our ux folk together which does give us the cross pollination thing, but means we miss out on the embedded engagement with the developers. I’d love to find some form of middle ground where I get to regularly mind meld with my design colleagues, but also am in there with the devs when the design hits the metal.