What do software practitioners really think about project success: A cross-cultural comparison

Due to the increasing globalization of software development we are interested to discover if there exist significant cultural differences in practitioners’ definition of a successful software project. This study presents the results of a survey in which Chilean software practitioners’ perceptions of project success are compared with previous research with US practitioners. Responses from both groups of practitioners indicate that there is a relationship between team-work and success; our results also indicate that there are similar perceptions related to the importance of job satisfaction and project success. However, Chilean responses suggest that if a practitioner is allowed too much freedom within the work environment, job stress results; this in turn is reflected in increasing demands for both job satisfaction and good environmental conditions. This may indicate the potential for the attribution of failure to conditions outside the team, thus preventing a search for problematic team issues and technical problems. In contrast, the data suggests peer control inside the US teams indicating a less stressful environment.     

Case study: factors for early prediction of software development success

Project managers can make more effective and efficient project adjustments if they detect project high-risk elements early. We analyzed 42 software development projects in order to investigate some early risk factors and their effect on software project success. Developers in our organization found the most important factors for project success to be: (1) the presence of a committed sponsor and (2) the level of confidence that the customers and users have in the project manager and development team. However, several other software project factors, which are generally recognized as important, were not considered important by our respondents.     

A replicated quasi-experimental study on the influence of personality and team climate in software development

This article reports a replication of a quasi-experimental study analyzing how personality factors and team climate influence software development team effectiveness, product quality and team member satisfaction. The replication was designed on the basis of the original quasi-experimental study, both of which were run in an academic setting. In the original study, data were collected from a sample of 35 three-member developer teams. All these teams used an adaptation of extreme programming (XP) to the academic environment to develop the same software system. In the replication, the data were collected from a sample of 34 three- or four-member developer teams working on the same software project. Student teams used a common object-oriented software development paradigm to solve the set problem and applied the Unified Process. In both studies all teams were formed at random, and their members were blind to the quasi-experimental conditions and hypotheses. The replication of this empirical study aims to verify the results of the original quasi-experiment. It examines, first, whether personality factors (neuroticism, extroversion, agreeableness, openness to experience and conscientiousness) are related to the quality of the developed software and team member satisfaction and, second, whether the preferences, perceptions and preferences-perceptions fit for the four team climate factors (participative safety, support for innovation, team vision and task orientation) are related to the quality of the developed software and team member satisfaction. The results of the replication corroborate some of the findings of the original study. On the one hand, the results revealed that there is a significant correlation between the extroversion personality factor and software quality, but no significant correlation between the extroversion personality factor and team satisfaction. Also, we found that the perception of team climate where participative safety is high is related to better quality software. We observed significant relationships between the perception of the four team climate factors and team member satisfaction. Additionally, the results showed a positive relationship between software quality and teams in which the real climate perception at the end of the project is better than preferences stated by team members at the outset of the project for the participative safety factor. Finally, we found that teams where the real climate is better than the stated preferences for the team orientation factor exhibit a direct and positive relationship to team member satisfaction.     

Towards understanding the underlying structure of motivational factors for software engineers to guide the definition of motivational programs

Aim

In this article, factors influencing the motivation of software engineers is studied with the goal of guiding the definition of motivational programs.

Method

Using a set of 20 motivational factors compiled in a systematic literature review and a general theory of motivation, a survey questionnaire was created to evaluate the influence of these factors on individual motivation. Then, the questionnaire was applied on a semi-random sample of 176 software engineers from 20 software companies located in Recife-PE, Brazil.

Results

The survey results show the actual level of motivation for each motivator in the target population. Using principal component analysis on the values of all motivators, a five factor structure was identified and used to propose a guideline for the creation of motivational programs for software engineers.

Conclusions

The five factor structure provides an intuitive categorization for the set of variables and can be used to explain other motivational models presented in the literature. This contributes to a better understanding of motivation in software engineering.     

Are team personality and climate related to satisfaction and software quality? Aggregating results from a twice replicated experiment

