Shortcomings


At the time of this chapter's final revision, we have practiced mob programming about ten times. It has not been an unmitigated success. In this section, we discuss the problems we have encountered.

First of all, we have had trouble following our own guidelines. For instance, it has always been clear that good preparation, in the form of previewing, has a strong effect on the quality of the meeting. However, only once or twice have we found someone sufficiently motivated to complete this preparation thoroughly. This points to a potential weakness of our practice. Mob programming, in some ways, stretches the principle of doing what is natural. For a quality meeting, some discipline is necessary. We are still searching for a degree of discipline that works for our team. It is not clear whether the team will eventually find preparation more natural, or whether we will find a way to avoid preparation. This is an important point. It is not just our guidelines that evolve, but also the team itself. This should not make us uncomfortable. Shooting at moving targets is an integral part of the XP experience.

We have also discovered that people find it difficult to remain focused, especially those who are not driving. The mob plays a role that is not as well defined as the driver role, so it is easy for a mob participant to feel useless during mob programming. Having more than two programmers in a group leaves the other members of the mob to daydream, to have other, unrelated conversations, and so forth. Unless everyone in the room feels engaged in the practice, the mob inevitably becomes unruly. How, then, could we change the format of mob programming so that we engage everyone? We have not yet found an answer to this question. The lack of engagement may be exacerbated by the fact that the team does not seem to have bought the idea of mob programming completely. At this point the costs are clearer than the benefits. We will expand on this greater issue at the end of this section.

When searching for ways to improve mob programming, we have so far found it difficult to get feedback from the rest of the team. This may just be because we have not been practicing it for very long, and people have not made up their minds one way or the other. However, we also wonder if perhaps this is because the group sees one of the authors (Moses) as the motivating force behind the meetings. We have some evidence that people feel reluctant to criticize the process because criticism may be construed as criticism of Moses.

The Role of "Coach"

One inadequacy of our chapter so far is that we have completely ignored an important role in the whole process, and that is the role of "coach" (to use Beck's terminology). This role, during and surrounding these weekly meetings, has consistently been played by Moses. All the developers on the team see these meetings and especially see mob programming as "Moses' baby."

Moses has made a number of probably classic coaching mistakes that can be summarized as leading too directly. When no one volunteers to act as a previewer, he does it himself. This can lead to this work being done at the last minute and not very thoroughly, because the burden is not shared. Because Moses is excited about seeing these ideas put into action, he often takes too active a role in the process. He is usually one of the drivers during mob programming.

This is clearly problematic. These meetings, in whatever format, will never work if they are not a creative and experimental process for the team as a whole. We have begun to see improvement in this area, however. Several months ago, the meetings would not occur if Moses were out of town or otherwise too busy to organize the meeting. Today this is no longer true. More regularly we observe other developers suggesting and implementing new ideas for improvement, both during the meetings and outside of them. Progress toward group ownership of this process takes time, and we believe we are beginning to see it happen. New ideas may take us completely away from our current format, but succeeding at mob programming in particular is certainly not the point anyway. It is far more important, and more in line with our goals, that we succeed at doing something owned by the group, developed interactively without one person at its center.

Sometimes, after a particularly unproductive meeting, we wonder whether we should continue having these meetings at all. If they began as unproductive presentations and have resulted in chaotic attempts at mob programming, have we really found anything of value? We believe that the answer is undeniably yes. We base this judgment on our observations of the changes in team behavior not only during developer meetings, but also during our day-to-day operation.

At the first meetings, no one talked except the presenter. Today our meetings are chaotic because everyone talks, and people are usually talking about code. They may not be talking about the code under discussion, but they are talking about code. The fact that at our last meeting four people other than Moses began a discussion criticizing mob programming and seeking a remedy is significant. These people saw the meetings as theirs to control.

Outside the meetings, frequent informal discussion has become markedly more common, even commonplace. We have also become bolder. Recently we used a developer meeting to discuss our level of commitment toward XP practices compared with our current level of achievement of those practices. We decided to speak with our project manager to put a plan in place to carry out the last half of our current release in three two-week iterations, with tasks estimated by the team instead of by a manager. For the first time in the history of our project, most of the development team participated in the planning and feature estimation part of our development process. Our team has become noticeably more courageous, more collaborative, and more open.

We can thus see our meetings, in whatever format, as a "generative" process a process that "produces the generated quality indirectly" [Gabriel1996]. Meeting together every week to invent and experiment with practices of our own design has changed us as a team. We have not only gotten better at designing and carrying out these practices, we have become closer and more capable as a team. These benefits cannot be attributed solely to our weekly meetings, but the meetings have played an important role.

Finally, we add that when we actually followed our guidelines for mob programming, the process went relatively well. Also, during periods when we have done less mob programming, we have found that less progress was made toward better and more complete testing.

We have decided to continue to pursue mob programming with two improvements. One, we will complete the necessary preparation. Two, the coach will coach more indirectly, yet more firmly (for example, more consistently enforcing the preparation). We have also decided, as a team, to alternate mob programming with other formats. We want to give mob programming a chance to succeed if it can, while experimenting with alternatives.



Extreme Programming Perspectives
Extreme Programming Perspectives
ISBN: 0201770059
EAN: 2147483647
Year: 2005
Pages: 445

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net