En nuestra empresa también enfrentamos un problema similar y estoy de acuerdo con la publicación anterior de que kanban es una buena opción. El tablero Kanban proporciona toda la visibilidad y claridad necesarias para el equipo, también hacemos reuniones de apoyo para una visión general rápida. Durante la fase de planificación participamos: si la planificación es para el primer proyecto, invitamos solo a los miembros que están relacionados. De esta manera ahorramos tiempo. Kanban también es excelente para las restricciones de multitarea, aquí vienen los límites en las columnas. Es muy importante tener límites en un entorno de múltiples proyectos para mantener a las personas enfocadas en tareas individuales hasta que las terminen.

Creo que esto es totalmente posible ya que debe ponerse de acuerdo sobre una y la regla más importante. Cuando planifica la acumulación de sprint, la cierra y no hay lugar para nuevos elementos de trabajo "inesperados". Debido a que se verá obligado a entregar valor en cada uno de los proyectos en curso, en cualquier otro caso no fallará en un proyecto sino en todos juntos. Además, es importante que todo el equipo esté relacionado con esos proyectos, porque si una persona solo está trabajando en el proyecto A y los otros miembros del equipo están trabajando en el proyecto B, estará perdiendo el tiempo en lugar de ahorrar.

Pero en general, scrum funcionará si emplea las pautas, tome, por ejemplo, un gran sistema que contiene diferentes módulos, pero son un gran proyecto, por lo que, como usted, sus proyectos son como módulos pero menos relacionados :)

Sin embargo, una pregunta, ¿tal vez el enfoque scrumban o incluso kanban simple sería adecuado para la entrega rápida de proyectos? En mi humilde opinión, kanban es más flexible y adecuado para equipos pequeños que scrum, ya que requiere muy pocas prácticas.

Espero que no haya demasiada redundancia en otras respuestas, pero quería entrar en algunos detalles sobre las herramientas que podría usar en un equipo ágil con varios proyectos.

Lo que hacemos (alrededor de 6 desarrolladores, en 2 proyectos más grandes y hasta 4 más pequeños al mismo tiempo) también es combinar herramientas de diferentes tecnologías.

1. Escribimos especificaciones basadas en historias de usuarios, que desarrollamos junto con nuestros clientes, o al menos las revisamos al final.
2. Al final de las iteraciones (o si se trabaja de manera más flexible cuando algo esté listo) hacemos que el cliente acepte el trabajo realizado en base a estas especificaciones.
3. Donde sea posible, trabajamos en iteraciones, no es un problema general hacerlo solo porque hay más proyectos al mismo tiempo.
4. La retrospectiva, la planificación de Sprint, etc. pueden ser más o menos completas según el tamaño del proyecto/iteración y otras circunstancias (p. ej., qué tan bien especifica el cliente).
5. Hacemos una reunión diaria con todos los desarrolladores y el control de calidad.
6. Para la reunión de pie, usamos un tablero de estilo kanban, donde tenemos tarjetas codificadas por colores en todos los proyectos. Tomó un tiempo y algo de disciplina hacer que todos entendieran que está bien escuchar los informes de otros proyectos, pero al final ayudó mucho a motivar a las personas a ayudarse mutuamente con la experiencia en los proyectos.
7. Principalmente utilizamos estimaciones de estilo de punto de historia, para poder tener una idea de la velocidad de cada proyecto / equipo de proyecto.

Como ya sugirieron otras respuestas, creo que un tablero de estilo kanban podría ser la herramienta más importante en su caso. Verá si las tareas, por ejemplo, se acumulan en el diseño o las pruebas, si las tareas se atascan, y puede tener una forma transparente de priorizar tareas incluso entre proyectos.

Haga sus proyectos secuencialmente, uno a la vez. Período.

Y como evitas que otros proyectos/clientes no te esperen un mes...

Piense en esto: supongamos que tiene tres proyectos para hacer, y cada uno tomará cuatro semanas (con todo el equipo trabajando en él). Suponga además que no perdería tiempo cambiando entre ellos.

Si hace esto perfectamente en paralelo, terminará sin ningún proyecto completado hasta el último día del período de doce semanas. Es decir, todos tus clientes acaban esperando casi tres meses.

Si alterna entre proyectos en sprints de una semana, termina un proyecto a las diez semanas, uno a las once semanas y otro a las doce semanas. Felicitaciones, ahora solo uno de sus clientes tiene que esperar tres meses, pero los demás solo reciben sus cosas una y dos semanas antes de eso.

Si realiza los proyectos secuencialmente, un cliente tendrá su proyecto al cabo de cuatro semanas. Un segundo tendrá la suya al cabo de ocho semanas. Y un tercero tendrá el suyo al final de las doce semanas, lo que sucederá sin importar cómo los programe, a menos que tenga una TARDIS.

En realidad, cambiar entre proyectos perjudica su productividad, por lo que su experiencia real de paralelismo o alternancia será peor que la que obtendría simplemente haciéndolos secuencialmente.

Tienes un equipo pequeño. No divida al equipo pensando que puede hacer más trabajo. no puedes

Sí, se puede hacer. ¡Es difícil!

