More and more, software development is becoming a team sport. Whether your dev team is 2,000 people, 200, or 2, if it’s more than just you, you’re part of a team.
But all teams are not created equal.
So what separates good teams from great ones? Is it speed? Technology? Data? Process? Communication? All of the above?
All organizations want better productivity and better outcomes. But are today’s orgs just ‘chasing the metrics’ or are they effectively identifying and implementing successful workflows to affect those outcomes?
We wanted to know the current state of developer collaboration. And our users are asking too. So we looked at the data to find out.
We analyzed a massive chunk of anonymous 2023 GitKraken usage data:
- 150,000 developers
- 1,200,000+ pull requests
- 8,500,000 commits
- Plus, survey responses from over 1,000 developers from across the globe.
And finally, JetBrains State of Developer Ecosystem research (with more than 25k survey participants) provided additional insights and context.
The result? A set of clear and immediate opportunities for improvement, including:
- How devs want their teams built & structured
- How devs think productivity should be measured & prioritized
- Where dev teams feel the most blocked & what can fix it
- Where devs want better collaboration & how to enable it
Success Story: Learn how Lansweeper cut pull request review time by over 50% with GitKraken
Comments from those that wished their team was smaller:
- “As the team lead, I spend most of my time helping people rather than working tickets. Having a large team only exacerbates the situation. Right now, I am bifurcating the team into sub groups, so that each group can work collaborating together (functionally two teams within a scrum team)”
- “We could have fewer discussions about how to do it, and more time just doing it. Overall faster delivery.”
- “I would like to have more connection between what is happening. Communication with a large team can be very difficult and time consuming.”
The bottom line:
What’s the right team size? It…depends – find the right balance for your teams. Some say you should be able to feed a team with one or two pizzas. If it gets larger than that, perhaps it’s getting too big. Things can get bogged down with alignment, meetings, etc. becoming more difficult and time consuming. Lean into the strengths of your current team size while experimenting with new team makeups. Consider aligning your teams vertically vs. horizontally. And think about the impact of distributed teams not in the same location or time zone.
Looked at more broadly:
- Over 1/3 of respondents felt their teams could greatly improve their tools and workflows
- 79% believe there’s an opportunity to improve upon what they’re doing today.
So what tools are developers using and when are they using them? JetBrains data provides some additional insights.
Not surprisingly, the most commonly used tool for issue tracking and project management is Jira, with GitHub Issues and GitLab Issues a distant second and third. This is a good reminder that the integration between your Git repositories and your planning systems is crucial for providing proper context and updates for stakeholders.
Moving from planning to source control, Git is the standard. 87% of respondents to the JetBrains survey said they use Git regularly. GitHub is the most frequently used service for company use (50%), edging out GitLab (38%) and Bitbucket (17%). When it comes to personal use, GitHub’s lead grew substantially, with 77% of respondents saying they use it in that manner compared to 19% for GitLab and 9% for Bitbucket.
Developers are most often working collaboratively when something is wrong. Typically it’s when they or a teammate is stuck and needs help or bug fixing. This points to a reactive vs. proactive trend of working on code together.
The bottom line:
Devs generally feel like they’re in an OK place when it comes to collaboration. Coding is primarily an individual effort, but developers need a sounding board for support and feedback. They need teammates they can trust to provide guidance and a gut check (or another set of eyes) in a healthy way. AI (e.g. GitHub CodePilot) can provide some of this; in essence letting a smaller team gain some of the benefits of a larger team. But, it doesn’t offer the broad perspectives that a diverse team of contributors can offer. It could also lead to less collaboration – and an over reliance on code you didn’t write nor understand. Tools and workflows that enable collaborative development like pair programming, are increasingly important as team makeups evolve.
GitKraken Focus View empowers you to achieve more, faster. A unified dashboard consolidates PRs, Issues, and WIPs from multiple repositories, placing them front and center. Prioritize, act, and collaborate with certainty.
The bottom line:
Remove sand from the gears and let developers stay in flow state. Think of them as artists or jazz musicians where creativity leads to process improvements, a better product, and new solutions. Meetings are often a necessary evil, but should come with clear agendas and expected outcomes. Team members should be empowered to abstain from meetings where they are neither receiving nor providing value. Devs state they are generally happy with their team’s collaboration, yet ‘poor communication’ and ‘changing requirements’ appearing as the top reasons for slowing a team down point to a troubling conclusion. They believe leaders aren’t doing a good enough job conveying a vision. Set clear goals with reasoning and provide opportunities for devs to be acknowledged for their work – identified as a large motivator in the success metrics section below.
Does work in an increasingly distributed world play a part in effective collaboration? Teammates are more often no longer in the same physical location, where it’s easy to tap someone on the shoulder to ask a question or have them provide a gut check on some code. We asked developers that were part of distributed teams what factor that plays in impacting their workflow.
If you’re part of a distributed dev team (i.e. not in the same location), what part of your workflow presents the largest challenge?
- “The speed of PR approval or denial. As soon as the PR is submitted, it should be reviewed and the submitter should get some feedback sooner than later”
- “It’s difficult to establish and maintain a good team atmosphere and culture”
- “It can be difficult to coordinate and manage project schedules in a distributed environment”
- “Lack of face-to-face interaction can lead to a decline in team cohesion”
- “It is not convenient for instant communication and problem solving between team members.”
- “Proximity knowledge transfer (i.e. to debate problems & solutions in a non-formal way) is difficult”
- “Monitoring remote team member’s productivity”
JetBrains data shows that for their global collection of respondents, the overwhelming majority of teams are distributed across more than one physical location. Collaboration can be challenging in those situations. 45% of developers practice remote collaborative development, with video calls (with screen sharing) as the most common way that simultaneous collaborative development is being done.
JetBrains data shows that for their global collection of respondents, the overwhelming majority of teams are distributed across more than one physical location. Collaboration can be challenging in those situations. 45% of developers practice remote collaborative development, with video calls (with screen sharing) as the most common way that simultaneous collaborative development is being done.
We don’t have a definitive answer of why, but can offer one hypothesis.
“The US is probably driving that behavior a little bit. A lot of companies are headquartered there who offshore work to the rest of the world. In a lot of offshoring situations they take on maintenance work; and a good rule of thumb is smaller pieces of work with more frequent commits. When they sign off for the day, and the team back in the US is back up, they want to make sure that whatever code they were working on is in the branch.”
– Ross Wheeler, VP of Engineering GitKraken
A parting thought about remote development. JetBrains data shows that 79% of developers would like to access development projects from various devices and locations. And 76% believe that it would be beneficial to standardize the development environments for developers. Being confined to local machines to perform work is quickly becoming a thing of the past. Solutions like GitHub Codespaces and JetBrains Space are making this easier and easier.
The bottom line:
In an increasingly distributed world, it becomes more difficult to establish team culture and cohesion and collaborate together. Communication and collaboration tools (like Zoom and Slack, etc.) certainly help us bridge those gaps, but it’s tough to truly replace the ease of walking over to a teammate’s desk to troubleshoot something. Collaborative development tools (like GitKraken’s developer services and JetBrains Code With Me) become vastly more important as this style of work becomes the norm.
Success Story: Learn how Superna achieved 94% time savings with GitKraken by onboarding devs faster and expediting labor-intensive workflows.
“Faster cycle times and less comments on PRs make logical sense for smaller teams. Your communication channels are smaller and you don’t have to explain as much. I am a bit surprised by the merge rate – I would expect the converse to be true. As a smaller team you don’t have the pressure to merge because the expediency isn’t there compared to a larger team where you would want to merge more often to prevent conflicts from happening.”
– Ross Wheeler, VP of Engineering GitKraken
When asked if their PRs are too large, most developers tended towards “sometimes,” with only 1 in 4 developers giving a firm “no.” While the distribution was fairly similar along team sizes, devs in larger team sizes were much more likely to say yes vs. their smaller team counterparts.
Engage in early collaboration and meaningful discussions long before the pull request with GitKraken Cloud Patches. Speed up merges and keep your repos simple, fuss-free, and organized.
The bottom line:
While making smaller pull requests more often is an option, a better approach is to engage in early collaboration and meaningful discussions long before the PR. By reviewing code and getting feedback from teammates earlier in the process, less rework is required and merges move quicker. Distributed teams in particular should look for tools that enable this as part of their standard workflows.
When it comes to measuring their productivity, the overwhelming majority of devs state code quality was their #1 measuring stick. When it comes to their view of what their leadership focuses on, Throughput rose to the top of the responses, narrowly edging out code quality and workload.
There was a much broader distribution of answers when it came to thoughts on leaderships’ focus. Developers know what they want to focus on, but aren’t quite as sure about their leadership. This potential disconnect can lead to poor team cohesion and impact business outcomes.
What was notably different from developers and their perception of leadership?
- Throughput was unsurprisingly perceived as the most important metric for leadership (33%), but ranked in the middle of the pack (20%) for personal metrics.
- Test coverage appeared for 30% of personal responses, but only 17% felt it was important to leadership.
- Only 13% of respondents stated activity (e.g. # of commits, lines of code written) was important to them. However, 1/5 developers stated that metric was important to leadership.
We see developers want to focus on writing non-brittle code that’s well documented, and has strong test coverage. Their view of leadership’s priorities is a bit more spread out, with the obvious choice of Throughput – getting work done in a defined set of time – on everyone’s mind. Developers were not shy in sharing what they thought was wrong with today’s approach to developer productivity metrics.
What’s wrong with today’s developer productivity metrics. What do individuals, managers, and execs focus on that they shouldn’t? What should they focus on?:
- “I’ve heard many stories from colleagues where their managers required them to write x lines of code, make x commits, completely ignoring documentation or test coverage – sounds a bit absurd to me.”
- “Though it’s changing, they don’t account for the interruptions, context change and fact that all is not know when we evaluate story points. Even with deep knowledge we can’t forsee every issue. We’ve started to add bucket in our sprints to log time spent on non-dev or non-storied tasks.”
- “Our manager focuses on too much hours devs spend, so we are really rushed and try not to spend time on tasks. It ends up not getting tested well.”
- “They focus too much on individual contribution and not enough on one’s multiplicative effect on the team output.”
- “In today’s developers, the problem lies in the thought process of their minds. Then tend to overcook a code/ over(under)-estimate their work and also tend to keep a couple of key elements to themselves rather than discussing ideas and making it better. A spirit of teamwork thus should be encouraged.”
- “They focus too much on time spent and tasks completed rather than the result itself. Usable UI, maintainable/legible code, and investing time commensurate to the value created are hard to measure with simple metrics. They need nuance.”
At GitKraken, we believe true acceleration = the right skills + knowledge + processes + tools — and sustaining flow state as long as possible. Our mission is to equip you and your team with the ultimate suite of Git productivity and collaboration tools; you’ll have to complete the equation.
Propel your projects forward — see what’s included in a free GitKraken Pro trial
The bottom line:
“Lies, damned lies, and statistics” colloquially refers to the power of pointing to data to support a bad argument. Are you using metrics in the right way? We can all capture data, but are we looking at the right data and using it properly? What do you do with it? Is it a whip to crack, or a ‘canary in the coal mine’ that your workflows, team cohesion, or tools need some love? The only way to improve something is by first establishing a baseline, changing a variable, then observing the change (positive or negative). It’s not surprising that devs #1 focus is code quality. They want more time to work on it and test it, so it works the first time and with subsequent releases. No one wants to debug and rewrite someone else’s hastily cobbled together work. But, timelines aren’t infinite and the business requires that code ships. Balance can be achieved by doing a better job of sharing vision and recognizing devs for how they are making that a reality.
As we conclude our journey through the vast landscape of Git collaboration, we’ve uncovered pivotal insights that redefine the essence of effective teamwork in software development. From the nuanced intricacies of team sizes to the dynamic challenges of distributed teams, our exploration has revealed both challenges and opportunities for software teams across the globe.
Actionable Steps for a More Collaborative Future
- Unify Vision and Efforts: It’s imperative to align your team’s efforts with the business’s overarching goals. Engage in open dialogues, gather feedback, and ensure every team member sees the value of their contributions towards these objectives.
- Rethink Team Structures: Evaluate your team’s composition and workflow dynamics. Are they optimized for fostering innovation and collaboration? Reflect on how structural changes could unlock new levels of creativity and efficiency.
- Embrace the Evolving Tools Landscape: The tools of today shape the successes of tomorrow. Empower your developers to explore and advocate for tools that enhance workflow efficiency. Both GitKraken and JetBrains offer powerful tools that can help elevate your team’s collaborative experience.
- Bridge the Gap in Distributed Teams: In a world where remote work is the norm, find ways to foster a sense of connection and belonging. Utilize tools and practices that encourage seamless collaboration and shared success, regardless of physical location.
Join the Conversation
This report is a starting point. We invite you to continue this conversation. Share your thoughts, experiences, and insights with us. Together, let’s redefine the boundaries of collaboration in software development.
In the words of Matt Johnston, CEO of GitKraken, “The future of software development hinges not just on the tools we use, but on the way we come together to use them. Let’s build that future, one commit at a time.”