¿Cómo podemos hacer que Agile sea agradable para los desarrolladores a los que les gusta poseer, de forma independiente, grandes fragmentos de principio a fin?

Estamos aproximadamente a la mitad de nuestra transición de cascada a ágil usando scrum; Hemos cambiado de grandes equipos en silos de tecnología / disciplina a equipos más pequeños de funciones cruzadas.

Como se esperaba, el cambio a ágil no se adapta a todos. Hay un puñado de desarrolladores que están teniendo dificultades para adaptarse a ágil. Realmente quiero mantenerlos comprometidos y desafiados, y en última instancia, disfrutar de venir a trabajar cada día. Estas son personas inteligentes, felices y motivadas que respeto tanto a nivel personal como profesional.

El problema básico es este: algunos desarrolladores están motivados principalmente por la alegría de realizar un trabajo difícil, pensar en un diseño, pensar en problemas potenciales y luego resolver el problema pieza por pieza, con una interacción mínima con otros, durante un período prolongado período de tiempo. Generalmente completan el trabajo a un alto nivel de calidad y de manera oportuna; su trabajo es mantenible y se ajusta a la arquitectura general. Al pasar a un equipo multifuncional que valora la interacción y la responsabilidad compartida del trabajo, y la entrega de la funcionalidad de trabajo en intervalos más cortos, los equipos evolucionan de tal manera que todo el equipo elimina ese difícil problema. Muchas personas encuentran que esto es un cambio positivo; alguien a quien le encanta tomar un problema y poseerlo independientemente de principio a fin pierde la oportunidad de trabajar así.

Este no es un problema con las personas abiertas al cambio. Ciertamente, hemos visto algunas personas a las que no les gusta el cambio, pero en los casos que me preocupan, los individuos son buenos, genuinamente abiertos al cambio, hacen un esfuerzo, ven cómo está el resto del equipo. cambian y quieren encajar. No se trata de que alguien sea difícil u obstruccionista, o que quiera acumular el trabajo más jugoso. Simplemente no encuentran alegría en el trabajo como solían hacerlo.

Estoy seguro de que no podemos ser el único lugar que no ha tropezado con esto. ¿Cómo han abordado esto otros? Si usted es un desarrollador motivado por poseer personalmente una gran parte del trabajo de principio a fin, y se ha adaptado a una forma diferente de trabajar, ¿qué hizo por usted?

Diré que hay muy pocas tiendas de software que tienen la suerte de tener la rara distinción de que Agile realmente no tiene sentido como metodología. Si todo su equipo está formado por desarrolladores de software verdaderamente excepcionales con un profundo conocimiento de los aspectos del negocio y la longevidad con la compañía y entre sí, y si los requisitos de su negocio y las necesidades del cliente son siempre similares y rara vez están sujetos a cambios en medio de un lanzamiento, entonces tienes la suerte de trabajar en un entorno tan raro en el que Agile probablemente pueda HERIR.

Está diseñado para ser el enfoque más efectivo en medio de requisitos comerciales caóticos y en constante cambio y las necesidades de los clientes, evolucionando o cambiando los recursos del proyecto y plazos ajustados o cambiantes. Tal entorno significa cierto destino para el desarrollo típico de la cascada, ya que es vulnerable a los cambios del equipo a mitad del proyecto, vulnerable a los requisitos cambiantes y extremadamente vulnerable a una fecha cambiante.

Siento por los valiosos miembros de su equipo que ya no encuentran alegría en su trabajo. Muy bien pueden ser personas excepcionalmente talentosas que se dedican a su trabajo, pero al final, una serie de factores fuera de su mejor control aún pueden matar el proyecto. La mejor manera de abordar el desarrollo de características es que pierdan la actitud y expresión individual y piensen en términos del enfoque de equipo.

Si encuentra que esto no funcionará para ellos, puede encontrar un uso especial para ellos. Si son excepcionalmente talentosos y experimentados, vea si estarían interesados ​​en un papel arquitectónico, diseñando diseños de alto nivel, enfoques, experimentando con nuevas tecnologías y desarrollando las mejores prácticas. Haga que estas personas controlen y revisen la documentación de diseño.

Si esto aún no les conviene, entonces quizás haga que trabajen por separado en refactorizaciones técnicas extremadamente complejas en una rama separada, prototipos muy involucrados y pruebas de conceptos, u otro trabajo pionero que a veces debe hacerse pero que no encaja bien en el alcance de un solo proyecto o lanzamiento.

