In our recent vlogs, we discussed software craftsmanship and how learning can benefit teams. This week we’re diving into teamwork and diversity, the other two core values at Creative Mines. Building strong teams is an essential part of any development project. Today, we’re breaking down the steps to building great software teams.
Identifying What the Software Team is Working On
One of the questions that comes up often is how to build and grow strong software teams that will develop high-quality products. To answer this, you first need to identify what the team will be doing. Will this team be building a whole software product (backend, front end, DevOps work), or is this a smaller team specializing in a specific section of a larger project? A smaller team may have one microservice or micro frontend they’re focused on, and they will specialize in that area and develop that one component taking it through its entire lifecycle.
For product teams, it’s ideal to have cross-functional teams. You want to have a team that has all the skills they need to deliver a completed product. This may include UX, QA, or product owners if you’re doing Scrum. We also call this a feature team. On a bigger project, a feature team will be doing big vertical slices of the project from the frontend to backend. They will work on an entire lifecycle of a feature. So on a smaller product team, it’s very similar to a feature team on a large product where you have skills across the board.
T-Shaped Skills for a Full-Stack Team
I often get asked if Creative Mines is all full-stack developers since we specialize in full-stack teams. My answer is yes, most of our developers are full-stack. However, when building a full-stack team, not all individual contributors need to be full-stack developers. We want the overall team to be full-stack, meaning they can work on any part of the application or component, but we don’t necessarily have to have everyone be full-stack.
This leads into the conversation about T-shaped skills and T-shaped individuals, where the breadth of an individual is how many different things they know, and the depth is how deep they know those things.
So if we’re building a full-stack team, we will want somebody who’s really deep on the frontend. For example, if we’re using React, we want somebody who’s done React for a while and understands it deeply. If the back end is Java, we also want an individual who knows some React but is deep in Java. If we take those two individuals and put them on the team, now we know we have the depth that we need on React and Java. And overall, the team is really deep in all the areas that it needs to be.
This leads right into diversity which, for us at Creative Mines, is any kind of different educational background, skill set, or experience that individuals bring to the team.
Let’s say we have an individual who has been doing UI development for a long time and really understands CSS, the DOM, and JavaScript. While they can focus on that area, it’s also beneficial to have them team up with someone who’s really deep on the backend. As they work on the project together, they will learn skills and best practices from each other very quickly.
So that’s where diversity really comes in. A team of full-stack developers who are all deep in the same areas will not learn much from each other. That team might all get along because they’re thinking the same way, but they’re not as capable as a team of individuals with different backgrounds and diverse experiences.
When we’re building teams, we’re trying to find a set of people who will add value to each other and help each other learn. With the team built this way, we’ll be able to build whatever we’re tasked with building to the best of our collective ability.
Building Cross-Functional Software Teams
The main reason for having a cross-functional team is because a team has the one goal of delivering a product. By having everyone who’s involved in delivering that software on one team, they are all working towards that same goal.
If you split people up into different teams, they all have different goals, and it’s much more challenging to align the teams to end up with actual client deliveries. They’re also less efficient than if everyone was on the same team.
So when we talk about cross-functional teams, we’re putting all those people into one team. And that single team can do a lot more by having everyone they need to complete the work they’re given.
If I’m building a product, I want someone from UX on the team to work with us day-to-day. The UX team member can be available for questions and guidance at any time. If the UX member was on a separate team, I could reach out to them, but I don’t know their priority. I could be interrupting them and creating unplanned work for them.
With cross-functional teams, we reduce unplanned work because everyone is focusing on the same task of the same goal, and we have the same deliverables. We’re also able to produce a lot faster. By removing those dependencies and unplanned work, we can move more quickly and efficiently towards the common goal.
There is a trade-off, though. If you have a lot of different people filling different roles, the work might not move as smoothly in some cases. For instance, let’s say we had 10 UI developers and one UX. Obviously, the UX developer is going to be overloaded because they’re splitting their time up between those 10 UI developers. On the opposite side of that, a team with 1 UX developer and 2 UI developers doesn’t have enough UX work.
For us, having full-stack developers means the full stack developers aren’t doing UX work, but having a set of full-stack developers means they can at least move between different parts of the code base. In this case, UX work may not be easy to divvy up. If we have a sprint that was all backend work and we only have two backend developers and three frontend developers, now we’re going to be in trouble. We have to find something else for the frontend developers to work on that maybe isn’t towards our immediate goal but something that’s off in the future. If we had five full-stack developers that could handle anything from frontend to backend development, now everyone can focus on doing that work and make sure it’s delivered.
One of the values of teams and Scrum is anyone can do any task and make the process smoother. If you have 10 tasks that only 10 different individuals can do, things are not going to be as smooth. So we want as many individual contributors who can put together as many pieces of the puzzle as possible, especially when we’re using a process like Scrum.
That’s how we build software teams at Creative Mines and that’s how we recommend our clients build software teams. In future posts, we will dive deeper into what makes great teams that enjoy their work and deliver consistently.
