SwarmQuestionnaire

De CCSL
Ir para navegação Ir para pesquisar
ProgrammingExperience.png

Questionnaire about technical knowledge with programming and Mob Programming

Individual answers of team members: Automata.Life 2016

These four questions are pertinent to experience in the evaluated technologies and processes in the experiment:


1. How many years have you programmed? (Educational and professional experience in any language)


Member 1: Programming at 4 years.

Member 2: Around 7 years, with a 1.5 year gap without programming

Member 3: I have 6 years of programming experience.

Member 4: I have been programming for 4 years.


2. How do you evaluate your current level of knowledge in the programming language used currently?


Member 1: In the current project, I know the basics of all languages (Python, javascript, java ...). The language I use most outside of this subject is lua, and I feel extremely comfortable using it (advanced knowledge).

Member 2: Basic to Intermediate.

Member 3: I have intermediate to advanced knowledge about the languages used, but basic to intermediate knowledge of the specific frameworks and tools used in the project.

Member 4: Low Intermediate.


3. Do you like Mob Programming? You had practical experience with Mob Programming before this course?


Member 1: I really liked mob-programming, and it was the first time I heard about it and was the first time that I used this practice.

Member 2: Yes, this was the first time I heard about MOB programming, but I enjoyed using it

Member 3: I love Mob Programming. I had no experience with it before this course.

Member 4: Yes I like Mob Programming, but I did not have any experience in the technique before the course.


4. How would you compare Mob Programming to other practices you have tried or know about such as XP, Scrum, etc?


Member 1: I found mob-programming a very rewarding practice, bringing many benefits to our project. I found it agile and with constant feedback on the progress of the project, which is something I felt working with XP practices.

Member 2: The team communication is better with mob and everyone knows about everything in the project so there's no need for stand ups which is nice.

Member 3: Mob Programming helps to create a sense of community, group and even friendship between the members of a programming team. Although I feel XP also has this effect, I believe Mob does more for creating a united group.

Member 4: Since I have had no real experience with other agile methodologies, I do not see myself in a position to compare them. As for the other methodologies more guided by the planning, I can say that Mob Programming made it possible for all the members to have knowledge and understanding of the totality of the project (ideal for the development of small projects), the same can no longer be said of other methods that focus In the proper division of labor among its members. If, on the one hand, the division of labor allows the parallel execution of tasks by accelerating the progress of the project by the number of members, on the other hand, working together allows the overcoming of blockages much more easily and efficiently.


Individual answers of team members: Mezuro 2016

These four questions are pertinent to experience in the evaluated technologies and processes in the experiment:


1. How many years have you programmed? (Educational and professional experience in any language)


Member 5: 30 years.

Member 6: 5 years.

Member 7: 5 years.

Member 8: five years.


2. How do you evaluate your current level of knowledge in the programming language used currently?


Member 5: In the current project, my knowledge is only the basics of Ruby on Rails and Bash. The language I have advanced knowledge is C#. However, we used a lot of Ansible, and I did not know anything about Ansible, but I did learn with the group members who know Ansible, Linux, Fedora and Debian very well.

Member 6: Most of the code was written in Ruby, of which I have a good knowledge, and Bash, of which I have average knowledge.

Member 7: Intermediate.

Member 8: I would say I have a pretty basic knowledge of ruby, not advanced knowledge at all.


3. Do you like Mob Programming? You had practical experience with Mob Programming before this course?


Member 5: I loved using Mob, I learned a lot about Ansible and Linux. Yes I had already used it, but this time I learned more. However, it is natural learn more in the university, with an environment favorable to scientific experimentation in relation to the labor market with its need by result and profit.

Member 6: I enjoyed using Mob, but I had never used it before.

Member 7: I do like it. But I also believe it does not fit everywhere. It does depend on the people and activities involved.

Member 8: I think it is a really interesting method to equilibrate knowledge in the team. However, this was the first time I used mob programming.


4. How would you compare Mob Programming to other practices you have tried or know about such as XP, Scrum, etc?


Member 5: Mini retrospectives are better to improve the colaboration than just a retrospective at the end of Sprint.

Member 6: I wouldn’t rate Mob as a better or worse practice, it’s just another tool to approach specific problems during development.

Member 7: It takes communication and knowledge sharing to the next level, I don't believe no other practices would be as good for these two purposes.

Member 8: I believe mob programming has some similar core concerns of approaches such as pair programming. However, the focus on the interaction is the focus on mob programming.

Individual answers of team members: GeoXPerience 2016

These four questions are pertinent to experience in the evaluated technologies and processes in the experiment:


