Agile Place

http://www.agileplace.com / http://www.floranta.com

AgilePlace aka GlueWiki aka Floranta is a CollaborationTool? for remote PlanningGame s developed by the OpenSource FlorantaProject. We are looking for volunteers to help us build a configuration tool for GlueWiki that can be open-sourced and released to the public under the LGPL as well. Any XP consultants who might be interested in helping us enhance GlueWiki or in supporting/redistributing it are invited to contact us at http://www.floranta.com/gluewiki/send_email.php?owner=floranta&projectid=1&command=show

Usage: Stories can be written down on IndexCards on the first table at the top of the page. These stories form the story pool to work out of. At the beginning of each iteration, a table can be created for the iteration and IndexCards moved onto it. Tables from previous iterations slide down to make room for new ones. It's as easy as that.

Workings: The OpenSource FlorantaProject (http://floranta.sourceforge.net) is developing a rich client Wiki centred around cards of various kinds. These cards can be diagrams, index cards, balloons, borders, groups, etc. Floranta allows these to be resized, organized into iterations, etc.

Feedback For AgilePlace/GlueWiki:

KyleCordes provided us with the following points:

The flicker is very annoying. Had you used Swing instead of AWT, you'd find it trivial to be flicker-free. Of course there are some browsers out there with a very old (Swing-less JVM).
the drag of a dot instead of the whole window is also unpleasant. Same thing - very easy to get it the other way with Swing.
It would be slick to see this as a Javascript thing, rather than an applet. Googles Maps indicates that screens with draggable pieces can be done that way. Of course, perhaps I should not complain, but rather do it myself. :-)
The chat window gets in the way, and its purpose was unclear. How about labelling it?
How about an RSS feed of entered and updated "cards"?

User Interaction Problems and Our Solutions

Problem 1: Growing Up

We are extremely grateful to KenAuer and the folks at RoleModel who offered to play guinea pigs with the early versions of AgilePlace. KenAuer was very encouraging, patient and helpful. RoleModel discovered some problems very early.

There was no way to fit a hundred cards comfortably in the 800x500 pixel tables that we had. There could have been many times that number of IndexCards in the stories pool.
There was no way to move index cards around in groups. We only allowed users to drag/copy/paste single cards.
Even the simplest operations required too many clicks. You had to double click to edit a card, and copy/paste was laborious.
Tallying nuts would be extremely useful
Exporting stories to a bulleted list would help make the data mailable.

Solution:

So, we enabled resizing of boards so they could be made many times larger.
We implemented hot keys and dragging of multiple cards and drag-to-select to reduce the number of clicks it took to do something.

Problem 2: Compensating for Absence of Sight

Then, when conducting planning games with team members in India, I observed the following problems:

There was no way of knowing who was already there on the page.
It was hard to tell where somebody was looking... We used Yahoo Messenger to chat (voice most often, sometimes by text-messaging). Once, when checking in textually, I kept waiting for the team members to say something on the YM chat window when they were all checking in using a second chat window that had scrolled out the bottom of the page.
More information had to be communicated about the other users' activities, to create the being-here feeling.
Synchronization bugs and penalties for synchronization errors had to be minimized. For instance, I often wondered if someone else was editing the card I was editing. It was stressful second-guessing the others simply because one of us would lose our changes.

Solution:

We created a space where all the visitors to the page would be listed.
We began to use a grouping figure with the text "I'm looking here" to indicate the point of focus. Everyone then knew that where the current speaker's focus was.
We realized that communication channels that were not all visible and focusable at the same time was a negative pattern. So, we decided to move the chat client out of its position at the bottom of the page and make it embeddable in the index card boards.
We are using multi-modal immersive commentary (in a generated voice) to tell everyone about each others' activities, something that should feel like listening to cricket commentary in the background. It does not affect the task you are performing but gives you enough information to alert you to potential problems.
We are looking into versioning cards so that if a collision occurs, there is no loss of information and a merge action is initiated.

Problem 3: Teaming

It was very hard to communicate emotional information. It was very difficult to tell when someone was feeling bad, or having a hard day.

Solution:

We are attempting to add support for core protocols. An explicit CheckIn? CoreProtocol? helps us sometimes to put on the wire things we can't observe on each others' faces.

Problem 4: Synoptic views

When we asked people for their comments on the tools, one of the problems they noticed almost immediately was the inability to see all the cards at once. The ability to resize boards allowed us to fit in hundreds of cards, but it did not help the use see all these cards at once. We found that this was a major irritant to many people who responded to our requests for comment.

