Experiment - from pair programming to whole team programming

I really want to share with you the translation of an article about an experiment with mob programming from one of its creators, Woody Zila. This is when the whole team immediately works on one computer. Like pair programming, only group programming. I am a former Java developer and team leader with 11 years of experience, and I would have been surprised by this approach before. It turned out to work very interesting. Inside - how the participants interact, what advantages it gives them, and what difficulties they encountered. This is a report on an experiment that has been successfully running on Woody's team for three years now. Useful if you want to configure this for yourself.

1. Introduction

Mob programming or mobbing is an approach to software development in which the whole team works on the same thing at the same time and in the same place on the same computer. This is similar to pair programming [PAIR] , where two people are sitting at the same computer and working together on the same code at the same time. In mob programming, this collaboration extends to everyone on the team, with only one computer still being used to write code.



In addition to writing code, the team works together to do almost all the work typical of a development team: defining stories, designing, designing, testing, deploying / releasing a program, working with a customer (in our environment, we call our internal customers our “Partners”, which in nature is similar to the concept of the owner of the product). Almost all the work is done during “work meetings” or workshops, and all the people involved in creating the program are considered team members, including our partners. We work this way every day and more or less all day.



In other words, this is an evolutionary step beyond the concept of pair programming from XP (extreme programming) [EXT] . In our work, we strive to emphasize and strengthen such concepts as, for example, face-to-face communication and side-by-side work, building a team, cooperation, involving the whole team, continuous review code and “self-organized team”.



In this experiment report, I describe: why we work this way, our main layout and location, some of the advantages we saw in mob programming, and how we work this way, including critical practices such as the team work model The “Pilot / Navigators” that we adopted so that we could work as a “whole team” throughout the day and every day.

2. How we started

We were not going to come up with a new way of working, or expand in some way the idea of ​​pair programming. We just noticed something that worked well for us, and expanded on just that.



Before opening mob programming and accepting it as our main style of work, we followed the practice of frequent retrospectives and constantly worked to improve current situations. We studied pair programming and development through TDD [TDD] testing and conducted practical exercises using the dojo coding approach (coding DOJO [DOJO] - where everyone uses the same computer with a projector and transfers the keyboard in a circle) to practice these skills. Some team members began using TDD and pair programming, along with other new skills in their daily work.



At some point, we needed to prepare to resume work on a project that we had already begun to develop, but then suspended for several months in order to take care of other more important work matters. We gathered in a typical meeting room to take a look at the project and decide how to get started. Several team members and one contractor previously participated in this project, but the rest of the team did not.



During the initial meeting, we introduced each other to the project. We started by looking at some code, tables in the database, documents and some other details of the project. At some point during this review, we started trying some ideas, writing tests, changing the code, and discussing how best to continue. Since we all studied and practiced pair programming over the past few months, it was very natural for us to start transferring the keyboard in a circle while working.



After several hours, it turned out that another group had planned to use the meeting room that we were occupying, so we quickly packed our things and headed for another free room. At the end of the day, we had a mini-retrospective [RETR] , on which we realized that we all consider this experience to be very productive. We decided to organize negotiations the next day so that we could continue to get together and work together in the same way.



We used the same basic principles of collaboration when we moved from the meeting room to the meeting room for the next two weeks. Every day we reviewed how the day went, and every day we came to the conclusion that we want to continue to work “as a team”. We felt that we were rapidly improving our ability to communicate productively, gaining new knowledge and finding better solutions. We have gained a deep and general understanding of the project and the technologies used in it. By this time, we decided to call what we do “mob-programming”.



Our biggest problems were things like the need to interrupt and move from room to room, problems with connecting to the network in some meeting rooms, different quality and usability of computers and projectors, and other similar difficulties associated with moving and equipment. We also found that we were experiencing ergonomic problems such as sore and sore backs and necks due to uncomfortable postures and poor orientation of tables and chairs with respect to the projected screen at the end of the table. We also had a headache due to having to squint on projected screens with low resolution and poor quality.



