DELIVERING VALUE TO THE CUSTOMER USING DISTRIBUTED SOFTWARE TEAMS: IDENTIFYING THE KEY RESEARCH FACTORS

Introduction

Every project is governed by cost, schedule, and technical constraints, commonly known as the Iron Triangle, Project Management Triangle, or Triple Constraint Theory. Given this, every project is a compromise. Spend more money or less, make the project more technically sophisticated or simpler, shorten or lengthen the time to deliver the desired features the customer is paying to receive. Businesses continuously evaluate methods of productivity, identifying barriers to success, to deliver more in less time for less cost.

With software development projects becoming more complex than ever, many businesses are looking to reduce their labor costs while creating products faster. Some companies are looking to build the product using cheaper labor, while others go global to find an available and qualified workforce. Regardless of the initial reason, labor or workforce, and what is being created, the businesses need their teams to succeed. Too often these teams fail over a short period of time. The successful usage of globally distributed software development teams has proven difficult for many companies in many parts of the world. With an idyllic goal of reducing labor costs and developing software on a continuous cycle, the panacea of globally distributed teams (GDT) has proven to be elusive (Ghafoor, Shah, & Rashid, 2017). GDT, for the context of this paper, refers to any distributed development team that is separated by space, buildings, states, or time zones.

The idyllic goals of cheap labor and continuous development are elusive primarily because team performance is multidimensional. It is based on unique people and therefore results in unique teams. The dimensions that make up the team’s ability to perform are directly tied to each team member’s personality. The person-fit to the team impacts the cohesiveness of the team and the overall team performance (Driskell, Salas, Goodwin, & O’Shea, 2006). Significant variables such as trust, knowledge of business, skillset knowledge, development process, continuous integration/continuous deployment, automated testing, and other essential factors influence team culture and performance. A scrum team's (a sub-team to the whole development team) individual performance impacts the other teams in a similar but aggregate way as each individual impacts the scrum team. The scaled development team (the set of scrum teams), working together or distributed, contribute to the quality, on-time, on-budget delivery to meet the customer's needs. The degree of alignment of the team of teams governs the overall project performance or success.

We have all seen teams that cannot get anything done, and we wonder where the problem lies. If you have ever seen high-performance teams, they can be amazing. Regardless of the team’s current performance, understanding what governs performance is key to identifying, monitoring, and correcting issues. Experience gained from more than 25 years of software development and management demonstrates that many factors control and influence the success or failure of a software development project. External influences, such as unmanaged change to current scope of work, may ruin a project. Poorly written contract vehicles may ruin a project. Misaligned customer expectations may ruin a project. These conditions are regular and significant influences impacting a software development team and the success or failure of the project. Internal factors may also contribute to project failure and include everything from lack of process adherence, making poor technical choices, poor team management, or poor leadership (Aaron J. Shenhar, 2004).

In addition to the previously known challenges, teams are now forced into the “New Normal” of working from home (WFH). Remote work adds a new dimension of challenge. We are separated by time and distance. We have the potential distractions of kids, dog, cat, partner, and goldfish; we do not have our co-worker friends to talk with; there is no soccer, football, or other sports to play, watch, or discuss around the water cooler; and identifying non-COVID productivity problems becomes exponentially harder to determine. Or, does it? To understand this “New Normal,” one can turn to the existing research for GDTs to understand much of the current situation, the impacts of being disconnected, and working separated from each other. This paper will discuss the identified key research factors that allow one to measure, monitor, and mitigate issues that impact the effectual output of a team, set of teams, or GDT in the course of executing a project or product development. The following section discusses how factors, sub-factors, and variables are identified and harmonized into a single set of factors affecting team performance.

Literature Research Method

In pursuit of identifying the key literature research factors involved in delivering value to the customer using distributed software teams, a literature research process based on the Preferred Reporting Items for Systematic Reviews and Meta-Analyses (PRISMA) process was first utilized. The initial research process, as shown in Exhibit 1, is used in many systematic literature reviews and is a process required in many healthcare journals (Liberati et al., 2009). While not required, this approach, research process, and methodology provided a mechanism to perform research in-depth. This approach may not be wholly appropriate for the broad subject of all research. It did, however, provide a significant starting point and base set of broad referenceable work.

