Agile 2009 Notes - Monday

The following material describes the sessions I attended.

Monday AM –

Research Stage

Research reports started Monday at 9AM before other sessions, but were located out of the way of all other session areas. Also, some people at information areas claimed sessions didn’t start until 11AM.

I spent the morning at two research presentations because the format this year drew in a great deal of audience participation as opposed to just a series of 45-60 minute talks. Dr. Jael Dublinksy explained that a goal of the Research Stage this year was to solicit a lot of input from industry folks. I believe it worked for those industry people present, but, again, being a out of the way(and mind) of people did diminish attendance.

The first presentation was by Rosalva E. Gallardo-Valencia on “How Agile Teams validate Requirements.” Team activity was observed and artifacts were collected for ~2 days, including stand-ups and Sprint Planning sessions. Overall, the study showed that, while standard validation approaches were not used (or even possible) in an agile environment, there as substantial validation performed at various points during team and team/PO interaction.
Interestingly, it was noted that the PO and written up a “checklist” of details about story information which was not shared with the teams. Instead, at the Planning Meeting, the PO would talk about this information and respond to team questions while the ScrumMaster worked to write the stories to match the discussion. I asked why, if all this material had already been written (even in brief form), did people feel index cards had to be created. There were a variety of audience opinions, but there really was no answer from the study why this occurred.
It was noted that the teams wrote jUnit tests before coding and that Fitnesse was used for acceptance testing.

After the presentation, there was a period of feedback to the presenter on work of the study. But then, the audience was asked to form into groups and consider research topics that they might like to see pursued. Our group had the following ideas submitted by various members of the group:

1) Classification of team sizes and recommendations for what team sizes/characteristics might be appropriate for different development situations. Dimensions to be examined were: trust, distribution of team, new vs “rewrite” type work, and degree of team integration, including senior management.

2) What concrete benefits does agile provide an organization, e.g., lower costs, higher customer satisfaction, improved time-to-market, market success (revenue).

3) Quantify an organizations degree of “agileness”

4) Effective approaches for introducing agile – path to adoption.

The next presentation was by Dr. Stuart Mitchell based on the work of Rashina Hoda regarding “Agile Undercover” where some organizations wanted to use agile but customers “couldn’t have cared less about what methods were used.”

Dr. Mitchell noted that a grounded theory approach (Glaser rather than Strauss style) was being used for data collection. Observation, without making conclusive statements was a characteristic of how this study was done.

Some outsourcing teams in India were studied. They wanted to use an agile approach, but most of their customers did not care to adapt to such an approach. Ms. Hoda interviewed a person from each of ~8 teams. It seemed that many ended up with customer proxies to allow their teams to try to function in as agile a manner as they wanted. Some teams did do periodic demos to actual customers, but some did not.

I suggested that the most interesting research work related to this might be to observe how the proxy role made it easier for the team as to behave as they wanted while the customer did not have to be aware of how the team was getting work done.

Monday PM –

Elizabeth Hendrickson and Chris Sims on Design of Simulations and Games

This was an all afternoon session that asked attendees, in teams, to design “games” of various kinds that could be used to allow help groups learn (presumably about agile methods, values, etc.). There were board games designed; some involving pure interaction among participants; one involving joint creation of sentences; etc. Each, however, was developed around a different goal. One being “Truth and honesty in planning.” Once teams had been given some time to design a game, members of other teams would come by to “playtest” and provide feedback. Teams could revise their games and get further feedback.

Many fascinating observations occurred about what the games “taught” as well as what contribution to that learning the participants brought compared to the games as originally envisioned. Some of the main ideas that came from the session as a whole (some offered directly and others arising out of the session itself) were:

1) The debriefing around playing the game(s) is where the main value occurs, not in the game(s) themselves.

2) Using the term ”simulation” rather than “game” might make the experience of using games more acceptable in some organizations.

3) It’s better to layer complexity on a simple game than to try to remove it from a more complex one.

4) Consider the incorporation of obstacles, choices and randomness in games.

5) Interesting results come from players not sharing the same mental model of what the game is about. (Two examples were a sentence-building game and a balloon passing one.)

6) One good goal of a game is to see how participants achieve alignment, perhaps by evolving the game and its rules themselves to reach a goal they determine to be the point of the game.

7) Game debriefing is like a retrospective for which some suggested questions ideas were asking what happened (in game play); what did players do and feel; what surprised people? In this regard Elizabeth and Chris suggested being very observant as game facilitators, noting what people did and how the game changed, then using these observations to ask what the participants thought about the things observed.

8) Ask participants to “map” what the learned/observed in game play to real world situations and how they could take action in their environment to implement what was learned.

All in all, it was a very interesting day.