Scrum para equipos de especialistas

Scrum es mejor para equipos con miembros generalistas, es decir, equipos donde al menos 2 personas pueden hacer las mismas tareas. Mi principal preocupación es encontrar buenas soluciones para adaptar scrum (qué conservar, qué eliminar, qué mejorar) para equipos formados por especialistas.

Supongamos que tiene un equipo de 5 desarrolladores (no real, solo por ejemplo)

1. Un matemático con fuertes habilidades en C;
2. Un desarrollador de DB;
3. Un desarrollador web;
4. Un desarrollador de UX / GUI;
5. Un arquitecto de software;

Aquí, todos son especialistas y nadie puede reemplazar a otra persona (no me importan los riesgos de construir un equipo así, quiero centrarme en scrum). Entonces, en un contexto scrum, aquí están mis pensamientos:

1. Planes de primavera inútiles: de hecho, cuando el matemático dice que una tarea específica vale 2 puntos, nadie puede votar en contra de él;
2. Métrica de velocidad de equipo inútil: como todos pueden asignar cualquier número de puntos a sus propias tareas, la velocidad de cálculo no tiene sentido;
3. Reemplace las reuniones de scrum diarias con reuniones de scrum semanales (más largas): como cada miembro del equipo está trabajando en sus propias tareas, las reuniones de scrum diarias deberían ser realmente importantes para mantener un "espíritu de equipo". Sin embargo, se supone que las reuniones diarias de scrum duran alrededor de 15 minutos. Claramente, esto no es suficiente para entender lo que los demás están haciendo y harán. Además, el matemático responderá la mayoría de las veces las mismas cosas: "Todavía estoy haciendo % & Lo (+? $$ + &)" ... Las reuniones semanales darían más tiempo. Para mantener el mismo tiempo de reunión entre las reuniones de scrum "iniciales" y las reuniones de scrum "semanales", cada reunión de scrum semanal debe durar (5 días a la semana, con sprints de 4 semanas, con reuniones de sprint de 4 horas y reuniones diarias de 15 minutos): (4 * 60 + 20 * 15) / 4 =>

¿O todavía se puede usar scrum? ¿Quizás debería usarse otra técnica ágil?

Scrum no es una bala de plata. No todos los proyectos tienen que usar Scrum para tener éxito. Sin embargo, la situación que está describiendo suena muy bien para Lean / Kanban. Es posible que desee comprobarlo.

Kanban básicamente te pide que hagas solo algunas cosas, ninguna de las cuales está en desacuerdo con el tipo de equipo que estás describiendo:

• Visualice el flujo de valor, es decir, el tablero Kanban. El tablero Scrum es una aplicación específica de un tablero Kanban; Es posible adaptarlo para permitir la especialización.
• Limite el trabajo en progreso (WIP), de modo que la cantidad de trabajo asignada al equipo sea suficiente para mantener el trabajo en constante flujo, es decir, sin "bloqueo" en el inicio de la secuencia (diseño) o el final (implementación) .

Es posible que desee consultar algunas referencias sobre Kanban:

• Un día en tierra Kanban
• Cebado Kanban (EBook gratis)

Te estás enfocando demasiado en la mecánica de scrum / agile sin mirar lo que se supone que ofrece agile. Dices que si el chico de matemáticas estima 2 puntos, nadie puede decir que está equivocado. Este no es el objetivo. El objetivo es acordar un conjunto de objetivos alcanzables para el próximo sprint. Como experto en esa tarea, sabrá mejor cuánto tiempo llevará.

"¿Y qué si él miente o simplemente se equivoca?" tu dices. En mi experiencia, la gente subestima más porque temen que les disparen por dar una suposición precisa. Otros subestimados luego agregan un margen de seguridad que equilibra todo y la persona perezosa extraña sobreestimará para que no tengan que apresurarse. De los tres, el primero se recogerá en el seguimiento de velocidad, el segundo, aunque suene mal, está funcionando y el tercero es algo con lo que tiene que lidiar fuera del scrum.

La reunión diaria aún ofrece beneficios. Existen dependencias entre los miembros del equipo, incluso si son especialistas. El chico de la IU puede estar esperando al chico del servidor para corregir un error de notificación. El chico del servidor puede estar esperando al chico de las matemáticas para descubrir por qué un cálculo está mal. Tampoco se trata solo de cómo le afecta su trabajo. Si un miembro del equipo se retrasa constantemente debido a la "Razón X", pero no se ha tomado el tiempo para mitigar futuras incidencias de la "Razón X", eso puede ser cuestionado.

Si tiene un especialista con calificaciones como las que describió, su suposición de que cada uno está trabajando en su propia tarea, y rara vez necesita comunicarse con los demás, está mal. De hecho, para realizar una nueva función (una "historia de usuario"), a menudo tendrá que