After the third or fourth week, we were able to find a “permanent” place of work that we could use every day for several months, and began to strengthen some of our work practices. We also found ways to solve ergonomic problems, which I will discuss in the next section.



We have successfully released many projects and improvements over the past three years, from the moment we began to practice “mobile programming”. We now have a permanent working area, and we have made many additional step-by-step improvements to our way of working, but we continue to follow the basic principle of working together, like the whole team, on one computer.

3. Why do we work like this

We work this way because the team decided to work this way. This is an important concept for us: the team that does the work can determine in the best way how to do this work. We were not told to work like that. We have the freedom and responsibility to decide how we want to work. Finding that constantly working together and interacting with each other throughout the day and every day - worked well for us, continuing to do this was the next natural step. We continue to pay attention to what works, and we often “tune and adjust” the process if necessary. Our mantra is “always improve the good,” [TURN] .

4. The main arrangement

The basic arrangement is not complicated, but it is very different from typical office open space cubes. While physical comfort and personal preferences are easy to take into account when working alone in separate office cubes, it becomes somewhat difficult to do the same when most of our work is performed sitting together in a common work area for long periods of time. We found that it is very important to feel psychologically comfortable when we work side by side with each other and use common monitors, keyboards, computer settings and software. We need to consider personal preferences in keyboards, coding styles, work styles, software tools and so on.



Please refer to fig. 1 to get an idea of ​​our basic layout. Our main work area is built from standard partitions and is 4.9 mx 5.5 m (16 ft x 18 ft) in size. There is only one computer that all team members use to write code. We also have two projectors that are used as two monitors on the wall, two keyboards, so that the team members had a choice which one to use, depending on their own preferences. Along the perimeter of the walls we have several boards on wheels and zones for flipcharts. Several desktops and other computers are available for use by individual participants when they do not write code or otherwise use the computer of the main team.





An early sketch on the board of our layout since we had a permanent work area

4.1. Computers

Only one computer is used for programming. All the code that enters the code base comes from this single computer. This computer is also used for writing team letters, design, design, testing and other activities in which the whole team participates.



We also have other computers and laptops that we use for research, for activities independent of the team, for example, to look in the databases or try something, for writing personal letters and for other purposes and tasks that go along with programming. It can often be that not only one person is looking for information about some problem or new technology that we are trying to use. Then we all stay together and constantly communicate about what we are studying.

4.2. Projectors

Dual projected screens



We have two projectors that we use as dual monitors. We project onto a wall that we painted with a special projection paint that is well suited for this purpose. Having experimented with height, distance, brightness, room lighting, wall paint and other settings, we adapted everything so that it suits everyone in the team well. We project onto the wall much lower than typical conference room projectors are usually set up, as we have found that this prevents our necks from sagging and sore. Both projectors are of the same model and of the same resolution. Our goal is to support our screens of approximately the same size, with a common layout, screen resolution and brightness, so that we are comfortable working behind them all day.

4.3. Keyboard and mouse

We have two keyboards and two mice so that everyone can choose what suits him. We experimented with four or five different keyboards, but ended up agreeing on two: regular and natural ergonomic. We do not use both of them at the same time, only one developer works behind the keyboard at any given time, as I will explain later. If some developer prefers a fundamentally different keyboard layout, such as QWERTY vs Dvorak, we find a way to quickly switch between options. There are many personal preferences to consider, such as a right-handed or left-handed developer, trackball or traditional mouse, and so on. Any issue with the configuration that requires one member of the team to work differently than the other member is not a problem if we find a way to quickly and smoothly switch when everyone takes their turn at the keyboard.

4.4. Tables and chairs

Each team member has his own seat, which he moves as we change different roles (pilot or navigator). Thus, we do not need to constantly select the chair settings, and each person can be located as conveniently as possible. Our chairs are comfortable, of good quality and are selected individually for each participant during a special assessment of their ergonomics. Our work surface is a pair of tables that are comfortable to sit at. On the tables are a computer, keyboards and mice, projectors, a telephone, speakers, a hand sanitizer and some other things that we need at hand.



