Value Creation/Innovation:

Exploring Value Creation Theories

By Russ Wright

Value Creation

Value creation or innovation as defined in the question above, focuses on creating new products and new ideas within the field of software development. There is much debate in the literature over how value is created within software development. Some literature focused primarily on the economy of software development (Boehm, 2003; Boehm & Sullivan, 2000). Others took a more holistic approach and realize that the culture and process have the greatest effect on the ability to innovate (Highsmith & Cockburn, 2002; Karlsson & Ryan, 2002; Little, 2005; Prahalad & Ramaswamy, 2004; Quinn, Baruch, & Zien, 1996). Regardless of the path taken to explain value creation and innovation in software development, the general agreement was that the process needed to change to better fit the challenges and opportunities of a global market. Inasmuch, this paper will explore the value creation theories related to software development and the additional challenge of outsourcing to create innovation.

The purpose of this document is to explore how an organization can create value in the software development process. There is a discussion of the background on value creation within the context of agile software development principles, which contain many ways to innovate. This document also explores the theories of outsourcing software development and how they relate to value creation or innovation within agile development. The conclusion finds that creating value in software development is still a topic up for debate among scholars and that outsourcing can add value but is full of pitfalls.

Value Creation Theories Related To Software Development

Achieving value creation has slowly changed the way software is developed into a set of methodologies loosely called agile software development. Research conducted by Fowler and Highsmith (2001) concluded that the agile development philosophy and methods sought to remove cumbersome and time-consuming barriers to value creation. The authors instead supported a philosophy of software development that focused on the individuals, their interaction, creating working software, collaboration with the customer and quick responses to change. There are several theories of value creation or innovation embedded within the principles of the agile philosophy of software development. Therefore, several of these embedded value creation theories are explored below.

Customer Defined Software Value

One theory of value creation in software development is that customer satisfaction is achieved by delivering software that the customer actually values. According to research by Highsmith and Cockburn (2002), the authors explained that within the agile development methodologies the customer defined value for the project and set the measurement of success. For software to be valuable the customer had to find that the product not only met their needs, but also was usable and useful (Constantine & Lockwood, 1999). In an article on agile methodology, Boehm (2002) explained that generating value in the development process for the customer was achieved by emphasizing customer involvement in the development process over the traditional contract negotiation. Consequently, value creation comes from the ability of the customer to define the measure of success, including usability and usefulness of the product and their involvement in the development process as a team member. Making the customer a member of the team means that the requirements might change, many times and even late in the process.

Requirements Changes

A change in the requirements for an application, even late in the development process allows a customer to build in greater value to the product. The ability to prioritize the customer’s requirements through a cost-value approach produced a win-win result when creating software products (Karlsson & Ryan, 2002). Prahalad and Ramaswamy (2004) explained that changed requirements happened because the customer and development team developed a greater understanding of the customer’s needs. Recent research conducted by Paetsch and Eberlein and Maurer (2003) explained that the ability to adapt to the changing situation in the software development project created more value than prediction of the customer’s requirements. A study by Cao and Ramesh (2008) offered a warning against too much change in requirements leading to project failure because the customer never saw the software product. Thus the ability to change requirements is a positive, yet too much change can prevent a usable product from being delivered.

Quick Delivery

The ability to deliver the software quickly builds value for the customer. According to a recent study by Quinn, Baruch and Zein (1996) quick delivery of the software product made a significant difference in the ability to compete in the global market. Larman (2004) explained that innovation was accomplished when the developers, through an iterative cycle, delivered a working product to the customer, which allowed the customer to see the progress and adjust requirements quickly to the changing market. Yet, Nurer Mahapatra and Magalaraj, (2005) in a recent paper cautioned that organizations who attempted to adapt to agile methods that delivered quickly could fail because they were often unprepared for the radical change in behavior. Therefore, quick delivery of the software product builds value by allowing the customer to adapt and refine the product but also holds a potential for disaster if not managed well. Managers, customers and developers have to work together well to build value.

Collaboration with Managers

The development team and managers must communicate daily to build value in the development process. Cohn and Ford (2003) explained that managers had to adapt to a new style of leadership where they were required to relinquish some of what they perceived as control. The authors posited that traditional development plans which offered specific delivery dates were probably padded and inaccurate and instead needed participation to see that they could deliver the product quicker and with less resources. According to research conducted by Patton (2002) the regular discussions with managers added the benefit of clearing roadblocks and bottlenecks, which would slow down the project and add costs. The managers were also able to see how the product met the customer’s needs. A study conducted by Augustine, Payne, Sencidiver and Woodcock (2005) explained that without the constant communication, managers would often fall back into trying to manage the project using linear approaches as they attempted to gain control of the project, which lead to lost time and possibly project failure. As a result, the constant communication with managers helps create value by not only keeping them informed but also empowering them to clear obstacles that might slow down delivery. Managers can also provide considerable motivation and support to help create value in the software development process.

Motivation and Support

The motivation and support of the management team has a significant impact on the value creation in software development. According to research conducted by Ceschi, Sillitti, Succi and Panfilis (2005) into development project success factors found that team members ranked motivation from management in the form of support and training as among the top key factors for innovation. The study further showed that managers agreed that their support was a significant factor in the success and value creation within the project. A recent study conducted by Asproni (2004) into the benefits of motivation from management in software development teams showed that highly effective teams benefited most and achieved the best results when management provided among other factors, clear elevating goals, a unified commitment to the project and a collaborative climate. The study further explained that this support gave the team members the ability to innovate and build better quality software, often with fewer resources. A research survey conducted by Forward and Lethbridge (2002) found that the management team provided a significant impact on the performance of the development process when they provided the team with the proper tools to improve automation in the development process. The team saw these tools as support and found motivation to perform at a higher level. Inasmuch, support and motivation from management has a reciprocal effect on the development process and the ability of the developers to innovate and create value.

In Person Meetings for Tacit Knowledge Transfer