• cambia tu base de datos
• agregar o cambiar la GUI o la interfaz web
• combine esto con la lógica de negocios correcta (donde, tal vez, ingrese su "matemático")
• asegúrese de que todos esos cambios funcionen bien juntos

Así que supongo que tendrán que comunicarse mucho más como en un equipo de generalistas, donde todos podrían trabajar en una aplicación / historia de usuario diferente, haciendo todos los cambios necesarios en todas las capas de aplicación por sí mismo. Por lo tanto, todas las actividades de equipo de Scrum que enumeró anteriormente tienen mucho sentido para dicho equipo.

Scrum ciertamente sigue siendo apropiado para su situación, pero también podrían hacerlo otros marcos.

Para ofrecer nuevas funciones, es probable que necesite todas o muchas de estas habilidades. Para que el equipo tome decisiones que se impacten entre sí y trabajen juntos, deberán comunicarse. Cuanto más tiempo transcurra entre las reuniones de Scrum, más tiempo un plan negativo puede desviar al equipo. Al reunirse a diario, el equipo puede abordar estas situaciones rápidamente y elaborar un nuevo plan.

Me gustaría abordar algunos temas específicos que mencionas también:

Equipos multifuncionales Un equipo se consideraría multifuncional si tiene todas las habilidades necesarias para cumplir con un objetivo de sprint y / o un elemento de la cartera de productos. Esto no significa que haya 2 personas por cada trabajo.

Dimensionamiento Es importante recordar que estamos dimensionando un problema o necesidad comercial, no una solución o parte de una solución. Por ejemplo, integrar las redes sociales / Twitter en nuestro sitio de comercio electrónico es un problema que requiere UX, diseño de IU, programación, base de datos y conocimiento de la API de Twitter. Un equipo debería dimensionar eso como una unidad, ya que, como equipo, entregarán esta funcionalidad. Este tamaño no será 100% exacto, pero sí encontramos que, en conjunto, los pronósticos basados ​​en el tamaño relativo son más precisos. Esto significa que algunos serán altos, otros serán bajos y, en conjunto, el pronóstico calculado es más preciso que la duración estimada.

Planes de primavera inútiles La planificación de Sprint es un momento para colaborar como Equipo Scrum (Equipo de Desarrollo + Propietario del Producto + Scrum Master) para determinar qué se debe producir y elaborar un plan sobre cómo comenzar. Algunos equipos dividirán estos elementos de la reserva de productos elegidos en tareas, mientras que otros idearán su propia forma de progresar, como pruebas que deben pasar (piense en XP).

Esta es una colaboración de dos vías. Asignar al equipo un conjunto de PBI y decir "ir" es el papel de un dictador. El equipo está negociando con el propietario del producto para maximizar el tiempo en el sprint.

Métrica inútil de la velocidad del equipo Con los equipos que evalúan los problemas y las necesidades de la empresa que atraviesan la arquitectura / sistema y la experiencia pasada que nos dice cuántos de ellos se han entregado al equipo en un tiempo constante (sprint), ahora podemos proporcionar un pronóstico del equipo para el resto de la cartera de pedidos.

Una vez más, no habrá dos sprints iguales y cuanto más pequeño sea el conjunto de muestra de elementos de la Lista de Producto que utilice, menos extendido será el error en las estimaciones. Piense en ello como el mercado de valores; siempre ha subido, pero eso no significa que no tengamos años bajos. En conjunto, puede ganar dinero, pero en cualquier mes, trimestre o año determinado adivinará mal.

Reemplace las reuniones de scrum diarias con reuniones de scrum semanales (más largas) El Daily Scrum está allí para proporcionar al equipo un ciclo de retroalimentación de 24 horas y la oportunidad de planificar las próximas 24 horas. Nada más y nada menos. Las "Tres preguntas" están destinadas a ayudar a facilitar ese esfuerzo.

Si no tiene comentarios durante 5 días, creo que sus tareas no son lo suficientemente precisas. Esta es simplemente mi opinión, pero se basa en mi experiencia como entrenador y miembro del equipo. Los equipos deberían hablar, planificar e integrar sus esfuerzos MUCHO más a menudo.

Conclusión Scrum está destinado a facilitar el aprendizaje y equilibrar ese aprendizaje con la entrega (donde ocurre el aprendizaje real). Experimente con sus procesos y herramientas a lo largo del tiempo y use Scrum para inspeccionar el impacto. Intente pasar de Scrums diarios a semanales y vea si esto ayuda o perjudica la capacidad del equipo para ofrecer la funcionalidad correcta. Eso puede funcionar para ti.