¿Cómo se puede adaptar Scrum a un entorno de voluntariado?

Recientemente me uní a un joven hackerspace que todavía está en proceso de configuración. Somos afortunados porque el espacio tiene algunos proyectos internos que necesitan trabajar y no hay escasez de voluntarios para trabajar en ellos.

Ha habido algunas discusiones sobre cómo organizar estos proyectos. Mi experiencia profesional más reciente ha sido con Scrum, así que estoy considerando lanzar un enfoque Scrum para nuestros proyectos de software, pero no estoy seguro de que sea una buena opción.

Aunque he visto a Scrum funcionar bien para pequeños equipos de tiempo completo, la naturaleza de esta organización es diferente:

• Los miembros son voluntarios . Algunos son estudiantes a tiempo completo. Otros trabajan trabajos a tiempo completo. No podemos esperar un nivel constante de contribución de nadie, ya que sus vidas reales tienen prioridad.
• Si bien casi todos tienen años de experiencia escribiendo software, no muchos miembros lo han hecho de manera profesional o en equipo.
• No hay dueño del producto . Los requisitos para estos proyectos son determinados por un comité. Los miembros de este comité también estarán trabajando en la implementación. Esto significa que no tendremos un propietario de producto único y dedicado.
• No tenemos plazos (blandos o duros). Los proyectos se realizarán cuando se realicen.

Estas son diferencias bastante significativas, pero no estoy convencido de que sean bloqueadores para aplicar Scrum. Creo que algunos pequeños ajustes podrían superar este obstáculo:

• Si cambiamos los Sprints para que tengan un tamaño de punto de historia fijo, pero una duración (tiempo) fluida , aún podemos beneficiarnos de lanzamientos iterativos sin ejercer una presión de entrega poco realista sobre los desarrolladores voluntarios.
• Podemos deshacernos de las tablas de quemado y el cálculo de la velocidad . Si entiendo correctamente, estas son herramientas y métricas que funcionan como un puente entre el equipo de desarrollo y la Administración. Sirven para informar el progreso en una forma que sea significativa tanto para los desarrolladores como para las partes interesadas. Teniendo en cuenta que no tenemos a nadie a quien informar (sin Gerente de Proyecto, sin Propietario de Producto y sin partes interesadas externas), creo que podemos abandonar esto por completo.

Cosas que creo que podríamos beneficiar de las cuales no requerirán ajustes:

• La (s) reunión (es) de reunión de requisitos . Donde todos se sientan alrededor de una mesa y discuten Historias de usuarios, bosquejan simulacros de UI y construyen una cartera de productos.
• Retrospectivas de Sprint . Esta será una forma interesante de converger en un proceso de desarrollo que funcione para nosotros como equipo de voluntarios.

Cosas de las que no estoy seguro:

• ¿Cómo se deben tratar los Stand-ups diarios ? Me pregunto si tendrían mucho valor en nuestro entorno. Mi comprensión del ritual de pie es que ayuda a la comunicación al diseminar información de forma natural en todo el equipo. Teniendo en cuenta el hecho de que nuestros Sprints probablemente ofrecerán mucha menos complejidad que un Sprint promedio, es posible que haya menos necesidad de estar al tanto de los avances / desarrollos de todos los demás miembros del equipo.
• ¿Debería presionar para obtener cosas de XP como integración continua, revisiones de código y TDD? Me preocupa que esto pida mucho. Me sentiría más tentado a incorporar estos conceptos en proyectos futuros una vez que las personas estén más familiarizadas con Scrum y trabajen en equipo.

Mis preguntas:

¿Se puede adaptar Scrum a un entorno voluntario?
¿Y mi enfoque planificado va en la dirección correcta hasta ahora?

Mira a Kanban. Es más apropiado que SCRUM para sus limitaciones.

Editar: SCRUM es (más o menos) un retraso acumulado ordenado con sprints y ceremonias para garantizar que el volumen de trabajo 'en progreso' se mantenga bajo control y tenga algo sólido al final de cada sprint. Si abandona las ceremonias y la cadencia de sprints, termina con Kanban: una acumulación ordenada y un fuerte énfasis en limitar el trabajo 'en progreso' directamente y asegurándose de que todo lo marcado como 'hecho' se haga en lugar de imponer estabilidad al final de cada sprint

Todavía obtienes los beneficios ágiles: libera en cualquier momento, flexibilidad, alguna medida de previsibilidad, aunque SCRUM puede llevarte un poco más lejos en ese aspecto, y sin las ceremonias o aspectos de SCRUM que no encajan bien en un equipo suelto y distribuido sin compromiso . ¿La captura? Abandonar las ceremonias requiere más disciplina, por lo que REALMENTE debe prestar atención a las pruebas, la calidad del código, el trabajo actual en progreso y asegurarse de que la parte superior de la cartera (cosas listas para ser recogidas por personas) esté suficientemente elaborada.

Podría tener una cartera de pedidos basada en votos, aunque en un entorno voluntario algunas personas simplemente trabajan en lo que quieran.

