2.5. Transactional Analysis in Software Projects

Henderson-Sellers [1997], in his Book of Object-Oriented Knowledge, discusses the comparative growth of interest in objects: “Why all the enthusiasm for object orientation in the last five years or so when the object-oriented languages have been around for over 25 years?” Indeed, object technology finds resurgence in the new millennium due perhaps to plummeting hardware costs, supporting software such as operating systems being able to cope with objects, and of course the ability to model objects uniformly and effectively through the UML. We, the IT community, had no hesitation in embracing object technology despite its remaining dormant in the business arena for more than two decades. Even the UML, as is well known, came out of our attempts to discipline object-oriented development after it was well on its way to becoming a popular development approach.

Based on our discussions thus far in this chapter, it is obvious that objects and components bring with them as much sociological phenomena as technological. While psychological considerations in quality of software projects is not new (seen as early as Weinberg [1971]), on the sociological front, a resurgence similar to that in the object-technology field is happening in the fascinating field of Transactional Analysis. While being a part of standard management curriculum for decades, its practice in software projects is becoming more interesting in the last few years.

I have personally used this approach in practice [Unhelkar 1999] and found it deceptively easy and effective to learn and use, and most rewarding in managing multiple project teams. A practical software project manager has a limited time to learn psychology and sociology. That is where I found Transactional Analysis helpful and rewarding. This book is not the place to delve into the detailed theory of this sociological aspect of project management. However, I am outlining the approach here, together with its application in practical software team management, with a hope that it will help practicing project managers to create quality software teams, quality software team environments, and eventually quality software products.

2.5.1. A Brief History of TA