Value creation can be significantly effected by the ability of team members to meet and share knowledge. Nonaka and Takeuchi (1995) drew on the work of Polyanyi (1966), and explained that tacit knowledge was personal, context specific and difficult to explain. They further explained that this knowledge, gained from experience, can be lost if an individual leaves an organization and does not share it. Likewise the members of a development team, which includes the customer, must meet often to share knowledge to establish the context of the requirements and build new knowledge, which creates value (Dyba & Dingsayr, 2008). Cohn (2004) explained that when teams met to transfer knowledge, the use of stories to explain the requirements helped to build up individual and group knowledge as they shared. The author does warn that this process might not work well in really large teams, but did acknowledge the positive impact of tacit knowledge sharing on innovation. A recent study conducted by Chau, Maurer and Melik (2003) found that knowledge sharing within agile development teams, particularly when done in face-to-face settings helped to build trust among team members and increased the team’s ability to function together. Therefore, sharing of knowledge among team members, especially in face-to-face formats helps build team trust and create value in the development process.

Working Software as Measurement Of Success.

The ability for management to measure the progress of a development project has a significant impact on the ability of the software development team to create value. Boehm and Turner (2005) explained that agile development processes do not include the typical milestones and other measurement techniques common to traditional development methods. They further explained that the completed functional stories could serve as a replacement for these measures as they showed the amount of work completed on a particular development phase. A case study by Fitzgerald, Hartnett and Conboy (2006) demonstrated that the ability of the management team to measure the progress of the team, based on the amount of working code, increased the project performance by reducing the amount of paperwork needed in the previous traditional software development projects. The developers spent less time writing reports and more time on the actual development, which accelerated the development process. In a recent report, Lapham, Williams, Hammons, Burton and Schenker (2010) explained that progress within an agile project was measured by gathering the customer’s value assigned to each completed part of the development project. As these pieces were completed, they were used as a measure of how much the customer valued the product at that time. Thus, the ability of management to measure progress, along with the customer’s assigned value at each phase of development adds value to the project, particularly because it reduces the reporting workload on the development team freeing them to perform more development tasks.

Realistic Schedules

The proper attitude towards development cost and schedule when managing a project will have an impact on the development team’s ability to create value. Glass (2001) explained that successful projects had a realistic schedule that was not a death march to finish the project and the developer worked a normal workweek. Developing innovative products did not require that the software development projects be managed by the schedule or costs, as it would have distracted from the real objective of creating a profitable product that met customer needs and gave a competitive advantage (Poppendieck & Poppendieck, 2003). Likewise, and exploratory study by Begel and Nagappan (2007) explained that one of the benefits of implementing agile software methods was the flexibility of the process which gave the developers the ability to change directions when a rigid schedule would not have worked. So, a tight management of the schedule and costs, as is common in traditional development processes would inhibit value creation because they lacked flexibility.

Technical Excellence

The quality of skill for each member of a development team will have an impact on the value creation ability of an organization. An organizational culture that supported and provided opportunities for growth in skills was desirable because it lead to productivity (Wendorff, 2002). A recent study conducted by Chow and Cao (2008) showed that team capability and delivery strategy ranked highest as critical success factors. Technical excellence also extended to the tools used by the software development team, as good quality tools impacted the ability of the team to innovate (Hanssen & Fægri, 2008). For these reasons, a skilled software development team equipped with the proper tools and supported by opportunities for growth is an important factor for innovation and value creation in software development.

Keep It Simple – Maximize Effort

The design of the software program can impact the ability of the software development team to create value in the development process. In the agile development process, one of the first steps is writing the test for the specific functionality. By writing the test for the code first, the developer would write code to the test and minimize the additional code needed to meet the test requirements and functionality (Poppendieck & Poppendieck, 2003). In a recent paper by Lindstrom and Jeffries (2004) the authors explained that value was achieved by keeping the design as simple as possible so that the design matched the functionality and included no additional wasted motion. They further explained that the design was regularly reviewed to keep effort to the minimum and maximize efficiency. Hence, value creation in software development can be improved by coding only what is required and reviewing the code regularly to increase efficiency.

Team Self-Organization

The ability for a software development team to reorganize themselves into different configurations as the situation dictates can affect the organization’s ability to innovate. Cockburn and Highsmith (2002) explained that the ability of a software team to reorganize as the situation dictated was important for making decisions quickly and dealing with ambiguity. A recent paper by Decker, Ras Rech, Klein and Hoecht (2005) explained that the ability to reorganize as a development team allowed for the reuse of engineering knowledge in new projects. The benefit of knowledge reuse was a key factor in the reasons given for reorganizing the team to fit the new situation. Yet, there is reason to show caution when attempting to use a self-reorganizing team philosophy. A study conducted by Moe, Dingsoyer and Dyba (2008) found that the very specialized skills of certain team members and the uneven division of work among the team presented barriers to realizing a true self-organizing team. Therefore, value creation, in regards to self-organizing teams depends upon the ability of a development team to reorganize quickly to meet new challenges, and the balancing of skills and workload within the team.

Team Reflection

The ability for a development team at regular intervals to reflect upon the entire project can impact the ability of the team to create value. According to research conducted by Salo,Kolehmainen, Kyllönen, Löthman, Salmijärvi and Abrahamsson (2004) the post-iteration workshops provided significant help to improve and optimize practices and enhance the learning and satisfaction of the project team. The authors further explained that the cost of the workshops was quite small, and the benefits quite large. Cockburn (2002) echoed this same idea and explained that the after process reviews were helpful in growing the skill of the team and improving the skill sets of the participants. A review at the end of the development cycle where the participants shared their experiences significantly enhanced the development process (Dingsøyr & Hanssen, 2003). Thus, reflection builds the ability of a software development team to innovate by improving and optimizing the team practices.

Within each of the principles behind agile software development are theories of value creation for a software development team. By allowing the customer to set the measures of success within the product, brings value creation by building trust. The ability to adapt to changing requirements allows the development team to innovate and meet the customer’s needs. Quick and often delivery of a working product, even if it is not complete, builds value for the customer and the development team as they both gain credibility. Constant communication with management helps to build trust in the team and give them the freedom to innovate and create value for the organization. Closely related to this theory is the need for management to be able to measure progress by measuring the completeness of the project. By using the completeness of the project for measure the management is able to see progress and eliminate additional paperwork for the developer, which freed them to write more code. Also related to management was using other measures instead of cost and schedule as they would detract from the real goals of the project. Another way that value is created is through the support of management with proper training and tools, which brings about excellence. The adaptable and self-organizing team, a difficult goal to reach, also brings about value creation by allowing the team to adapt to the fluid situations found in software development. And lastly, one of the important and relatively inexpensive ways that a software development team can create value is by reflecting regularly on the development process and integrating the lessons learned, thus constantly improving the ability to innovate.

