How to strengthen your development team with IBM DevOps Insights
Complex systems require developers to work together and problem-solve together. To achieve this goal, developers must be able to easily read, understand, edit, or rewrite each others code. The introduction to this series “How to strengthen your dev team with insights on social coding” explained how today’s DevOps practices rely heavily on social coding. In this post, I’ll explain in more detail how social coding interactions affect your development team dynamic and how your team can achieve greater output and respond faster by adapting your development processes based on these insights. IBM DevOps Insights can help answer questions like:
- Are team members comfortable changing each others’ code?
- Are development responsibilities distributed equitably?
- Who would be a good candidate mentor? Who could benefit from mentoring?
- Are there signs that the project is at risk of being abandoned in the future?
With the help of the Social Coding graph in IBM Cloud DevOps Insights, you can assess the dynamics of your software engineering team.
To set it up, follow the instructions in Create a toolchain from the Developer Insights and Team Dynamics with GitHub and JIRA template. After your toolchain is configured, DevOps Insights mines and analyzes your project. To track the progress of the mining and analysis, from your toolchain, click DevOps Insights and click Developer Insights to see its status as shown below:
With the setup complete, let’s look at some typical Social Coding graphs.
Exploring the Social Coding graph
After the mining is completed, expand Team Dynamics and click Social Coding to view the Social Coding graph. The graph below shows how well team members understand each others code and how comfortable they are with changing each others code:
The layout of the graph indicates the most central developers. In this example, Tammi is the most central developer. Developers on the outside of the graph are usually new team members. Those developers become more central as they interact with more team members.
You can see information about social coding during a specific time period by selecting a period from the time menu.
Each developer on the team is represented as a node on the graph. The size of the node correlates with the amount of code that the developer changed through social coding. The pie chart in the node captures the types of interactions with other developers.
Blue indicates how many lines of code a contributor added as a portion of the total number of lines that the contributor touched. Red indicates how many lines of code a contributor removed. The nodes are scaled, so the size differences are larger than they appear.
The lines between developers represent social coding interactions between those developers. The thickness of a line represents how much code those developers edited together. If a line returns to a developer, the thickness of that line indicates how much that developer edited his or her own code.
You can click developers to explore their interactions and view their social coding neighborhoods. In this example, look at Louise:
The nodes and lines are filtered to include only Louise’s social coding interactions. To return to the full graph, click white space anywhere on the graph.
Recognizing a well-connected vs. poorly connected team
On an outstanding social coding team, the developers work together. In the following example, the excerpted graph on the left shows a connected social coding team. Contrast that team with one that has a “heroic programmer”, who for some reason does most of the work. In the excerpted graph on the right, Zoe is a heroic programmer.
Among the other developers, few social coding interactions are occurring. Most of the interactions are Zoe changing her own code. If Zoe moves to another project, this project will suffer.
It’s important and valuable to track when one person is doing most of the work. It can be a symptom of overlooked or unknown issues. The project might be planned poorly, requiring one developer to handle all of the requirements. The code might be hard for newcomers to understand. Zoe might be territorial and reject changes. After the symptom is recognized, the cause can be found and mediated.
Align your team to achieve a social coding transformation. With the Social Coding graph, your team has the data that it needs to understand where it must improve.
Driving more effective retrospectives
The end-of-week retrospective is a useful way for developers to reflect on their work. Generally, this meeting is either driven by memory or an issue-tracking system. These methods have little or no visibility into the team coding dynamics.
You can drive the conversation by showing the code interactions during the week on the graph. From the time menu, select Past week.
Before a developer provides input in the retrospective, click that developer in the graph to load his or her social coding interactions. In this example, Navya is selected. Navya can drive the conversation by showing her coding interactions.
Navya fixed a major bug this week. Most of those changes were to Dunn’s code. This view surfaces that relationship so that knowledge sharing can occur between Navya and Dunn.
In the next example, the graph presents a developer who edited only her own code. If that behavior becomes a long-term trend, it might need to be addressed.
In the final example, the left graph presents a team that whose workload is fairly well distributed and whose interactions are frequent. In contrast, in the graph on the right, the social coding is sparse. A team might consider the potential of the project eventually being abandoned.
Tailor DevOps Insights to your team goals
The Social Coding graph in IBM Cloud DevOps Insights can be tailored to each team’s goals. Whether your goal is like one of the use cases in this blog post or another goal, such as choosing new team members, the graph is a flexible and powerful tool in your DevOps tool belt.
Stay tuned as DevOps Insights expands! To learn more, check out the tutorial video.
Share this post:
via Bluemix Blog https://ibm.co/2pQcNaA
May 23, 2017 at 03:06AM