An important factor is how we are facing projected screens throughout the day. In normal meeting rooms, the projector screen is at the end of the table, so almost everyone needs to turn their heads to see the screen. Although it is suitable for short meetings, it becomes very inconvenient when we work this way for several hours or a whole day. In our scheme, the tables are parallel to the screens, so we can look at them comfortably and without stress throughout the day.



We have a magnetic board on wheels, similar to a typical task board that we use to track our work, as well as several other boards and stands, a couple of file cabinets and small tables.

4.5. Personal work areas

Each of us has our own separate work area, which is used when someone prefers to work alone. To do this, we have small desktops in a separate part of the main working area. They are sedentary or standing workstations depending on preferences, and each team member has his own computer, two monitors, drawers, telephone, etc. In personal areas, we can still hear and pay attention to the fact that happens in the main mobbing zone, if we want, or we can wear headphones, or in another way to step back from what everyone else is working on.

5. Several important working practices

With mob programming, everyone is almost always in contact with all the other participants. Although it brings a lot of benefits, but for many who are involved in software development, it is also a relatively unfamiliar way of working. We found that we needed some simple principles and practices that would allow us to stay focused and interact well with each other throughout the day. Our goal is to make it possible for everyone to contribute or study at the level that he considers the most useful for both the team and for himself. And we really think of training as a contribution to the team.



Disclaimer: Although the principles and practices that we have discovered and apply that work well for us, we are always looking for improvements. We also understand that other groups and teams may find that our approach will not work in their context. We suggest trying experiments and innovations, and we are happy to hear the experience of other people who have found new and different ways of working that are well suited to their environment.

5.1. The principle of treating each other with kindness, attention and respect

Every day in our work there are tens and hundreds of interactions between people. The number of interactions increases rapidly when most of our discussions involve five, six, and sometimes even more people, compared to discussions between only two people. We express ideas, discuss problems, look for possible solutions and share thoughts throughout the day. In most cases, we rarely immediately agree with each other until there is an opportunity to hear everyone who has something to say, and until we hold discussions in different directions, expanding our understanding.



To be able to maintain a high level of communication throughout the day, we adopted the principle of always treating each other with kindness, attention and respect. Although it seems simple and straightforward, we believe that a direct recognition of the importance of this principle lays the foundation for our daily interactions. People like me, who don’t really manage to be kind, attentive and respectful, quickly get better when everyone wants to live by this principle.

5.2. Programming Pattern Pilot / Navigators (Driver / Navigators)

We use the Pilot / Navigators [DRVR] pattern , which I adapted from the “strong” pair programming style of Lewellin Falco. The basic rule is this: "for the idea to pass from your head to the computer, it MUST go through someone else's hands."



There are two roles: pilot and navigator. The pilot sits at the keyboard and types the code. Navigators discuss the basic idea that everyone is working on, and guide the pilot while writing code. This means that the pilot has much more mechanical work than if he worked alone. The pilot listens to the navigators and must trust the navigators. And the pilot himself is focused on typing and writing code. Navigators pass on their ideas to the pilot slowly and gradually, so that at every moment in time, the pilot needs to concentrate only on what is next to be printed.



When these ideas are expressed to the pilot out loud, they are also spoken out to all the other participants in the team. We discuss and work on various possibilities both verbally and on the board so that everyone gets a full understanding of the idea. This creates a kind of collective mind for navigators and the team as a whole.



We change roles, based on time, each team member works at the keyboard as a pilot for a short period of time (usually from 10 to 15 minutes). We use a timer, and the current pilot passes the keyboard to the next pilot when his turn ends (for details, see section 5.3 below).