ContextResearch into software engineering teams focuses on human and social team factors. Social psychology deals with the study of team formation and has found that personality factors and group processes such as team climate are related to team effectiveness. However, there are only a handful of empirical studies dealing with personality and team climate and their relationship to software development team effectiveness.ObjectiveWe present aggregate results of a twice replicated quasi-experiment that evaluates the relationships between personality, team climate, product quality and satisfaction in software development teams.MethodOur experimental study measures the personalities of team members based on the Big Five personality traits (openness, conscientiousness, extraversion, agreeableness, neuroticism) and team climate factors (participative safety, support for innovation, team vision and task orientation) preferences and perceptions. We aggregate the results of the three studies through a meta-analysis of correlations. The study was conducted with students.ResultsThe aggregation of results from the baseline experiment and two replications corroborates the following findings. There is a positive relationship between all four climate factors and satisfaction in software development teams. Teams whose members score highest for the agreeableness personality factor have the highest satisfaction levels. The results unveil a significant positive correlation between the extraversion personality factor and software product quality. High participative safety and task orientation climate perceptions are significantly related to quality.ConclusionsFirst, more efficient software development teams can be formed heeding personality factors like agreeableness and extraversion. Second, the team climate generated in software development teams should be monitored for team member satisfaction. Finally, aspects like people feeling safe giving their opinions or encouraging team members to work hard at their job can have an impact on software quality. Software project managers can take advantage of these factors to promote developer satisfaction and improve the resulting product.     

Design and implementation of a knowledge-based decision support system for estimating software development work-effort

Up to now, the assessment of work-effort in software engineering is based on statistical methods. Among the best known are COCOMO (Boehm [2]) or SPQR (Jones [6]). Nevertheless it is generally recognized that many qualitative factors enter into the cost of development, such as effectiveness of the team, user's motivation, and accuracy of the specifications. We have designed a Decision Support System (DSS) for estimating the work-effort, in which the processing of the qualitative data is made by an expert system while a function points analysis provides the theoretical work-effort according to the type of software and the past experience. The evaluation is performed at two levels: global and detailed. The global evaluation is made at the beginning of the development according to the data that are, at this moment, available. The detailed evaluation takes place when the design of the software becomes more precise. The software manager can follow the evolution of the changes at the detailed level during the development.In software development, project leaders mostly reason by using their past experience. It therefore follows that a DSS must contain a learning process. We have accordingly designed our system to record the data of the completed developments. These data serve for the new evaluations. At the end of each project, the learning module examines to what extent the already-recorded information must be updated. Thus our system combines statistic data and knowledge-based reasonings.     

项目管理中的文化

任何组织都有其自己的文化,组织中的项目也会受其影响产生属于自己的文化。作为项目经理,应该如何应对现有文化?又有哪些典型的项目文化?中西方组织之间的项目文化又有哪些异同?项目管理者在管理一个新项目时经常遇到新项目组成员、新客户、新老板、新业务内容、     

Software development productivity of Japanese enterprise applications

To clarify the relationship between software development productivity and the attributes of a software project, such as business area, programming language and team size, this paper analyzed 211 enterprise application development projects in Japan using a software engineering data repository established by the Software Engineering Center (SEC), Information-Technology Promotion Agency, Japan. In the analysis, we first identified factors that related to productivity based on a parallel coordinate plot (PCP) and a one-way ANOVA. An in-depth analysis on each productivity factor was then conducted by selecting a project subset for each factor so that the effect of other factors is minimized. Our findings include that the average team size was the strongest attribute relating to productivity. The outsourcing ratio (percentage), which can be controlled by software development companies, and the business sector both showed a moderate relationship to productivity. Finally, product size (FP), the duration of development and the programming language were only weakly related to productivity.     

Successful extreme programming: Fidelity to the methodology or good teamworking?

ContextDeveloping a theory of agile technology, in combination with empirical work, must include assessing its performance effects, and whether all or some of its key ingredients account for any performance advantage over traditional methods. Given the focus on teamwork, is the agile technology what really matters, or do general team factors, such as cohesion, primarily account for a team’s success? Perhaps the more specific software engineering team factors, for example the agile development method’s collective ownership and code management, are decisive.ObjectiveTo assess the contribution of agile methodology, agile-specific team methods, and general team factors in the performance of software teams.MethodWe studied 40 small-scale software development teams which used Extreme Programming (XP). We measured (1) the teams’ adherence to XP methods, (2) their use of XP-specific team practices, and (3) standard team attributes, as well as the quality of the project’s outcomes. We used Williams et al.’s (2004a) [33] Shodan measures of XP methods, and regression analysis.ResultsAll three types of variables are associated with the project’s performance. Teamworking is important but it is the XP-specific team factor (continuous integration, coding standards, and collective code ownership) that is significant. Only customer planning (release planning/planning game, customer access, short releases, and stand-up meeting) is positively related to performance. A negative relationship between foundations (automated unit tests, customer acceptance tests, test-first design, pair programming, and refactoring) is found and is moderated by craftsmanship (sustainable pace, simple design, and metaphor/system of names). Of the general team factors only cooperation is related to performance. Cooperation mediates the relationship between the XP-specific team factor and performance.ConclusionClient and team foci of the XP method are its critical active ingredients.     

Wearing two hats: analyst-managers for small software projects