Simplemente no encuentran alegría en el trabajo como solían hacerlo.

Correcto.

Ese es un gran síntoma de que lo estás haciendo mal.

Ágil no debería imponer un nuevo orden malo a las personas.

Agile debería permitir que el equipo se autoorganice de una manera que lo haga más efectivo.

La autoorganización significa que la administración no impone reglas extrañas. No impone malos horarios y no impone una interacción innecesaria.

Algunos desarrolladores están motivados principalmente por la alegría de realizar un trabajo difícil, pensar en un diseño, pensar en problemas potenciales y luego resolver el problema pieza por pieza, con una interacción mínima con los demás, durante un período prolongado de tiempo.

¿Por qué no pueden seguir haciendo esto?

¿Por qué cambiarlos?

Por favor, lea el Manifiesto Ágil varias veces.

El Manifiesto Ágil dice

Individuos e interacciones sobre procesos y herramientas

No dice obligar a las personas a trabajar de una manera incómoda e improductiva.

Si está obligando a las personas a tener demasiada "interacción" de bajo valor, entonces ha ido demasiado lejos.

Software de trabajo sobre documentación completa.

¿Están haciendo esto? Entonces déjalos en paz.

Colaboración del cliente sobre la negociación del contrato.

¿Ya estás haciendo esto? Entonces no cambies.

Responde al cambio sobre el siguiente plan.

¿Dónde estas personas ya pueden responder al cambio? Si es así, entonces ya eran ágiles. No necesitaban cambiar.

mi empresa intentó (y sigue intentando después de años de intentarlo) hacer la misma transición y hasta ahora personalmente, no he tenido mucho éxito con ella. Durante esta transición, leí mucho sobre el desarrollo ágil y las diferentes formas / aspectos / inquietudes / técnicas y una cosa con la que estoy totalmente de acuerdo es que el desarrollo ágil puro es el más adecuado cuando todo el equipo está formado por personas de alto nivel y alta calidad. (o al menos todas las personas del mismo nivel).

La última versión estaba en un equipo "ágil" que en mi humilde opinión tenía demasiados desarrolladores con niveles de habilidad por todas partes e intentamos involucrar a todos en el mismo proyecto. Fue un desastre. Hablamos / discutimos más que trabajamos, y al final lo que el equipo produjo fue un trabajo promedio (lea Peopleware o Mythical Man Month sobre tomar el promedio). Olvídate de los patrones de diseño, olvídate del bajo acoplamiento o de la división del código en clases y métodos pequeños. Olvídate de tratar de hacer algo interesante porque a) no podía ser explicado y entendido por todos los miembros del equipo (al menos no de manera oportuna) yb) ya que éramos ágiles, sea lo que sea que comencé esta iteración, alguien más sin ningún entendimiento continuaría en la próxima iteración. Personalmente,

Absolutamente odiaba el hecho de que no podía hacer nada con las plantillas de C ++, o escribir algunas geniales (pero algo complejas) bibliotecas de marco de bajo nivel que nos hubieran facilitado la vida. ¿Cómo se puede hacer algo así cuando nadie más en el equipo es capaz de leer archivos de encabezado STL, pero se supone que todos estamos trabajando en una cosa a la vez? Todo el proyecto terminó siendo brutalmente forzado característica por característica porque eso es lo que ágil parece enfatizar.

Al mismo tiempo, hay pocas (muy pocas) personas en mi empresa con las que me encantaría trabajar codo a codo y compartir todo mi código.

Pero ahora te enfrentas a una elección. A) Tome todos sus buenos desarrolladores senior que producen código de alta calidad y colóquelos en su propio equipo y coloque el resto en un equipo separado. O B) intente equilibrar equipos y poner buenos con otros no tan buenos. En (A) el problema es que uno de sus equipos tendrá un rendimiento muy bajo y no aprenderá buenas habilidades / hábitos de los buenos. En (B), los buenos (en un entorno puramente ágil) se sentirán frustrados y comenzarán a trabajar en sus currículums. La mía está actualizada.

¿Entonces qué vas a hacer?

No sé si esta es la solución correcta. Pregúntame de nuevo en aproximadamente un año más o menos. Pero, ¿qué pasaría si en lugar de ser "puramente ágil" formaras un equipo, pero identificaras claramente qué persona (s) tiene más influencia (diseño, revisión de códigos ...) y te asegures de que esa persona entienda eso y sea recompensado por una responsabilidad adicional. A medida que los miembros del equipo comienzan a trabajar juntos, identifique a aquellos que están aprendiendo buenos hábitos / prácticas y elevarlos al mismo nivel que sus buenas personas. Con suerte, a medida que las personas pasen una o dos versiones trabajando juntas, aprenderán lo que piensa la otra persona y cómo trabajan, para que sean más compatibles para trabajar en el mismo código al mismo tiempo. Pero hasta que eso suceda, si solo incluye a las personas en un proyecto, no será más que frustración (de nuevo, solo mi opinión).