It is important that the navigators speak at the highest level of abstraction that the pilot (and the rest of the team) can currently digest. Sometimes it can be a very high level at which the pilot understands the basic concept and can act without detailed instructions. It can also be a very detailed level, if necessary, if necessary, you can even reach the level of instructions for pressing keys. This will vary from person to person, and will change for the same person throughout the day, depending on the idea that is being worked on, and on the ability of the pilot to understand the instructions.



I found that the Pilot / Navigators approach is very powerful. To follow this approach, we must learn to communicate well and discuss each idea with another person before it becomes part of the code base. We automatically get a continuous discussion and review of the problem, designing a solution and code. Everyone remains involved and informed.

5.3. Pilot rotation (Driver) by timer

We rotate the pilot role every 15 minutes, so that no one remains attached to the keyboard for a long time. Using a randomized list of people who work on this day, we simply go through the list: every 15 minutes the current pilot leaves the keyboard and joins the navigators, and the next person on the list moves to the keyboard to start typing. During the day when we reach the end of the list, we simply start over from the beginning of the list. We wrote a small timer application that keeps track of this for us, and actually turns off the screens when the pilot expires. Although we usually practice a 15-minute rotation, we sometimes shorten the duration and offer those who are just starting to work with mob-programming to use much shorter periods. When we first started, we used the timer for 4 or 5 minutes and increased it over time when our skills and the level of comfortable possession of this practice became more mature.

5.4. Phone and Email

All team-related phone calls and email communications are handled by the team. We sign our letters as a “development team," and we have a separate email address for the team. When we make or receive calls as a team, we remind the other party that they are talking on the speakerphone: "Hi Mary, this is Woody on the speakerphone with some other team members."



One of the reasons why we apply this practice is that everyone in the team should be aware of all interactions related to the team with external people. This solves some of the common “well” problems that arise when there is only one person as a point of contact. When this person is unavailable, the connection is interrupted until he returns. In addition, misunderstandings become less common, as some team members will hear something that other members missed.

6. The Importance of Retrospectives [RETR] and Implementation Decisions

There is one of the principles of Agile: “The team should systematically analyze possible ways to improve efficiency and adjust their work style accordingly” [APRN] . We were very deeply and seriously imbued with this principle and found that it brings us great value. We often evaluate what works for us, what problems we may have, and how we can improve the situation. An important part of the principle is the “tune and adjust” part. Just paying attention to situations, and then “tuning and adjusting”, we were able to develop actions that led to huge improvements and to the discovery of the style of mob-programming.



In most of the retrospectives we conduct, we follow a typical retrospective scheme. We take half an hour to an hour to reflect on the past week or two weeks. In these sessions, we collect information on stickers, join groups, use voting by dots and discuss what we observed and something new that we would like to try [RETR] . We tried to use different techniques, but most often we do some variation of the format “What works for us”, “What needs to be fixed”, “What we want to have less”, where we collect ideas on each of these topics and explore those points which we consider the most significant for the team.



We always try to come up with “specific actions” and limit ourselves to only one or two of those actions that we can use to “adjust and adjust” our process. We found that trying more than one or two specific actions is almost always unproductive. We move in "small steps", checking that the changes we are trying to make will be useful in our opinion, and then reflect on, adjust and correct them.

6.1. We often hold impromptu retrospectives in the moment

In addition to the planned retrospectives, we conduct retrospectives at any time when we consider that it will be useful to us. When someone on the team notices something that seems worth considering, we just get together and do it while the experience is fresh. Usually these retrospectives are short and focused on one point or another. Also, the point is not always to “fix something”.



Besides marking problems, there is the same chance that someone will notice something good that just happened, or just something that seems interesting to us. If there is a specific action that, in our opinion, we should take, we create a note for it and put it on our board along with other steps and actions.

6.2. Lean Coffee Format [LCOF]