Value Creation Theories and Outsourcing Of Software Development

So far the exploration of value creation has focused on software development teams in local settings. The additional factor of distance between the development team and the customer or another development team, or even members of the same team presents some additional factors for innovation as well as failure. A review of the current literature shows much disagreement about the benefits and potential for success when outsourcing the development of software. Some of the theories, both pro and con, related to value creation, agile development and outsourcing are explored below.

Effects on Many Levels

Outsourcing of software development in general creates new opportunities for value creation, but also brings many challenges. A recent paper by Hersleb and Moitra (2002) explained that the separation of the software development team over the globe could add many problems. These problems included how the project manager divided up the work and how they handled resistance to the process. They further added that many cultural issues, including the attitude towards management, perceptions of time and communication styles all contributed to the successful outsourcing of a project. A paper by Agelfalk, Fitzgerald, Holstrom, Lings, Lundell and Conchuir (2005) explained that the process of communicating between team members, coordination of activities and control of the project were all challenged by distance. The authors further explained that only when strong supporting processes were in place could the outsourced project work. Hence, the challenges of distance, communication, culture and command and control in an outsourced software development project must be addressed with strong supporting principles and methodologies, like agile, to support value creation.

Even if an organization uses agile methods, because of the focus of the processes for dealing with ambiguity, change and communication, to create value in an outsource project, there are still many challenges that must be overcome. According to research by Carmel and Agrawal (2002) the authors identified three critical challenges of outsourcing software development as: (1) coordination, (2) control and (3) communication. Coordination was defined as integrating tasks across each unit so they all contribute to the whole. Control was defined as following the goals, policies and standards of the organization. Communication was defined as the exchange of information that is understood by those communicating. Thus, an understanding of how to deal with these three critical challenges is required to achieve value creation when outsourcing. Each of these challenges to outsourcing of software development, within the context of agile development principles, is explored further below.

Coordination

The division of tasks when outsourcing software development can impact the ability of an organization to create value. According to Shrivasta and Date (2010) agile teams that were distributed across too wide of a time zone difference suffered from poor performance as they had little overlapping time to coordinate activities. One possible solution to coordination problems suggested by the research of Carmel, Espinoza and Dubinsky (2010) was handing off the work from one site to the next toward the end of the work day going around the globe in the direction of the sun. The authors admitted that this solution was still not entirely proven, yet did present a method that might help in the coordination of distributed software development teams. Another possible solution to the problems of coordination suggested by the research of Wahyudin, Matthias, Eckhard, Schatten and Biffl (2008) was the use of a notification software tool that supported the agile development methodology and managed the interdependent tasks, which gave the project manager and the team members a way to coordinate activities. Hence, the coordination of tasks by the project manager and team members must be managed well to achieve value for the software development project.

Control

Adherence to organizational policies, goals and standards can impact value creation when outsourcing software development. In his research of outsourcing strategies Jennings (1997) explained that one of the most important factors for successful outsourcing was protection and development of the core capabilities that gave an organization their competitive edge. According to research by Sutherland, Schoonheim, Rustenburg and Rijk (2008) the authors found that exceptional productivity, and therefore value creation, in a development project among distributed teams was possible when the teams fully integrated the agile method into their development teams. This was achieved by bringing the teams together, instilling the agile goals and methods and then separating them. The authors acknowledged that the time spent instilling the agile principles and philosophy was a major contributing factor for success. Therefore, instilling the relevant goals and standards, especially the principles of agile development as mentioned above, gives a competitive edge, contributes to the success of outsourced projects and helps build value.

Communication

The most important factor for value creation when outsourcing software development is communication. Research conducted by Sutherland, Viktorov , Blount and Puntikov (2007) showed that communication, particularly when crossing cultures presented a significant obstacle as it limited productivity. The authors further explained that the solution that worked best was a full integration of the agile teams with members distributed around the globe as opposed to teams divided by geography. They argued that although this method slowed down the development process some when compared to an agile project done in a local space, it increased communication and built trust among the team members. A recent research paper by Shrivasta and Date (2010) concluded that knowledge management and communication were among the major problems encountered when software development was outsourced. They proposed an interesting solution were the agile teams used a web-based knowledge management wiki to assist in the capture of experiences. They further suggested that teams should still be brought together at different times in the development process and work together to build trust. Hence, a solid plan for communication among distributed software development teams is required to achieve value creation.

No Easy Answers

Agile software development philosophies and methods provide many opportunities to create value in software development. Much of the research into agile shows the potential for value creation when an organization is willing to embrace the philosophy and create a culture that supports and celebrates innovation. The process of embracing the philosophy and building the culture will take time and training on all levels of an organization to see the process happen. There is still much to be researched and solved to realize true value creation when outsourcing software development. Agile methods hold much promise, but still face many challenges to make the process work with teams spread across the globe. For an organization that already uses agile development principles, outsourcing might create additional value. For an organization that already has outsourced projects, adding agile development principles might also increase innovation. However, an organization with weak development procedures would risk much by trying to add agile principles and outsource at the same time and are likely to reduce instead of improve value creation.

References

Ågerfalk, P. J., Fitzgerald, B., Holmström, H., Lings, B., Lundell, B., & Conchúir, E. (2005). A framework for considering opportunities and threats in distributed software development. InInternational Workshop on Distributed Software Development (pp. 47–61). Citeseer.

 

Asproni, G. (2004). Motivation, teamwork, and agile development. Agile Times, IV (1), 8–15.

Augustine, S., Payne, B., Sencindiver, F., & Woodcock, S. (2005). Agile project management: Steering from the edges. Communications of the ACM, 48(12), 85-89.

Begel, A., & Nagappan, N. (2007). Usage and perceptions of agile software development in an industrial context: An exploratory study. In First International Symposium on Empirical Software Engineering and Measurement (ESEM 2007) (pp. 117-125). Presented at the First International Symposium on Empirical Software Engineering and Measurement, Madrid, Spain: ESEM. doi:10.1109/ESEM.2007.85

Boehm, B. (2002). Get ready for agile methods, with care. Computer, 27(4), 64-69.

Boehm, B. (2003). Value-based software engineering. ACM SIGSOFT Software Engineering Notes, 28(2), 1-12.

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