Hay muchas cosas que puedo recomendar, pero algo que realmente cambiará tu forma de trabajar es tu comentario: "¿Podemos realmente entregar algo en 2 semanas?". Sí. Automatiza absolutamente todo. Esfuércese por poder hacer múltiples implementaciones por día. Cambios más pequeños. Menos líneas de código. Riesgos menores. Pruebas más pequeñas. Menos bichos.

Cuando puede entregar con esa velocidad, su conversación con sus Proyectos cambia de: "¿Cuántas semanas necesitamos para terminar todo?" a "¿Qué te gustaría tener mañana por la mañana?"

Puede comenzar a administrar múltiples proyectos porque su conversación cambia de: "¿puede esperar hasta julio?" a "Podemos tener su funcionalidad más importante funcionando la próxima semana, ¿está bien?"

Creo que debes dar un paso atrás y no preocuparte por SCRUM y sprints.

Tiene un equipo pequeño y múltiples clientes con múltiples proyectos que quieren realizar.

Centrarse en un cliente o un proyecto

Para cada cliente y proyecto, es una buena idea hacer una estimación aproximada del valor ganado. Si es posible, como han dicho otros aquí, intente reducir el número de clientes o proyectos al cliente/proyecto de mayor valor.

Es una mala situación comercial en la que estar, pero si es pequeño y recién comienza, así es como las cosas tendrán que ser hasta que ahorre suficiente dinero para contratar desarrolladores y diseñadores adicionales. (Esta es la razón por la cual las agencias siempre buscan desarrollar productos en el futuro lejano, para evitar depender solo de clientes particulares y de la cartera de clientes/proyectos).

Agregar un búfer a las estimaciones de tiempo

Cuando planifique cada proyecto, agregue un búfer para cada fase que tenga en cuenta el cambio de contexto que ocurrirá. El cambio de contexto puede ocurrir en forma de mantenimiento o características (dependiendo de sus obligaciones contractuales).

Concéntrese en una pila tecnológica o tecnología

Intente consolidar los proyectos para que utilicen la misma base de código o los mismos marcos, bibliotecas o herramientas. Esto reducirá el cambio de contexto y es lo que permite que muchas agencias de desarrollo web completen proyectos de manera rápida y exitosa.

Por ejemplo, trabajé en un lugar que usaba Python/Django/PostgreSQL para todos los proyectos. Si un cliente quisiera usar alguna otra tecnología, aumentaría el precio del proyecto (para tener en cuenta la capacitación o la contratación de nuevos desarrolladores). La mayoría de los clientes se contentaron con dejar la elección de la tecnología a la agencia.

En otra empresa, solo usamos Drupal y Wordpress, lo que nos permitió conseguir clientes que querían un sitio CMS de nivel empresarial o un sitio web para una pequeña empresa. Las herramientas nos dieron la flexibilidad para trabajar en sitios pequeños o grandes.

SCRUM y gestión de proyectos y sprints

Su gran problema con múltiples proyectos será el cambio de contexto. Un desarrollador y un diseñador tendrán que cambiar su flujo de trabajo. Para tareas más grandes, deberá agregar un día antes de que se realice cualquier trabajo "real", para las tareas más grandes, es posible que deba agregar 2 o 3 días para que el miembro del equipo vuelva a la normalidad. Para tareas pequeñas, es posible que pueda salirse con la suya con medio día o unas pocas horas para el cambio de contexto.

Debe establecer expectativas sobre cuándo pueden ocurrir actualizaciones/reuniones con los clientes y cuándo puede responder a emergencias y solicitudes de los clientes. Esto le permitirá agrupar fragmentos de tiempo para reducir el cambio de contexto.

• 1 cliente, 1 proyecto: lo ideal, tu equipo se centra en realizar un proyecto, no hay cambio de contexto
• 1 cliente, 2 proyectos: casi ideal, su equipo puede brindar actualizaciones y enfocarse en las necesidades de 1 cliente
• 2 clientes, 2 proyectos: va a tener problemas con el tiempo y los cronogramas en algún momento, su equipo deberá concentrarse en un cliente y luego cambiar el enfoque a otro. Te encontrarás con dependencias de desarrolladores, diseñadores y clientes sobre qué días son buenos para las reuniones y cuándo se deben terminar ciertas tareas. Es posible que desee contratar ayuda temporal. Una buena idea es programar 1 cliente/proyecto para la primera mitad de la semana y el otro cliente/proyecto para la otra mitad de la semana o alternar entre semanas (1 proyecto por semana).
• 2+ clientes, 2+ proyectos: necesita contratar a más personas y dividirlas en equipos que se centren en 1-2 proyectos o clientes como máximo.

He practicado Scrum durante un par de años. Vine aquí porque ahora estoy trabajando con un pequeño equipo (4 desarrolladores, 1 control de calidad) responsable de una cartera de proyectos empresariales, nuevos desarrollos, mejoras y soporte. Creo que la respuesta obvia es de George P.; trabajar en un proyecto a la vez, completarlo y pasar al siguiente. De hecho, hará los proyectos más rápido y mejor. El rendimiento desde el compromiso hasta la finalización para cada cliente será más corto. He intentado ejecutar proyectos simultáneos con Scrum y la sobrecarga de los rituales de Scrum y la distracción de cambiar de proyecto es un desperdicio. Intentalo. Una vez que seas bueno en eso, sorprenderás a tus clientes con tu velocidad.