Etiquette / Leadership / Sharing Best Practices - How much should I try to influence?

Question

I recently joined another team part time where I kinda know several of the people, and they know me for my design work mostly, but I'll be doing design and some development with them. There's a lot of things I've noticed in the space of the first week that are just not done right, but I don't want to bring up a huge list and have people think "who is this person to tell us what to do? We've been doing just fine."

Many things I see aren't being done according to best practices, but not really for any reason other than that's just how they've been working for some time, figuring things out on their own.

So I'm just wondering how to help the team and the mission in an effective way, as it's not just preference, but I believe would make the whole team more efficient, happier, code would be cleaner and more maintainable, and it would be easier to bring new people in. I could either bring up stuff in batches, or just swallow it for now until I build up some leadership capital and have shown some of my value and expertise while temporarily working in the mess.

Some examples:

• the Scrum roles are all out of wack (the same person is scrum master and product owner, but someone else writes most of the stories)
• stories are poorly written, some are misleading, some are vague or just plain wrong, and there's a lot of background context needed. Mostly, people figure out what to work on even though the story doesn't really say
• daily meetings are 1 hour long, and are supposedly a mix of standup and sprint planning
• Git commits are mostly just a ticket number, no other explanation. Many examples of multiple commits in a row with exactly the same message
• Project has no Readme, and wasn't runnable after cloning
• There's apparently a process by which code is mocked up in one branch, then manually copied to another branch and modified in order to create the "real" code that is published
• There's a tiny smattering of unit tests, but no integration tests, no E2E tests. I'm still trying hard to learn how to do TDD well, and was hoping this team would have had it dialed so I could learn, but their software lead said "everyone was new to Framework X when we started, so we had to give some relaxation to the developers" and evidently that relaxation has never tightened up
• There's no built-in linting strategy, and there are examples of different, non-standard conventions within the code (like for naming things).

I know that was long, but given all those things, they seem like big things to me that I would like to help the team overcome and get faster and better, but I don't know if I should be the one pointing these things out at this early stage. Thanks in advance!

Answer 1

The main approach I use is to lead by example and pick your battles.

Large projects are almost never in great shape, because of the mix of talent, and because practices and code bases evolve. There's a lot of history involved that you can't see.

For leading by example, a lot of those things on your list are things you can just do. Before a regular change, make pull requests with titles like, "Improve test coverage in preparation for implementing feature X." Raise the bar. People will notice and up their own game.

For picking your battles, prioritize your list and just work on the first item. Bring it up in retrospectives. Propose concrete, incremental steps. Incorporate your teammates' feedback. People are generally willing to make improvements, but you have to introduce it gradually.

Answer 2

If your organization is following the values and principles of Agile Software Development, then there should be regular reflection on how the team is working and the opportunity to improve. This is the only specific practice called out in the Manifesto for Agile Software Development. In Scrum, this general practice comes in the form of the Sprint Retrospective. Other frameworks and methods may have other methods for reflection and improvement.

Since the question is tagged agile and mentions Scrum, I'm going to assume that you have regular retrospectives. If you don't, this would be the first practice that I would recommend implementing so the team can find and discuss things that are getting in the way of effective work.

The heart of this question is, from what I can tell, how to effectively bring up concerns when you are new to a team and your past experience tells you that there are a lot of ineffective practices. Especially in cases where you are not in a formal leadership role or have any kind of responsibility for the team's overall performance.

The first step is to realize that there are no best practices in complex domains like software development. What works very well for one team may fail for another team. The practices, methods, tools, and solutions to problems depend on the context the team is working in. Even teams within the same organization may find different practices are better for their contexts.

My recommendation is to find the most painful problem or two and bring that up in the next Sprint Retrospective. Since you are coming from outside, you've worked on teams that may not have experienced these problems or may have found a solution to them. The people on the team may have become desensitized to them if the problem has existed for a while. When considering the problems to bring up, consider your role on the team.

In this particular case, you are a developer on the team. The Scrum roles not being used properly or the time spent in meetings may be very annoying, but are they the biggest problems as a developer? Probably not. Things like the problems getting the project running after cloning is something fresh on your mind - can you get that fixed to make it easier to onboard new team members? You find the code difficult to read because of a lack of conventions, so can you start to introduce them in the code that you touch and get the team to buy-in?

This kind of approach can help the team take full advantage of not only your knowledge and skills as a developer but your experiences with onboarding onto the team and going through the learning curve that the other members of the team haven't had to go through recently. Hopefully, your perspectives in these areas will be valued by the team.

Answer 3

I hop in, as I have experience with many projects and company cultures. And you are on thin ice.

First you are in a non-scrum environment, the tag agile is so overused, and there are so many variations. Also there exists the attitude "do it simple as I understand it; no overhead." So if you want to see scrum, propose a workshop, best of a department that already does it right. Ask first the managers whether they would like to have insights on the current agile methodology.

Any reform will not happen fast, and preaching scrum will only frustate you yourself and your colleagues. Also 90 % of your code base will be legacy code. It is a bad idea to wildly refactor.

You yourself can work correctly and deliver quality. But you must accept the situation and love coding little jewels. Otherwise move to another job if more that three other developers are involved. Because then change is hard.

There are some general measures, like

• organizing presentations of new code/redesigns, special business features;
• code reviews, say on commit, to share knowledge;
• learning on the job: assigning always some other developer to hold a presentation on a new language/library feature (for java, C#, newer languages, SSH, SAML, ...);
• code checkers,SonarLint/SonarQube if not already in use. Free bug finders;
• tooling, small self-written code generators, analizers, language glossaries.

Especially I would refrain from accenting the entire scrum methodology, because scrum has a biblical jargon, and there exist mixed unpure forms, with Kanban and such. It might well be that some have already experience with scrum failures. Think of:

A: "A Scotsman does not lie."

B: "And McGorwedd?"

A: "A good Scot does not lie."

Names are relative. Legacy code has the advantage that basically the code works. New code means more risk and stress, with possibly worse quality.