1. How many years have you programmed? (Educational and professional experience in any language)


Member 9: Since 2008.

Member 10: I program since 2012.

Member 11: Since 2010.

Member 12: Since 2012.

Member 13: Since 2009.

Member 14: I've been programming for 5 years.


2. How do you evaluate your current level of knowledge in the programming language used currently?


Member 9: Intermediate.

Member 10: I consider I have an intermediate proficiency level at the currently used programming language (Python).

Member 11: I consider myself to be an intermediate to experienced Python programmer.

Member 12: I consider I have an intermediate level in Python.

Member 13: Intermediate.

Member 14: I'm pretty confident with my knowledge in the programming language used in this project. (Python).


3. Do you like Mob Programming? You had practical experience with Mob Programming before this course?


Member 9: Only in this course.

Member 10: Even though I never used Mob Programming before, I liked a lot using MP, it helped the group tackle difficult problems and spread the knowledge among us.

Member 11: Yes, it was a great experience. I had never experienced Mob Programming before this course.

Member 12: I liked it a lot, and I'd never had experience with it before.

Member 13: At first, I didn't like it much because I thought it would be a 'waste' of time, but then I realized it was a nice way to learn stuff and I started to like it. It was my first try with Mob.

Member 14: I've never had experience with Mob Programming before and I enjoyed it very much.


4. How would you compare Mob Programming to other practices you have tried or know about such as XP, Scrum, etc?


Member 9: It is interesting, but I think this is most useful when is used to share knowledge or solving big issues.

Member 10: I believe Mob Programming is a practice that can be used in XP or Scrum. It doesn't help to organize which task has to be done nor decide about when to do it. It is just about getting a group of interested people together and using everyone's knowledge to solve a task.

Member 11: I think these practices are not exclusive to each other. One can do XP using Mob Programming, just like the way we did in class. It does not violate XP principles. Compared to other practices such as pair programming, MP has its pros and cons. It is an excellent practice to spread knowledge in a fast way, but can slow things sometimes. In that way, they work good together, and agile teams should alternate between them for specific purposes.

Member 12: I think that Mob Programming is very useful when some of the members of the group are more experienced in some technology than the others and want to transmit some of that knowledge. In cases such as this, I think it's better than pair programming, for example. But Mob is not always the most productive (or fastest) option. I think the best option is to mix different practices.

Member 13: The idea of one guiding others sound kind of similar to me in Mob and XP, but the way you interact with others is way different. When no one on the team has any/few experience with something, Mob is a nice way to spread knowledge but takes a little bit more time than the others methods.

Member 14: Mob Programming should be used in any project, mixed or not with other practices. In my opinion, it's the best way to level the knowledge in a group and to tackle problems (big or small).

Questionnaire about your experience with Mob Programming at LAB XP

Teams Answers

These eight questions are pertinent to the setup of the room and also ask for a description of the Mob setting. Please describe the environment where your team practice Mob programming:


1. Do you use a tv or a projector? How many?


Automata.Life 2016: Yes. We use two projectors.

Mezuro 2016: Yes. We used a single large television.

GeoXPerience 2016: Yes, most of the time we used a projector. Sometimes when it was not available, we had a TV we could use.


2. Sometimes other computers were used? Could be useful?


Automata.Life 2016: Yes. They were useful for parallel searches.

Mezuro 2016: Yes. Another computer was used when a task with the main computer implied a large idle time.

GeoXPerience 2016: Other computers were used when we were doing something that was new for most of the people. This way we could use them to research concurrently and share the results and code based on that.


3. How many people in the work room? Everybody was from you team?


Automata.Life 2016: Around 30 people. Not everyone on our team. We are the only Mob team in the room, with 4 members.

Mezuro 2016: There were around 8 people in the work room, 4 of them belonged to our team.

GeoXPerience 2016: There were about 12 people I'm the room. But only, six were part of the team.


4. People from other teams asked or helped in something? Noise was a problem?


Automata.Life 2016: We had sporadic interactions with other teams, but nothing regarding technology or problem solution. Two members were heavily annoyed by the noise. Two members were not bothered too much.

Mezuro 2016: Noise was not a problem and people from other teams helped us as they saw problems we ran into while working in the large TV (if we weren’t using that media, it’s likely that they wouldn’t have seen our troubles).

GeoXPerience 2016: Noise wasn't much of a problem for us, on the other side sometimes the other group would feel bothered by the noise we made. The teams didn't interact a lot with each other


5. How to improve the visualization? Was it adequate to see the code?


Automata.Life 2016: We usually increased the magnification of the text and the brightness of the projectors. Reading the code was adequate, but we would like to be able to dim the room’s lights a little bit more.