Algunos de mis pensamientos se basan en cómo empecé profesionalmente en el software. Cuando era una cooperativa, trabajaba con un tipo que era mi mentor. Me enseñó todo, desde la ética de codificación hasta el buen diseño y la lectura de miles y miles de líneas de código que no escribiste. Al principio no estábamos cerca del mismo nivel y sería ridículo que nos coloquen en un equipo ágil y nos digan que podemos trabajar en el código de los demás. Pero con el tiempo (pocos años), comenzamos a pensar muy parecidos. Pude entender su código con una simple mirada y él me dijo varias veces que no tenía absolutamente ningún problema (y se sorprendió por eso) al navegar mi código que nunca había visto antes. Esto tomó años, no algo que sucedió durante la noche. Después de experimentar desastre tras desastre en un entorno ágil en los últimos años,

Esto no es realmente una respuesta, pero resume mi experiencia / observaciones. Quiero ver lo que otros dirían sobre esto.

¿Qué es ágil?

Lo es:

• un conjunto de reglas que debes seguir para lograr lo que pretendían los que establecen las reglas?

• ¿Cuál es el mejor método para hacer las cosas dentro de sus fortalezas, requisitos y limitaciones particulares?

Si crees que Agile es el primero, y siempre sigues todas y cada una de las reglas de Scrum y te preocupas constantemente si lo estás haciendo bien o no, quizás este enlace te ilumine un poco.

Si crees que se trata más de lo segundo, entonces felicidades: 'obtienes' Agile. Cualquier metodología ágil solo puede ser una sugerencia de cómo hacer las cosas. Si algún aspecto de su método ágil elegido no le parece adecuado, entonces tiene el deber de dejar de usarlo, cambiarlo o ser ágilal respecto Lo importante es que logre algo, que no se vea limitado por restricciones artificiales, no solo las que todos conocemos y amamos de nuestros viejos días de cascada donde el PM lo molestaría por diagramas documentados completos que nadie jamás lee solo porque "eso es lo que el proceso dice hacer", pero también por las restricciones de lo que sea que estés usando. Si un scrum diario se siente como una restricción, ¡no parpadee! Tenerlos a ciegas porque las reglas lo dicen no es más ágil que las viejas formas.

Ahora, si tienes algunos tipos que hacen las cosas encerrados en una habitación con solo un galón de cola y una escotilla para pizza, entonces utiliza ese hecho. Déles una parte del sistema que sea en su mayoría autónoma y enciérrelos. Cuando terminen, debe hacer que integren ese trabajo (o que alguien más lo haga si lo prefieren) con el resto del sistema.

Alistair Cockburn describió esto en sus métodos. Si tienes "practicantes de nivel 3", entonces un método ágil perfectamente válido es el siguiente:

“Ponga a 4-6 personas en una sala con estaciones de trabajo y pizarras blancas y acceso a los usuarios. Haga que entreguen software probado y en ejecución a los usuarios cada uno o dos meses, y de lo contrario déjenlos en paz ".

Como tiene una mezcla de personas, necesita encontrar una manera de hacer que trabajen juntas de manera constructiva, y eso significa que un enfoque de talla única para todos probablemente no será muy eficiente. Por lo tanto, debe dividir las tareas, asegurando al mismo tiempo que se enfatice el objetivo común. Está bien enviar a esos tipos al código, pero tienen que ser conscientes de cómo sus cosas serán una parte integral del resto del trabajo del equipo y que no lograrlo es un fracaso de lo que sea que estén produciendo. . Una vez que entienden eso (es decir, no pueden simplemente hacer lo que quieran y entregar algo inutilizable), entonces su trabajo está hecho.

Digamos que ágil no es para todos y ágil no es para todos los proyectos. Al mismo tiempo, ágil es un término muy amplio y Scrum es solo una implementación de un proceso ágil: de alguna manera puedo decir que la implementación probablemente tenga la mayor cantidad de restricciones que intenta establecer un proceso estandarizado con pasos bien conocidos.