Boehm, B. W., & Sullivan, K. J. (2000). Software economics: A roadmap. In Proceedings of the conference on The future of Software engineering (pp. 319-343). ACM.

Cao, L., & Ramesh, B. (2008). Agile requirements engineering practices: An empirical study.Software, IEEE, 25(1), 60-67.

Carmel, E., & Agarwal, R. (2002). Tactical approaches for alleviating distance in global software development. Software, IEEE, 18(2), 22-29.

Carmel, E., Espinosa, J. A., & Dubinsky, Y. (2010). Follow the sun workflow in global software development. Journal of Management Information Systems, 27(1), 17-38.

Ceschi, M., Sillitti, A., Succi, G., & De Panfilis, S. (2005). Project management in plan-based and agile companies. Software, IEEE, 22(3), 21-27.

Chau, T., Maurer, F., & Melnik, G. (2003). Knowledge sharing: Agile methods vs. tayloristic methods. In Enabling Technologies: Infrastructure for Collaborative Enterprises, 2003. WET ICE 2003. Proceedings. Twelfth IEEE International Workshops on (pp. 302-307). IEEE.

Chow, T., & Cao, D. (2008). A survey study of critical success factors in agile software projects.Journal of Systems and Software, 81(6), 961-971. doi:10.1016/j.jss.2007.08.020

Cockburn, A. (2002). Agile software development. Boston, MA USA: Addison-Wesley.

Cockburn, A., & Highsmith, J. (2002). Agile software development: The people factor. Computer,34(11), 131-133.

Cohn, M. (2004). User stories applied: For agile software development. Addison-Wesley Professional.

Cohn, M., & Ford, D. (2003). Introducing an agile process to an organization [software development]. Computer, 36(6), 74-78.

Constantine, L. L., & Lockwood, L. A. D. (1999). Software for use: A practical guide to the models and methods of usage-centered design. New York, NY, USA: ACM Press/Addison-Wesley Publishing Co.

Decker, B., Ras, E., Rech, J., Klein, B., & Hoecht, C. (2005). Self-organized reuse of software engineering knowledge supported by semantic wikis. In Proceedings of the Workshop on Semantic Web Enabled Software Engineering (pp. 126-135). ACM.

Dingsøyr, T., & Hanssen, G. K. (2003). Extending agile methods: Postmortem reviews as extended feedback. Advances in Learning Software Organizations, 4-12.

Dyba, T., & Dingsayr, T. (2008). Empirical studies of agile software development: A systematic review. Information and Software Technology, 50(9-10), 833-859. doi:10.1016/j.infsof.2008.01.006

Fitzgerald, B., Hartnett, G., & Conboy, K. (2006). Customising agile methods to software practices at Intel Shannon. European Journal of Information Systems, 15(2), 200-213.

Forward, A., & Lethbridge, T. C. (2002). The relevance of software documentation, tools and technologies: A survey. In Proceedings of the 2002 ACM symposium on Document engineering (pp. 26-33). ACM.

Fowler, M., & Highsmith, J. (2001). Manifesto for agile software development. Retrieved February 6, 2011, from http://agilemanifesto.org/

Glass, R. (2001). Agile versus traditional: Make love, not war! Cutter IT Journal, 14(2), 12-18.

Hanssen, G. K., & Fægri, T. E. (2008). Process fusion: An industrial case study on agile software product line engineering. Journal of Systems and Software, 81(6), 843-854.

Herbsleb, J. D., & Moitra, D. (2002). Global software development. Software, IEEE, 18(2), 16-20.

Highsmith, & Cockburn. (2002). Agile software development: The business of innovation.Computer, 34(9), 120-127.

Jennings, D. (1997). Strategic guidelines for outsourcing decisions. Strategic Change, 6(2), 85-96.

Karlsson, J., & Ryan, K. (2002). A cost-value approach for prioritizing requirements. Software, IEEE, 14(5), 67-74.

Lapham, M. A., Williams, R., Hammons, C., Burton, D., & Schenker, A. (2010). Considerations for using agile in DoD acquisition (Technical Note No. CMU/SEI-2010-TN-002). Hanscom AFB, MA: Carnegie Mellon.

Larman, C. (2004). Agile and iterative development: A manager’s guide. Prentice Hall.

Lindstrom, L., & Jeffries, R. (2004). Extreme programming and agile software development methodologies. Information Systems Management, 21(3), 41-52.

Little, T. (2005). Value creation and capture: A model of the software development process.Software, IEEE, 21(3), 48-53.

Moe, N. B., Dingsoyr, T., & Dyba, T. (2008). Understanding self-organizing teams in agile software development. In Software Engineering, 2008. ASWEC 2008. 19th Australian Conference on(pp. 76-85). IEEE.

Nerur, S., Mahapatra, R. K., & Mangalaraj, G. (2005). Challenges of migrating to agile methodologies. Communications of the ACM, 48(5), 72-78.

Nonaka, I., & Takeuchi, K. (1995). The knowledge creating company: How Japanese companies create the dynamics of innovation. Oxford, UK: Oxford University Press.

Paetsch, F., Eberlein, A., & Maurer, F. (2003). Requirements engineering and agile software development. In Enabling Technologies: Infrastructure for Collaborative Enterprises, 2003. WET ICE 2003. Proceedings. Twelfth IEEE International Workshops on (pp. 308-313). IEEE.

Patton, J. (2002). Hitting the target: Adding interaction design to agile software development. InOOPSLA 2002 Practitioners Reports (p. 1). Presented at the Object-Oriented Programming, Systems, Languages, and Application Conference, Seattle, WA: ACM.

Polanyi, M. (1966). The tacit dimension. London: Routledge and Kegan Paul.

Poppendieck, M., & Poppendieck, T. (2003). Lean software development: An agile toolkit. Addison-Wesley Professional.

Prahalad, C. K., & Ramaswamy, V. (2004). Co-creation experiences: The next practice in value creation. Journal of Interactive Marketing, 18(3), 5-14.

Quinn, J. B., Baruch, J. J., & Zien, K. A. (1996). Software-based innovation. The McKinsey Quarterly, (4), 94-96.

Salo, O., Kolehmainen, K., Kyllönen, P., Löthman, J., Salmijärvi, S., & Abrahamsson, P. (2004). Self-adaptability of agile software processes: A case study on post-iteration workshops.Extreme Programming and Agile Processes in Software Engineering, 13(2), 184-193.