Mezuro 2016: The large television helped a lot with the visualization and no obvious improvements were necessary to help with the coding.

GeoXPerience 2016: We tried to use bigger font sizes in terminal and text editors to make it adequate to see the code.


6. Did you use a laser pointer or other ways to communicate to the driver?


Automata.Life 2016: We used the laser pointer during some work sessions.

Mezuro 2016: No. We just explained where we the changes were supposed to be made. However we do think that a pointer would be helpful.

GeoXPerience 2016: No, we didn't. I believe that would been helpful.


7. Could you send photos to us that you and all team member authorizes to publish?


Automata.Life 2016: Alfredo took some pictures during the classes. We authorize the usage of those pictures. Please let us know if more photos are needed.

Mezuro 2016: Yes. The photos will be shared.

GeoXPerience 2016: Yes.


8. Were there people missing at the Mob sessions? About work frequency of people, do you think Mob Programming improves engagement or helps in good work environment? Something more about that?


Automata.Life 2016: All members were present at all Mob sessions. We think Mob Programming improves the engagement and work environment. We believe that having all members solving the same problem really helps understanding how to solve it. Even when individual members leave temporarily, the group is able to make progress.

Mezuro 2016: There were sessions without the whole team, as each individual simply had a total number of hours to be fulfilled during the semester. Mob programming is certainly not detrimental to the work environment, but a harmony among coworkers can be achieved through other organizations too. Alternating between pair and mob programming could be a positive practice.

GeoXPerience 2016: We mobbed most of the sessions, so sometimes I'd natural people would miss the session, but Mobbing had a positive impact on our work environment, it made everyone more engaged and helped spreading knowledge.


These questions are pertinent to Driver rotation:


1. Do you use a timer or a program? How was it?


Automata.Life 2016: We developed our own timer tool. It received an integer as argument and warned us when time was up. We enjoyed the timer because it helped us organized the rotation. We typically used 15~20 minutes.

Mezuro 2016: Yes. We created a simple script to count down the time of each driver and alert the team when it’s time to swap.

GeoXPerience 2016: We used the clock, but we were not very strict about it. Sometimes we lost track of timing so we would decide for rotation.


2. Do you use Strong Style driving style? When the driver does not have the ideas and for an idea to go from your head to the computer, it must go through someone else’s hands.


Automata.Life 2016: We were able to use the Strong Style at some points.

Mezuro 2016: Only in the beginning, we soon decided try our own style.

GeoXPerience 2016: No, we didn't use strong style.


3. If the Strong Style was not used, please describe the experience and compare with other styles that your team used including how it worked.


Automata.Life 2016: N/A

Mezuro 2016: We started trying to evenly divide the driving time among the team, however the disparities in the previous knowledge of the members prevented us from doing Strong Style driving in mind. With that in mind, we decided to let the less experienced members drive more often, which greatly improved the knowledge spread.

GeoXPerience 2016: Everyone was able to have ideas and get it in the project. The only requirement is that the driver would have to explain what he is about to do before doing it.


4. If your team tried Strong Style, please describe the experience and compare with other styles that your team used or have previous experience with.


Automata.Life 2016: We had difficulty enforcing it all the time. We found it difficult to force the rotation when the current driver had an idea to solve the problem, but we were able to do that sometimes. We had a good experience with Mob Programming, but we believe that its potential could be better developed when most members of a team are familiar with all technologies used in the project.

Mezuro 2016: The team spontaneously tried in the beginning. Then we decided that the driver only drive, so the less experienced members drove more often.

GeoXPerience 2016: N/A


These questions are pertinent to retrospectives and mini-retrospectives:


1. Could you send photos to us that you and all team member authorizes to publish?


Automata.Life 2016: Yes. I will send Alfredo the photos of our retrospective and Kanban boards.

Mezuro 2016: Yes. The photos will be shared.

GeoXPerience 2016: Yes.


2. Did the team do daily mini-retrospectives?


Automata.Life 2016: We did not do daily mini-retrospectives, but we did a mid-project retrospective, and a mini-retrospective during a call with Yoder.

Mezuro 2016: We didn’t do daily formal retrospectives as the members talked a lot with each other and we didn’t feel the need to halt our work for that (many of our tasks required a considerable amount of idle time, which gave us plenty of opportunities to retrospect).

GeoXPerience 2016: We did only once.


3. Did the team do other longer retrospectives (weekly, every other week, monthly, ...)?


Automata.Life 2016: We did one long retrospective before starting Mob Programming.

