How Git Makes Us Agile — Or Not
Can tools—and how we use them—determine whether a team works “agile”? A fool with a tool is still a fool, says Stefan Mintert.
Hi.
In my work with developer teams, I’ve come across the idea that “we’re agile if we work the way Jira expects us to.” I disagree. To me, the saying applies: A fool with a tool is still a fool.
I don’t believe a tool can make a team agile. However, the way tools are used can reveal a lot about how agile a team actually is. That also applies to tools an agile coach or Scrum Master often doesn’t pay attention to—especially Scrum Masters without a technical background. In those areas, developers need to take the lead so the team can move forward. Let me explain what I mean with a real example.
I worked with a team that struggled to meet goals and sprint commitments. The team often couldn’t finish what they had planned at the start of the sprint. Tickets rolled over from one sprint to the next. Cycle time was high. These are fairly common problems; there wasn’t much agile spirit left in sight.
While the causes were multi-layered, Git played a central role. It gradually became clear that Git skills varied widely within the team. There were younger developers who had always worked with Git, and older developers who had used systems like CVS or Subversion before encountering Git.
The latter had never engaged deeply with Git and largely tried to work the way they were used to with the older tools. What they especially missed in Git was the blocking check-out (file locking) to avoid merge conflicts. They weren’t good at resolving merge conflicts. When conflicts occurred, they avoided resolving them and started working on the next ticket. As it turned out later, the idea was: “I’ll tackle the unpleasant work later in one go with all the tickets.”
Too Many Tickets in the Final Stretch
What went unnoticed was this effect: the longer someone waited to merge during the sprint, the bigger the conflict became. The master branch kept evolving, of course. When merging finally came due shortly before the end of the sprint, the task had become so large that the team couldn’t finish many tickets within the sprint. Because it was considered normal for unfinished tickets to slip into the next sprint (“that’s how we always do it”), there was no impulse to question the situation.
An analysis of lead times in Jira didn’t easily uncover the root cause. That was because:
the statuses used (board columns) weren’t granular enough to show where a long-running ticket was stuck,
developers handled the affected tickets as opaquely as possible on the board—presumably to cover up the problem, and
the use of sub-tasks in Jira further obscured the cause. As an aside, this is why I’m not a fan of sub-tasks. They also undermined attempts to spot the issue via work-in-progress (WIP) limits.
All in all, it was a situation that made it very hard for me as an agile coach to get closer to the root cause.
In the end, it was one of the “Git native speakers” who recognized that several teammates had major gaps in their Git skills, which is why tickets remained unmerged for so long. He offered a few hours of pair programming. That’s how he saw which knowledge was missing. Once the problem was recognized, finding a solution was comparatively easy.
The team decided to run regular Git exercises. It actually took just one sprint for the problem to disappear. That was possible because the “Git juniors” asked the “Git seniors” for help with merging—remarkable, because the juniors have been developing software longer than the seniors. It showed that experience isn’t one-dimensional and doesn’t necessarily correlate with age. Diversity and appreciation within the team are important, but those are topics for another blog post.
Conclusion
Switching to agile ways of working isn’t a job for the Scrum Master or coach; it’s a change the team can only accomplish together. When developers step into their leadership role, they can achieve improvements that are not easily within the Scrum Master’s reach.
Until next time.
This article was originally published on heise.de in the german version.