The desire to determine a complete answer to the research question iteratively led to a new literature research process, as shown in Exhibit 2. Each article was naturally placed in a reference database for logging, future referencing, and tracking. Each article was scanned for success factors, which when found, were clipped, quoted, and referenced in the data set table of factors. For each article, quotes and notes were also collected for usage in future work. While this pulls data out of the article, it does not move the research forward from a systematic literature perspective. One may, as I did, manually scan the references for additional articles to review. Manual scanning is a laborious task that only yields limited positive results. Another method is to use references in the article that relate to the research topic to hone in on additional articles. This latter method, while still laborious, expands the iterative flow as it identifies additional research articles.

The research methods described above are slow, require extensive reading and re-reading of each article, and do not yield overall results quickly. While the targeted results are valuable, a broader research technique was explored during this research process. The result of this effort was the Feedback Research Process, as shown in Exhibit 2.

While utilizing the standard approaches articulated by PRISMA research method of tracking keywords, abstracts, and articles, the Feedback Research Process incorporates some basic analytical techniques to identify suggested authors and suggested articles to incorporate into the research. The Feedback Research Process produces rapid article identification expanding to second and third-order connections among articles very quickly.

The Feedback Research Process works by parsing the reference section of all articles in a given dataset. These references are combined into a single reference database and exported to Excel. Within Excel, basic analytics are conducted to identify authors of interest and articles of interest. These suggested authors and articles are fed back into the results pool and appropriately processed or discarded. Continuing this feedback process results in rapid identification and clarification of the research.

While this technological technique is an enhanced extension of the manual process, automating portions of the process significantly sped up appropriate article identification. The maturation of this process and software to improve it is left to a future effort. Two additional analytical results from the combined collective reference database are the top authors and the top journals for this topic. Positive results achieved thus far imply that the technique is worth exploring further. The Feedback Research Process was used to identify the key factors for distributed team performance.

Literature Research Analysis = Key Factors

Utilizing the Feedback Research Process described above resulted in greater than one hundred articles identifying success factors for this topic of research. The articles were focused on agile software development, GDTs, distributed teams, teams, and teamwork in general. Many of the articles used in the research were systematic literature reviews specifically focused on success factors of agile software development teams. As shown in Exhibit 3, based on the literature review, we have identified four primary factors: Value to the Customer, GDT Degree of Alignment, Individual Team Practices, and Tools for Mitigation. In the remainder of this paper, we will describe these four primary factors, the sub-factors that make them up, and their associated variables.

Value to the Customer

The real-world question for our research attempts to determine how to deliver value to the customer faster. To achieve these results, one may attempt to measure and improve the overall effectiveness, performance, or success of a project. Sink and Smith define performance as consisting of seven interrelated and interdependent criteria, which are, 1) effectivity, 2) efficiency, 3) productivity, 4) quality, 5) quality of work-life, 6) innovation, and 7) profitability (Sink & Smith Jr, 1994).Shenhar and Holzmann utilized a project success model that primarily consists of Clear Strategic Vision, Total Alignment, and Adapting to Complexity (A. J. Shenhar & Holzmann, 2017). Garousi et al. combine process success, product-related factors, and stakeholder’s satisfaction as a definition of project success (Garousi, Tarhan, Pfahl, Coskuncay, & Demirors, 2019a). Other research varies in form but may be summarized as combining effectiveness and efficiency in some form to determine team performance. Whether measuring effectiveness, efficiency, performance, or project success, the real measure of a team’s success is delivering value to the customer, which can be quantitively measured in terms of dollars the customer is willing to pay for the requirement. The researched literature does not agree on a consistent definition regarding efficiency, effectiveness, or productivity as a measure of the overall GDT’s ability to perform. As shown in Exhibit 4, the consolidated variables summarize value to the customer. Measuring value to the customer provides a definitive factor of interest to measure the performance or output of a GDT.

