full stack team with platform-specific and backend developers

full stack development team

I would suggest sticking to the "full team" idea and avoid getting developers working on other projects.

It also sounds like there is an idea of "sub groups" or teams within teams. This is something I would also try to avoid.

However, I haven't been in a team that has done mobile app development so I may not understand the issues completely.

Why can't the team help each other?

Why is the team working on things outside the sprint?

How do you organise work in a full stack development team that includes android developers, iOS developers, backend developers? In real life, the subgroup workload is never similar. One group might be struggling with legacy code and be slower than others. Another group of developers might have more developers than others and be faster. Backend developers might have tech support/maintenance responsibilities (e.g support customer support) and be slower due to that.

What forces are causing people to work in “subgroups”, rather than a collaborative and self-organizing Development Team?

From what you describe, it sounds as though skill-silos have impeded the ability of people to demonstrate teamwork. It seems that each is waiting for work of a certain type to come to them, rather than going to where the work is and collaborating on its completion.

Hey, Thanks for the replies.

So, here is the basic idea:

1. the development team needs to be self-sufficient

2. for us, this means mobile app work on independent ecosystems (iOS, android) and backend (java)

Based on the previous, you can see that there is no possibility that one person in the development team can do work of certain other people in the team. So this ensures there is some subgrouping. I doubt anyone would off the solution that an Android (Kotlin) developer should continue with iOS (Swift) duties when they have done their work unexpectedly quick. 

Thanks for the replies.

So here is the basic principle:

1. the development team is fairly self-sufficient (as it should be)

2. to meet 1, the team has platform developers (independent platforms, iOS and android) and backend developers

3.  If one developer gets their work done unexpectedly quickly, it can't be assumed that they can take up the work of most other developers. E.g. an android (Kotlin) developer can't pick up where iOS (Swift) developer or backend (java) developer left off.

Therefore one developer/subgroup works within their "technical silo" and implicitly there is subgrouping that can't be removed if you want to have a self-sufficient development team. This needs to be accounted for when planning work. 

