Archive Page 2

Seminar at Brigham Young University – Software Team Effectiveness

One of the topics I would like to discuss is “Team Effectiveness”. This is a complex topic that has been studied from different perspectives in group research.

Hackman (1987) has argued that, for teams in organizations (i.e., in practice and not in a experimental lab setting), effectiveness is more complex than counting “right answers” or timing the development of a task. Hackman argues that certain team outputs can be difficult to quantify. Furthermore, teams in organizational contexts tend to work together for a much longer time than the participants in a laboratory experiment, and what happens to a team during the development of one project may affect the feasibility of this team working together in the future. In his model, Hackman defines effectiveness as a multiple construct composed of

1. Acceptance of team’s output or results by those that receive or review them (Client Satisfaction with results)

2. Maintained or enhanced capability of members of the team to work together in the future (Team Viability)

3. Team member’s satisfaction has not decreased the the team experience (Member satisfaction with teamwork)

Cohen (1993) asks the question of whether we consider a team that produces what expected as being successful even if the team members present low morale, are not satisfied with the work, come late to work, or the team turnover is right. In her model, Cohen also considers effectiveness as a multidimensional constructed composed of:

1. Performance: costs, productivity, quality.

2. Member attitudes: satisfaction, trust, commitment.

3. Withdrawal behaviors: absenteeism, turnover.

Yeats and Hyten (1998) acknowledge that effectiveness is multi-dimensional, but only performance as client satisfaction and team economic viability. Their argument is that using a more complex, multi-dimensional view of effectiveness would make a model less accurate, since each dimension is affected differently by other factors that influence team effectiveness.

In the seminar, I will present some of our studies in which distinct definitions of effectiveness were used. I would like to discuss the implications (practical and theoretical) of using simple or more complex definitions in understanding the effectiveness of software teams in practice.

Fabio Silva.

References

Cohen SG (1993) The Design of Effective Self-managing Teams. Advances in Interdisciplinary Studies of Work Teams. Vol. 1 Theories of Self-managing Working Teams 1:

Hackman J (1987) The design of work teams. Handbook of organizational behavior 315-342.

Yeatts DE, Hyten C (1998) High-performing self-managed work teams. Sage Publications, Inc.

Seminar at Brigham Young University – January, 19th, 2012.

Professor Charles Knudson gently invited me to present a seminar at the  Computer Science Department at Brigham Young University in Provo, Utah. This will happen on January, 19th, 11:00 – 11:50. This is a great opportunity to discuss some research ideas about human aspects in software engineering and to start a closer collaboration with researchers from BYU.

I will try to develop the presentation incrementally in this blog. Comments are welcome.

Let’s start with the title. My choice at the moment goes like this:

“The orders of ignorance in our research about the influence of human aspects in software engineering”

This is inspired by an article from Phillip G. Armour, published at the COMMUNICATIONS OF THE ACM, October 2000/Vol. 43, No. 10. Armour describes what he calls the five levels of ignorance we face in software development, and I think these levels are quite good at describing our ignorance with respect to a lot of other things, including research. These levels are (extracted from Orders Of Ignorance):

  • 0th Order Ignorance: Lack of Ignorance. I have 0OI when I (probably) know something.
  • 1st Order Ignorance: Lack of Knowledge. I have 1OI when I don’t know something. With 1OI we have the question in a well-factored form.
  • 2nd Order Ignorance: Lack of Awareness. I have 2OI when I don’t know that I don’t know something.
  • 3rd Order Ignorance: Lack of Process. I have 3OI when I don’t know a suitably efficient way to find out I don’t know that I don’t know something.
  • 4th Order Ignorance: Meta-ignorance. I have 4OI when I don’t know about the Five Orders of Ignorance.

It is very likely that our research about human aspects in software engineering has different levels of ignorance (all but the 4OI). Therefore, I think it will make an interesting seminar to talk about:

  • 0th Order Ignorance: some things I think we (probably) know: past results of our empirical studies and literature reviews.
  • 2nd and 3rd Orders Ignorance: how are we conducting our research (methods and processes) so that we can become aware of new things that we still don’t know. i.o.w., how we are trying to decrease our 2rd Order Ignorance by using replications of qualitative case study research to help formulating good research questions (1st Order Ignorance) and/or testing some previously developed questions (0th Order Ignorance)
  • 1st Order Ignorance: some things I know we don’t know: some questions that we want to investigate and hope to do this investigation through collaborative projects.