Shrivastava, S. V., & Date, H. (2010). Distributed agile software development: A review. Journal of Computer Science and Engineering, 1(1), 10-17.

Sutherland, J., Schoonheim, G., Rustenburg, E., & Rijk, M. (2008). Fully distributed scrum: The secret sauce for hyperproductive offshored development teams. In Expanding Agile Horizons (pp. 339-344). Presented at the Agile 2008 Conference, Toronto, Canada: IEEE.

Sutherland, J., Viktorov, A., Blount, J., & Puntikov, N. (2007). Distributed scrum: Agile project management with outsourced development teams. In Information Technology in Health Care (pp. 274-284). Presented at the 40th Hawaii International Conference on System Sciences, Waikoloa, Big Island, Hawaii, USA: IEEE Computer Society. doi:10.1109/HICSS.2007.180

Wahyudin, D., Heindl, M., Eckhard, B., Schatten, A., & Biffl, S. (2008). In-time role-specific notification as formal means to balance agile practices in global software development settings. In Lecture Notes in Computer Science (Vol. 5082, pp. 208-222). Springer.

Wendorff, P. (2002). Organisational culture in agile software development. Lecture Notes In Computer Science, 17(2559), 145-157.

Leadership in Open Source Software Development:

Past, Present and Future

By Dr. Russ Wright

Abstract

This paper explores the past, present and future of leadership and governance within Open Source Software (OSS) development projects. This paper also explores the current factors for successful leadership and governance of OSS development. As background, this paper explores the beginnings of the “hacker” culture that became the current geek and OSS culture. The future implications for leadership in regards to the Open Innovation model are also explored. The conclusion is that the OSS development model is morphing and changing so quickly that research cannot keep up with the change.

Leadership in Open Source Software Development

The nature of geek work is cerebral, most of the effort takes place inside the head of the geek, who uses their smarts to find solutions to problems. Typical leadership methods, designed for people who work on something external to themselves is not going to work on geeks. (Glen, 2003) How is it possible to lead these people? Before an answer is offered consider these addition factors: The people who do this work are volunteers, they are also spread over the globe and might not ever meet in person. How can a development project with these seemingly insurmountable factors actually work?

What defines OSS?

There are two basic camps that occupy the Open Source Software definition. The more radical of the two camps, holds to the belief that closed source software is dangerous and harmful and holds firmly to the belief that software should be open for the public good. (Stallman, 2001) There are others, perhaps with a more moderate philosophy, is that closing the source is a defect, as it prevents public inspection and that makes the program inferior. They desire open software to remedy the quality of the programs and make them more secure. (Perens, 2005). Other recent research contends that “OSS ‘hackers’ conceive of themselves as a movement to correct the failure of existing institutions (both industry and academia) to produce software adequately. (de Laat, 2007) By opening the source code of a software application, the developers were able to make changes to the programs as they pleased, create a whole new development methodology and build whole new communities around projects. As a result, a new term was needed to manage the licensing, ownership and copyright issues that blossomed along with the movement. Thus the term Open Source Software (OSS) was created by Raymond and Perens to define the situation.

Defining Leadership Challenges in OSS Development Projects

Leadership, or more precisely governance, which encompasses the leadership and the structure of the organization, in the OSS development environment must take on some different strategies to work. The volunteer, not motivated by the reward of a paycheck, must be motivated by other factors. Some recent research showed that the average volunteer software developer spends about 14 to 18 hour in a week working for free on OSS projects. These developers are mostly full time employees at commercial software companies, yet contribute for free. (Lakhani & Wolf, 2007) Thus, the leader must not only appeal to these other motivations, but also put in place a structure that cultivates the rewards that will motivate the volunteer.

The existing research into the leadership of OSS development communities created multiple definitions, each coming from different perspectives and does not provide a single clear encompassing explanation. For example: To provide rules, formal and informal that help identify developer identity, and help assign people to tasks. (Crowston, Li, Wei, Eseryel, & Howison, 2007) Another definition given: To control outcomes, people and communication. (Lattemann & Stieglitz, 2005) Yet another: To provide the normal methods of exchange using the commonly held values structure and the belief in sharing code with others. (Shah, 2006) Thus, none of these definitions fully define the role of leadership within an open source project.

The reason it is difficult to create a single definition for leadership or governance within an OSS community is because the communities and their purposes are widely varied. Some OSS projects do little more than build a single simple program, others become organizations, with a simple legal shell to provide a holding place for the assets and allow the project to take donations. At the extreme, some are non-profit foundations with committees and managed releases and possibly employees on a payroll. Other recent research attempted to create a definition which stated: “Thus, OSS governance can be defined as the means of achieving the direction, control, and coordination of wholly or partially autonomous individuals and organizations on behalf of an OSS development project to which they jointly contribute.” (Markus, 2007, p. 152) Although purposefully vague, this definition does provide a good starting point for defining the role of leadership in OSS development projects.

 

The Markus (2007) definition is good because it does not seem in conflict with traditional software development leadership responsibilities, and only highlights those additional aspects unique to OSS development. Her research revealed three particular goals of OSS development leadership and structure: (1) Keeping developers motivated, (2) solving coordination problems, and (3) cultivating a climate where developers will want to participate. These three goals are explored below.

The Motivation Dilemma

In traditional software development the developer is hired to do a job to create some product and receives compensation in the form of a paycheck for the effort. The developer might also take the job because they are interested in learning about the particular area of programming and want to advance their skills or they are motivated to solve the problem because it intrigues them. These factors fall into two different categories. According to Glen (2003) the software developer can be motivated by extrinsic factors, most often the paycheck, or intrinsic factors such as the desire to learn. He further explained that most of the factors will be intrinsic over the extrinsic. This idea is support by the research of Roberts, Hann and Slaughter (2006) who discovered in OSS development projects that even when extrinsic motivations exist, such as a paycheck, they do not crowd out the intrinsic motivators. Thus the developers who work on OSS projects, more often than not, can only rely on intrinsic factors and the leadership of the project must identify and build on those factors to keep the developers interested in the project.

Development Coordination Problems