Otra área para pensar es ¿cuál es el propósito de ágil? ¿Es ágil sobre la forma en que trabajan los desarrolladores? Quizás, algunas metodologías realmente van en esa dirección. Pero ágil en sí mismo cubre áreas fuera del desarrollo. Agile se trata más de impulsar todo el proceso, la forma en que funciona una interacción, la forma en que entrega el producto de trabajo con las características más importantes a tiempo y la forma en que controla los recursos, cómo ve en qué parte del proyecto se encuentra actualmente, etc.

Hay metodologías que no intentan cambiar nada de su proceso de desarrollo: Scrum no es el indicado. Todas las metodologías ágiles enfatizan la mejora continua. Detectará algún paso ineficiente en su proceso e intentará mejorarlo / cambiarlo, esa es la forma ágil. Verifique otra metodología ágil popular: Kanban.

Usted / su compañía ha decidido usar Scrum y puede llevar a que algunas personas no les guste y se vayan. Debe tratar con cada uno de sus desarrolladores por separado. Debes hablar de eso con cada uno y tratar de encontrar algunos intereses que les permitan disfrutar nuevamente del trabajo.

Pueden tener el papel de mentores, pueden enseñar a otros, mostrarles cómo refactorizar el código para mejorar la arquitectura cuando se trabaja de forma iterativa. Pueden formar juntos el uso de planos de arquitectura global en todos los proyectos. También pueden trabajar en la prueba de conceptos, participar en RFI (solicitud de información) cuando los clientes hacen consultas para pensar en la viabilidad de los requisitos. Pueden trabajar en parejas con desarrolladores menos calificados y hacer juntos la tarea compleja, etc. Su principal valor debe ser el uso de sus habilidades y permitir que otros aprendan de ellas.

Scrum y ágil a nivel mundial de hecho de alguna manera mantienen a los individuos bajos y priorizan a los equipos: los equipos entregan aplicaciones, no individuos. Esta idea se basa en el hecho de que nunca tendrá un equipo donde todos tengan el mismo conjunto de habilidades y experiencia.

Si su transición a Scrum será exitosa, deberían ver que el proceso general ha mejorado, los tiempos de entrega se han reducido, la calidad ha mejorado y los clientes están más satisfechos. Todavía pueden creer que las aplicaciones desarrolladas son mucho peores de lo que podrían ser, pero ese es el punto: el cliente no quiere el mejor código jamás escrito. Los clientes quieren el código de trabajo mínimo / más barato / más rápido desarrollado que satisfaga sus requisitos. Si la fuerza bruta es suficiente para eso, entonces que así sea. Esto es algo que puede causar problemas a los desarrolladores altamente calificados, pero no es una falla de ágil, es el lugar donde las demandas comerciales y el perfeccionismo van uno contra el otro.

Beneficiará a todo el equipo si toma algunos de los principales problemas y se los entrega a un gran desarrollador. Todos pueden ponerse al día después y aprender algo en el proceso. Simplemente no cree una aplicación completa de esta manera.

No diluye el código al mínimo común denominador. Usted logra ponerse al día con los mejores desarrolladores.

Se ha discutido mucho sobre lo que es o no es "ágil" y muchos sentimientos personales, experiencias y dudas sobre el proceso ágil compartido aquí, pero realmente no he visto una respuesta real a la pregunta. La pregunta original era cómo mantener motivados a sus principales desarrolladores cuando ven su código que han escrito a nivel de arte puro, e invierten su sudor y sangre, hackeados por otra persona y "corrompidos". Tenga en cuenta que, ágil o no, esto va a suceder en algún momento, ahora es más visible porque todavía están trabajando en el código al mismo tiempo que otros, en lugar de que haya una transferencia típica que admitir, en ese momento simplemente no verían esos cambios realizados.

Lo que vería como la clave aquí es expandir la responsabilidad de estos desarrolladores y ayudarlos a cambiar su enfoque a una imagen más amplia. Tal vez eso signifique un nuevo título, como Arquitecto de software, Jefe de equipo o Ingeniero de software sénior. Luego muéstreles que esta es una oportunidad para tener un mayor impacto, no solo en un solo proyecto a la vez, sino en múltiples proyectos. El sentido de propiedad todavía puede estar allí, pero su enfoque ya no debería estar en entregar un solo gran proyecto, sino en ayudar a establecer el estándar para TODOSproyectos Ayúdelos a comprender su fuerte deseo de construir algo grandioso, pero cambie el enfoque para desarrollar las prácticas de ingeniería de software de su empresa y los otros desarrolladores. En lugar de encogerse ante la idea de que sus compañeros de trabajo rompan su código en pedazos, esta puede ser una oportunidad para que pasen al siguiente nivel y guíen a sus compañeros de equipo y los lleven a su nivel.