Globally Distributed Teams Degree of Alignment

GDTs are formed by bringing two or more teams together to right-size the development and delivery. Many, if not all, of the GDT factors may be seen when even two local teams are brought together, albeit in a microcosm. All of the local team factors contribute to the overall team’s ability to deliver value to the customer. With respect to GDTs, there are factors that research shows stand out more when teams are combined. The degree of alignment, conflict or lack thereof may be the primary factor impeding the delivery of value to the customer.

When value is delivered to the customer, a cloud obfuscates the team’s actions, as shown in Exhibit 3. This veil of obfuscation has to be lifted when storm clouds of conflict impede delivery of value to the customer. The cloud of GDT Degree of Alignment can be better understood by utilizing Hinds and Bailey's research on conflict between teams. When cohesive teams are brought together, conflict is generated by the combining of distinct units. This conflict may be categorized into Task Conflict, Affective Conflict, and Process Conflict. Task Conflict, as defined by Hinds and Bailey, refers to the alternatives to implementation of a particular feature (Hinds & Bailey, 2003). For this reason, this type of conflict is focused more within a team rather than between teams. As a between team source of conflict, this sub-factor would be most visible at a concept of operation level, known as ConOps. Other research captures task conflict in the technical/project or process practices as understanding the tasks at hand or understanding the business or project (Abdalhamid & Mishra, 2017).

Affective Conflict is defined as anxiety or hostility along with the time and energy associated with emotional disagreements (Hinds & Bailey, 2003). This type of conflict occurs both within a team and between teams. The people dynamic of teams draws this type of conflict to the forefront of visibility and research. Cross-Understanding and Shared Mental Models are people-related sub-factors that attempt to capture or mitigate affective (emotional) conflict (Huber & Lewis, 2010).

Process Conflict focuses on each team and team member's resources, roles, and responsibilities (Hinds & Bailey, 2003). Process conflict is quickly worked out as a within team sub-factor when leadership identifies and addresses visible issues. Between teams, process conflict may be harder to make visible due to the distinct differences between the teams. Dynamism and uncertainty (Misra, Kumar, & Kumar, 2006), degree of adoption (van Kelle, van der Wijst, Plaat, & Visser, 2015), and process variability (Boehm & Turner, 2005) are similar sub-factors relating to the conditions caused by process conflict.

The degree of alignment can be described and measured. A diagnostic framework known as SPACE considers issues from all aspects of the team: Satisfaction and well-being, Performance, Activity, Communication and collaboration, and Efficiency and flow (Forsgren et al., 2021). SPACE is one of several identification tools revealed through the literature research. SPACE may be utilized for discovery of issues within and between teams (Forsgren et al., 2021). The survey approach at the end of each iteration determines the areas where the team may improve. The multidimensional information obtained from the survey tool may be used to identify factors which are in less-than-optimal operation. Utilizing SPACE to find conflict areas may make mitigating or preventing conflict easier with a resulting increase in more value delivered to the customer in a shorter period of time.

Tools for Mitigation

The tools for mitigation sub-factors are themselves measurable. These sub-factors are also tools for mitigating or enhancing the degree of alignment. Using the tools, as shown in Exhibit 5, may lessen conflict thus improving degree of alignment and overall delivery of value to the customer. Media Richness and Degree of Dispersion are widely used and discussed in the literature with mixed conclusions. Architectural Modularity seems to be ignored or not addressed in the literature researched to date, perhaps due to the project specific nature of this sub-factor. Cross-Team Leadership is identified in much of the project management literature as a key sub-factor.