In typical OSS projects the developers are spread out over the globe and this can present special problems for the leadership of the project especially when coordinating the interdependence of pieces of the software program. Traditional development leadership would assign tasks to specific individuals and organize the workers to performs certain tasks best fitted to their skills. (Glen, 2003) A study of virtual teams by Kayworth and Leinder (2001) discovered that leadership of virtual teams is fraught with difficulties because the solutions to the problems are much fewer because of the great distance between members. This problem of assignment and coordination does not seems to be as much an issue in OSS development projects. A recent study by Crowston et al, (2007) showed evidence that the most common method used in OSS development is a self-assignment process where the OSS developers would do the work by choice. One example given in the research showed an email where a developer called “dibs” on a particular part of the project because he wanted to learn how to make it work. The research further showed that instead of a hierarchy in assigning tasks, the developers will politely ask or just take on the task and do the work. Thus, the leadership of OSS projects do not seem to have the same issue, at least of assigning tasks and coordinating interdependencies as the developers seem motivated to pick up the tasks themselves.

Cultivating The Climate

The developers that participate in OSS development project come from two basic sources. A recent study defined two distinct categories of OSS developers as need-driven and hobbyist. (Shah, 2006) The need-driven participants consciously made the choice to use an OSS product, rather than a commercial solution so they could view and change the code to meet their own needs and solve a particular issue for a work-related purpose. The hobbyist programmer viewed participation in a particular OSS development project as a hobby activity and described the work as fun and challenging. Thus, each group has a different set of motivations and the leadership must be aware of these differences if they want to cultivate participation and contribution. Having a voice within the community is a potential solution to the motivation dilemma.

Because the OSS projects have little if any extrinsic motivators, such as a paycheck, to offer the leadership must capitalize on the intrinsic motivators available to them. A recent study by Manville and Ober (2003) explored the potential of using the voice of democracy as motivator. The study explained a situation where a developer might consider two different jobs, which have different working conditions and different pay scales. Some developers might always consider the paycheck the most important factor and choose the job with higher pay. Other developers might choose to work at a lower paying job because of greater opportunity to shape the direction of the organization. Thus the ability to have a voice in the decision making process might be a positive motivator for participation within a project.

A Brief History Of OSS Developer Culture And Ideology

To understand these struggles in leading an OSS development project requires some background. The history of OSS development is a tangle of political and personal motivations that evolved over forty years from the early computer programmers of the first mainframes all the way to the current personal computer users. After several attempts to untangle hype from fact, this author found it near impossible to determine the real facts and history of the Open Source Software movement. Below is a brief history, amalgamated from multiple sources into a single time-line. The history provided here only includes information that can be corroborated from at least one other source and is limited to details that reflect the transformation of the original computer hacker culture into the Free and Open Source software development culture of today.

The Big Iron

To fully understand the culture that permeates the OSS development world, will require some background on the origins of the hacker culture that become the OSS developer culture. According to Raymond (1999) the first group to begin the OSS developer culture began in 1961 when Massachusetts Institute of Technology (MIT) acquired a Digital Equipment Corporation PDP-1. This is often called the beginning of the “Big Iron” batch processing computers. In 1969 the addition of ARPAnet, the forerunner of the Internet built by the Defense Department as an experimental digital communications network, brought these programmers together allowing them to collaborate via electronic discussion groups despite being spread across the US. The computing culture flourished across ARPAnet particularly in the computer science department of colleges and universities who all used DEC PDP computers.

The birth of collaborative development started with a project at the MIT labs in 1967. MIT bought a PDP-10, yet the team rejected the existing operating system and built their own. According to Raymond (1999) they built their own operating system because they wanted to work their own way. This point is important because it shows the first real example of OSS developer attitude when a group of developers started a project because they want to solve a need not met by existing programs. This attitude is echoed by Perens (2005) when he stated: “Open source is an indication of an unfulfilled need.” Thus, the current Open Source Software developer mentality was influenced by the actions of MIT in 1967 when the existing software did not meet the needs and the group developers decided to make their own operating system that did things their way.

The Unix Gurus

The second group who influenced the current Open Source Software developer culture started in a very different way. Raymond (1999) explained that Ken Thompson working at Bell Labs in New Jersey resurrected parts of the failed Multics operating system and combined it with his own ideas and created a new operating system to run on a scavenged DEC PDP-7. While still in the very early stages of creating Unix, another developer named Dennis Ritchie created a development language called C to run on Thompson’s fledgling Unix operating system. Raymond (1999) explained that two major factors propelled this OS into popularity. First, this OS could run on essentially unaltered on several platforms and second, computer hardware was getting cheaper and faster and the operating system did not need to eek out every possible ounce of power from the hardware. Thus, Thompson’s Unix and Ritchie’s C language started a change in development, that allowed developers to take and move source code with them to any project running on multiple platforms. This portability, the ability to take and reuse software for other projects is part of the Open Source Software developer mindset today.

Commercial Destruction

A major solidifying factor for the Open Source developer culture came about through the commercialization and subsequent destruction of both the Big Iron and Unix cultures. According to Levy (2002) several startup companies lured away the talent from the MIT Big Iron labs and started rival fractured groups who were once good friends. A few years later similar attempts to commercialize Unix started enormous infighting and knocked them out of the market. According to Raymond (1999) “The proprietary-Unix players proved so ponderous, so blind, and so inept at marketing that Microsoft was able to grab away a large part of their market with the shockingly inferior technology of its Windows operating system.” (p. 164) Thus the infighting and the commercialization attempts caused many years of efforts to create a free and open operating system to flounder.

One of the most influential figures of the Free Software ideology is Richard Stallman who was a developer during the time when the commercialization of some of the MIT lab technologies saw the fracturing and destruction of the Big Iron and the Unix cultures. According to Levy (2002) Stallman was so depressed by the schism in the labs that he would tell strangers he met that his wife had died. This fracturing obviously colored his perceptions of software ownership and continues to affect the OSS developer culture.

In 1982 Stallman founded the Free Software Foundation, which holds the philosophy that software should have essential user freedoms anmd maintains the following definition of free software:

Free software is a matter of the users’ freedom to run, copy, distribute, study, change and improve the software. More precisely, it means that the program’s users have the four essential freedoms:

The freedom to run the program, for any purpose (freedom 0).
The freedom to study how the program works, and change it to make it do what you wish (freedom 1). Access to the source code is a precondition for this.
The freedom to redistribute copies so you can help your neighbor (freedom 2).
The freedom to distribute copies of your modified versions to others (freedom 3). By doing this you can give the whole community a chance to benefit from your changes. Access to the source code is a precondition for this.

