Collaborative Software Development with GitHub Projects

As software projects grow, they increasingly depend on people with different professional backgrounds working together, often without ever sharing a room. The instinct is to reach for a tool. This paper argues that the tool only helps once the coordination problem underneath it is understood, because collaborative software development is a socio-technical challenge rather than a purely technical one.

GitHub Projects is examined as a functional, methodological approach to imposing structure on that process: not as a product recommendation, but as a workflow that takes a position on how distributed teams should organise their work.

Introducing a collaborative system

Before any workflow can help, it has to be adopted, and adoption is where these introductions usually fail. A lack of acceptance can threaten an entire system change on its own, independently of whether the system is any good. Ordering a new process top-down remains tempting and tends to perform worse than a staged approach.

The paper therefore sets out a four-phase model, drawn from change management, for introducing a collaborative system.

Promotion comes first because acceptance rises when people are involved early enough to feel some ownership of the change and to understand why it is needed. Withholding that context has the opposite effect: a strategy of obscurity hardens an existing disposition to reject. Once acceptance is reached, the change should be executed quickly, which favours parallel adoption or a single decisive cutover over a gradual one.

The analysis in phase two examines a change that has already been made. Changes are identified, their effect on the culture and processes of the project assessed, and the result discussed with the people affected. Even rejecting a small proposed variation produces a sense of shared responsibility, and the alternative to that is a further rise in shadow IT. Phase three then implements whatever variations that discussion produced, and the settling phase deliberately schedules nothing at all, on the reasoning that a central system change already demands above-average commitment on top of daily work, and a durable working environment needs intervals of lower organisational stress built into it.

Phases two to four then repeat, because requirements shift as a project proceeds and a process that was welcomed at the outset can quietly become a liability.

Where collaborative development goes wrong

The recurring problems are classified into six dimensions, and only one of them is technical.

Strategic issues arise because new requirements are hard to fit into a structure once the original scope is fixed. Cultural issues are the principal driver of interpersonal conflict, since differing needs and communication styles collide continuously and the resentments that follow cost real productivity. Inadequate communication is related but distinct, and it bites hardest early, when the volume of clarification a project needs exceeds what virtual channels carry efficiently. Knowledge management is the most neglected: where earlier results are not documented and readily findable, settled questions get relitigated, which demoralises people and erodes the transparency the project depends on.

The project and process dimension covers what the paper calls desynchronisation, the loss of a shared perception of project status, and its illustration is the sharpest thing in the paper. Two physically separated groups agree on a milestone described as a working module. One reads that as passing alpha testing, the other as passing beta. Nobody has misunderstood anything in an obvious way, and nobody is at fault, yet the delay surfaces only when the two modules are joined, by which point it has propagated to everything downstream on the critical path.

Technical issues, finally, cover the ordinary friction of a decentralised network: unreliable connections, incompatible development environments.

What GitHub Projects contributes

GitHub Projects, introduced in 2016, rests on Kanban, a method devised by Taiichi Ohno at Toyota to improve manufacturing efficiency and whose name translates as “visual signal”. Work items become cards, every team member can see them, and progress is legible at a glance rather than on request.

Six functions carry the workflow. Task management absorbs any kind of work, issues, bug reports, to-do lists or bare ideas, and allows it to be prioritised, sorted and assigned. Project planning introduces the element of time, syncing development status against management through indicators such as “To Do”, “In Progress” and “Done”. Workflow automation removes the manual bookkeeping that produces planning mistakes. Progress tracking follows from the two before it. Status sharing gives every card a unique URL, so discussion attaches to the work rather than living in someone’s inbox.

The sixth is wrap-up, and the paper argues it is the one most often dismissed. Closing a project cleanly, recording what was learned and leaving it retrievable is what makes the next project cheaper, and GitHub Projects retains past boards precisely so that history remains inspectable.

Three ways of working, compared

To assess whether the shift towards social coding is justified, the paper compares it against two alternatives across five criteria.

	Lone development	Non-collaborative team	Social coding
Level of collaboration	n/a	Low	High
Agility and reaction speed	High	Low	Medium to high
Transparency	Medium*	Low*	High*
Manageability	High	Low	Medium to high
Sync with project management	Medium*	Low	High*

* Dependent largely on personal responsibility.

Lone development, having no collaboration to coordinate, reacts fastest to structural change and is easiest to manage, but its transparency and its synchronisation with project management rest entirely on the disposition of one person. Non-collaborative teams carry more workload yet struggle across agility, manageability and project management sync, which is the worst of both positions. Social coding reaches the highest level of collaboration, with agility that holds up but depends on team size, and it is harder to manage than lone development while remaining easier than the uncoordinated team.

Conclusion and outlook

The shift towards collaborative forms of development is judged justified, on the grounds that a social approach tightly connected to project management buys fast reaction time, high transparency and good manageability at once. GitHub is recommended as a base for projects of both small and large scale. The qualification matters as much as the finding: the benefit is conditional on members actually following the agile approach and communicating actively, and without that the tooling delivers none of it.

The closing outlook, written in 2018, expected machine learning to reshape this work through better real-time translation for international teams and through the automation of routine programming tasks such as generating interfaces between modules or producing test units. The argument for it was not cost but attention: teams freed from standardised code brackets can work at a higher level, shortening development cycles while automated testing raises quality. It also anticipated that outsourcing and self-employment would continue to push teams apart, making collaborative systems more necessary rather than less.

Abstract

Following the ongoing trend of physically detached teams in collaborative software development, we examine the current possibilities of collaborative systems. At first we give an introduction to collaborative systems and the process of software development. Afterwards we analyse common problems that occur during collaborative software development. As a possible solution for the aforementioned problems regarding collaborative software development, we introduce GitHub Projects, a functional, methodological approach towards a structured development process.

@techreport{golombeck2018github,
  author      = {Golombeck, Marius and Orlowski, Henning and Tübben, Stefan},
  title       = {{Collaborative Software Development with GitHub Projects}},
  institution = {University of Applied Sciences and Arts Dortmund},
  address     = {Dortmund, Germany},
  year        = {2018},
  month       = jul,
  language    = {english},
  doi         = {10.13140/RG.2.2.19507.27681},
  url         = {https://www.researchgate.net/publication/330162832}
}