Mezuro 2016: Yes. The team did larger retrospectives monthly, around the time of each merge request.

GeoXPerience 2016: Yes, we would do retrospectives after each sprint (between 7 and 14 days).


4. Did the team change anything after a retrospective (Sprint) or mini-retrospective (Mob Session)? What was changed? Were the changes useful?


Automata.Life 2016: Yes. We decided to start the day with 30 minutes of individual research on an unknown topic or technology relevant to the project. The changes helped us to understand the technologies. These question are pertinent to automation of the job and avoid idle time. The difference between wasting one minute of your time versus wasting one minute of your entire team.

Mezuro 2016: Yes. The retrospectives led to many positive changes, one of which we can highlight is the (already mentioned) reorganization of the drivers and the alterations of the informative workspace to better fit Mob Programming.

GeoXPerience 2016: After the first retrospective (at the end of the first Sprint) we decided that we wouldn't follow pair programming too strictly, so that if someone had free time and wanted to work alone, that would be ok. This helped us a lot because some of the members of our group had tight schedules, so they could contribute more if they were able to code whenever they had the time than if they had to stick to pair programming all the time.


These two questions are pertinent to automation of the job and avoid idle time. The difference between wasting one minute of your time versus wasting one minute of your entire team’s:


1. Did your team automate anything? What? Why? Was it useful?


Automata.Life 2016: Yes. We automated the build, test and deploy processes and the timer. We did it because those tools helped us performing daily tasks.

Mezuro 2016: We tried to reduce wasted time by making use of our text editor’s automated functionalities (Vim). Furthermore, we frequently used shell commands to speed up various processes (especially mass changes).

GeoXPerience 2016: Only the tests and CI and it was useful, but maybe we would've been more productive if we had automated more stuff.


2. Did members of your team every split off and do some spike solutions to integrate back into the main solution?


Automata.Life 2016: Yes, when we had to learn new technologies and performed separated searches.

Mezuro 2016: No. Mainly because of how troublesome it was to set up a DevOps workspace in different computers.

GeoXPerience 2016: Yes, a few times.


These questions are pertinent to full involvement all the time can be exhausting:


1. Did the members of your team take breaks together? How were them?


Automata.Life 2016: Team members usually left to and came back from breaks individually, but we had some team breaks.

Mezuro 2016: Due to the abundant idle time, we would frequently stop to chat about subjects outside of the project’s scope. However, we didn’t take formal breaks together.

GeoXPerience 2016: Yes, most of the days we took a break to eat something, relax a little and sometimes even discuss issues that we were having trouble with.


2. Did your team make sure that every hour there was a 5–10 min break where people weren’t allowed to be behind the screen? What do you think about that?


Automata.Life 2016: We had spontaneous breaks instead of scheduled ones. We liked the freedom of being able to choose breaks individually and knowing that the team continues to make progress even when individuals left for a break.

Mezuro 2016: No. Even during our breaks we were constantly worried about whether our last deploy had succeeded.

GeoXPerience 2016: No, we usually did these longer breaks after 1.5 or 2 hours. Apart from that, anyone could take small breaks whenever they wanted, but we didn't enforce breaks after every hour. We think that it's important to have breaks, but that each person can feel how tired they are and take breaks when they think it's better; sometimes work is going very well and taking a forced break (even a small one) can actually make a person less productive, so even when we did longer breaks, sometimes there were members of the team that kept working because they wanted to finish something and/or didn't feel that they needed a break yet.


This question is about learning as a team:


1. Did your team try learning something? Was it together? Was it at the beginning of the Mob Session? How was the learning experience?


Automata.Life 2016: We did try to learn things together during the project. It was not always at the beginning of the session. Sometimes we were able to learn effectively.

Mezuro 2016: Once during the semester, we focused on a subject (Continuous Integration in GitLab) and studied it as a team at the beginning of a Mob Session. This study had been planned for some time before that session.

GeoXPerience 2016: Yes, we experimented with new tools, such as GitFlow, Docker and a few other things, and we did it at the beginning of the Mob Session. The learning experience was successful in all cases, because the little knowledge of one specific member of the group was slowly growing to the others during the Mob Session. It is cool to see that, after a while, inexperienced members were giving tips and finding new ways to get the work done, using previous knowledge and the recent knowledge obtained during the Mob Session. At the end, the entire group grew together in experience and problem solving using those new tools, that were applied in our project throughout the XP course.


This big question is pertinent to Groupthink. Just because we act with kindness, consideration, and respect does not mean that we always agree, nor does it mean we want to always agree.