We thought about it and realized that the feedback from the earlier customer trials also reinforced the need for a synoptic view. They had wanted to be able to put more cards on the table and felt ours did not allow it. The system was quite unusable to them even though we had scrollbars that allowed them to scroll around the space where the cards were. We had made it possible to have larger boards, but the board went out of the browser and the browser window had to be scrolled to see all parts of the table.

We asked ourselves if there was a lesson to be learnt from the feedback. What does this tell us about the planning game? Does it mean that people need to see a lot of cards when doing the planning game, to have some sort of long-term view in mind, some sort of vision of the future? If so, then it would also be true that the planning game is best conducted standing up if there are lots of cards to estimate. A person stands up when they want the big synoptic view. I don't know if this is true, but I would predict from this feedback that in planning games with lots of cards, there are large tables that people tend to stand up or back and look over.

Another feature of index cards seemed to support the hypothesis. The title. Why is the title line written larger than the rest? Why is there any need for one? Could it be so that folks use that device to be able to see the gist of the card when standing up at or back from the table?

Solution:

Well, that's the theory, but we decided that there was reason enough to abandon all other stories and concentrate on providing zoom in and zoom out, exactly as a consultant who gave us feedback, had suggested. To this person we are very grateful, because it was a very very valuable user story indeed.

We added zoom in and zoom out. The user clicks on the board (table top) and presses the - or + key to diminish or magnify the board.

Problem 5: UI Flicker

Lots of people felt that the UI flickered too much and that the cards did not respond very well to moving, resizing etc.

Solution:

The cards were made to not drag or resize until the mouse was released so as to keep the flicker low. However, we realized early on that moving cards to a precise target location became difficult. We're attempting to solve both problems using double buffering.

Problem 6: Parallel Projects

Estimating the minimum time it would take to complete a project with unlimited resources was something we wanted to support. In operations management, you use PERT charts to accomplish that task. PERT networks take into account dependencies between tasks to determine the critical path.

Solution:

We considered something like PERT charts but decided that it would be easier if folks moved the stories that ran in parallel into two separate projects. We also added views to facilitate the movement of cards between story pools in different projects.

Problem 7: Poor Response Times

Because of the poor response times of the hosting server, especially in South Asia, proactive visual indicators of progress became very important. Otherwise, a user could try to create a new card, then panic because no card had become visible, create another, and then yet another, until finally three cards appeared on his/her screen.

Solution:

We worked out a hack to place dummy cards on the screen in the locked state until the server should register the request for a new card and respond to the client.

Acknowledgements: Thanks to the people who kept us motivated all the way, to KenAuer, and all the users who provided feedback on the usability of AgilePlace.

FAQ

Q: What is the "Nuts" field for?

A: The nuts field is the size of the task, an indicator of the effort needed. We add up the nuts on a table and the sum is displayed on top of the board.

Q: Wonder how to sort this, would be nice to have templates consistent with domain of use

A: We currently support exporting to a bulleted list. That seemed to be a useful export format for Planning Games in eXtreme Programming. If there are other domains, we could create export templates for them, or provide a way to set export, sort rules :)

Q: Can an index card or sticky note be modified over time?

A: Yes, you can edit it over time.

Q: Is there a datestamping feature?

A: Did you mean timestamping? Not yet. We could easily add it if customers request the same.

Q: There's no obvious way for a customer to sort by priority. That could be added, but again with the tactile thing: sorting cards by priority, without writing the priorities on the cards, might be easier with physical cards than virtual.

A: The virtual table top can be used for sorting by priority. The floranta team sorts cards in the top table.. the stories pool. We keep higher priority stories lower and then slide em off to the next iteration. You can also use 'group' and 'border' widgets to prioritize cards.

Q: Do you have an expectation of how best teams can use the space? What was the motivation/need that this is supposed to solve/address?

The team that works on http://floranta.sourceforge.net is partly in India and partly in the USA, and we wanted to use XP. At the very least, we wanted to do iterative development with planning games and keep track of our weekly activities.
A consultant we knew needed to demonstrate a planning game to a remote customer and quickly capture the requirements of a new system he was planning to help build for them.
I needed a place to keep sticky notes of interesting things I read and I wanted this to be on the web so I could get to it from anywhere.

A consultant needs greater reach in the following cases:

An onsite customer is not available (a frequent problem).
A remote client needs a consultant to help prioritize his work.
A consultant wants to monitor the health of a team they have coached.
The XP team is located in different geographic locations.

The AgilePlace team wishes to make clear that no one mentioned in this page endorses AgilePlace or suggests that AgilePlace is superior to other XP ProjectManagement tools or paper IndexCards. This is but a tool. No one should believe that using AgilePlace is in any way preferable to standing around the table.

This part of the WikiPage may be used by GoalDonors to post UserStories for AgilePlace.