2

Recently my team transitioned from Perforce to Git. As part of the transition, the developers responsible for the transition wrote documentation and provided links to interactive tutorials to help other developers with understanding Git commands and terminology.

Now that the switch has occurred, it's becoming clear that a majority of people on the team may not have followed the transition's team advice to participate in the interactive tutorials, and I don't know how much of the documentation has been read beyond the simple setup steps. I am relatively new to the overall team but one of my first tasks was to assist with the transition to Git as I have Git experience from prior jobs.

How can I (or team management) encourage people to take the time to learn the new Git material?

  • The team definitely have time for git training in their work schedule? It's just a question of convincing them? – Nathan Cooper Jun 24 '16 at 20:51
  • @NathanCooper There is no explicit Git learning time set aside, but the scrum master and dev manager have both said the team should do what is necessary to learn. The team has started on the first sprint for the next release. I think it is becoming clearer that people may benefit from explicit time in the schedule to learn. – masrtis Jun 24 '16 at 21:18
6

it's becoming clear that a majority of people on the team may not have followed the transition's team advice to participate in the interactive tutorials, and I don't know how much of the documentation has been read beyond the simple setup steps.

It sounds as if you observe that the majority of the people are having trouble with git, and you infer that they may not have done the tutorials or read the documentation.

But git has a notoriously difficult learning curve, so my first response is to wonder about the reliability of the inference.

I would start by having a team discussion about how the transition is going: what have they mastered, what are they still having trouble with, what are they confused about? Did they find the docs/tutorials helpful? Do they want a team wiki page with documentation written by the team, containing project-specific examples? Who (else) on the team has git expertise, and can be asked for help? How would they find it most helpful to proceed?

I would strongly recommend the team wikipage, because no matter how good a general tutorial is, a concise project specific cheat sheet with clear notes on how to do common project tasks is an incredibly helpful crutch for climbing up the learning curve.

Some things I would offer as possible ways to proceed:

  • a group walk-through and work-through of the tutorials, so people can ask questions and make sure that everyone has the same understanding of what's going on and is using the same workflow.

  • a git training day, with snacks provided by me, where everyone mostly works through the tutorials independently, but can ask each other questions.

  • add training stories to the next sprint that, if possible, also have some minimal project value. For instance take some trivial bug fixes or tech debt or even documentation tasks, if you're keeping your docs in the repo, and go through specific workflow steps.

  • an entire sprint devoted to Learning Git, in which the sprint goal is that each team member has demonstrated a desired level of mastery, and the stories are defined by the team as helpful steps in getting there

  • Part of the evidence for the statement I quoted has come from the team directly: most team members have admitted that they haven't tried the interactive tutorials yet. Some others have called people on the transition team over to help them with setup or the basics, and when told that it is documented shortly after their current locations in the docs, were able to complete the task. Working on links for the latter, I think your suggestions will help with the former. – masrtis Jun 27 '16 at 14:19
4

Infrastructure Change Has Costs; Company Must Absorb Them

How can I (or team management) encourage people to take the time to learn the new Git material? ...There is no explicit Git learning time set aside, but the scrum master and dev manager have both said the team should do what is necessary to learn.

This is what is commonly known as an "unfunded mandate." By taking this position, you are essentially asking people to work off the clock to avoid charging the necessary time or training costs against the project. This is a pragmatic and an ethical no-go.

Since the organization determined that they needed to switch to Git, the company/project should absorb the full cost of the change. That most definitely includes budgeting for education or training, and adjusting the project schedule to making time for the development team to learn the new system and to get up to speed on it.

In a traditional project management shop, training and education work packages should be added to the schedule. Scope or schedule should then be adjusted to acknowledge that developers will be busy learning rather than developing, as well as factoring in a slowdown in productivity until the workflow fully adapts to the new tools.

In an agile shop, you need to accomplish much the same thing, but would do it by ensuring that there are training and education stories on the Product Backlog. The team may also have to temporarily reduce the number of story points accepted into each iteration to address the fact that integrating a new system into the workflow has a cost beyond the initial learning itself.

  • Completely agree with your statement and I can see where people might get the impression that it would be expected of them that they put in extra time or work off the clock with my comment. Because time isn't explicitly scheduled, I can see where some team members may also get that impression so I'll see what can be done to be more explicit. – masrtis Jun 27 '16 at 14:22
1

As I understand it your team already has no other option and sooner or later they must start using Git, or they will not be able to do their work properly.

In my opinion the most important thing for your team is to understand why the transition is being done and why Git is so awesome (and it really is). Here is really good answer for the benefits of Git.

A common approach in my company is to organise internal trainings - e.g. Git for Beginners, Intermediate Git, Advanced Git. This training contains presentation and practical exercises with realistic scenarios which participants should complete during the training. I'm aware that this costs time but gives really good results and you'll have more visibility of their progress.

0

It's a typical situation of change management. You think that the team didn't do enough effort to switch from Perforce to Git. However, it's very typical to humans that they resist change. To speed up the process you might want to set some type of accountability process to encourage them to use Git. You also might want to set up some type of skill transfer process by utilising internal or external trainings (by yourself, online, etc.).

0

Are you using windows? If yes, consider using Git with integrated UIs like TortoiseGit but don't remove the option of Git Bash on Windows Explorer integration for those who insists on using command lines.

I took the Git training from Udacity and they are using command lines, but I am still encouraging my co-workers to use TortoiseGit as it boosts our productivity and it has some good things like auto-complete when placing comments on the commits, very easy to compare submodules, no need to memorize commands, etc. We are using command-line only on our build servers.

  • Our project is cross-platform so a Windows only solution will not be applicable for everyone, but some developers have requested more information on available GUI choices for Mac and Windows specifically. – masrtis Jun 29 '16 at 17:31
  • yes, using GUIs for Git will lessen the learning curve and could entice your developers into using Git. Most of the times, the basics and intermediate usage of Git are covered by the UI based Git tools. If you hit a roadblock on those UIs and want to do advanced or stuffs that the UIs can not do, you can always fallback on command line. – newbie programmerz Jun 30 '16 at 3:31

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.