Git Integration for Jira

Overview

 

Report

2024 State of Git Collaboration

How well do teams work together? How should they be measured?

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.

THE DATA

Quantitative Git activity & qualitative dev opinions

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

TEAM SIZE

Devs want their teams to be larger, but smaller teams appear more productive
An important first step is to uncover the impact on team size and make-up. Most developers wished their development team was larger. And this was consistent across team sizes. Devs that work in groups of 6-10 were the happiest with their team size, with 48% of respondents indicating that preference.
Developers who wished their team was larger focused on information sharing and being able to collaborate more. For these devs, more bodies equals less load and the ability to accomplish more – a natural feeling that is often shared regardless of job role. Many also felt it would lead to the team being more productive. However, this somewhat surprisingly clashes with data that shows smaller development teams tend to be more active, and move more quickly and efficiently with shorter PR cycle times.
Not all commits are equal (and it’s a poor metric for productivity), but as team size decreases, the workload per person possibly increases.

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.

COLLABORATION

Devs feel like they’re doing OK, but want more ways to work together
Larger teams are more likely to score higher when asked if their tools and workflows enable their team to work collaboratively to deliver higher quality code faster. Larger teams with more resources might feel like they are better equipped with technologies and have more of a team they can lean on. This aligns with developers wishing their team size was larger.

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.

BARRIERS TO PRODUCTIVITY

Distractions and lack of focus clearly hamper both individual and team productivity
So what is getting in the way of developers being more efficient? On a personal level, the biggest culprit was context switching, followed by unclear/shifting priorities, and then too many unproductive meetings. When asked to think about their broader teams, poor communication was the most common answer.
The data shows that devs see being pulled in multiple directions and not being able to focus on finishing out tasks as the key issues in their workflows. Being able to more closely work together and collaborate while also having a common defined playbook to work off of would be a huge benefit. Unproductive meetings unsurprisingly increased as a response as team sizes got larger. However, poor communication as a source of slowing down teams was represented across all team sizes – showing that being able to work collaboratively and working effectively impacts everyone. Technical factors play a role as well, with infrastructure or stack and insufficient / inadequate dev tools making an appearance for more than 1 in 5 developers.

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.

JetBrains provides additional context into some of these barriers. 54% of developers believe they spend more than 21% of their working time in meetings or work-related chats. Looked at differently, that’s at least an entire day of the work week. Plus, 2 out of every 5 developers say they spend less than half of their working time on code-related activity.
Developers in the GitKraken survey cited context switching as their most common productivity barrier. One of the benefits of reducing context switching is the ability to get into and stay in a flow state. Flow state is important because it allows productivity and creative ideas to come much more easily than when a person is jumping between unrelated tasks. JetBrains put some numbers to how often developers are able to get into this state, with only 32% of respondents saying they are working under these conditions very often or always. On the other side of the coin, for 40% of respondents, flow state is most often out of reach.
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.

DISTRIBUTED TEAMS

It’s not 2020 anymore, teams are increasingly distributed and require more connective tissue

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.

One oddity that stood out in the data was the rate at which different global regions make commits. Developers in most regions tend to make about 1.6 commits per day. For developers in North America, that number drops 25% to 1.2/day. Commits are not a great measure of productivity, but why does this one region stand out?

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.

collab-distributed-stat1a
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.

PULL REQUESTS

Smaller pieces, earlier feedback are key to faster reviews and less rework
Looking at usage data, a clear trend emerged across team sizes. Smaller teams have less comments on their PRs, their cycle time is shorter, and their merge rate is higher. This intuitively makes some sense – less cooks in the kitchen, closer connections, and more autonomy.

“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.

The PR review process is a critical one as it relates to both productivity and collaboration. If they take too long, the potential for merge conflicts (and thus productivity loss) increases. Teamwork in the review process is also important. Do you trust the person reviewing it, who’s the best person to review it? Do they understand the history of that part of the code base? Are they available to review it in the time you need it to be – how do you know if they’re not free, who’s the next best? Both GitKraken and JetBrains are focused on improving this part of the dev lifecycle with built in intelligence and automation.

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.

PRODUCTIVITY & SUCCESS METRICS

Clear preference for developers, not so much in their view of leadership

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.”
In all of this talk about numbers and metrics, it’s important to remember what motivates developers. Per JetBrains data, what makes developers feel the most productive is seeing that the results of their work are of use. This narrowly edges out the obvious choice of a salary increase. But also important is that only 23% of respondents feel objective indicators and metrics / KPIs are a motivating factor.

What ignites your productivity?

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

Accelerate with GitKraken
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.

CONCLUSION

Reflecting on the State of Git Collaboration

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

  1. 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.
  2. 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.
  3. 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.
  4. 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.”