(Y sí, todas las ideas de TDD, CI, revisiones e programación de pares son buenas ideas).

Para abordar las diferencias que observa primero:

• Que sus miembros sean voluntarios no significa que no pueda pedirles un compromiso. Especialmente con la duración relativamente corta de un sprint en Scrum, debe ser posible para cada uno de los miembros saber cuánto tiempo pueden dedicar al proyecto durante las próximas semanas. Tener a los miembros del equipo disponibles durante una cantidad diferente de tiempo cada sprint hará que la planificación sea un poco más difícil, porque es más difícil determinar cuántos puntos de la historia son realistas, pero no hace que Scrum sea inviable.
• El propietario del producto es responsable de consolidar y comunicar la visión (y los requisitos) que las partes interesadas tienen para el producto al equipo de desarrollo. La parte de consolidación probablemente ya esté cubierta por el comité 'directivo'. Para la parte de comunicación, solo pueden delegar a uno de sus miembros como su portavoz principal. Ese será, a todos los efectos prácticos, el propietario del producto.
• No tener un plazo externo no es realmente un problema para Scrum. Simplemente se trata más del orgullo del equipo en el producto para terminarlo. Scrum tiene una fecha límite natural para cada sprint.

Con respecto a sus adaptaciones propuestas, especialmente cuando trabaje con voluntarios, recomendaría encarecidamente mantener la longitud del sprint fija. De esa manera, los voluntarios saben definitivamente durante qué período están dando su compromiso.

Tampoco abandonaría las listas de quemado inmediatamente. También pueden ser útiles para que el equipo mismo vea cómo están cumpliendo con su compromiso. Dejaría en manos del equipo decidir mantenerlos o deshacerse de ellos. Lo mismo ocurre con los cálculos de velocidad. especialmente con la gran variación en horas hombre disponibles en cada sprint, pueden resultar muy útiles (especialmente si calcula el número de puntos completados por hora hombre) en la estimación de futuros sprints.

Con respecto a las standups diarias, seguirán siendo útiles en su entorno, aunque solo sea para que se sepa lo que todos están haciendo o tienen problemas (y eso es independiente de la complejidad). Pero puede ser más difícil realizar una resistencia diaria, por lo que es posible que deba comprometerse allí.

Las prácticas de XP que mencionas se pueden introducir o no independientemente del uso de Scrum y también se pueden proponer durante una retrospectiva.

Me sorprende que nadie lo haya señalado, pero su proyecto parece ser la mayoría de los proyectos de código abierto. Si echa un vistazo a algunos proyectos de código abierto más populares, puede encontrar algo de inspiración. Y creo que deberías olvidarte de SCRUM y pensar en esto desde una perspectiva de agilidad general.

Ágil es todo sobre comunicación y colaboración. Hay una razón por la cual hay 2 puntos de 4 en el Manifiesto Ágil para hablar de ello.

Individuos e interacciones sobre procesos y herramientas

Colaboración del cliente sobre negociación de contrato

Y la forma en que describe su proyecto, sería difícil tener una comunicación cara a cara con todos los que trabajan en el proyecto, algo que tanto Agile como SCRUM fomentan. Entonces, lo primero en lo que me enfocaría es establecer canales de comunicación para todo el equipo (tanto voluntarios como comité de producto). Cosas como wiki, foros, videoconferencias y un sistema adecuado de trabajo atrasado, tareas y seguimiento de errores son excelentes maneras de garantizar que todos sepan lo que está sucediendo y lo que hay que hacer.

La segunda cosa que quisiera señalar es no solo rozar las partes tecnológicas de ágil. Muchos creen (incluido yo mismo) que ellos son los que hacen que el trabajo sea ágil, no el lado del proceso. La revisión del código es importante y la mayoría del trabajo de código abierto al hacer que alguien que conoce el proyecto revise los compromisos / impulsos para garantizar que se mantenga una calidad lo suficientemente alta. TDD se da prácticamente para cualquier proyecto ágil. Asegura que cualquier cambio en el código no rompa la funcionalidad anterior, lo cual es aún más importante en su caso cuando los voluntarios no pueden molestarse en corregir los errores de otras personas. También facilita la revisión del código porque el revisor puede ver en las pruebas qué funcionalidad se agregó y, al ejecutarlas, se asegura de que la funcionalidad realmente funcione según lo previsto. La integración continua es igual que TDD.

Lo último es que creo que debería tener al menos pocas personas trabajando en el proyecto a tiempo completo. Esas personas deberían tener roles específicos:

• Propietario del producto : si bien es bueno que tenga un comité completo dedicado a esto, debe haber una persona responsable de interpretar las palabras de este comité en las especificaciones o historias de usuarios y garantizar que se implementen correctamente.
• Coordinador y Scrum Master : esta persona debe ser responsable de todo el proceso y asegurarse de que todos sepan las cosas importantes que suceden en el proyecto. Además, mantiene la wiki y las herramientas de seguimiento de tareas y errores. Si alguien tiene una pregunta sobre el proyecto, esta es la primera persona que debe preguntar.
• Desarrollador y arquitecto principal : la persona que mejor conoce el código. Realiza las revisiones del código y garantiza que la calidad del código sea lo suficientemente buena para un desarrollo ágil.