We often use the Lean Coffee format for some of our retrospectives. This is an easy way to lead the discussion actively and to the point. The main message is that those present determine the agenda at the beginning of the meeting, and each topic discussed is limited in time to 5 minutes or so. This keeps us in focus and keeps conversations from drawing on. We found this to be a very effective approach to covering a large number of topics in a limited time. Usually we devote 45 minutes to a session in Lean Coffee format and strive to find specific actions and steps for everything that we discuss and that require new decisions. Applying here too our principle of treating each other with kindness, attention and respect, our Lean Coffee sessions are always significant for us.

6.3. “Improve the good” [TURN]

We found that we get great value when we determine what is going well and look for ways to improve it. We call it "improve the good." Although it may be useful to identify problems and try to solve them, we find that we get even more benefit from finding ways to improve those things that are already going well.

6.4. Execution of decisions

In order to get real benefits from thinking and conducting retrospectives, we need to follow the decisions made and take specific actions. We always discuss possible actions and choose a few of them that we want to try in order to move forward. Some actions give good results, and some do not. We pay attention to these results, reflect on them, adjust and adjust over time.

7. Disappearing problems [FADE]

After we worked for some time in the style of mob-programming, we noticed that many of the problems that we had previously encountered no longer affect us. Although we did not directly try to solve these problems, we noticed that they simply gradually disappear.



We recalled each of these “disappearing problems” and compiled a long list of specific problems that we had before, which either no longer affected us or became a much smaller problem for us. Although the specific problems are likely to vary from company to company, we have found that these problems can be grouped into several categories. Some of the main categories are counterproductive communications, dysfunctions in the decision-making process, unnecessary expenses beyond what would be enough, a debilitating disease of technical debt, as well as hardships and the associated loss of hard management methods (assessment, prioritization, scheduling, queuing, performance reviews, etc.). Other categories of problems are the loss of focus and efficiency caused by programmers overloading unnecessary switching between tasks, interruptions, harmful aspects of workplace behavior policies and the harm from “meeting management” with its inherent separation of decision-making from knowledge creation. Most likely, there are other categories of problems, and I listed these categories here just to give you an idea of ​​what kind of things we noticed.



Using Agile in software development solves all these common problems, and mob-programming supports and enhances Agile’s advanced work style. We use both the Agile Manifesto Philosophy [AM] (values ​​and principles) and Lean Thinking [LEAN] Lean Thinking concepts to select the practices and methods that we use or want to try. This happens almost automatically, simply “improving the good” in interaction with each other and working as a whole team as a team. For example, face-to-face communication and teamwork naturally occur, as well as decision making, when we all sit together during the day. In addition, fear and “analytical paralysis” that impede effective decision making are reduced or eliminated when we make decisions in an environment where everything is transparent and there is quick feedback, which allows us to quickly check the results of our decisions.



We believe that the improvements that we are observing have occurred due to constant cooperation and communication in our work style, automatic application of the principles of “WIP restriction (number of tasks in work)” and one-piece flow principle (about the flow of single products), frequent releases of software providing quick feedback, as well as conducting frequent and meaningful retrospectives for us. More information about these disappearing issues was written in a recent blog post [FADE] .

8. Productivity

One of the first questions people ask about mob programming is something like this: “How can five or six developers be productive with this kind of work? Wouldn't it be more productive if they worked on different things? ”



Although it seems to us that we have become much more productive by working in this way, it is not easy for us to prove that this happened only thanks to mob-programming. If we take seriously the principle of the Agile manifest “A working product is the main indicator of progress”, we may be able to evaluate our productivity by comparing the number of projects put into use one year before the opening of mob programming and a year after we adopted this work style: the number of completed projects has increased about ten times. There are many factors that we do not take into account when using these measurements, such as the size of the project or the number of features and the amount of functionality.Although this general comparison is important for ourselves, based on our knowledge of the work associated with these projects, it may not be significant for anyone else.



Although we believe that we had a significant increase in productivity, we do not claim that this will happen again in any other conditions. Here many factors influenced. For example, before mob programming, the traditional model of phased waterfall Waterfall was used in this group as the previous development methodology. The developers worked alone and on individual projects. Just moving from a similar methodology to an Agile approach can already lead to significant improvement.