Do some of the members in your team have strong personalities? What do you do about strong personalities? Did it help or hurt the team? Do you think that the decisions of your team were sometimes tentious or influenced by a strong personality?


Automata.Life 2016: No. N/A. N/A.

Mezuro 2016: Yes. In some way, each member had their own unique personalities: some due to their knowhow and experience regarding the project, some due to their views on the group organization and the evaluation processes. Fortunately, all these conflicts had a positive effect on the team, as many of our decisions (especially when talking about knowledge dissemination and driver setup) were made with each member’s opinions, preferences and needs in mind. For example, we considered organizing small lectures made by the experienced members to the rest of the team.

GeoXPerience 2016: No. N/A. N/A. N/A.


These questions are pertinent to Collective Intelligence. Every programmer has experienced moments of mental exhaustion where it can take a lot of time to resolve even the most trivial problem. Most programmers (even those that do not practice pair or mob or pair programming) are aware of this and will invite a fellow programmer to take a look at their code in those moments of frustration. In a mob programming session, such moments are practically non-existent.


1. Does your team agree with the above affirmation? Was it unanimous?


Automata.Life 2016: Since our entire team was not familiar with all the technologies that we used in the project those moments of frustration happened, because no one knew what to do. When that happened we switched to individual searches.

Mezuro 2016: No, the team does not agree. Basically, during some devops tasks, there were some days that a project build was failing and no member of the team knew what to try. It was exhaustive to the whole group to approach these situations. However, we do not know if that is simply because of the nature of devops tasks.

GeoXPerience 2016: Yes, these moments happened, but sometimes we could solve the problem by searching or trying other things individually; also we thought moments like this sometimes indicated we needed a break.


2. Did the experience help the overall team grow with collective intelligence? Were there advanced members that felt Mob Programming was holding them back or slowing them down?


Automata.Life 2016: Yes. Sometimes a member of the group was able to come up with a solution that helped the group.

Mezuro 2016: Yes, Mob programming definitely helped on that matter. Since the knowledge was not spread on the beginning of the project, Mob Programming helped equilibrating that. This could be seen on further discussions of the team, which every member started raising questions and opinions about the project.

GeoXPerience 2016: Yes, it helped.


3. Were there advance members that felt Mob Programming was holding them back or slowing them down?


Automata.Life 2016: No.

Mezuro 2016: About the advanced member, there was no such feeling. Mostly because the tasks the team was performing demanded knowledge that no member in the team already had. Therefore, the contribution of every member on solving issues were gladly welcomed.

GeoXPerience 2016: There weren't specific members that felt that Mob Programming was holding them back, but while Mob Programming helped us a lot and we liked to use it, we think it can be a little bit slower than other approaches.


These questions are also pertinent to Collective Intelligence. When dealing with more far-reaching issues like design and architectural questions, swarming provokes a creative dialogue and exchange of ideas without falling into a trap of long and heated arguments. After a while, in cases when a significant difference in opinion persists longer than usual, the collective decisions are based on mutual trust.


1. Does the team agree with the above statement? Tell something about that based on your team experience at LAB XP.


Automata.Life 2016: Yes. We usually made decisions based on trust and emerging from a group vote. We discussed opposing ideas but we always reached a consensus.

Mezuro 2016: Yes. We realized that this “united development” allowed each member to better understand the thought process behind the decisions, which, in turn, reduced the amount of unnecessary arguments and conflicts. Most of those conflicts were resolved with a simple nod from each member.

GeoXPerience 2016: Yes. We think that Mob Programming allowed us to have a more complete discussion; everyone's points could be discussed and it was easier to make a final decision.


These questions are pertinent to Learning and mentoring. In the knowledge industry, learning and mentoring should be an integral part of everyday work activity. A swarm provides an ideal environment for that, as long as it is done in a deliberate manner and at a steady pace. By observing others, team members learn almost immediately how to make better use of tools and perform their day-to-day work. More importantly, they will soon gain deeper understanding of the business rules and the problem domain and will improve their problem solving skills as they observe and question others on proposed solutions.


1. Do you agree with the above statement?


Automata.Life 2016: Yes.

Mezuro 2016: Yes. It’s important to notice, however, that the above is also the most prominent feature of Pair Programming (it is not an exclusive characteristic of Mob Programming).

GeoXPerience 2016: Yes.


2. Please, describe whether Mob Programming helps with the understanding of the problem domain and improves technical competence based on your team’s experience at LAB XP.


Automata.Life 2016: Yes. We were able to learn from others’ knowledge and experiences. We grew as a team while we learned new technologies.

Mezuro 2016: Yes. The driver setup helps new and less experienced members to adapt to the work environment quicker.

