Ayuda - El equipo técnico no quiere trabajar de forma ágil

No hace ninguna mención de un Scrum Master en su pregunta, por lo que voy a suponer que él o ella no existe o no es útil. Si no, ¡asegúrese de involucrar al Scrum Master! Es su trabajo abordar los problemas del proceso.

Dicho esto, Scrum proporciona una herramienta para abordar cosas como esta: la Retrospectiva. Esto es lo que yo haría, en tus zapatos.

1. Para un Sprint, retrocedería y dejaría que los desarrolladores dividieran las historias como quisieran (nota al margen: se supone que dividir historias es un proceso de colaboración entre el PO y el equipo de desarrollo).
2. Al final del Sprint, durante la Retrospectiva, señalaría los problemas prácticos reales causados ​​por la falta de división. (¡Suponiendo que haya alguno! Si no, regrese al paso 1).
3. Le pediría al Equipo que ayudara a pensar en posibles soluciones para los problemas. Sin ningún sesgo. Solo si y después de que el equipo no pueda proporcionar una solución viable, presentaré mi sugerencia de 'dividir las historias para que sean más granulares'.

Recuerde, ágil no se trata de evitar problemas. Se trata de encontrarlos rápidamente. No se obsesione tanto con seguir Agile para evitar posibles problemas futuros que evite la piedra angular de Agile en sí misma: intentar, inspeccionar, adaptar.

Esa es una situación frustrante, Chris. De su pregunta, no parece que el equipo no pueda desarrollar cosas en partes más pequeñas, sino que no lo harán. Baso esto en el hecho de que parece que cuando el entrenador ágil está allí, lo hacen y solo en mi experiencia como desarrollador, el tipo de división del que hablas no suele ser difícil.

En resumen, no tienes un problema ágil o técnico, tienes un problema de personas. Para resolver ese problema de las personas, debe comprender por qué el equipo elige crear sus funciones de esta manera. Espero que su entrenador ágil o maestro de scrum pueda facilitar esa discusión, pero pensé en dar dos posibilidades a continuación solo para que piense. Sin embargo, tenga cuidado, ambas son solo posibilidades. La única forma de saber si es uno de estos o algo más es tener una buena conversación con el equipo.

Posibilidad 1: Estás pisándoles los dedos de los pies. Las personas son fácilmente insultadas y, técnicamente, Scrum dice explícitamente que nadie puede decirle al equipo de desarrollo cómo hacer su trabajo. La situación de la que estás hablando es un poco gris, pero aún así, es completamente posible que alguien más que les diga cómo dividir el trabajo se escuche como "no sabes cómo hacer tu trabajo".

Posibilidad 2: Su forma de hacerlo es un poco más eficiente y piensan que les vas a pedir que las hagan todas de todos modos para que tomen el camino de menor resistencia. En estos casos, es posible que tengan razón o que deba presentarles un escenario diferente, en el que solo desea agregar y ver en 4 o 5 áreas primero antes del resto de la funcionalidad.

Como dije, hay muchas más posibilidades de las que puedo enumerar. Estos son solo algunos para hacerte pensar en ese sentido. Con suerte, su SM o entrenador ágil puede facilitar una buena conversación sobre el tema.

Soy un desarrollador que trabaja con código heredado en scrum y déjame decirte que creo que tienen razón porque yo hago lo mismo. Permítanme explicar mi caso, tenga en cuenta que soy lo que la gente considera un programador vaquero / hacker :

TL.DR:

• dividir todo en elementos más pequeños no es bueno, te estás perdiendo patrones e interacciones : estás intercambiando la posibilidad de tener un código factorizado para múltiples funciones específicas que se superponen y pueden factorizarse más tarde (nunca). Así es como nace el software de mierda.

• se está enfocando en el método en lugar del resultado : si su forma funciona, la calidad es buena y el recuento de errores es bajo, como PO, ¿qué sucede? debe dejar que los especialistas hagan su especialidad como mejor les parezca. no puedes obligar a la gente a cambiar sus métodos porque no te gustan. Así es como nacen los gerentes terribles.