Just as object technology is not new, but has become popular after more than two decades due to the availability of cheaper hardware and the need for complex and quality software systems, transactional analysis, more than three decades old, is found to contain all the ideal elements to enable managers to handle soft factors appearing in technical development and project management in the area of object technology. TA has been popularized by well-known works [Berne 1964; Harris 1973; James and Jongeward 1971]; at the same time, its application to management was made popular through books like The OK Boss [James 1975] and Practical Transactional Analysis in Management [Morrison and O'Hearne 1977].

We consider the basics of TA in the following sections. This is followed by how these principles can be applied in forming and managing teams within the area of object-oriented software development using the UML. The basics of TA include the ego states and life positions^[4] and games. Understanding these ego states, life positions, and games within a project environment makes a direct impact on the way the project teams are formed and managed.

^[4] A detailed discussion of these concepts is outside the scope of this book. Interested readers are referred to any of the TA in management books described earlier. For practical experience on its use in software projects visit www.MethodScience.com.

2.5.2. The Parent, Adult, and Child Ego States

Individual project team members exhibit personalities. Ego states are what make up a personality. Each person has within themself three ego states. These are:

Note that these ego states are within a person, and are different from real parents, adults, and children, and are therefore referred to in uppercase throughout. The structural aspect of our personality has a Parent, Adult, and Child (P-A-C) ego state. The difference in people is not of structure, but often lays in the dynamics of these ego states. These characteristics of the ego states can be summarized as follows:

• Ego states are phenomenological realities. They exist within a person and are not persons themselves.

• Everyone is structurally the same (everyone has a P-A-C).

• We differ functionally.

• Each ego state is important when expressed at the right time and place.

• It is the function of the Adult to decide the appropriateness of expression.

When a project manager is confronted with a decision-making process, data from all three parts of her ego states come into play.

The Parent data bring in her righteousness as well as prejudices and deal with such parental precepts as “work before play,” “work hard,” or “never leave a job undone.” These data have organizational value for the team. However, all Parent data are archaic and do not deal with external reality that has changed since the Parent-data was recorded in the mind.

The Child brings in fun and joy, laughter and parties, and is concerned with plans for the weekend. It has motivational importance but does not care for objective reality. This aspect of a project manager's personality influences the team-building exercises, project launch parties, milestone achievement lunches, and so on.

The Adult is the reality tester. It is free from the prejudices and rigidity of the Parent, as well as from the emotional and carefree approach of the Child, in understanding what is real out there. However, a person doesn't need to ignore her Parent or Child—only to correctly identify it as such. In the decision-making process the Adult of an individual's personality functions like a computer. It takes into account the three sources of data (the Parent and Child within a person and the Adult reality) before arriving at a final decision.

2.5.3. The Life Positions

The emergence and display of the aforementioned ego states is based on life positions. Positions are the view formed by a person of the world and the people within the world [Berne 1972]. The possible views have been classified by Berne into four life positions.

Creating software teams and assembling people within the teams is best accomplished if the life position of the people is “I am OK—You are OK.” Not only do people exhibit life positions, but also teams, projects, organizations, and nations exhibit these positions. Needless to say, people cannot always be categorized into one or the other life position, but awareness of this view of the world that a person or team exhibits can play a crucial role in the success of the team.

This also enables us to map the software team models (based on Constantine) discussed earlier to corresponding life positions. As shown in Figure 2.8, the synchronous team is the most ideal team, and exhibits the most ideal life position of “I am OK—You are OK.” The closed team would be ruled in a hierarchical manner, with the project manager telling everyone what to do and what not to do—thereby exhibiting the “I am OK—You are not OK” life position. The other two team models are still constructive team models and they fall somewhere in between. The other extreme of these life positions is the totally negative “I am not OK—You are not OK” position, which means there is no team at all and people are unable to work together in any sensible form, as is sometimes evident in kindergartens, parliaments, and the like. We will not discuss such situations here.

2.5.4. Games

The ego states and the life positions provide the backdrop against which people and teams function. Most of this functioning is psychologically a means to structure the time allotted. In software projects, this is the time given to complete the project or to achieve a particular milestone. In TA terms, people and teams tend to structure their times in one of the six possible ways: withdrawal, ritual, activity, pastime, intimacy, and games. Out of these possible ways to structure time, ritual, activity, pastime, and games have an important role in handling the soft issues of a software development work environment. The other two ways to structure time, withdrawal and intimacy, are usually outside the work environment—although individuals occasionally do tend to exhibit these time-structuring mechanisms, leading to very interesting challenges for the project manager.

Work can be a nine-to-five ritual—and some project team members quickly slide into the safety of this routine if put under pressure. Meetings, organizational charts, boring training sessions, and workshops can all be activities. And meeting in corridors or stepping out for a cup of coffee or a smoke at the stroke of every hour can be pastimes. Each of these time-structuring mechanisms of ritual, activity, and pastime can still be managed, and work can be accomplished in a formal, rigid way. However, games have the potential to annihilate software projects. Games, as referred to in TA, are not the same as the games of baseball or rugby. In fact, even those games tend to be so serious at times that they can no longer be called games in the true sense of the word. In terms of software project management, games are an ulterior and dishonest way to structure time, which eventually results in project failure through the underlying soft factors. Games can play havoc with quality, as it is the one factor that is so abstract that it cannot be easily measured, categorized, or corrected.

Berne [1964] defines a game as a series of complementary ulterior transactions progressing to a well-defined payoff. Games have concealed motivations and are almost always destructive in human relations (teams, in this case). However, since most of the working time is involved in some form of games, it is essential to develop a careful understanding of the nature of games. This reduces their negative impact on the functionality of the team.

Some of the examples of games have been succinctly described by Berne in Games People Play. Overtly, in their attempt to structure time they tend to encourage teams to make progress. But then they keep on making progress without delivering value at all. These types of team games have a relationship with the teams in IT that keep progressing without producing a single product. Organizations and projects seem to have a fair share of people playing these games, with some senior managers excelling in them. The key to producing quality products and delivering them on time is to avoid these destructive natures of games within software projects. This is accomplished by the use of Adult ego state, and a firm commitment to the “I am OK—You are OK” life position by the team members and leaders.

2.5.5. Games in an OO Project

Games are neither fun nor productive. They are a time-structuring mechanism that is almost always ulterior in nature. Since software development is a team event wherein all the nuances of social psychology (as discussed in the theory of TA) emerge, it is obvious that these games exist within development teams and that they are responsible for many software project and quality failures.

Examples of some games played in IT projects, and possible antidotes, are discussed here. Obviously more discussion and practical application of these concepts are needed and encouraged in IT projects, in order to successfully handle the sociological aspect of software development.^[5]

^[5] This gamey aspect of IT projects is discussed separately in my proposed book Games IT People Play.

2.5.6. Use It or Lose It

Constantine [1995] mentions the need of some programmers to use every available feature of the language. This results in a highly complex code with many of the functionalities present in the class or component only because that feature was cool to use, or was available in a particular language or tool. Brown et al. [1998], in Anti Patterns, discuss a software architecture “anti-pattern” of a Swiss Army knife, wherein a class or a component has literally hundreds of interfaces that are there to handle any and every imaginable (and unimaginable) situation. Many of these features might be provided just because the language of choice offers them, or just because a user has mentioned them likely to be needed “in the next ten years.”

Project managers should discourage the use of technology features just for the sake of using them. Quality meetings, including quality workshops where UML-based designs are subject to quality checks, should ensure that every feature provided in a component or asked for in a use case has a corresponding genuine need in the problem space. Thus, the antidote of this game is justification. Generalization, needed for reuse and so on, can further complicate this game, but if those who are generalizing for reuse stick to their objective Adult ego state, they will have less need to generalize for the sake of generalization.

2.5.7. Cowboy Programming

This is a game played by people who disregard process disciplines. Dodani [1994] discusses examples of situations that reflect the cowboy programming game. This is a situation where the programmer aims to be the superhero of the project and, in the process, treats software development and quality processes with disdain.

Creation of a Quality Software Process that refers to a formal process discipline (as discussed in Chapter 3), insistence of the project manager on following the process, and the semantic and aesthetic checks provided by the process, are the best antidotes to this game. However, it is important for project managers to keep the practicality of process discipline in mind. If processes are didactic, and strangle the creativity of individual programmers [Unhelkar 1995], they can be used as an excuse for developers to continue to play cowboy programming. This balance between the need for creativity and obviating the need to play process games takes us in the realms of agile methodologies [Fowler 2002] such as eXtremeProgramming [Beck 2000] and needs further discussion, which is outside the scope of this book.

2.5.8. Flour Mix

The game of flour mix represents the creep factor so often discussed in IT project management. It is a game played by the developer (at times with help from the project manager) where she wants to add, with utmost sincerity, one more functionality before delivering the system. Then, to satisfy that functionality, she needs more time and resources. The development proceeds along the lines of an inexperienced cook trying to mix the flour with water in order to create the dough for baking bread. After an initial attempt to create the mix, the cook ends up with extra water. So, in order to compensate, the cook adds more flour. That leads to extra dry dough; hence she adds more water—ad infinitum.

As an antidote to this game, once a set of functionality is put together in a use case diagram, the approach should be to provide for that functionality in the first release. There is no restriction on changing the use cases or the class diagrams, but if that results in a change of scope, then that feature should be incorporated in a later release. The time-box approach to development, wherein a release is due every three months or so, can also be a possible antidote to this game. The Next Release Maybe (NRM) approach proposed by Meyer [1995], in which the requirement of the functionality is accepted, but only on the condition that it will be provided not in this release, but the next one, can also be utilized effectively to help break up this game.

2.5.9. Meetingitis

Meyer [1995] discusses a well-known problem in projects wherein the development team spends hours in meetings without deciding on anything or resolving any issues. UML-based projects are no exception. “Meetingitis” is a game that provides tools to structure time for workers who don't know what to do with their time or who are restless on their own. They just go to a meeting. This is indeed unproductive and self-defeating. One primary reason for meetingitis is a lack of clear objectives. Scott Adams's cartoon character Dilbert is popular not just because of well-presented jokes; there is a real Dilbert in every one of us, and we know it so well. The joke comes out of our personal experiences of knowing “what a waste that meeting was” and in the same breath we are setting up another meeting for next week.

Setting an agenda before the meeting, and reiterating that agenda in the first five minutes of the meeting, is an excellent antidote. Creation of a parking lot where all gamey issues can be parked is also very helpful in breaking up meetingitis. Other attempts to break up this game can include having an e-meeting instead of a physical meeting. If a physical meeting can't be avoided then try having a standing meeting—with no chairs. While these may appear to be drastic anti-social measures, the results they produce far outweigh the outcry that project managers may face initially. People should also be encouraged to come prepared for the meetings by reading through the agenda, and by contemplating solutions in their minds.

Meetings should be used for making decisions, not for investigating and research. In any case, being aware of the game is a definite first step toward breaking it up.

2.5.10. Deadline

Development teams play this game in many situations. When the team wants to look busy, it tries to approach the development with a harried approach (described by Berne [1964]). It appears to the onlooker that the team will die if it does not meet the deadline. There is a phenomenal amount of project activity—with people shouting and screaming, and compilations being fired every few minutes or seconds, and developers crowding around a lone hero who has just finished writing his 5,000th line of code in a killer class and has assembled it with the legacy wrapper.

“If the code doesn't build this time, we are all dead” is the common belief of the team. Then the deadline comes and goes, and the team still exists. So it brings in the next deadline. Deadline is a game played by people who feel they can only work under pressure. While that may be the case with some, creation of these false deadlines and the hullabaloo that surrounds them can be very unproductive.

The antidote to this game includes proper use of an interactive and incremental approach. The eXtreme Programming community provides the best antidote to this game by releasing their work on an almost-daily basis for the users to see. The chance of a project team suffering from deadline neurosis is thus considerably reduced. This approach is more effective in small to medium projects, as large projects will have to consider the issue of deadlines in the context of managing user expectations, business opportunity needs, and so on.