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!
Best Answer
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.