With the evolution of software development, companies have changed their project methodology and are asking IT employees to evolve with them. The business analyst talks to users, ironing out the details of what they wanted and balancing that wish list against what an IT system could economically or practically deliver. The business analyst also ensures that users develop business processes to support the software. The actual task of writing the software falls to a project manager and his team of software developers. Today, companies commonly ask IT managers to assume the business analyst role in addition to their duties as project manager, especially in small projects. This article discusses how IT managers can successfully navigate the thin line between business analyst and project manager.     

The role of project management in ineffective decision making within Agile software development projects

Decision making in traditional software development lies with the project manager. In contrast, Agile software development teams are empowered to make decisions, while the role of project manager has changed from one of command and control (i.e. to make decisions and ensure they are implemented) to one of a facilitator. This article argues that decision making in software development is not characterised by a sequence of isolated or exclusive decisions; rather, decisions are inter-related, with each decision leading to further decisions, the chain of which often spans the entire duration of a project. Over this extended period, there are several potential factors that can negatively affect the efficacy of decision making by Agile teams. One of the findings of this exploratory longitudinal study is that the high level of empowerment of a cohesive software development team undertaking an Agile project may be one of these negative factors, as empowered, cohesive teams can exhibit problems such as groupthink or the Abilene Paradox. This article therefore argues that the role of project manager in Agile development initiatives needs to be reassessed, with project managers taking on the role of devil's advocate in the decision-making process.     

Influence, discretion and time available: a case study of HCI practice in software development

In the field of human-computer interaction, reports of the involvement of its practitioners in system development projects are rarely available for general scrutiny. The paper draws upon the experience of an HCI team at work within a large collaborative software development project. This experience of four years of HCI practice suggests three key, interdependent, factors that are central to the effectiveness of HCI input. The factors are influence, discretion and time available, and are discussed in the context of other report, of the role of HCI practitioners in the field. A number of issues are identified about the nature and scope of HCI in practice. The experience reported is relevant to software development in general, particularly where there are several groups working, sometimes in different sites, towards a unified outcome.     

State of the practice: An exploratory analysis of schedule estimation and software project success prediction

During discussions with a group of U.S. software developers we explored the effect of schedule estimation practices and their implications for software project success. Our objective is not only to explore the direct effects of cost and schedule estimation on the perceived success or failure of a software development project, but also to quantitatively examine a host of factors surrounding the estimation issue that may impinge on project outcomes. We later asked our initial group of practitioners to respond to a questionnaire that covered some important cost and schedule estimation topics. Then, in order to determine if the results are generalizable, two other groups from the US and Australia, completed the questionnaire. Based on these convenience samples, we conducted exploratory statistical analyses to identify determinants of project success and used logistic regression to predict project success for the entire sample, as well as for each of the groups separately. From the developer point of view, our overall results suggest that success is more likely if the project manager is involved in schedule negotiations, adequate requirements information is available when the estimates are made, initial effort estimates are good, take staff leave into account, and staff are not added late to meet an aggressive schedule. For these organizations we found that developer input to the estimates did not improve the chances of project success or improve the estimates. We then used the logistic regression results from each single group to predict project success for the other two remaining groups combined. The results show that there is a reasonable degree of generalizability among the different groups.     

An empirical study of open-source and closed-source software products

We describe an empirical study of open-source and closed-source software projects. The motivation for this research is to quantitatively investigate common perceptions about open-source projects, and to validate these perceptions through an empirical study. We investigate the hypothesis that open-source software grows more quickly, but does not find evidence to support this. The project growth is similar for all the projects in the analysis, indicating that other factors may limit growth. The hypothesis that creativity is more prevalent in open-source software is also examined, and evidence to support this hypothesis is found using the metric of functions added over time. The concept of open-source projects succeeding because of their simplicity is not supported by the analysis, nor is the hypothesis of open-source projects being more modular. However, the belief that defects are found and fixed more rapidly in open-source projects is supported by an analysis of the functions modified. We find support for two of the five common beliefs and conclude that, when implementing or switching to the open-source development model, practitioners should ensure that an appropriate metrics collection strategy is in place to verify the perceived benefits.     

Staffing a software project: A constraint satisfaction and optimization-based approach

Software development is a people intensive activity. The abilities possessed by developers are strongly related to process productivity and final product quality. Thus, one of the most important decisions to be made by a software project manager is how to properly staff the project. However, staffing software projects is not a simple task. There are many alternatives to ponder, several developer-to-activity combinations to evaluate, and the manager may have to choose a team from a larger set of available developers, according to the project and organizational needs. Therefore, to perform the staffing activity with ad hoc procedures can be very difficult and can lead the manager to choose a team that is not the best for a given situation.     