Trataré de ilustrar algunos aspectos que no han sido abordados por otras respuestas y que, en mi opinión, son importantes.

El problema básico es este: algunos desarrolladores están motivados principalmente por la alegría de realizar un trabajo difícil, pensar en un diseño, pensar en problemas potenciales y luego resolver el problema pieza por pieza, con una interacción mínima con otros, durante un período prolongado período de tiempo. Generalmente completan el trabajo a un alto nivel de calidad y de manera oportuna; su trabajo es mantenible y se ajusta a la arquitectura general.

Este tipo de desarrolladores puede tener dificultades para adaptarse a un entorno ágil y su actitud a menudo se descarta como "falta de voluntad para cambiar", posiblemente relacionada con el ego o con el pasado de moda.

Lo que a menudo se ignora es que, para resolver problemas complejos, se necesita manejar mucha información, y esto puede requerir mucho análisis, pensar, intentar, esbozar una solución, desecharla, probar otra. Un problema tan complejo puede requerir de unas pocas horas a unas pocas semanas de trabajo enfocado hasta que tenga una solución final.

Un enfoque es que un desarrollador toma la especificación del problema, va a su habitación y regresa dos o tres semanas después con una solución. En cualquier momento (cuando sea necesario), el desarrollador puede iniciar alguna interacción con otros miembros del equipo o con las partes interesadas (haciendo preguntas sobre temas específicos), pero la mayoría del trabajo lo realiza el desarrollador al que se le asigna la tarea.

¿Qué sucede en un escenario ágil? El equipo divide el problema en pequeños fragmentos (historias de usuarios) después de un análisis rápido (preparación). La esperanza es que las historias de los usuarios sean independientes entre sí, pero a menudo este no es el caso: para dividir un problema complejo en fragmentos realmente independientes, necesitaría un conocimiento que normalmente solo obtiene después de trabajar en él durante varios días. En otras palabras, si puede dividir un problema complejo en pequeñas partes independientes, significa que básicamente ya lo ha resuelto y que solo le queda trabajo de diligencia. Para un problema que requiere, digamos, tres semanas de trabajo, este probablemente será el caso durante la segunda semana, no después de un par de horas de preparación al comienzo del sprint.

Entonces, después de planear un sprint, el equipo trabaja en diferentes partes de un problema que probablemente tengan dependencias entre sí. Esto genera una gran sobrecarga de comunicación al tratar de integrar diferentes soluciones que pueden ser igualmente buenas pero que, bueno, son diferentes entre sí. Básicamente, el trabajo de prueba y error se distribuye entre todos los miembros del equipo involucrados, con una sobrecarga de comunicación adicional (que aumenta de forma cuadrática). Creo que algunos de estos problemas se ilustran muy bien en este artículo de Paul Graham, en particular el punto 7.

Por supuesto, compartir el trabajo entre los miembros del equipo reduce el riesgo relacionado con que un miembro del equipo abandone el proyecto. Por otro lado, el conocimiento sobre el código se puede comunicar de otras maneras, por ejemplo, utilizando revisiones de código o dando presentaciones técnicas a los colegas. A este respecto, no creo que haya una bala de plata válida para todas las situaciones: la propiedad de código compartido y la programación de pares no son la única opción.

Además, la "entrega de la funcionalidad de trabajo en intervalos más cortos" da como resultado una interrupción del flujo de trabajo. Esto puede estar bien si la porción de funcionalidad es "agregar un botón de cancelación en la página de inicio de sesión" que puede completarse al final de un sprint, pero cuando está trabajando en una tarea compleja no desea tales interrupciones: es como tratando de conducir un automóvil 100 km lo más rápido que pueda y deteniéndose cada 5 minutos para verificar qué tan lejos ha llegado. Esto solo te va a retrasar.

Por supuesto, tener puntos de control frecuentes tiene como objetivo hacer que un proyecto sea más predecible, pero en algunos casos la interrupción puede ser muy frustrante: uno apenas puede ganar velocidad y ya es hora de detenerse y presentar algo.

Por lo tanto, no creo que la actitud descrita en la pregunta esté relacionada solo con el ego o la resistencia al cambio. También puede ser que algunos desarrolladores consideren que el enfoque para la resolución de problemas descrito anteriormente sea más efectivo porque les permite comprender mejor los problemas que están resolviendo y el código que están escribiendo. Obligar a dichos desarrolladores a trabajar de manera diferente puede reducir su productividad.