According to Raymond (1999) Stallman’s idea of a free clone of Unix, which later became GNU/Linux, and his stubborn adherence to a free and open operating system epitomized the OSS developer culture. Thus Stallman, influenced by witnessing the destruction of computing cultures by commercialization forwarded through his creation of the Free Software Foundation another aspect of the Open Source developer culture.

Stallman began the construction of a Unix clone in 1983, that would be free and open. The original project was called the GNU (Gnu’s Not Unix) operating system. The project moved along slowly developing many tools and really floundered when AT&T sued over Unix rights in 1992. Stallman wanted to make sure that his software would stay publicly available and created a regulatory framework that came to be known as the GNU Public License (GPL). (“The GNU General Public License,” 2007) The GPL allows the developer to use, modify and redistribute the modified program, with one very important rule. The new code created from the original code must carry the same license. Thus this self perpetuating licensing scheme kept the source code always in the public domain. Around the same time a Helsinki University student named Linus Torvalds began developing a free Unix kernel for 386 machines using the Free Software Foundation’s toolkit. His initial, rapid success attracted many Internet hackers to help him develop Linux, a full-featured Unix with entirely free and re-distributable sources.

The Birth Of The OSS Development Method.

The OSS development methodology underwent a significant change when Linus Torvalds started developing his Linux kernel. The application development methods used reflected a significant culture shift from the previous development style. Raymond (1999), explained the difference in the development style by comparing the typical commercial development style of the time to building a cathedral and the development style of Linux to a marketplace bazaar. The cathedral style of software development was typified by a small group of experts working away in isolation with few code releases. The bazaar was a much more open style of development typified by many developers contributing updates continuously and many and often releases of the code. From the late 90′s through the early part of 2003 OSS development saw an enormous explosion using the Torvald’s model of development.

The Early Leadership Problems