• Desde el punto de vista moral, es mejor trabajar en un gran proyecto que tiene un final en lugar de la rutina interminable de elementos más pequeños : como sufrieron los trabajadores en las fábricas de Ford, Scrum es bastante rompedor y desmotivador con su ciclo interminable de nuevos elementos pequeños que son Nunca un producto completo. Así nace la alta Tasa de Rotación (cita necesaria) .

Respuesta larga (con algo de historia)

Tenemos una solución de software, escrita a lo largo de los años en un lenguaje de nicho y spam de más de 1 millón de líneas de código distribuidas en cientos de módulos y aplicaciones diferentes. Entonces, cada vez que el cliente/PO/alguien preguntaba "¿por qué no hacemos esta pequeña funcionalidad aquí?" y el maestro de scrum lo atomizó más allá del reconocimiento, introdujimos nuevos errores de interacción que eran bastante difíciles de resolver. El ciclo interminable de pequeñas tareas sin sentido, correcciones constantes de errores que podrían haberse evitado y la falta de motivación para hacer algo bueno hizo que nuestros desarrolladores siguieran adelante gradualmente, hasta que terminamos con solo uno: yo.

Cuando era obvio que iba a ser la última rata en el barco (un barco que todavía me gusta) hice algo estúpido pero necesario: estudié TODO el código base. cuando eventualmente me convertí en el único que podía trabajar en los elementos, implementé la forma más eficiente de arreglar las cosas: les dije que se fueran a la mierda, haré las cosas a mi manera, con mi propia lista de prioridades y si no les gustaba podrían despedirme y hundirme en un mes.

Primero dejé las reuniones porque estaba solo, no necesitaba dar explicaciones ni coordinarme con nadie. Luego abandoné el modelo de entrega iterativo porque no necesitaba mostrar el progreso y el software que funcionaba a medias era inútil aquí. Luego abandoné el sprint porque quería entregar un producto de calidad rápidamente, así que me tomé mi tiempo para hacerlo bien desde el principio. Y con eso encontré algunas cosas realmente geniales:

• si me dedico a arreglar todo el módulo en lugar de un montón de elementos en cada iteración, pude escribir un código más pequeño, más eficiente y a prueba de errores que aún se mantiene.
• con cada módulo completo que trabajé, pude aprender, definir estándares y mejores prácticas que hicieron que las interacciones fueran más una transacción que una conjetura.
• aunque era dolorosamente consciente de que si fallaba todo terminaría, en ese período de tiempo realmente me sentí motivado y bastante satisfecho con cada módulo que se puso en marcha. no fue solo un empujón moral, me sentí feliz con mi trabajo.

Cuando las cosas mejoraron lo suficiente y comenzamos a atraer a más personas, la metodología "salvemos el barco" recibió algunas modificaciones orgánicas:

• Necesitaba coordinarme con la gente, así que desarrollamos una política de "siempre abiertos a preguntas en cualquier momento" en lugar de reuniones estructuradas.
• las entregas iterativas terminaron siendo reemplazadas por entregas de tareas completas, lo que mejoró la comprensión de todas las partes que interactuaban con él y eran más a prueba de errores en lugar de un trabajo de parche cíclico.
• todos entendieron que las tareas tomaban tiempo para hacerlas bien, en lugar de tratar de encajarlas en un marco de tiempo arbitrario.

Ahora somos scrum de nombre, porque solo es scrum a menos que se interponga en el camino para que las cosas funcionen.

¿Qué tiene que ver esto con tu equipo? :

Su equipo parece haber llegado de alguna manera a las mismas conclusiones que yo, que la atomización genera más problemas de los que puede resolver. ¿Entonces, Qué haces?

Hay muchas maneras diferentes de hacer algo, y cada persona/grupo tiene la manera que funciona mejor para ellos. seamos claros, la única razón por la que no me despidieron y terminé siendo odiado por todos mis compañeros de trabajo es porque lo que hice funcionó (aunque en ese momento me odiaban un poco); pero eso es cierto para scrum y cualquier metodología también: se aplica solo porque trae resultados con los que estamos de acuerdo. si su forma de trabajar ofrece buenos resultados y su recuento de errores está bajo control, ¿por qué querría cambiarlo? porque no es como te gusta? eso suena muy parecido a lo que diría un gerente terrible en lugar de un PO.