GeoXPerience 2016: Yes, it helps because there are more people thinking and working on the same problems, so everyone can help everyone and learn from one another.


These questions are pertinent about if other practices were used or only Mob Programming:


1. Did your team use Mob Programming all the time? Were there activities when your team did not apply Mob Programming? Why?


Automata.Life 2016: We used Mob Programming all the time.

Mezuro 2016: Since we started with Mob Programming, we did not try mixing any other programming setups.

GeoXPerience 2016: In the first sprint, we used only pair programming. After that, we used Mob Programming when we were all together and pair programming only when some members of the team were doing remote pairing. Also, in the last sprint we used some pair programming again because we had little time and needed to focus on different issues simultaneously.


2. What other practices did your team use (such as informative workspace of Kanban)?


Automata.Life 2016: We used a Kanban and a burndown graph.

Mezuro 2016: Refer to question 3.

GeoXPerience 2016: See question 3.


3. Please, tell us about your informative workspace and about other practices you used?


Automata.Life 2016: We used a whiteboard where we wrote the Kanban and the burndown. We also used a small whiteboard where we drew concepts and ideas.

Mezuro 2016: Outside of coding, we used a Kanban including a Backlog, an Ongoing Task and a register of Done Tasks. We also used Scrum’s Sprints and a table of Accomplished hours for each member. These practices were modified and evolved as the project progressed.

GeoXPerience 2016: We had a Kanban, a pairing chart (we used this mostly when we were doing only pair programming, in the beginning of the project), and a backlog.


4. Did your team stop using Mob Programming or used other practice together with Mob Programming?


Automata.Life 2016: No.

Mezuro 2016: Refer to question 1.

GeoXPerience 2016: See question 1.


5. Did your team try to Improve the Mob Programming Session?


Automata.Life 2016: We tried to inserted learning sessions during the Mob Sessions, where each member used a computer to learn or search a topic.

Mezuro 2016: Yes, we tried regarding the driver rotation, DevOps tasks and about Groupthink.

GeoXPerience 2016: We didn't strictly follow all the Mob Programming concepts, we did our version, which was what worked best for us, so in that sense we were trying to improve it.


6. Do you think that it is good to do Mob Programming all the time?


Automata.Life 2016: We think that when no one on the team knows a technology it is better to individually search and learn.

Mezuro 2016: We think that a team based on Mob Programming should stick to that and avoid the overhead caused by constantly swapping organizations and spreading tasks. However, a team based on Pair Programming should be ready to approach some problems with Mob Programming, specially when a pair is having a hard time solving the problem and/or when the problem requires a wide range of expertises to be solved. However, there are some tasks that the team does not seem fit for Mob Programming all the times. The solving of some devops tasks were actually improved by Mob Programming, but others not so much. Specially the ones which the team did not know what to do for sure and the approach was trial and error.

GeoXPerience 2016: It depends on the team and the goals. It was very good for us when some of the members knew more than others and we wanted to share the knowledge. If there are too many different things to do and not much time, Mob Programming might not be the best solution.


7. Did members of your team say that they approved and enjoyed the Mob Programming? Was it Unanimous?


Automata.Life 2016: Yes it was unanimous.

Mezuro 2016: Yes. The approval of Mob Programming was unanimous at every retrospective.

GeoXPerience 2016: Yes. Yes.


8. Do you think that Mob Programming was productive? Why? Was it more productive than other ways you’ve previously used to work with a group with the same number of people?


Automata.Life 2016: Yes because the team was able to continue working even when some members left for a break. We believe that Mob Programming was useful to spread the knowledge between team members and was more productive because every team member became familiar with the code and the build process.

Mezuro 2016: Our team had to constantly deal with DevOps tasks, which lead us to experience a lot of idle time. In this scenario, the Mob Programming was detrimental to the productivity as it implied that the whole team had to wait for each individual task to complete. However, these problems can be circumvented by preemptively setting side tasks for the members.

GeoXPerience 2016: Yes, because with the whole team working on the same problem, it was easier to find a solution and if one or a few members were tired or unproductive it didn't affect the progress so much because the others could make up for it. It wasn't more or less productive than other practices.


9. Did your team measure something? How and what did your team measure?


Automata.Life 2016: Yes. We measured the points of each task using a burndown graph.

Mezuro 2016: We did use story points to measure the velocity difference between the Sprints.

GeoXPerience 2016: We measured task points at first and then switched to measuring story points. At the end of each sprint, we compared the expected number of points and how many we actually did.


10. What was your favorite experiences of Mob Programming?


Automata.Life 2016: Sharing knowledge and working with friends.