Here is where the paths of the Free Software Foundation and the Open Source Initiative really began to diverge on philosophy. Raymond (1999) explained that shortly after a presentation of his paper on Torvald’s development model, Netscape announced that they would try this model and open the source of their browser. He further explained that over the next several days, in meetings with many influential figures, the decision was made to create a definition of Open Source Software through an organization called the Open Source Initiative. Raymond (1999) Explained: “What we realized, under the pressure of the Netscape release, was that FSF’s actual position didn’t matter. Only the fact that its evangelism had backfired (associating `free software’ with these negative stereotypes in the minds of the trade press and the corporate world) actually mattered.” (p. 256) Thus, a conscious decision was made to create a definition that would be more appealing to the business person as the definitions of the FSF did not translate well to business.

Over the next few years a great injustice was done to Stallman. As previously mentioned, Stallman had a large chunk of an operating system completed, but lacked a kernel and Torvald’s Linux kernel filled that gap. Often developers refer to an operating system by it’s kernel, despite the fact that many other pieces exist to make it an operating system. Perens (2005) notes: “Although Stallman did a great deal of the work that made Linux possible, Torvalds’ team of kernel contributors was not closely allied with Stallman, and announcements of Linux were not attributed to FSF.” Thus the considerable work of Stallman was not credited in the Linux announcements creating a division within the community that still exists today.

These major events shaped the culture that is the OSS community today. From the Big Iron era the early developers demonstrated the desire to meet a need not met by the existing operating system. This desire was carried forward into the Unix and C microcomputer era where tools and languages become portable and could be carried to other jobs so developers did not have to start over on each new assignment. Then the birth of the personal computer, and the explosion of the Internet brought together these developers from around the planet to work together to create software, GNU/Linux for example, that introduced a new way of creating software, and all the new challenges of leading these developers.

Major Intrinsic Motivation Factors In The Current OSS Development Culture

Like all development projects, regardless if the project is open-source or not, one of the major jobs of the leadership is to keep the team motivated. According to Glen (2003) the leadership must set a tone for the work environment to cultivate motivation. The unique qualities of an open-source project require the leadership of the project to take on some different attributes than their commercial counterpart. A recent study by O’Mahoney (2007) defined five specific intrinsic motivation traits of OSS development that manage and motivate the developers: (1) Independence, (2) Pluralism, (3) Representation, (4) Decentralized decision-making, and (5) Autonomous participation. Each of these traits are interrelated to each other and build a cohesive model of the motivations of the OSS volunteer developer. Thus, these traits are the basis of a community managed OSS project and represent the primary motivations for volunteer involvement. Each of these traits are explored in detail below as they relate to OSS development practices and other research.

Independence

For a mature OSS project, independence is natural, as the gained experiences of the community will form their own culture. Independence, according to O’Mahoney (2007) is defined as “A community that is independent does not rely upon the resources from any one organization, but is supported by a diverse body of participants.” (p. 144) This seems to resonate with Glen (2003) where he explains that the culture of a community will grow over time and establish shared patterns of interaction and will limit the ability of any one entity to control the group. Thus, independence seems a natural part of an OSS project as leadership cannot exert control but only nurture the environment.

This issue of project control and leadership came to a head with the development of the Linux Kernel. An article by Lemos (2002) explained that the developers who worked with Linus Torvalds on the Linux kernel were frustrated by the lack of response and tight control Torvalds was exerting over the development process. Changes and bug fixes would be submitted only to be ignored or flat out rejected without explanation which angered the developers. This created a delicate situation for Torvalds as the developers could easily fork the project, taking a set of the existing code, walking away from the existing Linux kernel project and starting a new project of their own. To resolve the problem Torvalds appointed several new people, he called lieutenants, who took over different segments of the development and code integration responsibilities. Torvalds had to give up some control to keep control of the project. Thus the kernel development project was establishing patterns of interaction that went beyond the control of the Torvalds.

Pluralism

The intrinsic motivator of pluralism has two dimensions, that partially overlap. The first part of the definition has to do with the governance of the project. For a project to recruit and retain talented developers, no one organization may own or control too much of the project and stifle other voices. According to research by West and O’Mahoney (2008), project with sponsors have a special problem as talented developers, which the project desires, will want freedom to act and share their thoughts. These developers will test the ability share and become vocal and critical of the project leadership if their voice is not heard and respected. Thus, the leadership must be cautious to not let any one sponsor dominate the project or talented developers will not want to participate.

The second part of pluralism deals directly with the voice of the developer. Because the work done in the development of a software programs comes from the creative mind of the developer, there can be multiple solutions to the same problem. Some solutions will be better that others, but all must be heard. O’Mahoney (2007) defined pluralism as: “A pluralistic community allows many approaches, methods, theories or points of view to be legitimate or plausible in pursuing a course of action” (p. 146) This also resonates with Glen (2003) who explained that one of the important roles for the leadership of a project is to create an environment that is safe for the presentation of ideas and that freedom of speech exists within the community. Thus the intrinsic motivator for the OSS developer is the freedom to present ideas that they know will be heard and considered as part of the solution.

Representation

The developers must also have a voice in the direction of the project. The definition of representation provided by O’Mahoney (2007), was a system of democratic representation within the project. However, the researcher does differentiate that the authority of the representative is limited to making decisions on the project and not in control over other members. The Glen (2003) research seemed to agree with this position as he stated, “everyone should feel that what they have to say is valued and becomes part of the discussion about how to proceed” (p. 127). Thus, even if the voice is representative and not a pure democracy, the members must feel that their voice impacts the direction of the project.

Decentralized Decision Making

To understand the organization of OSS development requires an understanding of the social structure, often called a social network. In the research by Wasserman and Faust (1998) they defined the structure within a social network as a grouping of units who depend upon each other and who are connected by relationships. In an OSS development project, where the participants are scattered about the globe and interact and connect with each other over the Internet, these units might be the groups of developers, testers and users. The relationships might be the direct discussions between two developers via a conversation or the bonds of trust formed between the users and developers. This social network is how the groups of people share knowledge and solve problems.

In OSS development the structure of the social network, usually comes in two distinct styles. The first style is centralized or group centralization, which Wasserman and Faust (1998) explained and modeled as equivalent to a solar system with a star in the middle and planets in orbit about them. The model they created of group centralization provides a simple measurement of the inequities of the team members based on the differences on actions and the patterns of interaction. This is the model initially used to create the Linux kernel as Linus Torvalds acted as the star and hundreds of developers worked though him suggesting changes which he accepted or rejected. (Raymond, 1999) The second style, as defined by Wasserman and Faust (1998), is core-peripheral which exhibits a central dense interconnected core surrounded by a halo of unconnected peripheral participants. Decentralized decision-making according to O’Mahoney (2007) is defined as a model where some of the decision making rights are distributed to the community members. The decision making rights generally deal with or fall into three distinct categoris of (1)code, (2)sub project and (3)community wide issues. This is the development model used on the FreeBSD operating system where some 300 core developers all have the ability to add and update the source-code at the same time. (Jørgensen, 2007) Thus, the collaboration and decision making process is influenced by the style social structure within the OSS development project and can affect how well a project team performs and the perception of belonging and satisfaction each member of the team experiences.

Autonomous Participation

Developers working on OSS projects will often desire to stake a claim on a particular part of the program and work on that part of the code. The research by O’Mahoney (2007) defined autonomous participation as one of the most important factors where developers are attracted to projects by the opportunity to learn, solve problems and improve their skills. This seems to agree with earlier research by Hackman and Oldham (1980) where their Job Characteristic Model (JCM) defined autonomy as a precondition for high motivation potential that multiplies the other intrinsic motivators. Glen (2003) also discussed the importance of autonomy:

With a solid understanding of the environment, they are able to make their own decisions about day-to-day matters without having to check with the boss constantly. For geeks, who generally have a strong independent streak, autonomy fosters motivation.(p. 110)

Therefore the ability to operate freely within a particular area of the code is a large motivating factor and the existence of autonomy will be a deciding factor for an OSS developer to join a project.

 

The Future of OSS Leadership: Harnessing Innovation

The OSS development model is currently jumping over to physical products such as beer and bread, and into other disciplines such as biotechnology and government policies. This new development process for physical products is often called Open Innovation. (Chesbrough & Garman, 2009) The research by de Laat (2007) made a bold proclamation about the flexibility of the OSS development model when he suggested that this model is the only known model of development that can be applied across products and is not restricted software alone. He tried to find an example of the closed source software development model that can be used for physical products and was unsuccessful in finding any examples. Thus the OSS development model, renamed Open Innovation for physical products is unique in the ability to be used in other industries. This concept is still relatively new to researchers and there is much territory still unexplored.

There is not much current research on how the leadership or governance will be affected by the shift of the OSS development model to other physical product industries. Most of the research continues to demonstrate the need to provide extrinsic motivators but also maintain a focus on the intrinsic motivators. (Chesbrough & Garman (2009), Dahlander, (2008); Grönlund, Sjödin, & Frishammar, 2010)

Most of the current research on Open Innovation looks at the for-profit companies and how they will need to shift their thinking about corporate boundaries. The companies will have to accept that the boundaries of their organization, once firmly defined will now have to be permeable and allow for interactive and distributed innovation where the resources, ideas and people move in and out of organizations constantly. (Laursen & Salter, 2006) This means that employees will need to experience those same intrinsic motivators as defined by O’Mahoney (2007) as their affiliations with a company will be much looser and not tied to the extrinsic motivation of a paycheck.

The research by Chesbrough & Garman offers an example of the Phillips company who, seeing a failure in their research model, opened up their R&D facility and created a open campus where now some 7000 researchers from multiple organizations share knowledge about products they create. The authors explained how this style of leadership prevented lay-offs and prevented the “high emotional and economic costs of severance while boosting morale for remaining and departing workers alike ” (p. 75). Thus the current research still reflects the regular needs of leadership as defined in Glen (2003), but also recognizes the advantages of embracing an Open Innovation model.

Changing Fast

All the research uncovered by this author had a common thread of exasperation among the researchers. The OSS development process is changing and morphing quickly. So quickly in fact, that the research cannot keep up. The research into the motivators of OSS developers by O’Mahoney (2007) explicitly stated that the rapid evolution occurring in the OSS development process as new hybrid models appear made defining the responsibilities of leaders and the structure of governance difficult to define. The leadership of the future version of an OSS development project, or Open Innovation product, will require a cyclic return to the list of extrinsic and intrinsic motivating factors to determine how well they are meeting the needs of their open communities.

References