Si su rol es PO, entonces su única tarea es decirles lo que necesita /quiere en su producto, no cómo hacerlo. si lo que quiere es un producto hecho de la manera que cree que debe hacerse, entonces no es un PO, solo es un mal gerente en la ropa de PO

Está asumiendo que sabe lo que es mejor para el equipo sin estar obligado a entregar el software.

Creo firmemente en las metodologías ágiles y Scrum en particular. Apoyo totalmente el enfoque iterativo de la historia del usuario. Dicho esto, hay compensaciones a considerar:

• Si el equipo está trabajando en un producto existente o está acostumbrado a trabajar en productos existentes , es posible que duden en trabajar en algo sabiendo que tendrán que refactorizarlo más adelante. Se siente como si estuvieran perdiendo el tiempo.
• Es común en muchas organizaciones que se espera que los desarrolladores lancen funciones rápidamente con la promesa de que pueden volver y "hacerlo bien" más tarde, y nunca se les da tiempo para eso. Si el equipo ha experimentado eso, incluso en trabajos anteriores, podría estar condicionado a no confiar en el desarrollo iterativo.

El desarrollo iterativo supone un bajo coste de cambio. El desarrollo iterativo tiene que ver con la refactorización. Si está refactorizando todos los días, lo está haciendo bien. Pero si está refactorizando constantemente, ¿no va a pasar todo su tiempo probando la regresión? Agile funciona bien cuando simplemente puede cambiar el código, ejecutar las pruebas y estar seguro de que no rompió nada. El equipo tiene que experimentar eso para creer en ello. Y es extremadamente difícil incorporar ese tipo de capacidad de prueba en un producto existente.

Así que mi consejo es hablar con el equipo y comprender sus dudas. Vea lo que puede hacer para ayudar. Encuentre si hay alguien en el equipo que tenga experiencia en el trabajo iterativo que pueda ser su aliado.

Desde el punto de vista del desarrollador