No puede adaptarlo de la manera que lo describe y aún llamarlo SCRUM. pero en mi opinión, puede usar Scrum como sigue para la configuración que ha descrito.

1. Tener iteración fija. Para que pueda medir su progreso. Esto no es solo para la administración sino también para que el equipo "sepa" cómo se están desempeñando.
2. Pida voluntarios para compartir capacidades al inicio de la iteración. Todo el equipo necesita lo que los miembros se comprometen; de lo contrario, ciertos miembros pueden abandonar el equipo por un trabajo más profesional.
3. No tener fecha límite está bien. Scrum no fuerza eso, sin embargo, lo que hagas al final de cada iteración debería ser potencialmente enviable. Esto le permitirá decidir qué hacer a continuación en función de lo que haya hecho hasta entonces (que está funcionando).
4. No tener un propietario del producto puede funcionar también. Puede tener algún tipo de sistema de votación para apilar el trabajo acumulado y aceptar / rechazar el trabajo realizado.
5. La recopilación de requisitos no es parte de Scrum. Puedes hacerlo de la forma que quieras. Pero no incluya eso como parte del alcance de la iteración. Tener capacidad separada para eso. Entonces, para una iteración, planifique solo ese trabajo para el cual los requisitos son claros, por ejemplo, el equipo conoce los criterios de aceptación.
6. Las retrospectivas son buenas. Por lo tanto, inicie Scrum como tal, pero luego, utilizando la retrospectiva, vea qué está funcionando y qué no, por ejemplo, es posible que deba cambiar el tamaño de la iteración, es posible que deba deshacerse de algunos voluntarios que están arrastrando a todos los demás.
7. El estado diario es obligatorio. Eso le da la oportunidad al equipo de sincronizarse entre sí, es decir, alinearán sus esfuerzos para que ninguna tarea se bloquee innecesariamente debido a la falta de disponibilidad del entregable de otro miembro.
8. XP es bueno. Tenga una definición estricta de hecho basada en XP, por ejemplo, no entra código a menos que se revise. Haz menos para hacer más ...

Podría sugerir un enfoque diferente. Como se trata de voluntarios, debe tener en cuenta algunas cosas. Su equipo probablemente tendrá una alta rotación, la vida se interpondrá y la gente se distraerá. De los que quedan, unos pocos contribuirán de manera consistente, pero no mucho, y finalmente tendrás ese grupo hardcore que realmente hundirá sus dientes en el proyecto. Estoy haciendo muchas suposiciones sobre su fuerza laboral aquí y si siente que mi evaluación no refleja a las personas con las que está trabajando, no dude en ignorar el resto de esto.

Ahora necesita una estrategia que permita a las personas que no hacen mucho trabajo poder trabajar de manera bastante autónoma, solo tienen mucho tiempo para dedicar a esto y no quieren hacer que gasten la mayor parte de eso en comunicación. Las personas que están más involucradas deberían ser responsables de la integración y eliminar algunas de las ideas más complejas.

Esto me lleva a pensar en un proceso de desarrollo más centrado en marcos de alambre y prototipos.

Puede tener un grupo de elementos de trabajo disponibles y alentar a las personas a escribir marcos de alambre para ellos. Puede usarlos como Tracer Bullets (terminología prestada del programador pragmático) para perfeccionar la idea y proporcionar inspiración a las personas para que la desarrollen. A partir de ahí, puede graduar las ideas exitosas en prototipos, nuevamente estos son proyectos muy pequeños diseñados para ayudar a las personas a aprender más sobre los proyectos. Después de eso, ahora tiene una sección más pequeña de ideas sólidas que han sido creadas por una multitud de personas que puede transmitir a algunos miembros del equipo que son un poco más activos y pueden trabajar para integrar esas ideas en su sistema.

Creo que Kanban encajaría mejor para esta situación.

Scrum tiene algunas cosas que no encajan. Las mediciones de tiempo o alcance no son necesarias y todos los que desarrollan tienen la misma visión de producto de las reuniones. La responsabilidad y el seguimiento de un plan corto con coherencia son objetivos comerciales.

Kanban ofrece muchas de las mismas ventajas que Scrum sin sus desventajas. Puede darle prototipos rápidos. Los prototipos se pueden ejecutar antes de las reuniones. También proporciona TDD para código modificable y pruebas de regresión. La programación de pares puede facilitar a los recién llegados y no habituales a la base del código mediante la transferencia de conocimientos.

Kanban también tiene ventajas únicas. Si la visión de lo que hacen los usuarios se está desarrollando en paralelo, Kanban funciona bien. Prueba de ello es el éxito de los programas de pequeñas empresas. Además, para los días con pocos voluntarios, como tres personas, Kanban aún funcionaría bien. Scrum, a pesar de ser ligero, sería demasiada cinta amarilla.