Although performance is important, it is no more important than working on the right things. Testing our ideas and results, identifying values ​​and good communication about what we are working on increases our chances of obtaining valuable results. Maximizing the amount of work done by focusing on simplicity and finding “barely sufficient” solutions eliminates losses. The simple execution of a large volume of work brings little value if the result of poor quality is either unsupported and not expandable, or not suitable for the intended use, or if the use itself is of little use to the end user.

9. The factor of happiness

Another aspect of our work style is that every day we come to work charged and inspired to work together. Although few could claim that they are “living to work,” we believe that our lives are greatly improved because we work together as a team. We call this the "factor of happiness." We take a very sustainable approach that retains our commitment and interest in our work. We pay attention to our physical and psychological health and strive to create an environment where everyone can succeed in their work, as well as succeed in their lives. This helps us to think with maximum efficiency and invent the best solutions that we are able to create. We all constantly improve our career opportunities by studying and developing skills and abilities.We have a common sense of happiness and self-fulfillment at work.

10. ,

Mob programming provides an environment in which continuous learning takes place. Typical programming skills are easily revealed and learned when we observe how each of us writes code. Everything from keyboard shortcuts and programming language functions to design patterns and business concepts is open and accessible and spreads throughout the team. An interesting side effect is that we all learn to be better students and teachers, better ask questions and answer them. Regardless of the level of experience that each person possesses, each of us has endless opportunities to discover and study things that are significant for our own improvement.



In addition to the intensive training that occurs naturally as a result of teamwork, we also daily“Improving the acuteness of our knowledge” [S & R] , spending the first hour of the day in a group training session. In addition to this, we conduct an extended training session on Fridays to provide more intensive training for two or three hours. In our daily training sessions, we choose some aspect of programming, which, in our opinion, is a weak point for us, and devote an entire hour to studying it. We usually conduct training in the form of a workshop or workshop using a dojo coding approach similar to our style of mob programming. We use any technique that can help, for example, working with a code kata, watching online video training, studying a book or researching some interesting algorithm and some new technology.



Since we work in very short iterations per day or two days, it is easy for us to experiment with different ways and methods. We monitor every aspect of our work that we can automate or simplify, and try to use any approach that, in our opinion, can work. This includes both programming and process related ideas. For example, if we have several ideas for solving a problem, but the team does not have a clear margin of opinion and a clear winner among the ideas, we will try the minimum version of each solution and see what we like best. The cost of experiments is relatively low, and the return on them is often many times greater than the time spent.



One interesting thing that we noticed is that when we add new members to the team, they almost immediately bring new ideas and programming skills to the teamwork. And vice versa, they will quickly learn the details and specifics of the project we are working on, and “learn as they contribute to the work”; the new developer benefits, while at the same time learning all the intricacies of the business logic that we are developing. It also appears when our visitors join the team for one day. We had many cases when our guest began to contribute to the programming and generation of technical ideas within 10 minutes after joining the team.

11. Some things to watch out for.

Working in the style of mob means that all our weaknesses are put on display. Everything we do is visible to everyone on the team. This may seem so uncomfortable to some people that they will not be able to work this way. However, despite the fact that it took us some time to achieve this, all members of our team were able to adapt to such constant and close attention and being in full view of everyone. We all understand that we undertook to treat each other with kindness, attention and respect, therefore we are not as vulnerable as it might seem at first glance. While some people are more experienced or more capable than others, we are all a little imperfect, and we all have something in which we do not feel confident to show it to others.



To make it easier for everyone, we do not insist that people take part in this style of work if they are uncomfortable. We expect everyone to do everything in their power, but we do not force anyone to sit and work with the team. This is everyone’s personal choice. Everyone is invited to join, but you can work alone if someone so desires.

12. Health and ergonomics