Fabio Silva.

Task Identity in Software Development

The model proposed by Hackman (1987) for the design and development of effective work teams is one of the most influential in the research about team work. Central to the model is the concept of task design as one of the conditions that support effort from team members. The task design concept postulates that a work group would “work especially hard on its tasks” when five conditions are met. One of these conditions is usually referred as task identify, defined by Hackman as follows:

“The group task is a whole an meaningful piece of work, with a visible outcome.” (Hacman, 1987, pp. 324)

In trying to use Hackman’s model in the design of tasks for software teams, one faces the problem of understanding the meaning of task identity in software development. Several alternatives to operationalize this concept in the software development would have distinct implications for task and team design.

First, and the most obvious, alternative is to consider that the development of a whole system. It certainly meets the criteria of task identify as a whole piece of work, meaningful and with a visible outcome. Some software teams in industry are responsible for the development of an entire system, but not all. In fact, it is more likely that the majority of the software teams in industry do not work on an entire system, but on parts of a system.

On the other end of a possible spectrum of task designs, is the case in which the development is broken in phases, each one assigned to specific teams. Coding and testing conducted by different teams are typical examples. One could argue that even in this case it is possible to have certain degree of task identity in each task, but this is certainly different from the first case. In this cases, it is more difficult for individuals or even teams to have an understanding of “the big picture.”

In the middle, there is the case in which a team is responsible for a part of the system, and performs all (or most of the) tasks associated with that part: design, coding, testing, maintenance, etc. Again, certain degree of identity exists that is “smaller” than the first case and “larger” than the second.

Aninteresting research problem is to understand the relationship between different types of task design and the motivation (or demotivation) these designs have on software engineering teams. In particular, it seems relevant to understand task identity in the context of agile and traditional development, as well as in the context of open source development. It is likely that in the three context the “levels” of identity will vary and, thus, the level of motivation that the task design will have on software engineers will also be different.

We are currently working on this problema and comments are welcome.

Fabio Silva.

 

Reference

Hackman J (1987) The design of work teams. Handbook of organizational behavior 315-342.

Best Article Award at ESEM 2011

The article  “An Empirical Study on the Use of Team Building Criteria in Software Projects“, presented by Prof. Fabio Silva at the 5th International Symposium on Empirical Software Engineering and Measurements (ESEM’2011), in Banff, AL, Canada, received the Best Paper Award at the closing ceremony, on Friday, September 23rd, 2011. The article is co-authored by  Fabio Q. B. da Silva, A. César C. França, Tatiana B. Gouveia, Cleviton V. F. Monteiro, Elisa S. F. Cardozo, Marcos Suassuna, members of the HASE Research Group.

The goal of the research  was to identify criteria used in industrial practice to select members of a software project team, and to look for relationships between these criteria and project success. The study was carried out with project managers of over 30 software companies from various cities in Brazil.  The findings show that the consistent use of a set of team building criteria correlated significantly with project success, and the criteria related to human factors present the strongest correlations.

The paper can be found in the ESEM’2011 Proceedings, which should be electronically available soon at IEEE.

Systematic Review about Personality in Software Engineering

We investigate the effect of personality on various aspects of individual an team work in software development. We have recently published a systematic literature review on the EASE’2011 Conference, in Durham, England. This article received the Joint Best Paper award in the Conference.

An extended version of this paper is being prepared and will be submitted to IET Software later this month.

Human Aspects in Software Engineering

Welcome to HASE.

We are a research group at the Center of Informatics, at the Federal University of Pernambuco, Brazil, focused on developing empirical studies of the effects of human factors on the industrial practice of software development.

The research group leader is Prof. Fabio Q. B. da Silva, who has been actively involved in industry-university collaborative research in software engineering in the past 20 years. He is one of the founders of C.E.S.A.R., a research institute that has received twice the award of the Most Innovative Research Institute in Brazil.

HASE is the research home of 6 doctoral and 16 master students, and has an extensive track of published work in the last five years.