Además, no creo que algunos miembros del equipo trabajen de forma aislada en problemas específicos y difíciles va en contra de los valores ágiles. Después de todo, los equipos deben ser autoorganizados y utilizar el proceso que han encontrado como el más efectivo a lo largo de los años.

Solo mis 2 centavos.

Some developers are primarily motivated by the joy of taking a piece of difficult 
work, thinking through a design, thinking through potential issues, then solving
the problem piece by piece, with only minimal interaction with others, over an 
extended period of time

Parece que son "Lone Rangers". En el Scrum canónico, estas personas simplemente no pueden encajar en el Equipo (se pierden el bit de "interacción").

Si no son "Lone Rangers", entonces hay esperanza. Si está haciendo Scrum correctamente, deben ser parte del diseño de la función en la que estarán trabajando (durante la planificación de Sprint). Este es el único momento en que necesitan interactuar con otros. Incluso puede "asignarles" todas las historias relacionadas con esa característica.

Durante el Sprint, solo serán "molestados" por el Scrum diario ... hasta que puedas demostrarles (por acciones, no por palabras) que solo serán 15 minutos de su tiempo, y solo para garantizar que todo esté funcionando suavemente. Manténgase cerca de las tres preguntas y la mayoría de las personas dejarán de cumplir.

En nuestro equipo, tenemos un grupo especial solo para mejorar el rendimiento. No los vemos mucho, solo al comienzo del sprint para hablar sobre los cambios a realizar, y al final en la retrospectiva. Tienen su propio "líder scrum" que informa al equipo Scrum of Scrum. Puedo decirte que se están divirtiendo.

Si Joe (su desarrollador de Hero) es un poco flexible, entonces no veo ningún problema:

Como se dijo anteriormente, deje que el equipo se autoorganice: si algunos problemas se resuelven mejor dejando que Joe lo muerda solo, entonces esperaría que un equipo de autoorganización de mente abierta llegue a esa conclusión por su cuenta.

Los únicos desafíos que quedan dentro de las pocas restricciones que impone Scrum:

1. Entregando funcionalidad a intervalos regulares: si deja que Joe analice un problema durante meses, sin nada que mostrar hasta el final, entonces Joe no es ágil: está tomando al dueño del producto como rehén y no le da la oportunidad de volver a especificar esa parte del producto. Con esta práctica también existe el riesgo de que llegue tarde y nadie se dé cuenta. (Pero de acuerdo con su descripción, eso no es tan probable). Remedio: ¿Sería demasiado pedirle a Joe que se sentara junto con la OP, separe la historia del usuario y acuerde entregas intermedias, preferiblemente (pero no necesariamente) con el valor del usuario?

2. Honrar las prioridades establecidas por el propietario del producto: si los códigos son propiedad de expertos, entonces corre el riesgo de una situación en la que la evolución del producto está determinada por la disponibilidad de cada experto, en lugar de las prioridades comerciales: el resto del equipo podría estar trabajando en funciones menos importantes, mientras que las 3 funciones principales se estancan porque "solo Joe puede hacerlo". Eso es malo. En ese momento, el equipo debería (temporalmente) cambiar su hábito y dividir el trabajo de Joe entre más miembros del equipo.

En resumen: si Joe, el héroe desarrollador, está de acuerdo con el PO en cómo mostrará el progreso en cada sprint, entonces el equipo puede asignarle ciertas historias y dejarlo solo. Pero si PO tiene demasiado trabajo para Joe, y no lo suficiente para el equipo (o viceversa), entonces Joe y el equipo tienen que adaptarse, no el PO.

Las reglas para un equipo ágil deben personalizarse para adaptarse al equipo; esto puede ser una personalización realmente personal; Por ejemplo, trabajé en un equipo donde la regla era:

Todo el Código debe estar escrito por un par, excepto que David puede escribir el código solo.

David era un desarrollador / arquitecto senior, que trabajó principalmente en herramientas que otros usarían en su propio código. Era el dueño del código que escribió. Era mantenible y probado, y todos en el equipo sabían que él probablemente era el mejor programador allí, y que el equipo se beneficiaría mejor al permitirle construir ciertas piezas del marco y presentarlas como completas al equipo.

No tengo una respuesta para los introvertidos de variedades de jardín, pero para introvertidos excepcionales, el equipo tomará diferentes reglas para obtener el beneficio.