Theoretical and empirical studies on essence-based adaptive software engineering

The OMG Essence standard was published as the kernel for software engineering methods in 2014. We show that the Essence view of software engineering is reminiscent of a nondeterministic, multidimensional finite state machine, and that the Essence lends support to a semi-Markov decision process model of software engineering which, in practice, facilitates a goal-driven adaptive software engineering. We develop an activity-state mapping algorithm and a goal-activity cover algorithm based on the Essence, which can help automate the health monitoring of project states and the adaptive planning of project activities in a software engineering project. Practical applications of the model and algorithms are illustrated. Benefits to software practitioners of the proposed approach are measured through statistical experiments.     

Motivating developer performance to improve project outcomes in a high maturity organization

In this paper we discuss the impact software developer performance has on project outcomes. Project performance remains unreliable in the software industry with many compromised software systems reported in the press. We investigate the impact that developer performance has on aspects of project success and explore how developer performance is motivated. We present interview, focus group and questionnaire data collected from a team of developers working in a software organization that has been assessed at CMM level 5. Our main findings are that developers value technical skills in their colleagues, but appreciate these especially when supplemented with good human skills. Software developers with a proactive, flexible, adaptable approach who are prepared to share knowledge and follow good practice are said to be the best developers. Motivators for these developers are pay and benefits, recognition and opportunities for achievement in their work. Overall, we found that technical competence, interpersonal skills and adherence to good practices are thought to have the biggest impact on software project success.

Performance Alignment Work: How software developers experience the continuous adaptation of team performance in Lean and Agile environments

ContextCompanies increasingly strive to adapt to market and ecosystem changes in real time. Gauging and understanding team performance in such changing environments present a major challenge.ObjectiveThis paper aims to understand how software developers experience the continuous adaptation of performance in a modern, highly volatile environment using Lean and Agile software development methodology. This understanding can be used as a basis for guiding formation and maintenance of high-performing teams, to inform performance improvement initiatives, and to improve working conditions for software developers.MethodA qualitative multiple-case study using thematic interviews was conducted with 16 experienced practitioners in five organisations.ResultsWe generated a grounded theory, Performance Alignment Work, showing how software developers experience performance. We found 33 major categories of performance factors and relationships between the factors. A cross-case comparison revealed similarities and differences between different kinds and different sizes of organisations.ConclusionsBased on our study, software teams are engaged in a constant cycle of interpreting their own performance and negotiating its alignment with other stakeholders. While differences across organisational sizes exist, a common set of performance experiences is present despite differences in context variables. Enhancing performance experiences requires integration of soft factors, such as communication, team spirit, team identity, and values, into the overall development process. Our findings suggest a view of software development and software team performance that centres around behavioural and social sciences.     

The Process Enactment Tool Framework—Transformation of software process models to prepare enactment

Rich development process models contain information about structures for project organization and also for concrete outcomes of a project. However, rich processes are hard to implement. They often contain hundreds of pages of documentation. Development teams tend to be skeptical about rich processes in fear of additional effort, risking the benefits of rich tool support for enactment. Process enactment is a challenging task. There is no common methodology to quickly “implement” a development process in a tool or a set of tools. Often specialized tools are used to provide assistance during the project and it is the project manager’s task to consolidate the information with the rest of the team.The Process Enactment Tool Framework (PET) is a software tool that supports the transformation of a given formal development process into a format that project tools can work with. PET is an instrument to import processes based on a metamodel and provide exports for a specific project environment. PET takes an input software development process model and transforms it into an intermediate format that serves as the basis for a second transformation step into data formats of tools such as office suites or comprehensive ALM platforms. In this paper we present the tool framework and show how metamodel-based processes can be transformed into an environment that is ready to use for a project team. We show how PET is applied for the German V-Modell XT and for SPEM-based processes to generate, e.g., process templates for the Team Foundation Server or work product document templates.     

Controlling Project Schedule Progress,Using Control Charts

For monitoring the status of project activities, project costs, and for controlling the project, the Earned Value Management system (EVM) is extensively used by both researchers and practitioners. However, using only EVM methodology to control a project schedule, the project manager will not know accurately when to take the appropriate corrective measures or when to exploit opportunities for the project. We suggest in this work using both EVM methodology and statistical process control (SPC) in order to better control a project schedule progress. Using the software R, a control chart for monitoring the Schedule Performance Index (SPI) individual observations is designed for the application of the study. We present results and conclusions about unusually slow or unusually fast work progress for a construction project, about the link between the schedule progress and the project team stages of development, and about the entry data necessary to design a project control chart for controlling the schedule of a project.