[RD#01] March 13, 2010 – Experience Report

This post aims to present our experience report about the 1st Requirements Dojo organized by GUMA-RS (Agile Methods Users Group of SUCESU-RS).

General Information

• DATE: March 13 (Saturday), 2010 * 09:30 AM - 12:00 PM
• PLACE: PUCRS (Porto Alegre, RS, Brasil) – FACIN (Faculty of Informatics) – Room 516
• ORGANIZER: GUMA / SUCESU-RS
• FACILITATORS: Luiz Claudio Parzianello and Daniel Wildt
• ATTENDANTS: 40

About the Plan

As the 1st Requirements Dojo executed without any previous reference from another international group, we’ve decided to experiment some ideas from Coding Dojos and Requirements classes performed by GUMA facilitators when running this meeting. Our main goals were:

• Present the concept and dynamics of a Requirements Dojo;
• Present the basic elements of Agile Requirements Analysis;
• Present the elements we intended to explore during the event: Problem Statement and Vision Statement;
• Communicate that people must contribute with us in order to evolve this kind of meeting;
• Communicate that people will be charged with non perishable food (for donation) in order to adhere to the event.
• Use a standard presentation file (check it out here) to conduct our oppenings.

Basically, our agenda was defined like that:

1. 10’    Introduction
2. 10’    The day practices
3. 50’    Round #1 – Problem Statement
   - 5’ Problem
   - 15’ Brainstorming about practices,techniques and tools
   - 20’ Group dynamics (the same problem)
   - 10’ Results presentation
4. 10’    Break
5. 50’    Round #2 – Vision Statement
6. 15’    Retrospective

About the Execution

Before we start reporting what really happened during this 1st Requirements Dojo, we’d like to thank people from Centro Software (Santa Maria, RS) for the post they’ve published about the event.

# Introduction

• We got 40 participants in that morning! Too many people running an experimental Requirements Dojo for the first time, but we’ve survived the experience!
• We  welcomed people and started presenting the Coding Dojo basic concepts as well as how we intended to use them in a Requirements Dojo;
• We set some basic etiquette rules and presented the agenda of the day;
• It has spent more than 30 minutes to finish our introduction (much more than we’ve expected).

The 1st Requirements Dojo was attended by 40 participants at PUCRS (Porto Alegre, Brazil)

The 1st Requirements Dojo was facilitated by Luiz Parzianello and Daniel Wildt, both representatives of GUMA/SUCESU-RS

# Investigating a Model for Agile Requirements Analysis

• In order to demonstrate that it’s very common to see several requirements models in Agile Projects, such as Problem Statements, Vision Statements, Business Themes, Roles and Personas, Business and Product Strategies (Releases), Features, User Stories, and so on, we followed our plan to discuss a Concept Map organizing some Agile Requirements Analysis tools;
• For many people, this model was elucidating because help them to understand that the Agile Requirements context is not limited to a simple User Story;
• Based on this model, we explained that our first experiment was related to the Problem Statement of a simple problem.

# Evaluating People Knowledge and Skills about Problem and Vision Statements

• Before we start with the Problem Statement, we tried an experiment: What is our self-perception about knowledge and skills we present when working with Problem and Vision Statements?
• People were invited to go to the white board to indicate their perceptions with a dot ranked at levels of knowledge and skills.
• As you can see (figure below), most of people are used to work with Vision Statements (VS) rather than Problem Statements (PS).
• However, around 50% of people have considered theirselves as + Good or ++ Very Good workers of Problem Staments.

“]

All attendants have indicated their own expertise level working with Problem and Vision Statements [++ Very good; + Good; - Bad; Ø Null

# Exploring the Problem Statement

• We asked teams to brainstorm and then organize ideas about what should be on a problem statement and what should not be.
• They started working in teams with 5-6 people and after some minutes, we started grouping ideas to understand how a problem statement should be based on the knowledge of the attendees.

A diagram identifying the elements participants have considered or not to be in a Problem Statement!

# Practicing the Problem Statement

• Daniel Wildt is not an actor (really not!!!), but he tried to convince people that he was the owner of a dvd rental store, a small one. Actually, a really small one. But he wanted to grow, because there was new competition in the block, so his dvd rental store needed some controls to help business to continue.
• After telling a sad story and information about the problem he was living in business for the audience, teams worked to provide a narrative with a PS, considering items they considered that should be on a PS.
• Some teams used items instead of a narrative, and we talked about how important was to tell a story to understand the problem to be solved. To be objective and consistent to the problem being lived by the customer, by using a narrative and using the same language of your customer (try using metaphors).

About the Donation

• To participate in a Requirements Dojo promoted by GUMA-RS you have to bring at least 1Kg of non perishable food to be donated to a non-profit charitable organization;
• It was the way we’ve found to reverence our practice and thank all the people who are donating their time to develop a high level learning environment;
• We’ve adopted “Os Cozinheiros de Plantão” and invite them to visit our events to receive our food and tell us about their stories cooking for homelesses everyday.

Event break to make our donations and run a talk with the NPO Cozinheiros de Plantão (Cooks on Duty)

About the Retrospective

By the end of the event, we ran a retrospective with all participants. This is an important activity that must be done in all Requirements Dojo!

What Went Well:

1. It was the first one, and we pass through it;
2. Lots of people are interest in the subject, that’s important;
3. We did not care about achieving the dojo objectives (we planned problem statement and vision statement but only worked problem statement) – more important than achieving a goal is the practice itself using the participants pace, and that’s what we were looking for;

What Went Wrong:

1. Registration Process – People used “LinkedIn Events” to make their registration, but we had some trouble getting a list of all participants. It was very time consuming to the organizers and was changed for the 2nd meeting;
2. The Venue – The room FACIN has provided us was an auditorium. Auditoriums are not appropriate for team work or group dynamics – We will try a different room for the 2nd meeting;
3. We Planned to Push not to Pull – When we planned to run Problem and Vision Statements at the same event we didn’t expect that we would be pushing people to do stuff. We had to provide information about the process, sometimes it was looking more as a college class. We end up sometimes teaching more than facilitating. This is something to be improved so that people go there to practice, not to be in class.

What Have to be Improved:

1. To explore the Kake format in order to promote more interaction between participants;
2. To register and publish as soon as possible the experience report;
3. To annouce previously what will be the main topic of next event;
4. To record an introductory video explaining principles and values that drive the Requirements Dojo (will be available by the 3rd meeting – May 08th).

# Exploring the Problem Statement

• As a first activity related to the element we
• Daniel representou um cliente com um problema numa DVD Rental Store
• Avaliamos quais informações deveriam estar contidas numa Problem Statement
• Texto