We understand that working closely with others can increase our chances of spreading germs and diseases. To reduce the likelihood that we all will get sick at the same time, we have enough space so that everyone can sit far enough apart, without sneezing or coughing at each other. We also hold a hand sanitizer on the table to use when changing pilots at the keyboard. When one of us is sick, we urge such people to stay at home. If they want to work, we make them work from home, rather than spreading germs throughout the team.



It is also important to pay attention to ergonomic factors. We are working on the identification and elimination of problems that impede the creation of a comfortable workplace without stress. For example, we have different keyboards to accommodate everyone’s preferences and try to help with repetitive stressful situations. We pay attention to avoid recurring stresses, headaches and eye strain, and make all necessary adjustments. Our rotation helps to limit the time spent working on the keyboard and mouse. Everything is set up at us in order to be able to work comfortably and often change our position. As I said earlier, each of us has our own chair, adapted for ourselves. We move our seats to the keyboard when it’s our turn to take the pilot’s seat,which helps us maintain a comfortable posture without the need for additional adjustments.

13. What is the ideal team size?

This is a frequently asked question, and we do not have enough information to answer it. We are currently working with six people in a team. We had only three people, and even twelve who worked together in the style of a mob, and we found that we were able to be productive. Nevertheless, we use empiricism to experimentally understand “how much will be too much”: for everyone who does not feel that they are contributing or learning something, we see this as a sign that there may be more appropriate now time for independent work, or to team up, or with several other people to start working separately in the style of mob-programming.

14. Do you recommend mob programming?

People often ask if we recommend mob programming. We have found that this style works well for us, and it may also work in your case. However, instead of recommending this, we simply share our experiences. We really believe that it is worth exploring this concept and see if any of its parts are applicable to you. Who knows?This may end up working well for your team.



There are a number of teams around the world that are experimenting with mob programming, and several of the teams that we have heard of work this way every day or several times a week. We often get information from people who use this style of work when they have to solve urgent or especially difficult problems, and I added below links to several articles written by other authors about their experience [LINKS] .



One of the concepts that I consider important is that the team must decide if this is right for her. Most likely, it would be inappropriate to require that someone necessarily work in this way.



For those who want to try mob-programming, I would say that it would be useful to have preliminary knowledge and experience in such areas as pair programming, work in the style of one-piece flow of single products, development through TDD testing, continuous delivery / CD release / releases, retrospectives, Coding Dojos dojo coding, clean code Clean Code, and other Agile and Lean concepts. Nevertheless, all that you need can be learned in the process of work, if you are committed to the principle of treating each other with kindness, attention and respect.



We want to inspire everyone to become better at conducting retrospectives that are meaningful to you, paying attention to what works and experimenting with how to “improve the good.” If you decide to try mob-programming, I will be glad to know about your experience. Also, if you need help, just let me know - I will be happy to help than I can.

15. Acknowledgments

First of all, I want to thank those members of the team with whom we first discovered mob programming: these are Dexter Baga, Gordon Pu, Chris Lucian and Dan Yong Wong. Without their commitment to pay attention to what works, and always “improve the good”, we could not find such a wonderful way to work. I would also like to thank my boss, Mark Keyes, who has the wisdom and foresight to recognize the strength of the Agile principle: “Motivated professionals must work on the project. For the work to be done, create the conditions, provide support and fully trust them ” [APRN]. I also want to thank Aaron Griffith and Jason Kearney, who joined the team after we started using mob-programming, made a great contribution to its work and became excellent team members.



I owe a lot to Lewell Falco for his disinterested exchange of knowledge on every good thing he finds, for his ability to discover a lot of good things and his indispensable habit of always looking for ways to help others than he can. I learned from him the model of “strong” pair programming “Pilot / Navigator”, as well as the concept of the dojo coding. I also learned a lot from Lewellin about pair programming, development through testing, working with legacy legacy code, testing with ApprovalTests [APPR]and software development in general.



I am very grateful to Joseph Yoder [YODER] , who was my mentor on this article. Without his help and guidance, I would not be able to turn my tangled set of ideas into a real job. Everyone should have a chance to work with Joe - he is a true professional.