Mezuro 2016: The capacity to distribute the knowledge through a streamlined method and the bond formed among the members were the strengths of our experience.

GeoXPerience 2016: The friendly mood and the sharing of knowledge.


These questions are pertinent to Continuous Improvement:


1. Was there any change from when you started to do Mob programming?


Automata.Life 2016: Yes. We started to allocate 30 minutes at the beginning of each session to individual searches.

Mezuro 2016: Yes, we improve the information on whiteboard for the informative workspace to be meaningful to us.

GeoXPerience 2016: We started doing it just sometimes but then proceeded to do it almost every time and we became less strict about the time each person spent as the driver.


2. How would you improve your environment in the future?


Automata.Life 2016: We would like a more silent room and that each member has access to an individual notebook or computer.

Mezuro 2016: The laser pointer available seems a good idea.

GeoXPerience 2016: We had some trouble with cables and adapters (to use the projector) and also could have benefited from a laser pointer.


3. Do you have any ideas on improving the Mobbing process or Swarming?


Automata.Life 2016: No.

Mezuro 2016: One improvement we would suggest to increase the productivity of Mob Programming would be to properly divide tasks during the Planning Poker sections in order to facilitate the transitions between Mob and other organizations, therefore reducing the possible idle periods of the team.

GeoXPerience 2016: No.


References

1. Zuill, W.: Mob Programming: A Whole Team Approach. Experience report, Agile (2014) https://www.agilealliance.org/resources/experience-reports/ mob-programming-whole-team-approach-woody-zuill/

2. Zuill, W., Meadows, K.: Mob Programming - A Whole Team Approach. First edition of Book published on October (2016) http://leanpub.com/mobprogramming

3. Beck K.; Andres, C.: Extreme Programming Explained: Embrace Change. 2nd Edition, Boston-USA. Addison-Wesley, 75p. (2004)

4. Rooksby, J., Hunt, J., Wang, X.: The theory and practice of randori coding dojos. In: Agile Processes in Software Engineering and Extreme Programming, vol. 179, pages 251-259. (2014)

