What qualities should this specific team have? First of all, its members must have the necessary technical skills that will enable the delivery of content. One important member of the team should be someone with analytical skills, someone who will analyze the entire project and its requirements and check for completeness. Another important member of this team is a software engineer whose main task will be to design the architecture of the solution. Another member of the team is a programmer who will write the solution. Another person has to be a tester, who will check for errors in the solution. Sometimes, one person can have all the required competencies in all these dimensions. Of course, it may also happen that a few people are needed to fill all the skills required. Some may also be better in some skills while being weaker at certain aspects than the rest of the team. It seems really very complicated, but in reality it is not. How is this done in the real world? Well, in the case of building such teams, people are usually chosen from different departments who then sit together to learn to work together. However, no one mentioned that the way to forming a good team is lined with roses. Forming this type of assembly will certainly require some time and patience. In addition, you may encounter a few problems along the way, but in most cases, the solution may be easier than the team first imagined. Is creating a good team enough? Will this type of team be able to complete each and every project? Usually, there would be no major problems but that’s not always the case. Consider what a finished project really is. The end of the project primarily signifies one thing, namely, the release of a fully operational and ready-to-deliver product. This means that all parts of the product must be fully integrated. Usually this is not a problem when one or two development teams are working on a project. The project is usually integrated in a continuous manner so that the product is fully and easily managed, which creates a situation where teams do not enter each other’s way. The situation is much more complicated when more teams are working on a project. The integration of individual modules is usually a serious problem in this case and very often, despite continuous integration, everything takes a lot of time which causes a lot of errors. Why is this happening? In the case of real-life projects, good communication really determines the success of the project. Good communication also quickly fixes common goals and ensures that the vision of the product is very clearly presented. The team must begin to perceive the product as a whole and not just look at the modules that they are currently working on. I’ve thought a lot on how to remove barriers to communication between teams and how to minimize the scattering of knowledge. Well, I came up with a way in which this can be done easily. The solution of this type is Collective Code Ownership. What happens in this is that the programmer is not only the owner of his own piece of code, but of all the code to enter the build system. In fact, to build a good team that is able to deliver software on a decent level, you need more than the exchange of experience and skills to the level of competence. What is needed is a very good agreement at the level of knowledge of the product being built. What are the main problems of this type of team? Usually, the problem is the excessive complexity of the product architecture. This is a problem that really can not be avoided. Most projects are actually increasing in pace at an alarming rate. Usually, they do not have an idea or a vision, or an architecture that would be able to become independent from each individual components or modules. And that’s when we are dealing with a situation in which the dispersal of knowledge about the product becomes impossible. We can then say the same about the dispersed knowledge skills of the individual members of the team. That does not mean that you can not try to perform this operation. In my humble opinion, it is always worth a try. Later this may actually be the right path. Perhaps a full spread of knowledge about the product between the teams would give us a place of chaos, creating a coherent vision of the architecture of all solutions. As a result, all subsequent refactoring will always run in a certain direction. Sometimes you may find that we have set up a team with members who can complement each other in spite of everything. Sometimes we can do this in two ways. And as it turns out, it’s not the end of the fun of building a team. Only then does it begin. If you have a band, you still have to do one very important thing; namely, we need to make all of the requirements fit in a special way. Of course, we should be doing this from the start. All requirements should be fulfilled in all layers and components of the created system. Of course, this is also not too complicated. Creating the system requirements in the form of User Stories is enough here as well. In the case of small projects and small teams and their products, most people do not feel any of the problems described here. However, in the case of larger teams, you’re probably already wondering what the benefits of having a fully-functional team are. But that’s not all. Let’s move on. How did I come to a technique that actually works? I once had to deal with a project where there was a lot of new people and I was wondering how to implement the project. Normally implementing each project takes about 6-7 months. Then, there’s also the project costs. So how can you reduce costs and accelerate the deployment of people for new projects so as to shorten the whole process of implementation by several days? I decided to try one of the aspects of extreme programming, namely programming in pairs. Now analyze this situation. The company is in great need and begins to employ people who are only able to type on the keyboard. Most of these people have never before participated in the automation of testing and programming. So our company offered training for the new employees. At the beginning, the training will last 5 days and then they will be moved to a small number of test groups. The material that they were given was enough for five days of intensive work, and sometimes there was noth enough time to bring us to the end of the topic. So we started thinking, what is wrong and how to accelerate? At the beginning we went completely the wrong way, that was not really of any value. We started to revise the training program and wonder if there was anything we can connect with each other. Afterwards, we just completely cut out a part of the training program. Hooray! We were then able to finish the entire three hours of training before the final whistle. It was not at all a small accomplishment, but for us it was still not enough. How can we actually improve the absorption of the material? How can they start to program in pairs? How does it work out in practice? The next training was planned completely differently. We planned it again as a five-day program, but we made the material for the next two days, because it required the management of the company. Programming in pairs turned out to really be our last chance and hope. And you know what? It worked. We finished all of the material in less than 4 days, and the last day it took us to the same conclusion. How is it organized? After a quick introduction of the theory, we divided the entire group into pairs. For this, we used a great portable random number generator, namely twenty-sided dice such as those used for Dungeons & Dragons. During pairing, we set two groups of people. One of them consisted of people who had already written code and automated tests. The second group were those who sat for the first time in front of the keyboard. So the only criterion for the distribution of the team was the level of experience. Even before we finished, we got to see one thing. Namely, the most effective are those couples where one developer was very experienced while the second was at a much lower level. And it worked exceptionally well. So we used a different variant. Namely, we tried to balance the level of two people sitting at the keyboard, which turned out to be a hit. The two people of each pair worked at the same computer. Every 10 minutes, or a maximum of 20 minutes, heard the alarm timer, which was a signal that the people have changed the keyboard. And so it has. That’s what happened, it was almost impossible to describe. On the first day of training, people approached the topic with great enthusiasm. We were surprised at the volume of discussion. At the end of the first day, we knew that we went the right way. Namely, we’ve covered most of the material from the second day of training. After lunch on the fourth day, we had three hours to repeat. The fifth day was completely devoted to them. In addition, we solved a lot of problems of the participants. We did it! A few comments on programming in pairs Here proper selection of pairs is important above all. Always, when we are dealing with people at a similar level, they learn much faster. In a situation where one person is better, one of them is usually bored and frustrated while the other is sitting at the keyboard. In a situation where the other person is programming, usually the weaker just can not keep up and understand some things. In fact, only two people at the same level are able to learn at the same time and bring both of them satisfaction. A fixed time change also creates a rhythm. Frequent changes at the keyboard lead to a situation where the person sitting on the side had no choice and had to be really actively involved in programming. She was performing a flight navigator role, and she could not afford to lose out because then the implementation of the work would take too long. Working in pairs was also very tiring. Every 45 minutes, each person needed a 10 to 15 minute break, and after 6 hours, all participants were exhausted. Working in pairs also blocks all distractions. Pairs effectively combat all the same crap, such as checking their e-mail or browsing Facebook. People simply do not have time for this, because other couples too quickly went to the front and then it would be very hard for them to catch up. It also turned out that programming in pairs poses less of a problem than it seemed at first. Couple alone solved most of the problems by using Google or manuals. Summary As you learned in this method of team building, interpenetrating skills and pair programming is able to solve most of the problems faced by most companies during product development. As it turns out, it is best to combine it all together: teams of interpenetrating skills, collective code ownership and pair programming. I’m doing all of this in my projects and it turns out that I raised the amount of work done. With 30% of projects completed, I raised the threshold to 50% or more, compared to older methods. Do not worry that so many projects would end in failure. It is the natural order of things, that once something is successful, and all other ends fail.
