SwarmQuestionnaire
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.
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.
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.
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.
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.
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.
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).
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.
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.
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.
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.
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.
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.
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:
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.
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.
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.
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.
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.
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.
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.