7 Strategies Every Dev Team Should Be Aligned On
Software Development decisions are usually really easy to make when you have 1–3 people working on a team. It means simply having a quick conversation, making a decision, and moving forward. But what about when you have 9 people or maybe 15 people or more? Any time you have more than a few people on a software development team, there is an additional cost that is created anytime a developer on the team handles day-to-day decisions. Anytime you add somebody new to the team or a developer starts working on a new feature there is an additional cost that can drag down the team if there is no alignment or clear understanding.
When software developers on a team struggle with knowing how to do something like deploy a new version of the code or what is expected of them when they want to merge some changes to the main branch, there is an opportunity for gaining alignment with the whole team. When everybody has alignment on how the team wants to handle doing things like submitting a Pull Request, the team is able to move forward quickly and deliver new changes frequently and confidently.
The following are 7 strategies that that every software development team could benefit from to make sure there is alignment among all the team members on the team.
1. Testing Strategy
Every serious software developer out there tests the code they write. Sometimes that means starting up the application and doing it manually. Other times it’s in the form of automated tests. Since every team likely needs to test the application they are delivering to their customers, it’s important that everybody on the team has a good understanding of what the testing strategy is in the first place. Spending some time as a team talking about what the team expects in terms of test types, processes, levels, etc. is a good way to ensure testing is consistently applied.
2. Pull Request Strategy
A developer starts working on a new user story. That developer thinks they are done with the story and want to merge those changes into the Main branch. What should they do? Does all new code need to be reviewed? Can anybody review the new changes? The team should have a good understanding of what the Pull Request strategy is so that everybody has alignment and can make decisions quickly as to what they should do.
3. Deployment Strategy
How do we deploy new features to our customers? What needs to happen before the new code can be released to our customers? Answers to these types of questions are sometimes complicated and have multiple feedback loops. Knowing how to navigate decisions around deploying changes can mean the difference between delivering value quickly and having system outages.
4. Repository Management Strategy
Team repositories for software can be expensive in terms of the overhead for clarity around the repository. Some teams have just one repository, some teams have 400 repositories, and most have somewhere in between. Anytime somebody joins the team, the repositories are going to be some of the first things they are trying to get access to so they can get a feel for the development work and what the tech stack looks like. If a developer joins a new team and starts looking at the repositories and they are not able to determine quickly what the repo is for, how they set up the repo, how they build the code, and how they test the code, etc. then that is information that somebody is going to have to teach them. Other questions like when should we create new repositories or why we have separate repositories for related components of a system should be something everybody has alignment on. A strategy for handling the management of repositories can ensure the team is making things easier on themselves and especially anybody who joins the team.
5. Backlog Management Strategy
A lot of teams out there utilize some type of backlog of upcoming work. Sometimes teams utilize a Product Owner that “owns” the backlog. Software developers learn things about the work they do all the time. That means that they find bugs, they determine something new needs to be added, or they want to address some technical debt. Keeping the backlog organized, fresh, and prioritized can help teams make sure they are delivering value to their customers. Team members should have a good idea of what their roles and responsibilities are for the team backlog. As a developer, I want to know how I should approach adding or updating cards in our backlog. Making sure this is well-known and clear makes this process flow smoothly.
6. Defect/Bug Management Strategy
If a developer is working on a new feature in an application and they come across a bug that is unrelated to the feature they are working on, what should they do? Do they fix it immediately and move on? Do they throw a card in the backlog and notify the team? Are there steps they need to take to triage the bug? If they create a card in the backlog, is there specific information the team expects in each card? The biggest question might simply be what’s the difference between a defect and a bug or is there a difference? All of these questions should be defined in a Defect/Bug Management Strategy so that everybody on the team has some guidelines about how to quickly address any bugs when, not if, they find one.
7. Production System Support Strategy
While this is the last strategy in this list, it’s also usually the most important. If your team has an application or system of applications in production then that usually means that if something goes wrong with any part of that system then usually your customers are going to notice and be negatively impacted. Anytime customers start having issues with an application, confidence erodes away from the customer in that application. Sometimes that confidence is lost quickly and sometimes it takes time but confidence is difficult to get back once it starts to erode. This is why it’s important that teams make sure they treat production systems like they are production systems. What this means is that a team should have a solid approach to monitoring the system and applications. They should be trying to get in front of issues before the customers are impacted. When customers are impacted the team should be getting the issue resolved quickly and with limited risk. This is a strategy that every member of the team should be confident in. Any doubt in this strategy can lead to a system that nobody wants to use, a system customers don’t want updates from, or a system that will get replaced soon.
Not every team needs to take the time to focus on getting alignment on these strategies. Lots of teams are firing on all cylinders and every team member has a great understanding of what the team expects from each other. Those teams are also in a position where onboarding new team members is a smooth process where the new member is able to transition from walking to running quickly. However, if your team is currently struggling with having alignment or clarity around any of the strategies that were covered then it would good to take some time as a team and identify a strategy for how the team should move forward. Create a living document for that strategy, make it big and visible, and revisit it every time a new team member joins the team. Make sure to iterate on it and make changes as necessary. This will ensure everyone is aware of and continues to have alignment on what the team expects from each other.
This is meant to be an introductory entry to these strategies. I intend for this to be a series that provides more detail on what a strategy is, what the goals should be for the team, and how best to facilitate the discussion of the strategy. I also plan to dive deeper into each strategy and identify questions with example answers that are a good starting point for teams to consider. Stay tuned!
