I know this topic is quite known already, but still, I wanted to write about it.
I will try to be clear as possible explaining each type of teams using my own drawings, I will give you a little bit of context so you understand what are you seeing.
whatever.com
In this article whatever.com means our main product, basically our website, and the teams are doing new features and maintenance of the site.
You can see that on our website we have different things that we take care of, they are in different colors(orange green and brown), basically, they are independent areas within the site.
Component teams
In this example, we have a team with nice Project Manager, who works together with the stakeholders and the tech teams, which in the case are divided into different areas of expertise, DBA’s, Architects, Developers, and Testers, they are specialists working in their own areas, we can call each expertise team as a component.
Below the product manager, you can see a nice list of things to do, we can call it the backlog, which also you can differentiate that they belong to the different areas of the site.
How do they work?
Our project manager has a list of things to do, imagine for instance that there is a new shopping cart coming, developing a new shopping cart will imply have everyone involved, DBA’s, Architects, Developers, and Testers.
- DBA’s will have to think in the best schema possible, all relations, column types, etc.
- The architects will have to think about how the developers should do it, they will specify all the requirements, even the classes, interfaces, attributes, and in order to do so, the architects will need to know the DB schemas, means that they have a dependency on another group of people and they cannot start, or they will have struggles if they started before the DB’s finish.
- Once all requirements are ready the developers will action and start working on it, we again have the same dependency, but this time with the architects.
- Once everything is finished, if we are lucky before every release, the testers will make sure that what is being developed is working.
- The release is done so we deliver value to the user, and this value is symbolized with euro notes.
All the arrows that you can see between the list of features and the teams symbolize different dependencies, this approach as you can imagine is very waterfall, going phase by phase, the main problem I see here is that in this way of doing things, we will be delivering value very late on the time, which means that we will miss early feedback from the end user that could help to build something better.
We will be losing opportunities to inspect, adapt and react to market changes, therefore we might be doing work that is not actually valuable!
Benefits I see on component teams:
- You will really have good specialists on different topics.
- You will provide them a stable environment where the sense of responsibility for the other phases won’t be that high, so they will feel happier because their work is done.
- You will have clear individual responsibilities.
Disadvantages or risks I see on component teams:
- People will not be held accountable equally in all different phases, not shared responsibilities.
- This is a waterfall approach, so no increments, having the consequence of not having feedback loops.
- Loose different points of view of people that are doing/participant on other parts of the projects.
- Missing complete overview of how are we doing it.
These are only some of the benefits and disadvantages, but I think you can get my point.
Feature teams
In this case, we have a different approach, in this scenario, we don’t have this expertise separation, at least we don’t have it at project phases level, we will see that we can still have it, but the approach here is different.
The dev team will be represented by the Product Owner at stakeholder level, and instead of building team around different areas of expertise, what we will do is build teams around different areas of interest of the product, as you can see in the image, each team has a different color, and each team is formed by 4 people.
The color means the areas of interest of the site, and the 4 people is a cross-skilled team that can handle all that is needed to develop an entire feature, epic or whatever is it but within the area of interest. We can use the example of before, if we have to build a new shopping cart which is represented in brown in this case, we see an entire team that will take care of it, each team will work towards one mission, and each mission will have many things to do to move forward our product strategy.
This approach has an important benefit, we will have priorities by the different areas of interest! in the other example, the priorities are going to be decided by the different specialists team, this means that if 2 or more request goes into the DBA’s area we will be having problems of prioritization, what is going to be more important? in most cases what the DBA’s thinks is important.
In a feature team, as we will have different DBA’s shared between all areas of interest we won’t be having the same problem, at least we know the area of focus of each DBA.
Using feature teams together with Scrum will have a positive impact on your product and team, you will be now having feedback loops, with a possibility to inspect, adapt and react to market changes, the consequence is going to be: delivering value early.
Benefits I see on component teams:
- We will be having cross-skilled teams focus on areas of interest of the project.
- We don’t be having dependencies on other teams, our team will be our dependency.
- We will be having different opinions on how to do things because we will different point of views, so more chances to think about a better solution, but one thing! you need to be carefull with people opinions, because this is what they are, opinions, I can have my opinion on many topics where I don’t have clue.
- We will be learning new things, won’t be easy to stay in a comfort zone.
Disadvantages or risks I see on component teams:
- We could have dependencies on a team level, we could end up handing over things to each other, and we have to aim for a cross-functional team.
- As the component team, I see a risk of thinking “My job is done” even if the feature is not done.
- Not having a Scrum Master can make the situation a bad situation, you could end up with specialist silos that don’t hold accountable on the other parts of the process.
There are many other benefits and disadvantages, but my goal with the post is only to give you some information about what is each type of team, now you can use google for information!
If I would be the owner of a company I know which type of teams I would like to have, and they are of course the feature teams, but they won’t do magic, you are gonna need good coaching there, because otherwise you will just end up with a waterfall process within the different features teams, and this is not good!