Mitigating conflict between teams may be achieved by enhancing Media Richness to increase the effectiveness of communications (Daft & Lengel, 1986). Using Media Richness to increase communication effectiveness is not a cure-all. Understanding the root cause of the conflict and applying corrective actions based on these root causes will solve the issue more thoroughly. A related method to increase communication between teams is to decrease the Degree of Dispersion (O'Leary & Cummings, 2007). Shifting the workday of one or both teams may decrease the degree of dispersion, leading to better communication opportunities. Maximizing the overlap between teams provides opportunity to utilize richer media technology such as voice, video, and instant messaging in lieu of just email communications.

Architectural Modularity is a key technological approach that begins early in the architecture phase and must be maintained as features and capabilities are added to the system. Architectural Modularity affects the degree to which one team can operate without interaction with another team. Higher degrees of Architectural Modularity decreases the need for communication and in turn decreases the types and impacts of task, affect, and process conflict. Having well-defined application programming interfaces (API) and thorough continuous integration/continuous deployment automated testing (DevOps) infrastructures help to mitigate conflicts raised by the interactions.

Cross-Team Leadership identifies the level of leadership and distinguishes it from leadership as part of team practices. The leadership skills, traits, and variables are similar and inclusive of team practice leadership but focused on the cross-team aspects rather than the individual team.

Team Practices Delivering Value

Do customers care how a team produces something? Experience answers “not really.” It is critical that the customer receive value delivered on-time and on-budget. Often with today’s complex projects this is considered a win. Achieving the desired results requires digging into sub-factors governing team practices and contributing to barriers between teams and within teams. Gaining a deeper understanding of the team practice sub-factors that contribute to issues is of significant value to development companies.

Based on early research, the within or local team sub-factors were categorized into practices of agile methodology, social and cultural, physical and infrastructure, technical and business knowledge, and leadership groups. The summation of these governing team practices results in what the team can produce and can be measured by a rating for the value they deliver. Further research has culminated in the individual practice sub-factors of Organization, People, Process, Technical/Project, and Team Leadership which characterize a local team’s ability to deliver value to the customer or GDT, as shown in Exhibit 6.

It is important to fully understand the individual practices as each one consolidates a wide array of variables. A detailed breakdown of the consolidated variables for team practice sub-factors is shown in Exhibit 7 at the end of this section.

Process. The focus for this practice sub-factor is on agile process variables such as the say/do ratio, the stability of the team’s velocity, and the DevOps maturity. These are essential variables, and they do govern a large portion of the success or failure of a project from a process perspective. From the literature, research shows many more significant variables are at play in this practice. In Boehm and Turner’s article, “Management Challenges to Implementing Agile Processes in Traditional Development Organizations,” planning and control, dynamism and uncertainty, and testing were directly identified (Boehm & Turner, 2005). Planning and control refer to standard project management planning techniques such as scheduling, earned value, and other quantitative performance measures. Dynamism and uncertainty can be measured or visualized using team velocity. The stability of velocity shows the dynamic nature and uncertainty or lack of control in a team’s process. Testing by today’s standards of development is an outdated variable to individually measure. DevOps maturity encompasses not only the testing measures but also the frequency and completeness of the testing. The degree of adoption is the relative measure regarding how well teams agree on the framework process to follow. While this is similar to dynamism and uncertainty, these measures do not focus on the same aspects of the team. Dynamism and uncertainty relate to fluctuation in the backlog and is analogous to requirements volatility, while the degree of adoption relates more to stability of the framework process (van Kelle et al., 2015).

People. People variables include items such as social norms, cultural idioms, and cross-understanding. Other variables found from the research include emotional intelligence components such as openness, agreeableness, emotional stability, conscientiousness, and extraversion. These traits contribute to creating trust and psychological safety in a team (Driskell, Salas, Goodwin, & O’shea, 2006). Team psychological safety goes beyond individual characteristics to describe how these people-based variables mold together (Edmondson, 1999). As teams come together from far and wide, increased cultural diversity requires an enhanced cross-understanding (Huber & Lewis, 2010). Localized teams utilize the team's bond of trust as a basis for their psychological safety. Team members using emotional intelligence may lead to a shared mental model of one another, which will increase effectiveness as a team (Cohen & Bailey, 1997).

Organization. The Organization practice sub-factor includes infrastructure variables such as internet stability and availability, tools, buildings, and workspace. Research reveals additional variables of identifying appropriate team members, the ubiquity of common tools throughout the team, effective knowledge sharing, and team autonomy (Guzmán, Ramos, Seco, & Esteban, 2011). Other common organizational variables include the alignment and support of management. This includes project alignment to the organization's management style, vision, mission, alignment to project monitor and control practices, and alignment to change and risk management techniques (Garousi, Tarhan, Pfahl, Coskuncay, & Demirors, 2019b).

Technical/Project. The Technical/Project practice sub-factor includes customer knowledge and technical ability to execute the work. Misra et al., 2006, defines this variable as Competency. Variables such as skillset knowledge, ConOps knowledge, and directional or project alignment also drive the Technical/Project practice. Experience shows that unequal technical factors between teams force a superior-subordinate relationship. This uneven footing for independent operating teams creates barriers to success in many cases. Until all teams are on relatively equal footing, the operation as a GDT will be hindered. The concept of operation knowledge is the domain knowledge relative to how the customer will use or interact with the product or service. As a key variable, it is this ConOps understanding of the customer, their needs, their desires, and their goals that will help to deliver value to the customer quickly.

Technical expertise encompasses knowledge to execute technical aspects of the project at hand. For example, a great C++ embedded developer does not always function well on a web development project written in JavaScript. The technical expertise variable focuses on an individual, the team, and as a comparative measure for between teams. Additional variables found through research include project size, type of project, technological uncertainty, technical complexity, project criticality, and urgency (Garousi et al., 2019b).

Team Leadership. Leadership is required at all levels from the smallest team up through and including the management team. Each leadership level must develop and communicate the appropriate vision and value both up to their management and down to the team. Each leader must accomplish this in a straightforward manner to each constituent (A. J. Shenhar & Holzmann, 2017). Leaders must also recognize when the individual variables affecting a team are not in total alignment, not understanding or following the vision, or not working as a unit to adapt to the issues encountered.

Leadership variables start with mission clarity and vision. For each team, mission clarity, or "Start with Why," as described by Simon Sinek, sets the vision and purpose for the team (Sinek, 2009). “Why” is the intrinsic motivation that one feels toward achieving the project goals. When the team members share the same "Why,” they have the same motivational purpose. Shenhar couples the “Why” described by Simon Sinek with the concept of operation when he describes what he terms Strategic Project Leadership (SPL) (Aaron J. Shenhar, 2004).

The SPL framework, as defined by Shenhar, consists of standard project leadership characteristics such as process, tools, organization, and the inclusion of spirit and strategy, which are vital. SPL fills in the gaps between traditional project management and direction of the larger organization. Spirit can be defined as having a vision of the project with the ability to articulate it up and down the organizational chain. Tying in strategy is the key that is often missed. In this sense, strategy is connecting the corporate objectives with the project objectives, thus creating harmony using the vision to articulate and drive the project (Aaron J. Shenhar, 2004).

Conclusions

There is a wide variation in factors, sub-factors, and variables found in the literature for a given team or GDT. However, the literature does consistently consolidate to a set of team practices for success. The consolidated team practices of Process, People, Organization, Technical/Project, and Leadership characterize a team’s contribution to the overall team performance. As teams are brought together, between-team barriers may arise decreasing the GDT Degree of Alignment. The barriers may be characterized as Task Conflict, Affective Conflict, and Process Conflict (Hinds & Bailey, 2003). Media Richness (Daft & Lengel, 1986), Degree of Dispersion (O'Leary & Cummings, 2007), Architectural Modularity, and Cross-Team Leadership are tools available to provide mitigation of the barriers to success (A. J. Shenhar & Holzmann, 2017). The literature research has implications for the “New Normal.” Conditions and conflict once only recognized when teams were brought together are now visible in local teams. This is due in part to the remote nature of work-from-home resulting in our “New Normal.” Getting to know someone while sitting at the breakroom table now takes intentional usage of instant messaging and video meetings. From a distance, shared mental models are harder to construct. Trust is also harder to obtain and takes more work to develop. Creating a shared mental model and developing trust are essential to fostering the highly necessary variable of team psychological safety (Edmondson, 1999). With intentionality and effort, utilizing the GDT tools for mitigation may lessen the impact of the “New Normal.” In the “New Normal,” one would expect task conflict to decrease. That is to say that the team will debate less about how a feature or capability is implemented when executed by an individual on the team. This is a natural extension and application of the theories and research by Hinds and Bailey. However, just as task conflict is likely to decrease, process conflict will increase for the same reasons and conditions. As a local development team, tasks like Git Pull Requests, code reviews, and individual code development should not be impacted in the “New Normal” due to their individual nature. However, DevOps and the state of automated testing gain a new importance in the work-from-home world. Automated testing within the DevOps pipelines creates a known state for the development team. Remote teams do not communicate as frequently nor as richly, therefore DevOps takes on a heightened role in showing the state of software.  

Recommendations

Engineering Management Researchers may use this paper to help identify the important factors focused on distributed software development team performance. Specifically, using the key finding of delivering Value to the Customer in quantifiably measurable methods could be used to evaluate differing approaches in process, people structures, and organizational constructs. The “New Normal” identifies weaknesses in localized teams. Utilizing knowledge gained through GDT research, engineering managers can identify issues, mitigate the conditions, and adapt to the “New Normal.” Tools such as the SPACE dimensions survey can test the overall health of the team and help identify where issues or conflicts exist. Utilizing instant messaging and video tools intentionally and more frequently increases the media richness of communication. Driving the team to common working hours helps with accessibility and decreases the degree of dispersion. The “New Normal” is different, difficult, and distant. Utilizing effective GDT techniques drives commonality, community, and clarity.  

References

Abdalhamid, S., & Mishra, A. (2017). Factors in Agile Methods Adoption. Tem Journal-Technology Education Management Informatics, 6(2), 416-421. doi:10.18421/tem62-29

Boehm, B., & Turner, R. (2005). Management challenges to implementing agile processes in traditional development organizations. IEEE software, 22(5), 30-39.

Cohen, S. G., & Bailey, D. E. (1997). What makes teams work: Group effectiveness research from the shop floor to the executive suite. Journal of management, 23(3), 239-290.

Daft, R. L., & Lengel, R. H. (1986). Organizational Information Requirements, Media Richness and Structural Design. Management Science, 32(5), 554.

Driskell, J. E., Salas, E., Goodwin, G. F., & O’shea, P. G. (2006). What makes a good team player? Personality and team effectiveness. Group Dynamics: Theory, Research and Practice.

Edmondson, A. (1999). Psychological safety and learning behavior in work teams. Administrative science quarterly, 44(2), 350-383.

Forsgren, N., Storey, M.-A., Maddila, C., Zimmermann, T., Houck, B., & Butler, J. (2021). The SPACE of Developer Productivity: There's more to it than you think. Queue, 19(1), Pages 10. doi:10.1145/3454122.3454124

Garousi, V., Tarhan, A., Pfahl, D., Coskuncay, A., & Demirors, O. (2019a). Correlation of critical success factors with success of software projects: an empirical investigation. Software Quality Journal, 27(1), 65. doi:10.1007/s11219-018-9419-5

Garousi, V., Tarhan, A., Pfahl, D., Coskuncay, A., & Demirors, O. (2019b). Correlation of critical success factors with success of software projects: an empirical investigation. Software Quality Journal, 27(1), 429-493. doi:10.1007/s11219-018-9419-5

Ghafoor, F., Shah, I. A., & Rashid, N. (2017). Issues in adopting agile methodologies in global and local software development: A systematic literature review protocol with preliminary results. International Journal of Computer Applications, 160(7).

Guzmán, J. G., Ramos, J. S., Seco, A. A., & Esteban, A. S. (2011). Success factors for the management of global virtual teams for software development. International Journal of Human Capital and Information Technology Professionals (IJHCITP), 2(2), 48-59.

Hinds, P. J., & Bailey, D. E. (2003). Out of sight, out of sync: Understanding conflict in distributed teams. Organization science, 14(6), 615-632.

Huber, G. P., & Lewis, K. (2010). Cross-Understanding: Implications for Group Cognition and Performance. Academy of Management Review, 35(1), 6-26. doi:10.5465/amr.35.1.zok6

Liberati, A., Altman, D. G., Tetzlaff, J., Mulrow, C., Gøtzsche, P. C., Ioannidis, J. P., . . . Moher, D. (2009). The PRISMA statement for reporting systematic reviews and meta-analyses of studies that evaluate health care interventions: explanation and elaboration. PLoS medicine, 6(7), e1000100.

Misra, S. C., Kumar, V., & Kumar, U. (2006). Success Factors of Agile Software Development. Software engineering research and practice, 1, 233-239.

O'Leary, M. B., & Cummings, J. N. (2007). The Spatial, Temporal, and Configurational Characteristics of Geographic Dispersion in Teams. MIS Quarterly, 31(3), 433-452. doi:10.2307/25148802

Shenhar, A. J. (2004). Strategic Project Leadership® Toward a strategic approach to project management. R&D Management, 34(5), 569-578. doi:10.1111/j.1467-9310.2004.00363.x

Shenhar, A. J., & Holzmann, V. (2017). The Three Secrets of Megaproject Success: Clear Strategic Vision, Total Alignment, and Adapting to Complexity. Project Management Journal, 48(6), 29-46. Retrieved from https://login.ezproxy.net.ucf.edu/login?auth=shibb&url=https://search.ebscohost.com/login.aspx?direct=true&db=edsggr&AN=edsgcl.519900823&site=eds-live&scope=site

Sinek, S. (2009). Start with why: How great leaders inspire everyone to take action: Penguin.

Sink, D. S., & Smith Jr, G. L. (1994). The Influence of Organizational Linkages and Measurement Practices on Productivity and Management. Paper presented at the Panel on Organizational Linkages, Washington, D. C.

van Kelle, E., van der Wijst, P., Plaat, A., & Visser, J. (2015). An Empirical Study into Social Success Factors for Agile Software Development: IEEE

About the Author

Ben Park, Ph.D., completed his doctorate in Industrial Engineering with an emphasis in Management Systems at the University of Central Florida (UCF), Orlando. Dr. Park has a Master's degree in Engineering Management and a BS in Computer Engineering, both from UCF. Dr. Park is a software engineering and development leader with 30 years’ experience developing and deploying custom-built software solutions. As CTG’s Director of Software Development, he leads a team of software development professionals that build flexible solutions to meet the needs of enterprise clients across industries. Dr. Park is a proven, motivated, and enthusiastic leader that understands how to apply a strategic vision to practice, seeks and forms collaborative teams, and transforms groups into teams aligned to a common vision. Dr. Park is an award-winning technical leader with the knowledge to design large systems of systems as well as small, embedded devices. With a Ph.D. focus in globally distributed teams using agile software development, he has a clear understanding of what is needed to operate in multiple time zones, locations, and cultures.

Timothy Kotnour completed his doctorate in Industrial & Systems Engineering with an emphasis in Management Systems Engineering at Virginia Tech in Blacksburg, Virginia. He completed his Bachelor’s of Science in Industrial Engineering at Bradley University in Peoria, Illinois. He is the Lockheed Martin St. Laurent Professor in the Department of Industrial Engineering and Management Systems at the University of Central Florida. He is the Director of the UCF Engineering Leadership and Innovation Institute and the Program Director of the Professional Engineering Management Program. He is the author of the books “Transforming Organization: Strategies and Methods” and “Inspiring the Leader Engineer: Instilling the Burning Desire and Confidence to Change the World.”Dr. Kotnour has been awarded three NASA Public Service Medals (2016, 2005, and 2001) for the partnership work with the Kennedy Space Center. He is also a Fellow of the American Society for Engineering Management (ASEM).He was past editor of ASEM’s Engineering Management Journal.