(for some reason the comment isn't added, trying again: )

Thanks for the replies.

So here is the basic principle:

1. the development team is fairly self-sufficient (as it should be)

2. to meet 1, the team has platform developers (independent platforms, iOS and android) and backend developers

3.  If one developer gets their work done unexpectedly quickly, it can't be assumed that they can take up the work of most other developers. E.g. an android (Kotlin) developer can't pick up where iOS (Swift) developer or backend (java) developer left off. 

Therefore one developer/subgroup works within their "technical silo" and implicitly there is subgrouping that can't be removed if you want to have a self-sufficient development team. This needs to be accounted for when planning work. 

How do you organise work in a full stack development team that includes android developers, iOS developers, backend developers?

Why not let them decide because of the whole self-organizing team concept?  You might be surprised at some of their ideas. 

I'll give a couple of suggestions though.

Sounds like the teams might be bigger than they need to be.  Have you considered smaller full-stack teams that can focus on more specific work instead of having a large team trying to solve multiple things?  For example, split on mobile OS and keep backend developers to work on things specific to that problem space. The backend could still coordinate on standards or shared functionality through conversations and a Community of Practice.  Legacy code could also benefit from a Community of Practice to raise the knowledge of others in order to expand the number of people capable of helping in those code bases. 

You mentioned a lot of issues around the concept of teamwork.  The "faster" developers could be pairing with the "slower" developers to raise their level of ability.  The legacy code could be split across the smaller teams along the lines of the work that they are doing to deliver value. The support of the backend can follow similarly to the legacy code option. Having multiple teams available to work on all of that actually can improve the ability to get things done. I would consider all of those things to be "unplanned work" and there are a lot of options for dealing with it.  Yesterday I found this link in another post in this forum and I think it is a fabulous list of ideas. 

https://medium.com/agilelab/strategies-for-handling-unplanned-work-duri…

the best idea is to just allow the ones ahead of the others to break ground on the next project until the next sprint

Tanel, you may find some of your answers through a better understanding of Lean and the hazards of waste.   Under your proposal, there is the risk that work may be performed (breaking ground on next project) where there is the potential (however small) that such work may be put on the shelf (excess inventory) in favor of a different "project" when a new sprint begins.

Your solution is based on resource optimization, which is an ineffective way of delivering value.   To put it another way, ask everyone to focus their efforts on moving the most critical items through your workflow, regardless of individual expertise or work preference, instead of expending effort trying to ensure that everyone stays busy.

I think Tanel's question is very valid, clear, and real. And I am surprised I haven't seen an actual response to the question "how have you managed this situation in your SCRUM teams?"

Tanel talks about specialization of, let's say 3 team members: A Java developer, a Kotlin developer and a Swift developer. You can change the programming languages for any of your choice, it is still a very real situation. I know Scrum talks only about a team and not about roles, but in the real world, not all team members can work on all the programming languages with the same profficiency. I am saying 3 team members to address Daniel's hypothesis that the problem is with the team size. Even with a team of 3 you'd have the problem anyway. What if the Java developer takes longer and makes the Swift and Kotlin developers stay idle say 20% of the time? Would you hire another Java developer that would stay idle 80% of the time?

It would be great if anybody with real experience handling the situation could share the approach used and lessons learned.

To give my take to Tanel, one option that I would try is to find a developer that handles at least 1 backend and 1 frontend programming language, so that he can help leverage the throughput as needed, depending on where the bottleneck is. I am starting with a team that has a similar stack of a backend programming language + Swift + Kotlin + React.js. I may have some better ideas to share in 6 months from now.

I guess that some companies separate the backend team and 3 frontend teams and create make sure that the backend team exposes a contract in the form of an API to all the frontend teams, but this is a guess and that's why I would be great to hear if someone has taken this route and what the tradeoffs have been.

Scrum is very good at highlighting real-world problems of this nature. The lesson I have learned is that they may then be either accommodated or challenged, and only one of these will improve outcomes.

@Rolando Matarrita Sequeira, you said 

It would be great if anybody with real experience handling the situation could share the approach used and lessons learned.

The situation I described was a real life example of the solution we used to address the exact situation that Tanel asked.  Making sure that all of the people involved are using their time wisely is an important thing to consider.  But just because a person has a job description of Front End Engineer, doesn't mean that writing code is all that person can do to contribute.  Leveling up junior developers by a senior developer is valuable to the company.  Using time to refine the Product Backlog Items is valuable to the company and the team.  (Remember, refinement is ongoing work and it does not have to be done in a meeting).  I did not share lessons learned because the lessons we learned were from the actual processes we put into place.  Those lessons might not apply to anyone else.  Each organization and team are unique. In our case we had 10 different teams take this journey and every one of them learned different lessons. 

Tanel has the PSD certification so I assume that he was asking this from a developer's perspective.  I do not know this for sure about Tanel and it is a generalization but most of the developers I have ever worked viewed their job as being to write code. And he mentions developers that are specialized in their areas of expertise.  I do not think that specialization is a bad thing but it frequently results in idle time for those specialists.  Especially if their only job is to write code.  That is why so many companies will include other activities in the job descriptions, many of which are related to mentoring more junior staff or aiding individuals in different focus areas (i.e. Product Managers).  

I am saying 3 team members to address Daniel's hypothesis that the problem is with the team size.

If you read the rest of my statement you would have understood that I wasn't being specific about the number of people on the team.  It was more about having teams being responsible for solving too many issues at the same time and that breaking a larger team responsible for many items into smaller teams focused on related and specific items might be a better option.  

I may have some better ideas to share in 6 months from now.

The reason you might have better ideas in 6 months is because you will have 6 months to learn new things.  That is empiricism in action and empiricism is one of the basic building blocks for companies that are agile. Both of your suggestions are valid approaches and I have been involved in the use of both.  But again my findings most likely won't align with yours because our needs might have been different.  Some teams might benefit from a full stack developer with many skills while another team would only find that as being an annoyance.  As for your second suggestion, that is a very popular option for companies that are building stand-alone or micro services.  In that model each part is built independent of the other parts based upon API "contracts".  

From my experience here, most people will not provide an exact answer.  We are all Scrum Professionals and the heart of Scrum is helping teams to be better at doing things on their own.  Scrum is a framework and thus is not prescriptive.  We offer opinions, we ask leading questions, we suggest areas to focus on.  The intent is for the people asking the question to learn how to arrive at their own answers rather than relying on people to tell them how to do the work.  The first is indicative of a framework, the second is indicative of a process. 

Thank you Daniel for elaborating on some of the points and bringing up some additional ones. I doesn't only provide more valuable information, but it also provides more insight into how to read the rest of the responses. I also think that we are all Scrum professionals, and that we should not be afraid to share lessons learned in a specific context because they might not apply in another context. As Scrum professionals I think we would take them as food for thought to help us expand our perspective as to what could work in our specific scenario, that's also how Scrum patterns begin to form.