5. Wilson, A.: Mob Programming { What's works, what's doesn't. In: Agile Processes in Software Engineering and Extreme Programming: proceedings of the 16th International Conference on Agile Software Development, XP 2015, pages: 319-325. held in Helsinki, Finland, in 25-29 May (2015)

6. Kattan, H. M.: Illuminated Arrow: a research method to software engineering based in action research, systematic review and ground theory. In: CONTECSI - International Conference on Information Systems and Technology Management 2016: pages 1971-1978. 21 Jul. (2016) DOI: 10.5748/9788599693124-13CONTECSI/PS-3926

7. Budgen, D., Charters, S.; Turner, M.; Brereton, P.; Kitchenham, B.; Linkman, S: Investigating the Applicability of the Evidence-Based Paradigm to Software Engineering, In: Proceedings of WISER Workshop, ICSE 2006, ACM Press, 7-13, May (2006).

8. Kitchenham, B.; Charters, S.; Budgen, D; Brereton, P; Turner; M; Linkman, S; J0rgensen, M.; Mendes, E. Guidelines for performing Systematic Literature Reviews in Software Engineering. Version 2.3. EBSE Technical Report EBSE-2007-01 Software Engineering Group School of Computer Science and Mathematics Keele University Keele, Staffs ST5 5BG, UK and Department of Computer Science University of Durham Durham, UK 9 July, 2007

9. Allan, G. The Legitimacy of Grounded Theory Proc. Fifth European Conf. Business Research Methods, pp. 1-8, 2006.

10. Brooks, F. The Mythical Man-Month: Essays on Software Engineering, 20th Anniversary Edition. Reading, MA: Addison-Wesley, 1995, 322 pages.

11. Falco, L.: Llewellyn's strong-style pairing. (2014) http://llewellynfalco.blogspot. com.br/2014/06/llewellyns-strong-style-pairing.html

12. Kerney, J.: Mob Programming { My first team. Experience report, via Initiative of Agile Alliance (2016) https://www.agilealliance.org/wp-content/uploads/2016/07/ Mob-Programming-My-first-team.pdf

13. Boekhout, K.: Mob Programming: Find Fun Faster. In: Agile Processes in Software Engineering and Extreme Programming: proceedings of the 17th International Conference on Agile Software Development, XP 2016, Publisher: Springer International Publishing Switzerland. vol. 251. Pages 185-192. Edinburgh, UK, May 24-27 (2016)

14. Griffith, A.: Mob Programming for the Introverted. Experience report, Agile (2016) http://agilealliance.org/wp-content/uploads/2016/03/Mob Programming for-the-Introverted.pdf

15. Arsenovski, D.: Swarm: Beyond pair, beyond Scrum. Experience report, Agile (2016) https://www.agilealliance.org/wp-content/uploads/2016/07/D.Arsenovski. Swarm-Beyond-pair-beyond-Scrum.pdf

16. Hohman, M.; Slocum, A.: Mob Programming and the Transition to XP. (2001) http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.18.2967& rep=rep1&type=pdf

17. Kattan, H. M.: Programming and review simultaneous in Pairs: a pair programming extension. In: Technological Research Institute of S~ao Paulo State. (2015) http://aleph.ipt.br/F. Or 'ipt.br', click on: Online Consultations, then click on: Library.

18. Zuill, W.: A Day of Mob Programming. (2012) https://www.youtube.com/watch? v=p pvslS4gEI

19. Mezuro Wiki: http://ccsl.ime.usp.br/wiki/Mezuro

20. Mezuro: http://Mezuro.org

21. Mezuro GitLab: http://gitlab.com/mezuro

22. Mezuro GitHub: http://github.com/mezuro

23. The Game of Life Wiki: http://ccsl.ime.usp.br/wiki/Automata.Life

24. The Game of Life GitHub: http://github.com/Automata-Life

25. GeoXP: http://ccsl.ime.usp.br/wiki/Sistema online de georreferenciamento

26. GeoXP GitLab: http://gitlab.com/geoxperience

27. Questionnaire: http://ccsl.ime.usp.br/wiki/SwarmQuestionnaire

28. GDS post: http://gds.blog.gov.uk/2016/09/01/using-mob-programming-to-solve-a-problem/

29. Western Electric Company Hawthorne Studies Collection, Baker Library, Harvard Business School. http://oasis.lib.harvard.edu/oasis/deliver/~bak00047

30. Santos, V., Goldman, A., Souza, C.: Fostering effective inter-team knowledge sharing in agile software development. In: Empir Software Eng (2015). Pages 1006-1051.

31. Weinberg, G.: The Psychology of Computer Programming. New York: Van Nostrand. (1971)


Consent Term

Criteria for selecting participants:


We are looking for participants over 18 who know how to program and is developing some software through the practice of Mob Programming. We hope to have the Participants of the 3 groups of the discipline Lab XP that adhered to the Mob Programming in this study.


Procedures:


If you agree to participate in the experiment, we ask that you complete a questionnaire about your programming knowledge and your experience with Mob Programming during Lab XP.


Risks and Discomforts:


The risks involved in their participation in this study are no greater than those in their regular programming activities.


Benefits:


Your participation will be very valuable to our research. You probably will not have direct benefits when you participate in this study. However, the Publication containing the experiment will be available. We hope that the results of the experiment lead to a better understanding of Mob Programming.


Compensation and costs:


There is no compensation for participation in this study. There will be no costs, besides your time, for your participation in the study.


Anonymity, Confidentiality & Privacy:


The following procedures will ensure your anonymity and privacy. In the questionnaires, no personal information is requested. So questions about your development experience will not be tied to you.


In case of damage / loss:


If you have any problem, damage or discomfort as a result of participating in this study, please contact Herez Moise Kattan by email (herez at ime.usp.br). Neither Herez, the research team, or the Institute of Statistics and Mathematics of USP has provision for the payment of costs associated with any damage resulting from participation in this study. Therefore, there will be no form of compensation under any circumstances.


Rights of Participant:


   - Your participation in this study is voluntary.

   - You can refuse to participate or withdraw at any time.

   - Failure to participate will not affect your grades or academic performance.


Questions about the study:


If you have any questions about the study, do not hesitate to contact us: herez at ime.usp.br or gold at ime.usp.br


Consent:


If you are willing to participate in this study, please answer the questionnaire about your experience in Mob Programming and Development during Lab XP. After completing this questionnaire, you can respond in the same email for which you received the questionnaire. By completing the questionnaire, you indicate your consent to participate in this study and you have read the information in this consent term.


Final dispositions:


This study will be submitted to ethical approval by the Research Committee of the Institute of Mathematics and Statistics of the University of São Paulo. The results of this study will be published in the form of a scientific article in periodical or conference, and may be contained in a book, or even published on the internet. You can contact us for more information about the results of this study at any time.


Photos

MobYoder.png MobGame1.jpg MobGame2.jpg MobGame3.jpg MobGame4.jpg MobMezuro1.jpg MobMezuro2.jpg MobMezuro3.jpg MobMezuro4.jpg