El ejemplo que has usado:'Users Grid', with everything written in (search, filter, sort, add/edit users

Para lograr lo anterior, muchos marcos brindan herramientas integradas (es decir, Yii2 Gii) y generarán la cuadrícula en cuestión de minutos. Ahora, si desea dividirlo, requerirá más tiempo porque el desarrollador tiene que ingresar y eliminar la función y luego volver a agregarla. Será frustrante pasar por ese método.

Así que tal vez hable con ellos y pregúnteles por qué se oponen. Si la razón es algo como lo anterior, cambie un poco su método para que tanto usted como el equipo puedan encontrar puntos en común.

Lo que tienes aquí es un desacuerdo . Tú prefieres hacer las cosas de una manera, el equipo técnico prefiere su manera. Entonces, la forma de solucionar esto es preguntar ¿POR QUÉ? . Y no solo por qué ellos prefieren su manera, sino también por qué tú prefieres la tuya.

Tal vez ellos estén establecidos en sus caminos, y usted esté establecido en los suyos. Tal vez no entiendan todo esto de Agile y no vean el punto. Tal vez Scrum parezca tonto. Tal vez no les guste la forma en que divides las historias. Tal vez eres realmente malo para dividir las historias. Tal vez tengan una idea del producto y piensen que es mejor hacer las cosas a su manera. Usted es el PO, pero tal vez debería estar más abierto a sus comentarios. Tal vez no son muy hábiles técnicamente y les preocupa que se ensucien las cosas al no saber cómo dividir el trabajo correctamente, para permitir un desarrollo incremental, por lo que tratan de mantener todo junto. Un montón de "tal vez" porque estoy tratando de adivinar lo que está pasando simplemente por lo que se ha publicado aquí, pero yoy haciendo esta pregunta.

Así que organice una reunión con todos y discuta las cosas. El propósito de esta reunión es entendernos y llegar al fondo del problema . Sólo entonces podrá encontrar una solución que funcione para todos . Decirles que quiere que trabajen de una manera más ágil no significará nada para ellos a menos que entiendan por qué es necesario.

El entrenador SM/Agile puede mediar en las cosas y asegurarse de que las conversaciones se mantengan en un nivel respetable y adecuado, pero esto debe ser una reunión separada, no parte de los eventos de Scrum. La retrospectiva es el lugar para tener tales discusiones, pero es obvio por la pregunta de los OP que las retrospectivas no están haciendo su trabajo correctamente (el equipo vuelve a sus viejas costumbres en el momento en que el SM no está mirando, hay oposición a la idea , y esto lleva ocurriendo desde hace mucho tiempo, tanto que el OP se ha dado por vencido y está dispuesto a trabajar con mini cascadas a pesar del riesgo para el proyecto y el cliente). Una reunión separada es una señal adicional sobre el peso de la situación. La gente necesita entender que " este arreglo no está funcionando para todos". Una vez que las personas entienden el peso de la situación, se descompone el problema y se encuentran las causas fundamentales del desacuerdo, solo entonces se puede hacer algo al respecto. De lo contrario, cualquiera, en ambos lados, puede percibir cosas como "es porque alguien lo dice o lo quiere ”.

Me parece un poco que tanto tú como el equipo están perdiendo el mismo punto. No se trata de lo que es fácil de construir o probar, no se trata de ser incremental porque sí, se trata de entregar el valor correcto en el momento correcto.

¿Cómo te estás acercando actualmente a tus objetivos de sprint? Ha mencionado la priorización en función de la prioridad y el valor, pero ¿establece objetivos de sprint claros? ¿Tiene objetivos comerciales claros? ¿Dejas que elijas el flujo de trabajo del objetivo establecido para el sprint, o solo hay una gran acumulación de cosas y solo estás trabajando para bajar?

Si es lo último, puedo imaginar a los desarrolladores pensando de la forma en que lo están haciendo ahora. Si no hay una razón real para entregar algo ahora o en el próximo sprint, es más fácil agrupar áreas funcionales y ofrecer nuevas funciones completamente formadas.

Pero si hay una meta clara, entonces en algún momento necesitas hablar "¿cómo alcanzaremos esta meta?" y te darás cuenta de que no puedes ofrecer todas las características secundarias no esenciales para alcanzar el objetivo del sprint, y todos se darán cuenta de que alcanzar el objetivo es importante y luego puedes tener una discusión sobre dividir los componentes y construir lo importante las cosas primero y las no tan críticas después de entregado el gol.

Si no hay un objetivo importante que alcanzar, entonces ningún enfoque es mejor que el otro porque sin el objetivo del sprint, todo lo que está haciendo se reduce esencialmente a trabajo ocupado y no hay una mejor manera de lograrlo.

Cuando las personas son muy resistentes al cambio, a menudo es un comportamiento protector y eso es lo más importante. ¿Por qué? tienes que preguntar

Mi reacción inmediata fue que parecían estar incorporando mucha auditación en la tarea, que ustedes perciben como una mini cascada .

Cuando el equipo crea un nuevo usuario manualmente en SQL, ¿qué más tienen la oportunidad de hacer? ¿Están preocupados por las implicaciones de que alguien más cree usuarios? A veces, un procedimiento manual incluye comprobaciones que requieren mucho trabajo para compilar en el código.

Parece que está adoptando un enfoque común de dividir las cosas en segmentos horizontales de funcionalidad. Puede ser que hayan aprendido, en gran medida de la manera más difícil, lo que lleva a más errores y otros problemas en el contexto de este código base.

Puede haber un problema político, o recuerdos de eso, en esta organización en la que han tenido muy malas experiencias al entregar solo una parte de una función esperada.

Entonces, si desea realizar entregas de forma incremental, ¿puede mantener el mismo conjunto rico de características pero ofrecer versiones más simples en incrementos? ¿Puede la interfaz de usuario ser drásticamente más simple?

la funcionalidad es más fácil de desarrollar y probar si es incremental

Bueno, no siempre. ¿Tiene experiencia directa con este dominio o una base de código específica que le permita ser una autoridad en esto?

Detesto el término ágil porque es muy crítico cuando le dices a la gente que no está siendo ágil .

He sido desarrollador durante casi 40 años y, como alguien profundamente interesado en herramientas y técnicas, observé el crecimiento de la entrega incremental y el nacimiento del Movimiento Ágil. También he trabajado en bases de código complejas, por ejemplo: CAD 3D de más de 1 millón de líneas de C++. Prefiero la entrega incremental, pero también sé que no siempre es apropiado.

Abordar Time-Boxing y Cultura Organizacional

La noción de "reelaboración" es engañosa cuando se adoptan metodologías de desarrollo iterativo. En los marcos tradicionales, todo lo que no sea uno y listo se trata como un error o una falla por parte del equipo de desarrollo. La realidad es que los marcos ágiles aceptan el cambio, y una cierta cantidad de reelaboración y refactorización son una compensación conocida por ciclos más frecuentes de inspección y adaptación.

Asegurarse de que todo el equipo (y la organización en la que vive) comprenda completamente el propósito del time boxing, así como el valor de utilidad de las inspecciones frecuentes tanto del producto como del proceso de desarrollo/entrega, no es el trabajo del propietario del producto. Pertenece correctamente al Scrum Master, con el apoyo de la organización matriz y cualquier entrenador que pueda ser asignado para facilitar la transición.

En resumen, muchos desarrolladores nuevos en Scrum necesitan sentirse seguros al adoptar un proceso de desarrollo/entrega que promueva inherentemente el diseño emergente en lugar del gran diseño inicial (BUFD). Como proceso de control empírico, Scrum implica una cantidad de gastos generales y reelaboración que provocaría culpas, señalamientos y acciones adversas del personal en las organizaciones BUFD. Hasta que todo el equipo esté seguro de que esto no sucederá, se mostrarán justificadamente escépticos respecto de cambiar los patrones de trabajo que les han servido bien en su carrera hasta el momento.

Una inmersión más profunda: reformular la conversación

Mi razón es que la funcionalidad es más fácil de desarrollar y probar si es incremental; reduce el riesgo, podemos mostrar cosas antes al cliente y obtener comentarios antes. Mientras que, para ellos, es más fácil si no fragmentamos el trabajo y entregamos las cosas completas de inmediato.

No fragmentar el trabajo no entrega nada "de inmediato". Por otra parte, los paradigmas incrementales e iterativos a menudo ofrecen segmentos en lugar de características completas, todo a la vez. En cualquier caso, ambas partes parecen estar discutiendo sobre la cuestión fundamental de si el tiempo inherente a Scrum agrega valor a sus procesos o productos actuales.

Nadie fuera de su empresa realmente puede determinar esto. Sin embargo, debe trabajar con su entrenador ágil para enmarcar esto de manera diferente al debate actual "monolítico versus incremental" que usted y el equipo están teniendo.

Como Dueño del Producto, usted es miembro del Equipo Scrum. Eso restringe cuánta autoridad (específicamente, ninguna sobre el Equipo de desarrollo) e influencia (tanto como pueda proporcionar) tiene dentro del proceso Scrum. Sin embargo, también eres la persona que controla el Product Backlog. Tener en cuenta sus roles duales como propietario del producto y miembro del equipo Scrum puede ayudarlo a enmarcar la conversación de manera diferente. En particular, usted debe:

1. Administre activamente la cartera de productos para asegurarse de priorizar los elementos de la cartera que (al menos conceptualmente) encajan en una sola iteración.

2. Trabaje con Scrum Master y el equipo de desarrollo para establecer la expectativa de que el Sprint Goal acordado debe completarse en un solo Sprint.

Al enmarcar la discusión como "¿Qué podemos encajar con confianza en nuestra próxima caja de tiempo?" en lugar de "¡Deberías trabajar de manera incremental!", cambias el marco de la discusión de si trabajar de manera incremental a una sobre cómo dividir el trabajo. Concéntrese en lo que necesita (p. ej., un circuito de retroalimentación rápido de inspección y adaptación que se pueda demostrar a los clientes como trabajo en progreso), en lugar de cómo el equipo debe lograrlo.

El Scrum Master y el entrenador ágil deben trabajar con usted y el equipo para explicar el ángulo del negocio (si es necesario), así como también ofrecer algunas técnicas prácticas si el equipo tiene dificultades con el desarrollo de tiempo limitado. Sin embargo, usted y el Scrum Master deben colaborar activamente para garantizar que el equipo de desarrollo tenga la oportunidad necesaria para volver a trabajar y refactorizar a medida que cambia la cartera de productos.

Desacoplar y descomponer características puede ser complicado y supondrá mucho ensayo y error antes de que el equipo adquiera la experiencia y la madurez del proceso para hacerlo incluso con un intervalo de confianza del 60-80 %. A menos que el equipo esté motivado (ya sea por iniciativa propia o externamente) para hacer ese esfuerzo y confíe en que tiene una oportunidad segura de aprender por ensayo y error (con énfasis en el "error") sin consecuencias adversas, simplemente adoptando las trampas de Scrum no lograrán nada.

Esperar el éxito de la gestión de moda del día es un dilbertismo. Los marcos ágiles como Scrum solo son efectivos cuando los utilizan equipos empoderados y autorrealizados . Imponer un marco ágil a los tradicionalistas inconversos es una forma de Buzzword Management™, y es la razón número uno por la que he visto fallar las implementaciones "ágiles". Para tener éxito, Scrum debe ser adoptado por todo el Equipo Scrum, la organización matriz y los clientes/partes interesadas/patrocinadores del proyecto.

Ayudar a cada colaborador dentro del proceso a descubrir la propuesta de valor del marco en relación con su propia piel en el juego no es algo que deba hacer usted mismo. Apóyese fuertemente en su Scrum Master y otros para hacer que los problemas de adopción de procesos sean transparentes y visibles para que puedan abordarse de manera constructiva.

(buscar, filtrar, ordenar, agregar/editar usuarios, etc.)

Solo desde el punto de vista de un desarrollador:

• Mostrar una lista sin poder agregar elementos es inútil, así que esto es lo primero.
• La máscara para editar un elemento probablemente será la misma que para agregar un elemento.

Entonces, esto le brinda el primer sprint para la funcionalidad CRUD.

• Por lo general, una búsqueda por palabra clave es solo otro filtro aplicado a la consulta de la base de datos.

Por lo tanto, tiene sentido desarrollar la funcionalidad de búsqueda y filtro juntos en el segundo sprint.

• La clasificación puede ser en tipos primitivos, entonces es simple, o podría involucrar algoritmos difíciles, entonces tiene sentido hacerlo en un sprint separado.

Así es como dividiría el trabajo, pero realmente no veo el sentido de entregarlo después de cada sprint. Tiene que ser potencialmente liberable, pero no significa que lo envíe o lo revise con el cliente. Mira, tenemos una lista. Oh mira, ahora puede buscar. Y ahora.. sigues despierto? ¿Hola? Creo que la mayoría de nuestros clientes sugerirían una revisión después de que todo esté listo. También es un poco incómodo para nosotros presentar una pequeña parte de una funcionalidad porque todos piensan "¿eso es todo lo que hiciste en un sprint?", mucho más divertido hacer clic en una función completa y mostrar todas las cosas diferentes que puedes hacer a la vez. .

Por experiencia, no creo que cambien mucho los comentarios para una pantalla CRUD simple, tal vez algunos aspectos de diseño o diseño que también se pueden solucionar después de la primera revisión. Para partes más grandes del proyecto, tiene sentido dividirlo y obtener una revisión temprana, digamos la pantalla de administración de elementos que describe, alguna otra pantalla donde interactúan los elementos o una página de informe donde puede imprimir cosas. Esas son entidades separadas y deben desarrollarse en sprints separados.

También depende de las tecnologías y plataformas que utilice, cuántas personas están involucradas en el desarrollo, su disponibilidad y cuánta coordinación se necesita para realmente terminar algo en un sprint.

Debe preguntarle al equipo qué se necesitaría para dividir las tareas de manera eficiente y trabajar desde allí. Tal vez necesitan condiciones de trabajo diferentes.

Scrum también significa que todos trabajan juntos en una cosa, ¿es esto posible? Tal vez necesiten un bloqueador en otros proyectos entrantes. ¿Quizás necesitan mejores herramientas?

Averigüen el verdadero problema y luego resuélvanlo, juntos.