XP As a People Process

Agile methods have a much higher emphasis on people than previous methodologies. This is a very good thing: Agile proponents recognize that a large proportion of a project involves people in some way. People are the primary ingredient in any development process. It takes people to do programming, designing, requirements gathering, object modeling, testing (including writing unit tests), and so on.

However, the terminology that accompanies agile methodologies can leave many people cold (particularly techie types, whose personalities lead with logic, perception, and intuition). For such people, the fluffy people processes appear, relatively speaking, like a hippie love-in. Most distasteful! Let s all sit down and respect each other? Show compassion for incompetent programmers? [Sound of logical person spitting feathers.]

The Hippie Love-in Scale of Agile People Processes

People processes are definitely beneficial because they address a major aspect of software development that has been neglected (partly because of the cultural aspect: Programmers by nature tend to be cold, impassioned, logical beasts. We should know, we fit into this category and we re plum proud of it). Those programmers who get past their natural distaste of the fluffy people terminology get to understand better the dynamics of the team that they re working with, and in so doing fine-tune their software process according to the people involved.

But of course, that s really the problem: At the very core of software agility, there s something that a great many programmers must get over if they re to accept and benefit from the wisdom that agile methods teach. The height of this particular barrier varies between methodologies ”in other words, some methodologies are better than others at getting the point across without turning away their audience.

Scrum, for example, is an agile methodology that s concerned much more with how to manage talented staff than with precisely what the staff should be doing. It makes no allowances for less capable staff; the sentiment is very much that everyone on the team must be pulling his own weight. As with any project, there s no room for freeloaders. Scrum is actually a rather pragmatic methodology, both in its practices and in its relatively hippie-free terminology. ^[8]

By contrast, XP is significantly higher up on the California hippie love-in scale. XP has specific practices that allow for the weaknesses of lesser-abled programmers. Pair programming (a very people-oriented practice) is one such example. In an XP project, everyone must program in pairs for all production code so that mistakes are caught by the programmer buddy. Another example is collective ownership: No one programmer (or pair) is singularly responsible for any section of code. ^[9] In fact, programmers are moved around frequently to work on different parts of the project. This has the joint effect of increasing general awareness of the design (so there are no specialists in the team) and catering to the weaknesses of lesser programmers. Any bugs being introduced by a low quality programmer will (sooner or later) be discovered and fixed by somebody else.

As we explore in Chapter 3, the prescribed people process aspects of XP reduce its applicability to some projects and organizations.

 

Not everyone will enjoy working under such conditions. Pair programming and collective ownership are both mandatory and pervasive parts of XP. If you introduce XP into your organization, expect there to be some cultural differences at best. At worst, expect some programmers to leave (either the project or the company) in disgust.

Of course, some programmers will love the new way of working ( especially those whose code is traditionally riddled with bugs). The danger is that, whereas such people should be weeded out of any organization, or at least moved to a nonprogrammer role, an XP project gives them sufficient cover to continue to program. The process shields the people from blame.

Paradoxically, the opposite can also be argued: that XP leads to a tendency to blame the people, not the process.

IfXPIsntWorkingYoureNotDoingXP

For a clue as to why this section title s WordsAreRunTogether, see the section Big Words Like Constantinople and TerminationCanBeSuccess later in this chapter.

 

Luckily, if you re a manager of an ailing project, XP gives you the opportunity to blame the entire team, pretty much:

Extreme Programming sees itself as a ˜ humanistic discipline of software development . Project problems are mainly people problems, as Gerald M. Weinberg once pointed out: ˜No matter what the problem is, it s always a people problem . However, it is highly doubtful to solve people problems with a process. If that was possible, you could establish the right process and all problems were solved . This is a false impression Extreme Programming seems to create. Even worse , there are indications that Extreme Programming leads to a tendency to blame the people, not the process. ^[10]

This can t fairly be blamed on XP itself, but rather on people s interpretation of XP. The problem is that XP is so steeped in people practices that if something goes wrong, then it clearly must be the people s fault, not XP. An XP project compensates for the weaknesses of its programmers; therefore managers, initially at least, are much more likely to take a forgiving approach to their staff members , even the incompetent ones. So an XP project kicks off with a small but enthusiastic team that includes one or more incompetent programmers. What happens next ? The project fails, having spent months or even years spinning around in refactor land. And so the search for the guilty begins. The programmers are caught red-handed. With a low-risk process like XP, how could the project have possibly failed? It must have been the people! So the team gets unceremoniously fed to the ducks , and XP comes out shining.

So if you re a manager who loves to cover your behind, fully expects your next project to fail, and is looking for a way to come out of it stinking of roses, then why not give XP a try? I gave them all the snack food they could possibly want . . . I did my bit!

The indications that XP leads to a tendency to blame the people, not the process, can also be seen in the comp.software.extreme-programming newsgroup. When somebody describes a failed XP project, the response is almost invariably along the lines of You weren t doing such-and-such, therefore you weren t really doing XP. Ergo, XP isn t to blame. You can find a lengthy discussion of this aspect of Extremo culture on the Wiki site at http://www.c2.com/cgi/wiki?IfXpIsntWorkingYoureNotDoingXp.

However, it s generally accepted that XP is a high-discipline methodology, meaning that it takes a great amount of consistent effort to keep to the straight and narrow throughout an XP project. If you set someone an impossible task, which she will of course subsequently fail, was the person really to blame for failing?

Similarly (while we re in unanswered questions mode), if you set out to use XP on a software project but end up not using some of the practices because they re just too difficult (perhaps in the context of your project), does that count as an XP failure? Or is XP exonerated because the team wasn t performing all of the XP practices? (We leave this one open as a basis for discussion.)

