How to measure collaboration in software development?

Abstract

Software development is a complex process that requires the collaboration of multiple team members. But, how do you measure the efficiency of this collaboration?

Software developers apply their knowledge to deliver desired outcomes. They discover knowledge about "what" tangible output to produce and how to produce it.

Collaboration is a knowledge discovery process that acquires missing information only from personal sources. It enables developers to share their knowledge and discover new information that they wouldn't have found on their own.

To measure the efficiency of collaboration, we need to measure the efficiency of knowledge discovery. The more efficient the knowledge discovery process, the more efficient the collaboration.

KEDEHub allows you to measure the knowledge discovered in software development, using the scientifically backed and patented metric - Knowledge Discovery Efficiency (KEDE). With KEDEHub, you can measure the efficiency of collaboration, productivity, and happiness of your team.

What is collaboration?

“An organization can acquire more information than any one individual, for it can have each member perform different experiments. Thus, the limitations on an individual's capacity are overcome.” ~ Arrow [2]

Software development is a process of going from 0% knowledge about an idea, to 100% knowledge of a finished product - ready for delivery to a customer.

Software developers are engaged in a Knowledge Discovery Process consisting of asking questions in order to acquire the missing information about "what" tangible output to produce and how to produce it. We know there was knowledge discovered when we see at least one question asked.

Missing information can be acquired from two types of sources[1]:

• personal sources - those that communicate information personally
• impersonal sources - those that communicate information to broad audiences e.g. books, articles, conferences, audio and video

Collaboration is a knowledge discovery process that acquires missing information only from personal sources.

It is not possible for two or more people to type on the same keyboard. Thus, when two or more software developers collaborate they don't work together on the manual part of knowledge work.

When software developers collaborate they work together on the knowledge part of the knowledge work.

That is very much seen in practices such as Peer Programming and Mob programming. Pair programming is a software development technique in which two programmers work together at one computer. One, the driver, writes code while the other, the observer or navigator, reviews each line of code as it is typed in. The two programmers switch roles frequently[7]. Mob programming is a software development approach where the whole team works on the same thing, at the same time, in the same space, and on the same computer. With mob programming, the collaboration is extended to everyone on the team, while still using a single computer for writing the code and adding it to the source code repository[8].

The principle of bounded rationality formulated by Herbert Simon states that the capacity of the human mind for formulating and solving complex problems is very small compared with the size of the problems whose solution is required for objectively rational behavior in the real world[4]. Simon defines a ""triangle of limits'':

• the individual is limited by skills, habits, and reflexes;
• by values or conceptions of purpose which may diverge from organizational goals;
• by the extent of knowledge and information possessed[5]

An organization can alter the limits to rationality of its members by creating or changing the organizational environment in which the individual's decision making takes place. Consequently, It is only because individual human beings are limited in knowledge, foresight, skill, and time that organizations are useful instruments for the achievement of human purpose[4].

The information has to be communicated if it is to be of any use to the organization. Communication channels have to be created within the organization[2]. Communication bandwidth is one of our most obvious limits,

How to measure collaboration?

Human capital is the total of collaboration, impersonal sources of information and existing knowledge. Of those only collaboration can be affected by the number of people who work together.

• Existing knowledge doesn't depend on the number of people in the organization. That is because Human Capital is the average KEDE for all contributing developers for a time period. It doesn't matter how many contributed. It does matter what their individual KEDE was.
• Impersonal sources of information don't depend on the number of people in the organization. If people with access to better impersonal sources of information join, their personal capability will affect the organizational human capital only if there is collaboration in place.
• Collaboration depends on the number of people in an organization. Collaboration can be negatively affected by the coordination overhead. Teams of non-collaborating developers become less productive ,as they grow in size.

Thus, we can conclude that if we consider the Human Capital relative to the number of contributing software developers then we can infer if the collaboration is increasing or decreasing.

Collaboration can be measured, with the efficiency of a knowledge discovery process, relative to the number of contributing software developers.

There is a way to measure the knowledge discovered (missing information) in software development. KEDEHub allows you to measure the human capital of your company using the scientifically backed and patented metric - Knowledge Discovery Efficiency (KEDE). KEDE is an acronym for KnowledgE Discovery Efficiency. It is pronounced [ke.de].

KEDE is a ratio between how much knowledge a knowledge worker discovered for a time period and a predetermined constant representing an estimated maximum amount of knowledge that could possibly be discovered for the same time period.

When presented as a percentage, KEDE has a minimum value of 0, and maximum value of 100.

Existing knowledge is the easiest and the fastest to discover - it is there, one just applies it. In other words, when existing knowledge is applied then there is the most efficient knowledge discovery. Conversely, when a lot of knowledge is missing then the knowledge discovery is less efficient. The more existing knowledge was applied i.e. the less knowledge was missing the more efficient a Knowledge Discovery process is.

KEDE reflects the capability of software developers to efficiently discover and apply knowledge.

As an example, let's look at Solana - one of the leading crypto companies with a market cap of $13 billion!

Below is a diagram presents the impact company size has had on Solana's capability for the last two years.

On the x-axis we have the quarter dates. We have two y-axises - one for the capability and one for the size of the company. Capability axis is to the left and is in Weekly KEDE values. How capability changes through time is presented by the dark blue line calculated using EWMA. Each point of the blue line is the average Weekly KEDE for all the developers who contributed in that week. Company size axis is to the right and is the number of developers who contributed to any of Solana projects in a given week. How company size changed through time is presented by the green line. Each point of the green line is the number of developers who contributed in a given week. How the diagram is constructed is explained here.

We witness a period, where there is a negative association between the company size and its capability. For more than two years company size grew steadily from 20 to 44. That is a 120% increase. At the same time capability steadily decreased from 3.6 to 1.3. That is a 64% decrease. Such a long period of decline in development capability points out some significant flow in the way software development has been managed at Solana. From the frequency diagram we see that there even were a few weeks where Solana had only one contributing developer!

KEDEHub allows you to make comparisons among your company's functional areas and between your company and others. You are now able to unleash your company's untapped collaboration potential by objectively and scientifically answer questions such as:

• What is the level of a company's collaboration compared with the average level in the industry?
• Did the latest increase in headcount increase a company's collaboration?
• Did the Agile transformation increase a company's collaboration?
• Did the latest re-org increase a company's collaboration?
• What is the level of a team's collaboration?
• Did the new recruits increase a team's collaboration?
• What is the level of a team's collaboration compared with all other teams working on the same project?

Works Cited

1. Choo, C. (1994). Perception and use of information sources by chief executives in environmental scanning, Library & Information Science Research, Volume 16, Issue 1

2. Arrow, K. (1974) The Limits of Organization.New York: Norton

3. Simon, H. (1947) Administrative Behavior: A Study of Decision-Making Processes in Administrative Organization. New York: Macmillan.

4. Simon, H. A. (1957). Models of man - social and rational. New York: John Wiley.

5. Simon, H. A. (1976). Administrative behavior. (3rd edition) New York: Free Press.

6. Choo, C. (2005). The Knowing Organization: How Organizations Use Information to Construct Meaning, Create Knowledge, and Make Decisions. : Oxford University Press.

7. L. Williams, "Integrating pair programming into a software development process," Proceedings 14th Conference on Software Engineering Education and Training. 'In search of a software engineering profession' (Cat. No.PR01059), 2001, pp. 27-36, doi: 10.1109/CSEE.2001.913816.

8. Zuill, Woody (2014). "Mob Programming: A Whole Team Approach". Agile2014 Conference Experience Reports: