Different projects, different team sizes, one SM

The wording of your question is confusing.

It seems like you're using "products" and "projects" interchangeably. You refer to different products to deliver, but then different project sizes. Do you have products or projects? The idea that products will be "complete" in 1 or 2 Sprints further compounds my confusion as products are normally long-lived and continue to result in value to the developing organization over an extended period of time.

What does it mean to be "completed"? If you have a good picture of what it means to be "complete" at the outset, that indicates a few things. One possibility is that the work is very well-defined. In that case, I'm not sure you are looking at agile approaches, which are best suited to cases where there are high amounts of uncertainty and ambiguity in the work. Another possibility is that there is a high amount of uncertainty, ambiguity, or risk and you are not certain if the effort will actually be completed in the timeframe that you think.

The team composition is also not clear. Is this team of 12 developers supporting all of the different products or projects? If you need specialist skills, are there any limitations or potential bottlenecks where you don't have enough of a particular skill to have individuals dedicated to products or projects?

What does it mean to you and your organization to be a "team leader of the 12 developers"? How does this definition of the team leader role align with the definition of the Scrum Master role as it's defined in the Scrum Guide?

Why do you believe that either Scrum or Kanban would be appropriate for the situation that you describe?

My team is growing and I am going to have from 2 developers to 12, and wanted to ensure the best way to organize this. 

Perhaps the best thing you might organize for yourself and others is professional Scrum training, and seek to enable self-organization from there.

Hi both,

You refer to different products to deliver, but then different project sizes. Do you have products or projects

Products. Please ignore the word 'projects'. I am mixing it because the way we do it now, every project delivers a product. We develop IT apps that improve productivity within the company . Most of these apps are unique on their own.

I'm not sure you are looking at agile approaches, which are best suited to cases where there are high amounts of uncertainty and ambiguity in the work.

Since every product aims to solve a different problem, it has high amounts of uncertainty in the work itself, which I think could fit with Agile.

Is this team of 12 developers supporting all of the different products or projects?

The 12 developers will work all of them in different products. Teams of 2 or more developers will be formed depending on the product's complexity. So we may end up having 4 sub-teams (e.g. one team with 2 devs, the other with 4 devs, and 2 other with 3 devs each) working in 4 different products. Due each product complexity, some will be completed in less sprints than others.

What does it mean to you and your organization to be a "team leader of the 12 developers"? How does this definition of the team leader role align with the definition of the Scrum Master role as it's defined in the Scrum Guide?

In the past, as a tech team lead, I was the contact point with the business. Worked with them in effort estimation, planning etc. I was also doing development. In this new setup I won't do development but rather enable the team for success, following Scrum guide. The 12 developers are inexperienced, so I will provide also tech mentoring at first, however as the time passes, I expect them to be autonomous.

Why do you believe that either Scrum or Kanban would be appropriate for the situation that you describe?

We can not apply Waterfall and wait for 6 or 12 months to deliver something. In our organization the expectation is to have continues deliverables and within a short span of time (weeks, not months), and the probability of changes during development is very high as I could see last year, so I think Scrum could be a good fit.

It seems to me that you want to use Scrum terms but do not really understand what they mean.  And it is also clear to me that you have not read the Scrum Guide (https://scrumguides.org/scrum-guide.html) because you do not seem to understand the framework and focus of a Scrum Team. I'm going to provide the section that describes a Scrum Team. I have added some emphasis to support my following statements.

Scrum Team

The fundamental unit of Scrum is a small team of people, a Scrum Team. The Scrum Team consists of one Scrum Master, one Product Owner, and Developers. Within a Scrum Team, there are no sub-teams or hierarchies. It is a cohesive unit of professionals focused on one objective at a time, the Product Goal.

Scrum Teams are cross-functional, meaning the members have all the skills necessary to create value each Sprint. They are also self-managing, meaning they internally decide who does what, when, and how.

The Scrum Team is small enough to remain nimble and large enough to complete significant work within a Sprint, typically 10 or fewer people. In general, we have found that smaller teams communicate better and are more productive. If Scrum Teams become too large, they should consider reorganizing into multiple cohesive Scrum Teams, each focused on the same product. Therefore, they should share the same Product Goal, Product Backlog, and Product Owner.

The Scrum Team is responsible for all product-related activities from stakeholder collaboration, verification, maintenance, operation, experimentation, research and development, and anything else that might be required. They are structured and empowered by the organization to manage their own work. Working in Sprints at a sustainable pace improves the Scrum Team’s focus and consistency.

The entire Scrum Team is accountable for creating a valuable, useful Increment every Sprint. Scrum defines three specific accountabilities within the Scrum Team: the Developers, the Product Owner, and the Scrum Master.

Notice that there are 3 roles and the entire team focuses on a single product. It is possible to have multiple teams focusing on the same product but having one team focus on many products is never stated. 

You talk about projects with fixed durations with a preset number of people working on them.  You talk about products that can be delivered in 1 to 2 sprints.  You ask how to show how all of the products are being worked on in a single board. My head immediately interprets that as your products being features or enhancements to products that are small and well defined in nature with no chances of uncertainty or need for adaption during the work in progress. You never mentioned anything about Product Owners that are responsible for the many small products that you appear to have or how they play a part in your team's activities. 

I feel like you would be better served with using standard project management techniques. Instead of a board, you would have a Gantt Chart that shows all the work and how it relates to each other. If you absolutely want to use some type of agile techniques you should look into Kanban or take a good look at Extreme Programming methods. Forget about words like sprint and roles like Scrum Master because you are not using them in the appropriate context for Scrum. Be a team leader that helps your team deliver the work your organization wants with the best quality and shortest duration as possible. 

I do want to try an attempt at @Ian Mitchell's famous approach of short questions before I leave.  Is your organization ready and willing to make the changes needed in order to support Scrum? And do other team leaders share your desire to act in the manner described by the Scrum Framework?

If you absolutely want to use some type of agile techniques you should look into Kanban or take a good look at Extreme Programming methods. Forget about words like sprint and roles like Scrum Master because you are not using them in the appropriate context for Scrum. Be a team leader that helps your team deliver the work your organization wants with the best quality and shortest duration as possible. 

Thanks for the advise. This (Kanban) is what I will be looking at after reading your comments and discussing with other colleagues. In the end seems more advisable for the setup we have.

Products. Please ignore the word 'projects'. I am mixing it because the way we do it now, every project delivers a product. We develop IT apps that improve productivity within the company . Most of these apps are unique on their own.

A project could create or modify a product. However, a project is also temporary. A product continues to live on after it is created. Many of the frameworks for Agile Software Development, including Scrum, are product-centric. That is, they are built around not only creating but maintaining a complex product or service and continuing to evolve it over a long period of time.

If every project delivers a new product, consider how you'll continue to support the products over time. Also consider what a large number of fielded products would mean for the organization, especially if the supporting team doesn't grow to support the fielded products. Also consider any ongoing support that may need technical support from developers.

The 12 developers will work all of them in different products. Teams of 2 or more developers will be formed depending on the product's complexity. So we may end up having 4 sub-teams (e.g. one team with 2 devs, the other with 4 devs, and 2 other with 3 devs each) working in 4 different products. Due each product complexity, some will be completed in less sprints than others.

There are a few assumptions made in many of the Agile Software Development frameworks. One of those assumptions is about team size. Scrum, as one example, is built around a starting size of about 5 people (1 Scrum Master, 1 Product Owner, ~3 Developers). There aren't that many built for 2 or 3 people. Coordinating effort with 2 or 3 people is very different than coordinating effort for 4 or 5 or more people. Using frameworks like Scrum with a team that is too small could result in too much coordination and synchronization overhead.

If the teams are going to be re-teamed regularly as efforts end, that could also be an issue. Another assumption is a fairly stable team. However, this may not be an issue since the entirety of the development organization is relatively small. 12 people is small enough to have an "everyone knows everyone" environment. Regular re-teaming in a larger organization may be an issue if it ends up scaling up in terms of developers.

We can not apply Waterfall and wait for 6 or 12 months to deliver something. In our organization the expectation is to have continues deliverables and within a short span of time (weeks, not months), and the probability of changes during development is very high as I could see last year, so I think Scrum could be a good fit.

The choices are not only "Waterfall", "Scrum", or "Kanban". There a number of other existing Agile Software Development methodologies - Extreme Programming, Crystal, and DSDM come to mind. You can also roll your own framework. Disciplined Agile is a framework for helping to understand the typical objectives of a development effort and provides decision points for practices that could be useful. Rolling your own method, perhaps learning lessons from how different practices fit together in the existing methods, is a valid option. Especially if you have teams or 2 or 3 people, you may get better results from rolling your own lightweight method than trying to use a framework designed for 4 or more people.

Thank you Thomas!

A project could create or modify a product. However, a project is also temporary. 

A project, like a Sprint, is a temporary endeavor that creates a result of value. In Scrum the term "project" can therefore be applied to all of a Product Backlog, or part of it, or to each Sprint itself. This last definition is arguably the most important because it allows empiricism to be established and maintained.

“A Scrum project is only one Sprint long." - Ken Schwaber.