Another danger of XP s own special people-oriented approach is that it becomes too inward focused. That is, the team is busy refactoring, redesigning away, moving between tasks , spending all its time concentrating on how cool the code is. The team s only contact with the outside world is the on-site customer, who also spends all his time buried in the project (in the same room as the programmers). A good process needs to encourage the team to look outside the project (by spending sufficient time analyzing the target business environment, the user s actual goals, the real problems behind the customer s stated requirements, and so on). A team that spends all its time looking in really needs to look out.

Taking the People Process to Extremes

A people-oriented approach is definitely a good thing. However, a process that immerses itself too far in the people aspect risks losing sight of the fact that human weakness is a bad thing (in a software project, at least).

For example, XP tells us to spend time writing unit tests for all important classes and methods, so the computer can tell us when we get things wrong. XP also tells us to program in pairs to catch each other s mistakes. And XP tells us to keep revisiting and redesigning our code, because we re bound to have got the design wrong.

These safety nets are all great things, but as with most things in life they don t come free. They add time to a project, and that s time that a decent team could put to much better use ”for example, designing and writing new code rather than going round in circles in refactor land.

It s a very good idea for a process to try to compensate for human weaknesses, but the XP practices in many ways actually make the problem worse. By eliminating too many of the steps before code, and thereby the ability to review designs before code, we actually reduce our ability to compensate for human error at the design level (a higher level of abstraction than code). So XPers end up refactoring code all day to nudge it onto the next design. Of course, they wouldn t have to spend all day refactoring if they had designed the thing properly in the first place!

Compensating for weak staff is good and beneficial up to a point, but the practices we put in place to do this usually aren t free ”and particularly the XP ones aren t. Because of this, we need to draw the line somewhere and say, Okay, we ll only hire programmers who not only know how to program, but also are good at programming, designers who know how to draw and visualize diagrams and so on. If we do this, then we can free up more time to place safety nets in more appropriate places.

To what extent do we really want to cushion our projects to compensate for substandard programmers? Programming is hard. Don t let anyone tell you otherwise . This very fact riles those who believe that we re all equal, or should be. The requirement for intellectual rigor and capability is in their eyes inherently elitist: Little Timmy may be slow, but he s got a heart of gold. Put him in QA.

We re all human ”we all need safety nets, to an extent, and a process that helps to cushion our day-to-day mistakes is definitely a good thing. However, the next time you watch the Olympics, if you see the championship swimmers splashing about in the water wearing inflatable arm-bands, you ll know that the world is starting to mollycoddle itself just a bit too much.

XP and Snack Food

GROUCHO  

˜There must be food is a core XP principle, and Chet and I have our dials set to ten on that one. ^[11]

Snack food is an important part of Extremo culture, as the following Voice of eXPerience section suggests. The core principle is that teams find it easier to concentrate when there is plenty of snack food on the table in front of them. We have to wonder whether snacking instructions really have a legitimate place in a software methodology. In fact, it seems that, in XP, snacks are specified more carefully than requirements. Hmm . . .

VoXP
Voice of eXPerience: Snack Food

This description is from an XPer who wishes to remain anonymous. This is probably the one situation in which you might want to let a couple of XP snakes loose.

Thought you might find this interesting. As you know, XP labs are encouraged to have snacks. Well, not surprisingly, we finally have mice. When they found him the little mouse got startled and started bouncing off the walls trying to find a way out, so they let the poor bugger out into the hall to find another stash of XP snacks. Today the building and facilities maintenance group sent out a companywide e-mail (to all 3,000 or so employees ) announcing that we have a serious rodent and bug problem and they are taking care of it. I wonder why?

(My employer doesn t take animals too lightly. A possum managed to shut down the system some time back by chewing through a data wire, in spite of the fact that the data systems are located in an underground bunker.)

 

Code Hound

(Sing to the tune of Hound Dog by Elvis Presley)

You ain t nothin but a code hound
Smellin code all the time
You ain t nothin but a code hound
Smellin code all the time

Well, the C code smells like whiskey but the Smalltalk smells like wine

You ain t nothin but a snack hound
Snackin all the time
You ain t nothin but a snack hound
Snackin all the time

If you keep eatin those donuts you will get a big behind

Better watch out code hound
Cause you re wasting too much time
Better watch out code hound
Cause you re wasting too much time

You know if you start snortin
Java you just might lose your mind

VoXP
Voice of eXPerience: No One Touches His Drink Unless I Say So!

by David Van Der Klauw

My department forced all software developers to do eXtreme Programming in an extremely rigid fashion they called Vanilla XP. Vanilla XP involved rigid adherence to the 12 XP principles, 7 hours of pair programming per day, no solo programming, and loss of personal desks and PCs.

Criticism and abuse were rampant during the implementation of Vanilla XP. In one ridiculous incident, a team was admonished for taking too long to have coffee and thereafter banned from having coffee before 10:30 AM. Most of that team quit the company soon after.

 

For our take on snacking and XP, see the section The XP Society s Annual Picnic in Chapter 12.

 

^[8] Although, Scrum does have its own language that is mostly derived from Rugby and is admittedly not to everyone s taste.

^[9] Mr. Cynical reminds us that this also means no accountability when something goes wrong! Now, that would never appeal to a cowboy coder ”would it?

^[10] Gerold Keefer, Extreme Programming Considered Harmful for Reliable Software Development, http://www.stickyminds.com/sitewide.asp?ObjectId=3248 & Function=DETAILBROWSE & ObjectType=ART , February 6, 2002.

^[11] Ron Jeffries, Adventures in C#: Ship It, http://www. xprogramming .com/xpmag/acsShipIterationOne.htm , August 31, 2002.