As the new guy, how do I get people to act on all their big talk?

Question

I'm "the new guy" at a small manufacturing company's IT department. We've a small team of 3 application devs + 1 database dev/dba-ish role. I've been here for a few months, so I'm hitting the point where I've started to gain the trust and recognition of my colleagues.

During my interview, there was a lot of talk about wanting to be more Agile. There is still a lot of talk about it, but no action on it. To be honest, I don't care if we're "Agile" or not, but we really do need to start doing some things that are just best practice, Agile or not. Things like Unit Testing and Code Reviews. Yes, let's go with those two first, as they're the biggest bang for the buck.

Now, I've been putting code I touch under test before modifying it. Partly because I've seen the benefits, and partly because I'm afraid of breaking anything in a legacy code base. My manager is very happy with this. He's told me so himself. The rest of the team seems to like the idea of testing and gated check-ins, but have not taken any action to start actually doing these things. I think it might be because they simply don't know how, but it's possible that they think "they don't have time". (The not having time part is totally untrue by the way. Management knows it's an investment up front that pays dividends back and is completely supportive of the effort.)

It's honestly becoming a bit frustrating for me to hear so much talk, but to see no action from my teammates. As the new guy, how can I push them into action without ruffling feathers? I don't want to be that guy.

---

This is not a duplicate of the suggested question because that guy was asking if/how he should push his ideas. These aren't my ideas (although I agree with them, obviously). My question revolves around how to get my colleagues to take action on their words.

Answer 1

It's honestly becoming a bit frustrating for me to hear so much talk, but to see no action from my teammates. As the new guy, how can I push them into action without ruffling feathers? I don't want to be that guy.

Using phrases like "big talk" and "push them" can indeed make you that guy, so you don't want to go there.

Consider asking your manager if it would be okay for you to create a presentation on some of the practices you consider important. Some companies have "brown bag talks" during lunch where such topics are common.

If accepted, you can talk about what you are proposing, why you consider it important (hopefully not just because you feel it's a "best practice", but more about why it will benefit the team/company in their particular context), and how you all can go about implementing these ideas.

Try to get the manager's explicit buy-in ahead of time, then use your powers of persuasion to convince others to get on the bandwagon. Sometimes suggesting a pilot project starts things off well - often starting small is the simplest way toward improvements.

Answer 2

The rest of the team seems to like the idea of testing and gated check-ins, but have not taken any action to start actually doing these things

Do they actually know how to do unit testing?

If you've never done this before, this may not be straightforward to just start doing. Especially if you have years of experience doing no testing.

It sounds like your entire team at least is open to the idea of changing their processes. I'd focus on making sure you know why they are not doing things. I suspect it's either a general resistance to change or lack of understanding for how to do things.

If it's a lack of knowledge, you can consider ways to help with this. One good way might be asking someone for help and sort of doing a pair programming thing, when working with code you don't understand (as fully). You can talk through what you are doing, and see if you can write tests with the other person there, explaining what you are doing.

Note that seeing a test written (code review) and knowing how to approach writing a test aren't necessarily the same thing.

If it's just a "we like talking about it and sounding hip without doing anything" problem, you might try when that conversation happens, to be suggesting or asking about very specific, practical things (rather than just lamenting lack of code review or unit testing, too):

• "man I wish we were more agile."
• "well, do you want to review each other's code? I'm free this afternoon and have a commit I am making"

Answer 3

To make code reviews practical, you need a system that facilitates them. For example, as GitHub does with Pull Requests or as GitLab with Merge Requests. I heard great things about Gerrit, but I haven't used it. Get one of these or similar installed (even just on your own PC, at first), otherwise it just won't be practical.

Here's an example of introducing code reviews to a colleague using GitHub.

Implement a reasonably interesting change on a branch, and intentionally leave in some mistakes. Create a Pull Request, and ask a teammate to kindly review it. Sit with him, show him your mistake, and how he can enter a comment on the relevant line. Walk him through the rest of your changes, if he makes any remarks, ask him to enter a comment right there and then. After you reviewed all the changes together, return to your desk, commit and push the corrections. The earlier comments will be gone from the Pull Request, ask him to make another pass in case he finds anything else. Repeat until he finds nothing, and the Pull Request can be accepted.

Show to other teammates too, keep assigning to them Pull Requests, and encourage them to do the same to you. Hopefully the practice will catch on.

The process is exactly the same with GitLab (free clone of GitHub), but they call Pull Requests as Merge Requests. I don't know with Gerrit and others, I'd imagine similar functionality exists.

We implemented this idea in two teams so far, over the past 3 years. It's the single most popular practice we implemented. The guys doing it love doing it, and occasionally send me Merge Requests even after I moved to another team. In my new teams I'm trying to spread the practice precisely the way I described above.

As for unit testing:

• Get a continuous build system working that executes unit tests as part of the build.
• Propose a brown bag lunch talk demonstrating examples of good unit tests and bad unit tests. Put the content you used in a public repository.
• Write good unit tests and assign Merge Requests to a teammate who's most likely to buy into the idea.
• Lobby for a practice of everybody implementing (at least) one unit test per week. Make sure to measure and track progress (I use a simple Excel sheet).

As for code quality improvements:

• Get a static analysis tool integrated into the continuous build system. For example SonarQube.
• Implement corrections to problems raised by the static analysis tool, and assign Merge Requests to a teammate who's most likely to buy into the idea.
• Propose buying books that are well-known to be good resources in your domain, have them lying around your desk, and encourage others to pick up and borrow anytime.
• Lobby for a practice of everybody implementing (at least) one correction to problems raised by the static analysis tool per week. Make sure to measure and track progress (I use a simple Excel sheet).

Notice the common pattern in both of the above examples:

1. Get a tool setup that will help achieving your goals efficiently
2. Use code reviews as a way to lead by example
3. Get additional supporting materials lined up
4. Lobby to implement improvements in small, manageable steps

All these ideas are so small and simple incremental changes that they are really easy to sell.

Customize, and use a variation adapted to your environment.