5. Director general, Apress Media LLC: Welmoed Spahr Editor de
adquisiciones: Shiva Ramachandran Editor de desarrollo: Laura
Berendson Editor coordinador: Rita Fernando
Cubierta diseñada por eStudioCalamar
Distribuido al comercio de libros en todo el mundo por Springer Science + Business Media New York,
233 Spring Street, 6th Floor, Nueva York, NY 10013. Teléfono 1-800-SPRINGER, fax (201) 348-4505, correo
electrónico orders-ny@springer-sbm.com , o visite www.springeronline.com . Apress Media, LLC
es una LLC de California y el único miembro (propietario) es Springer Science + Business Media Finance Inc
(SSBM Finance Inc). SSBM Finance Inc es una corporación de Delaware .
Para obtener información sobre traducciones, envı́e un correo electrónico rights@apress.com , o visite
www. apress .com / derechos-permisos.
Los tı́tulos de Apress se pueden comprar a granel para uso académico, corporativo o promocional. Versiones de
libros electrónicos y licencias también están disponibles para la mayorı́a de los tı́tulos. Para obtener más
información, consulte nuestra página web de ventas a granel de impresos y libros electrónicos en
www.apress.com/bulk-sales .
Cualquier código fuente u otro material complementario al que haga referencia el autor en este libro está
disponible para los lectores en GitHub a través de la página de productos del libro, que se encuentra en www.
apress com / 9781484236901. Para obtener información más detallada, visite www. apress .com /
codigo fuente.
Impreso en papel libre de ácido.
Contenido
Sobre el autor .............................................. v
Agradecimientos ............................................ vii
Introducción................................................. ix
Capítulo I: De cascada a ágil .............................. I
Capítulo 2: Visión general de las metodologías ágiles ...................... 7
Capítulo 3: Agile Scrum Deep Dive ............................. 15
Capítulo 4: Scrum Master: de qué se trata ................... 31
Capítulo 5: Dinámica del equipo ................................... 39
Capítulo 6: Conclusiones clave .................................... 51
6. 75
Apéndice A: Estudios de caso .................................... 53
Índice
Sobre el Autor
Ilya Bibik es un Scrum Master con experiencia con más de 16 años de
experiencia en la industria del desarrollo de software, incluidos siete años
en el rol de Scrum Master. Él tiene una maestría en comercio electrónico
y una licenciatura en ingeniería de software, y un diploma de enseñanza.
Su experiencia profesional incluye desarrollo de software, gestión de
proyectos de software, gestión de calidad de software, seguridad de
software, ventas de software, enseñanza escolar y experiencia militar con
tecnologías electroópticas.
Durante su carrera en la industria del software, Ilya ha utilizado metodologías de desarrollo de
software como Scrum, Kanban y Waterfall. Ha trabajado en proyectos de software en las áreas de
venta minorista, venta al por mayor, moda, e-com-merce, e-learning, fabricación, ISO-9000 y
administración de propiedades de alquiler. Para obtener contenido adicional del autor sobre la
metodología de Scrum y contactar a Ilya, visite http://scrumyes.com/ .
Expresiones de gratitud
Este libro está dedicado a mis padres, Yaara y Victor; ya mi hermana Anna, a quien se
lo debo todo; y para mis hijos, Basil, Michael y Evan, ¡a quienes tengo la suerte de
tener cerca y verlos crecer!
Quiero agradecer a todas las personas que me ayudaron. Primero, gracias a mi gran
esposa, Marianna Levant, por su apoyo a la idea y la edición y comentarios originales
cuando escribí mi primer borrador durante mi viaje en tren.
Gracias a mi gerente, Camille El Gammal, y a mi colega, Scrum Master Parinaz
Barakhshan, que revisaron la primera versión y me dieron sus comentarios y
comentarios de apoyo sobre el libro.
Y estoy agradecido de haber trabajado con el equipo de Apress: el editor de
adquisiciones Shiva Ramachandran. Quien me dio la oportunidad de publicar con
7. Apress; la editora coordinadora Rita Fernando Kim, quien hizo las cosas rápidas y
simples; y la editora de desarrollo, Laura Berendson.
También quiero agradecer a todas las personas con las que trabajé en SAP Labs
Canada en la ubicación de Montreal que me toleraron durante casi dos años y me
permitieron adquirir experiencia en diferentes temas.
Introducción
Después de trabajar siete años como Scrum Master, decidí crear un libro
programático, conciso y fácil de usar que cubra lo que sea necesario. Este libro es una
guía práctica y pragmática para la implementación de la metodología Scrum en el
equipo, no solo la teoría, sino los problemas de la vida real de trabajar con personas
reales en lugar de con los equipos ideales imaginarios que no existen. El libro se
centra en el rol de Scrum Master porque es clave para una implementación exitosa de
la metodología Scrum.
El público objetivo de este libro es cualquiera que sea nuevo en el tema y esté
interesado en comprender de qué se trata la metodología Scrum. El libro también será
de utilidad para cualquier persona que busque formas de matar al monstruo Scrum
existente si está luchando por adoptar Scrum en su organización. Además, este libro
ayudará a comprender mejor la importancia y los desafíos de los roles de Scrum
Master.
Hay otras metodologías ágiles en el mercado y menciono algunas de ellas en este
libro (Kanban, Scrumban, eXtreme programación) en el contexto de Scrum.
Mi objetivo es responder a las siguientes preguntas:
• ¿Qué es ágil? (de Manifiesto de Waterfall a Agile y cómo Agile
puede convertirse en un problema en lugar de una solución)
• ¿Qué es la metodología Scrum y cómo se relaciona con eXtreme
y Kanban?
• ¿Cuáles son los desafíos de Scrum Master?
• ¿Cuáles son las etapas de desarrollo del equipo?
• ¿Qué métodos existen para manejar los conflictos en el equipo?
CAPÍTULO
8. De la cascada al ágil
Antes de que Agile entrara en escena, la metodología más común de desarrollo de
software era Waterfall. Waterfall es un modelo en el que el proyecto se planifica y
ejecuta dentro de un período de tiempo que se requiere para lograr el objetivo final.
Eso significa que, cuando estamos hablando de grandes proyectos que normalmente
tardan unos años en completarse, es posible que solo podamos ver resultados en
unos pocos años.
Por lo general, la cascada se traduce en dividir el proyecto en fases según el tipo de
trabajo: capturar los requisitos, diseñar la arquitectura, desarrollar el software y,
finalmente, probar y desplegar (Figura I -1).
10. James Grenning Jim Highsmith Andrew Hunt Ron Jeffries Jon Kern Brian Marick
Figura 1-2. Waterfall vs. Agile (Fuente: The Standish Group 2015 Chaos Report)
Desde este entorno arcaico, 17 veteranos de software experimentados y cansados crearon el Manifiesto Ágil
y cambiaron totalmente el juego. Antes de que se adoptara el Manifiesto Agile, el proceso de desarrollo de
software no era demasiado flexible y era muy largo; sin embargo, después de la introducción del concepto
Agile, el proceso de desarrollo se hizo más rápido, más flexible y capaz de adaptarse a la realidad en
constante cambio.
El Manifiesto Agile que se publicó en 2001 es solo un conjunto de 12 principios y valores, en lugar de
metodologías reales o un marco.
Lo he reproducido aquí en su totalidad porque muchas personas que lo promueven, consultan sobre el tema
o afirman que están siguiendo los principios nunca lo han leído, o si lo han leído, pueden no entenderlo.
Conclusión: antes de continuar leyendo este libro o familiarizarse con Agile o con cualquier metodología
Agile, lea el manifiesto por completo e inspírese. Si cree que ya está siguiendo la metodología Agile pero
este manifiesto no se alinea con sus métodos actuales, solo podría significar una cosa: en realidad no está
siguiendo los principios Agile.
MANIFIESTO PARA EL DESARROLLO DE SOFTWARE ÁGIL
1
Estamos descubriendo mejores formas de desarrollar software haciéndolo y ayudando a otros a hacerlo. A través de este trabajo
hemos llegado a valorar:
Individuos e interacciones sobre procesos y herramientas.
So ware de trabajo sobre documentación completa. Colaboración del cliente sobre negociación de contrato. Respuesta a
cambio sobre seguir un plan.
Es decir, mientras hay valor en los elementos de la derecha, valoramos más los elementos de la izquierda.
Kent Beck Mike Beedle Arie van Bennekum Alistair Cockburn Ward Cunningham Martin Fowler
13. No significa que las personas que promueven alguna metodología Agile particular de cierta manera tengan
malas intenciones. Sin embargo, significa que repetir algunos rituales exitosos de un equipo a otro no
necesariamente traerá el resultado deseado.
A modo de ilustración: durante la Segunda Guerra Mundial, algunas islas melanesias se convirtieron en bases
para las fuerzas japonesas y, más tarde, aliadas. Los locales fueron expuestos a los aviones y la civilización
occidental por primera vez. Los militares compartieron sus suministros de alimentos y otros artículos con los
lugareños, y los isleños se acostumbraron a los productos occidentales. Después de la guerra, las tropas
abandonaron las bases y las islas fueron olvidadas.
Años más tarde, las expediciones de investigación visitaron las islas y vieron que los lugareños imitaban
rituales militares y habían construido pistas e ídolos de aviones de madera. Los lugareños esperaban que si
realizaban la rutina que había estado allí durante la presencia de militares en las islas, los aviones regresarían
y les traerían carga. Este fenómeno ha sido nombrado un culto de carga.
El seguimiento religioso de algunos métodos ágiles que funcionaron para algunos equipos en cierto punto
también es una forma de culto de carga.
Se espera que si todos los rituales y terminologías de las sagradas metodologías ágiles se respetan
religiosamente (sin comprender necesariamente el razonamiento detrás de ellos), sucederá el milagro de la
productividad y el éxito.
Desafortunadamente, en la mayoría de las situaciones, no es así y lo contrario podría ser un resultado
probable.
Antes de experimentar o discutir cualquier método sofisticado de las metodologías ágiles, los tomadores de
decisiones y el equipo deben familiarizarse con la mayoría de los principios básicos de Agile del Manifiesto.
Y solo después de eso, el equipo puede comenzar a explorar las técnicas populares de Agile y decidir si
tienen algún valor real para resolver los problemas que encuentran.
CAPÍTULO
Resumen de Agile
15. extremo
Programación
Figura 2-1. Pasando de lo prescriptivo a lo más adaptativo.
Echemos un vistazo más detallado a cada metodología mencionada.
Programación extrema
XP es la más prescriptiva (específica) de las metodologías ágiles, para las cuales el enfoque principal es la
prescripción de procesos de ingeniería .
Por lo general, XP funciona en ciclos cortos de desarrollo de una semana, por lo que los cambios solicitados
por el cliente pueden incorporarse con frecuencia. Todo el equipo funciona como uno sin tener roles
definidos, y el cliente se convierte en parte del equipo.
XP prescribe muchas prácticas básicas, que incluyen desarrollo guiado por pruebas, pruebas de clientes,
integración continua, iteraciones cortas, pequeñas versiones, programación en pares, juego de planificación,
diseño simple, refactorización, propiedad de código colectivo, estándares de codificación, metáfora, ritmo
sostenible, trabajo con clientes estrechamente en el sitio con el equipo, y prueba de aceptación del cliente
en cada versión.
Eventualmente, todo debería traducirse a una alta calidad del código producido. A pesar de las afirmaciones
de que XP es más productivo en los recursos orientados a XP, el desarrollo puede ser más lento que otras
metodologías. Creo que solo puede ser más productivo en algunos casos específicos.
La principal diferencia con Scrum: encuentro que XP se basa más en las metodologías de desarrollo de
código que en las dinámicas y los procesos del equipo dentro del equipo. XP tiene un marco menos flexible
que Scrum. Scrum puede adoptar prácticas de XP y básicamente hacer lo mismo que XP, pero cuando es
16. necesario, Scrum es lo suficientemente flexible como para cambiar a una metodología menos prescriptiva
como Kanban. Scrum se centra más en la productividad, mientras que XP se centra en la ingeniería.
Si desea que su equipo utilice la metodología de XP eventualmente, Scrum puede ser un paso intermedio; el
equipo puede comenzar a utilizar Scrum y adoptar gradualmente las mejores prácticas de XP.
Riesgos y mi gaciones
Riesgo de pérdida de capacidad: algunos de los procesos de ingeniería prescriptiva aplicados a XP pueden
aportar muy poco o ningún valor.
Mitigación: en los casos en que la calidad no es un proceso crítico para la vida, la metodología Scrum puede
ser una metodología más adecuada.
Riesgo de falta de disponibilidad de los clientes: dado que los clientes no siempre pueden
comprometerse a formar parte del equipo, puede convertirse en un problema para la metodología XP.
Mitigación: confíe más en la metodología Scrum, donde el Propietario del producto (PO) puede sustituir la
falta de compromiso del cliente, hasta cierto punto.
Kanban
Kanban fue inventado por Toyota en la década de 1940 para reducir el tiempo de inactividad durante la
fabricación. En el mundo del software, básicamente se ejecuta el trabajo como viene y se usa un tablero con
notas para rastrear el progreso y los cuellos de botella.
Kanban tiene que ver con la visualización del proceso, por lo que la expresión "una imagen vale más que mil
palabras" realmente describe el proceso Kanban con mucha precisión (Figura 2-2).
Nuevo
Análisis en proceso
Análisis
Hecho Desarrollo en proceso
Desarrollo
Hecho
Prueba Desplegar
; Característica 1 (Bob)
Característica 2 (Bob)
Característica 3 (Alicia)
Característica 4 (Yevgen)
Característica 5
17. Característica 6
Característica 7
Figura 2-2. Ejemplo de tabla kanban
El trabajo no tiene que realizarse en iteraciones en Kanban, y este proceso es muy adecuado para actividades
de soporte o, en algunos casos, para soluciones basadas en la nube de SaaS.
Los roles en el equipo no están necesariamente definidos: todos hacen todo.
Kanban se concentra principalmente en el proceso de trabajo. Puede ser una buena práctica tener algunos
elementos de la metodología Scrum, como una reunión diaria de Scrum si es necesario. La principal
fortaleza de Kanban es una visualización del proceso de trabajo que ayuda al equipo a identificar cuellos
de botella u oportunidades para reducir el tiempo de inactividad. Por ejemplo, en lugar de continuar
con el desarrollo, todos los miembros del equipo comenzarán a realizar pruebas si ven que la cantidad de
tareas de prueba se acumula.
En la superficie, el tablero Kanban puede parecer un tablero de tareas regular, con una diferencia: en Kanban,
la cantidad de elementos que pueden estar en progreso en un momento dado se limita estrictamente a una
o dos tareas que cada miembro del equipo puede procesar en paralelo.
A pesar de que el tablero es el centro de la metodología Kanban, también puede ejecutarse sin el tablero
físico real. Cuando todos los miembros del equipo operan de forma remota, se pueden usar herramientas
como Trello . O en algunos otros casos, simplemente asignando incidentes a los miembros del equipo, se
logra el mismo objetivo sin la necesidad de tener un tablero físico o virtual.
Kanban es realmente fácil de implementar en el equipo; El proceso es muy simple. Entonces, aunque este
libro trata sobre la metodología Scrum, siempre debe considerar Kanban como una posible solución para
sus necesidades en ciertas situaciones. Por ejemplo, durante la fase de mantenimiento o prueba, tiene más
sentido usar Kanban que tener una sobrecarga con la metodología Scrum.
Riesgos y mi gaciones
Riesgo de perder el panorama general: Kanban toma cada tarea por separado y, como resultado, a
menudo el diseño, el desarrollo y la prueba se basan en la granularidad de esta tarea. El inconveniente es
que un miembro individual del equipo puede tener éxito en el desarrollo de esta función de una sola tarea,
pero fracasará en el panorama general de cómo se unirán todas las funciones.
Mitigación: en caso de un nuevo desarrollo complejo, confíe más en la metodología Scrum que en Kanban.
Riesgo de falta de responsabilidad: debido a la falta de roles, no hay responsabilidad individual para las
diferentes partes del proceso de desarrollo, lo que puede resultar en el incumplimiento de las necesidades
del cliente y los problemas de calidad .
18. Mitigación: en caso de un nuevo desarrollo complejo, confíe más en la metodología Scrum que en Kanban, o
al menos tenga algunos roles responsables.
Melé
Scrum es una de las metodologías ágiles más populares, si no la más popular. Similar a XP, tiene
lanzamientos cortos. Esas iteraciones se llaman sprints. Tiene roles en el equipo como Scrum Master (a cargo
del proceso) y Product Owner (a cargo del producto); También hay otros roles definidos en el equipo.
También incluye reuniones obligatorias: Daily Scrum (reunión stand-up), planificación, revisión, retrospectiva
y preparación de trabajos pendientes.
Discutiremos la metodología Scrum en detalle en capítulos posteriores de este libro.
La principal ventaja de Scrum y la razón por la que abogo por XP y Kanban es que Scrum puede incorporar
lo mejor de ambas palabras de Kanban y XP, según la situación y las necesidades.
Riesgos y mi gaciones
Riesgo de reuniones excesivas: los rituales de reuniones no siempre son relevantes para todos, y pueden
ser desmotivadores e innecesarios.
Mitigación: Scrum Masters requiere habilidades de moderación de reuniones.
Riesgo de cambios durante el Sprint: Los cambios en el alcance durante la ejecución del Sprint pueden
llevar a un Sprint y desperdicio sin éxito, ya que pueden dar lugar a la duplicación de reuniones y
discusiones.
Mitigación: Abrazar el cambio con una actitud positiva; Mejor hacerlo en medio del Sprint luego del Sprint.
Sin embargo, la habilidad de moderación de reuniones de Scrum Master es una necesidad para reducir la
duración de las reuniones tanto como sea posible. También sea claro para resaltar los problemas y ser
transparente con las partes interesadas sobre cómo los cambios afectan la capacidad.
Riesgo de estimación: las estimaciones inexactas pueden llevar a suposiciones erróneas y Sprints fallidos.
Además, la estimación durante las reuniones puede llevar a largas reuniones y desmotivación.
19. Mitigación: habilidad de moderación de reuniones Scrum Master : estimación de alto nivel. Mantener algo de
búfer y comprometerse con menos tareas durante el Sprint, pero tener algunas tareas adicionales en caso de
capacidad adicional.
Híbrido de diferentes metodologías
Se pueden modificar y combinar diferentes metodologías para abordar problemas particulares que deben
resolverse.
Scrumban, por ejemplo, como su nombre indica es una mezcla entre Scrum y Kanban. Desde Scrum, utiliza
los principios de iteraciones para desarrollar nuevas funciones y, por otro lado, Kanban puede usarse para
proporcionar correcciones a las funciones existentes. Combinados, esta metodología puede adaptarse
perfectamente a las necesidades del equipo y ofrece nuevas funciones y brinda soporte a las funciones
existentes.
Sin embargo, el soporte no es el único caso en el que Scrumban puede ser útil.
Muchos proyectos se mueven a la nube como soluciones SaaS. Dado que ejecutar software en la nube y
actualizarlo constantemente en algunos casos puede ser un proceso diferente del desarrollo estándar en el
que lanzamos software de versión a versión, una fusión de las metodologías Scrum y Kanban puede ser una
buena opción. Las características pequeñas se entregarán con Kanban y se seguirá desarrollando una
funcionalidad más compleja en la metodología Scrum.
Otro caso en el que Scrumban puede ser útil es cuando tenemos una escasez de personal. Kanban con
algunos elementos de Scrum puede ser una buena manera de compensar la falta de recursos, ya que no
requiere todos los roles existentes en Scrum.
Una mezcla de Scrum y Kanban no es la única combinación posible. La programación eXtreme también va
bien junto con la metodología Scrum. Podemos usar muchas técnicas de XP prescritas como parte de
Scrum, por ejemplo, integración continua, refactorización y programación de pares.
Apoyarse
Lean no es una metodología ágil, pero como estamos hablando de Agile, es muy probable que haya
escuchado el término Lean y que se esté preguntando cómo se relaciona con Agile. Si bien el manifiesto
Agile se creó originalmente para el desarrollo de software, los conceptos Lean provienen de Lean
manufacturing y fueron adoptados por Mary & Tom Poppendieck para adaptarse al desarrollo de software.
1
20. Esos principios son:
1. Eliminar los residuos
2. Construir calidad en
3. Crear conocimiento
4. Aplazar el compromiso
5. Entrega rápida
6. respetar a las personas
7. Optimizar el todo
Si ya sigue los principios de Agile, es muy probable que reflexione sobre esos principios y los aplique en su
entorno de trabajo de Agile.
Como puede ver, Lean y Agile se superponen en el proceso de desarrollo de software. No son alternativas: si
eres ágil, eres Lean y algunas veces viceversa (Figura 2-3).
Figura 2-3. Lean vs.
' http://www.poppendieck.com/
CAPÍTULO
21. Agile Scrum Deep
Dive
Como mencioné anteriormente, la metodología Scrum es una de las formas más populares, si no la más
popular, de implementar Agile.
Esta metodología fue desarrollada por Ken Schwaber y Jeff Sutherland. La piedra angular de Scrum se
describe en la Guía oficial de Scrum.2
El enfoque Scrum consiste en dividir el proyecto en partes lógicas más pequeñas (mini proyectos) y
ejecutarlas en iteraciones cortas de idealmente de una a tres semanas. Esas iteraciones se llaman Sprints
(Figura 3-1).
Figura 3-1. Iteraciones Scrum (Sprints)
Entonces, en lugar de correr un largo maratón hacia un destino imaginario como hicimos en Waterfall,
dividimos la distancia en Sprints cortos con una línea de meta visible. Cuanto más corta sea la duración del
Sprint, más visible será el acabado y más fácil será planificar y predecir el resultado y decidir a dónde iremos
a continuación.
Es más fácil detectar "errores" cuando el equipo está codificando las cosas incorrectas, asumiendo que
recibimos comentarios regulares del cliente (o su PO de poder) para informarle lo que el equipo entregó
incorrectamente, por ejemplo, debido a los requisitos de software incompletos.
De esta manera logramos muchas ventajas frente al modelo de cascada.
A - Mejora continua: ya que ejecutamos un ciclo completo de software en cada iteración de diseño-
desarrollo-prueba, mejoramos de iteración a iteración.
22. B - Transparencia: obtenemos muchos puntos de revisión que nos permiten ver el resultado final, ya que el
objetivo de cada Sprint es producir un código funcional completo que podamos demostrar, revisar e
implementar idealmente para el cliente al final de cada Sprint. (Con la cascada clásica, incluso si
establecemos puntos de control, generalmente nos permiten ver dónde estamos con respecto al plan
maestro original, que podría quedar desactualizado)
C - Adopción temprana: como se mencionó en el punto B. Podemos entregar al final de cada Sprint incluso si
no se han completado. Hace posible la pronta adopción.
D - Abrazar el cambio: dado que el desarrollo del software se divide en partes, después de cada parte
tenemos la oportunidad de reflexionar y alinear si vamos en la dirección correcta y tenemos la oportunidad
de hacer cambios.
El Equipo Scrum
La metodología Agile Scrum implica un equipo autocontenido y autogestionado. Por lo general, hablamos
de equipos de diez que incluirán los siguientes roles. Desarrolladores, Scrum Master, Propietario del
producto, Arquitecto, Ingeniero de calidad y, en algunos casos, Escritor técnico.
La composición del equipo se basa en la naturaleza del trabajo y la situación actual de su organización. Sin
embargo, la parte más importante es que el equipo será autónomo. Para obtener los mejores resultados,
debe adoptar el enfoque de dividir su empresa en subcompañías más pequeñas.
Vamos a discutir todos los roles en el equipo con más detalle (Figura 3-2).
Figura 3-2. Roles de equipo
23. El propietario del producto (PO) recopila los requisitos de los clientes (internos o externos) y produce los
documentos de los requisitos. El PO se alinea constantemente con los clientes y determina el alcance del
trabajo y el cambio en el alcance, por lo que el PO obtendrá los resultados de los Sprints. La OP es
responsable de proporcionar toda la información necesaria relacionada con el producto requerida por el
equipo y de proporcionar los requisitos.
El Scrum Master (ScMa) es el líder servidor del equipo que ayuda al equipo a entregar según los
requisitos. La ScMa organiza el proceso y modera las reuniones que permitirán que el equipo se
desempeñe. Además, la ScMa proporciona estados a la OP o a cualquier parte interesada. La ScMa está a
cargo de la resolución de cualquier bloqueo e impedimentos que enfrenta el equipo. La ScMa protege y
protege al equipo de equipos externos y partes interesadas.
■ Nota El desempeño de los miembros individuales del equipo y otros temas de recursos humanos no son responsabilidad directa de la
ScMa. Hay otro rol de Line Manager que es responsable del desempeño de los miembros individuales del equipo. Line Manager es el
administrador directo de todos los miembros del equipo Scrum.
El Arquitecto (Arc) es el líder técnico del equipo. A menudo, la mayor parte de su tiempo se dedicará a
guiar a otros miembros del equipo, en lugar de tareas individuales. El arquitecto crea / aprueba el diseño,
revisa el código y trabaja en estrecha sincronización con la ScMa y la PO.
■ Nota No todos los equipos de Scrum tienen un Arquitecto; sin embargo, al menos un desarrollador senior en el equipo debe tener
una profunda experiencia en aspectos técnicos del trabajo.
El Gerente de calidad (QM) o el Ingeniero de calidad (QE) es el miembro del equipo responsable de la
gestión de la calidad del producto. El QM organiza el proceso de calidad en el equipo, educa a la OP y ScMa
sobre las mejores prácticas de calidad y proporciona requisitos de calidad al equipo en base a los
comentarios de la OP, los estándares de la industria y las mejores prácticas (incluido el rendimiento, la
seguridad, la facilidad de uso, la accesibilidad, etc.). .).
Los desarrolladores (DEV) estiman y se comprometen con la estimación a base de Sprint. Constantemente
mejoran la precisión de la estimación y se mejoran automáticamente de Sprint a Sprint sin microgestión de
otros roles y gerentes. Los desarrolladores distribuyen entre los diferentes roles expertos, por ejemplo, el
rendimiento, la seguridad y el diseñador de la interfaz de usuario.
Un Escritor Técnico (TW) escribe la documentación de respaldo para el proyecto. Este rol puede ser
centralizado, ya que generalmente no se requiere tener un escritor técnico de tiempo completo en el equipo.
Sin embargo, la documentación técnica también puede ser producida por cualquier otra función en el
equipo como una responsabilidad adicional.
24. Cómo se divide el alcance
Puede haber diferentes convenciones de nomenclatura sobre cómo podemos dividir el alcance del proyecto.
A menudo, cualquier parte ejecutable y priorizada del alcance se denomina trabajos pendientes; sin
embargo, la convención de nomenclatura común en la metodología Scrum es:
Epopeya> ■ Historia de usuario> -Tareas
Cuando:
Epic algo que no tiene que encajar en un Sprint. Se puede desglosar en varias
historias. Epic es cómo los propietarios de productos dividen los requisitos en
grupos lógicos. Se puede ejecutar durante varios Sprints.
Historia: algo accionable y lo suficientemente pequeño como para caber en un
Sprint. Se puede desglosar en varias tareas.
Tareas: partes de una historia que pueden ser completadas por un solo miembro
del equipo. Recomiendo que una tarea no exceda las 18 horas de esfuerzo
planificado.
Por ejemplo:
Agregamos a nuestra sección del sitio web de la agencia de viajes donde los usuarios podrán intercambiar
experiencias de sus viajes. Esta será nuestra epopeya.
Constará de muchas historias.
• Historia 0: Todos los viajes vendidos estarán disponibles en el sitio.
• Historia I : el usuario debe poder crear una reseña para el viaje que ha comprado.
• Historia 2: el administrador del sitio podrá validar la revisión antes de que se
publique.
• Historia 3: el usuario puede obtener me gusta de otros usuarios y tener una
calificación.
25. • Historia 4: el administrador del sitio podrá delegar responsabilidades de moderación a
usuarios con altas calificaciones.
Verá cómo la historia se ha dividido de manera que cada historia se encapsula funcionalmente y se puede
implementar una vez finalizada. Además, cada historia es lo suficientemente pequeña como para ser
completada durante un Sprint.
Y las tareas, por ejemplo, para la historia 0:
• Tarea T. Crear API de viajes donde podamos leer datos del DB de la Agencia (18
horas)
• Tarea 2: crear una página web que muestre todo el contenido de la API de viajes,
con clasificación y paginación (12 horas)
• Tarea 3: Agregar búsqueda por destino, hotel, país, ciudad a la página web de
viajes que creamos (14 horas)
Ciclo de sprint y reuniones
Cada Sprint debe estar dedicado a la ejecución de ciertas historias de usuario.
El equipo se compromete a completar esas historias de usuario de acuerdo con los criterios de Hecho. (Los
criterios de finalización se explicarán más adelante en la sección "Definición de finalización" de este capítulo).
Hay ciertas reuniones que generalmente se realizan durante una iteración de Sprint; por supuesto, una
reunión de Scrum que se ejecuta diariamente y reuniones centrales en un nivel de Sprint: planificación,
revisión, retrospectiva y preparación de trabajos pendientes.
Sprint (N) Planning> - Siguiente Sprint (N + l) Enumeración de pedidos > ■
Revisión de Sprint (N)> ■ Sprint (N) Retrospectiva.
La Figura 3-3 muestra un ejemplo de un ciclo de reunión para un Sprint de dos semanas. Por supuesto, todas
esas reuniones no están escritas en piedra y se pueden ajustar según las necesidades.
26. Figura 3-3. Ejemplo de detalles de la reunión durante el Sprint
Reunión de planificación (obligatoria): el equipo planifica las historias de usuario (trabajos pendientes) que
se ejecutarán durante el Sprint y las divide en tareas. El equipo se compromete a completarlos durante el
Sprint de acuerdo con la Definición de Hecho (DoD).
Preparación del backlog (opcional) durante la ejecución del Sprint N: El PO introducirá nuevos backlogs si
es necesario y esta reunión será una oportunidad para que el equipo haga preguntas sobre los backlogs
para el próximo Sprint (N + I).
Revisión de Sprint (obligatorio): La ScMa y el equipo presentan a la PO todos los atrasos que se cometieron
en este Sprint y el estado de acuerdo con el DoD.
Reunión del equipo retrospectiva (obligatoria): los miembros del equipo discuten qué salió mal, qué salió
bien y si se debe cambiar algo para mejorar el rendimiento del equipo, también se usa como una reunión
para liberar algo de energía. (Se puede ejecutar cada segundo Sprint en caso de Sprints cortos).
Scrum meeting o Stand-up (obligatorio): breve reunión diaria donde los desarrolladores del equipo
responden tres preguntas: ¿Qué se hizo desde la última reunión? ¿Cuáles son los bloques? ¿Qué voy a hacer
a continuación?
A pesar de que algunas reuniones se consideran opcionales y otras obligatorias, trate de comprender la
naturaleza y el propósito de la reunión y para determinar si es necesario utilizar el sentido común para no
generar un desperdicio y tener reuniones (rituales) largas e innecesarias sin valor agregado.
Por ejemplo, si un equipo no pudo realizar la entrega durante el Sprint y todos los trabajos pendientes se
moverán al siguiente Sprint, es posible que la preparación de los trabajos pendientes y la introducción de los
27. trabajos pendientes no sean necesarios. Por otro lado, la retrospectiva podría ser una buena idea para
determinar qué salió mal.
Proceso de planificacion
La reunión de planificación es la reunión más crítica del Sprint. El objetivo principal de la planificación es
averiguar a qué historias de usuario (trabajos pendientes) se comprometerá el equipo durante el Sprint
actual. Si la planificación no se realiza correctamente (por ejemplo, el esfuerzo se subestima), el equipo no
podrá entregar lo que se comprometa o trabajará horas adicionales para completar todos los entregables
del Sprint.
En caso de que se sobrestime el trabajo, el equipo siempre debe tener una lista adicional de trabajos
pendientes en caso de que haya capacidad disponible. Durante la planificación, el equipo no solo calcula,
sino que también divide las historias de los usuarios en tareas más pequeñas. Es posible asignar tareas a
individuos, pero también es posible mantenerlas abiertas para que cualquiera las pueda elegir.
Desglose de tareas debe ser razonablemente detallado. La tarea debe ser una unidad lógica de trabajo.
■ Nota Siempre hay algunas tareas de rutina que deben ejecutarse para diferentes categorías de tareas. Por ejemplo, si desarrolló una
función, desea tener una prueba de unidad para esta función, caso de prueba, automatización, documentación, etc. Entonces, en
algunos casos, para no crear demasiado ruido, en lugar de tener una tarea separada para cada uno Actividad que se pueden agrupar
todos juntos. Cree pre-plantillas que se pueden usar para diferentes tipos de tareas.
Esto simplificará el proceso de planificación y seguimiento durante el Sprint. Será responsabilidad del ejecutor incluir tareas de apoyo en
la estimación.
No tiene que asignar ninguna tarea para el trabajo de rutina del escritor técnico, ScMa, QE, Architect y PO. Hay ciertas tareas rutinarias y
relevantes para el rol que tienen que ejecutar y es responsabilidad de esos roles administrar su tiempo y progreso. Es decir, a menos que
haya algunas tareas adicionales que no sean repetitivas, por ejemplo, la preparación del paisaje para la ScMa, las pruebas para el PO, la
tarea de desarrollo para el QE o una tarea de prueba para el escritor técnico.
No es una buena idea tener reuniones de planificación largas y tediosas donde las personas están aburridas y desconectadas. Hasta
ahora, mi patrón favorito en Sprints de dos semanas es tener 30 minutos a 1 hora de planificación. Esto se puede lograr si las historias
de usuarios tienen propietarios asignados por adelantado, y esos propietarios monitorean esas historias de usuarios y preparan un
desglose de tareas para la reunión de planificación. Esto puede validarse rápidamente con el equipo y asignarse durante la planificación.
(No significa que el propietario de la historia de usuario tenga que ejecutarlo).
Otro proceso para acelerar la planificación es que la ScMa no supervise el tiempo asignado versus la capacidad: cada desarrollador
calcula individualmente su tiempo y se compromete a una cierta cantidad de tareas que pueden ejecutar durante el Sprint.
28. Definición de Hecho
Antes de que el equipo comience a implementar cualquier cosa, tiene que llegar a un cierto acuerdo (DoD)
sobre qué pasos se deben ejecutar para considerar el trabajo realizado. Esto se puede acordar entre la QE,
la OP y otras partes interesadas relevantes. Por supuesto, es un documento vivo y puede ajustarse y
modificarse si así lo acuerdan las partes interesadas. Es importante no inflar demasiado este documento
porque, si hay demasiadas condiciones o el documento es demasiado complejo, no funcionará. Cuanto
menos, mejor.
Por ejemplo, el DoD de uno de mis proyectos recientes se muestra en la Figura 3-4:
• 1ª columna : define cómo se deben considerar las tareas completadas en el nivel Sprint
• 2ª columna: define las tareas que deben completarse para el Sprint anterior. Por
ejemplo, no podemos crear automatización de pruebas antes de completar el
desarrollo, por lo que esta tarea solo se puede ejecutar en el próximo Sprint.
• 3ra columna : es lo que tienes que hacer para liberar todo lo que has desarrollado
durante todos los Sprints en producción.
O Sprint Level En Sprint N + 1 Nivel Nivel de lanzamiento
Pruebas unitarias Documentación
Prueba de integración ejecutada (incidencias resueltas)
Verificaciones de código estático Automatización
Seguridad validada
Caso de prueba de integración creado Casos de prueba estándar del producto ejecutados (incidentes
resueltos)
Retroalimentación de la anterior revisión de Sprint
integradaEjecutar una cita
Aeee ptance test exeeu t ed (incidentes resueltos)Abajo portado
Inspección de código / Programación
de pares
Documento de diseño actualizado
Desarrollo completado
Desarrollo probado
QE probado con OK (ineidentsresolved)
Figura 3-4. Definición de ejemplo de Hecho (DoD)
Tablero
Una placa puede ser una herramienta de software o una placa física con post-its, donde las tareas después
de la planificación se publican y se mueven según el progreso. Una vez más, una tabla es solo una
29. herramienta. El tablero no debe convertirse en un trabajo por sí mismo, es decir, un buen progreso en el
tablero que no siempre se traduce en software de calidad y proyectos exitosos.
La Figura 3-5 muestra un flujo simple de tareas en el tablero.
Reglas del equipo
A veces también tiene sentido tener un cierto conjunto de reglas relacionadas con el gobierno del equipo.
En el caso de hacer reglas de equipo, es importante recordar que cuanto menos es mejor. No trates de tener
reglas para cubrir alguna situación hipotética. Solo los más necesarios deberían estar allí, si acaso,
idealmente menos de diez.
El equipo determina si se requieren las reglas; La ScMa solo identifica la necesidad y modera las discusiones.
Vea una muestra de las reglas del equipo en la Figura 3-6.
Tenemos seis horas en un día en las que podemos planificar el trabajo (estimación).
Nos vigilamos si podemos hacerlo o si no podemos.
Medimos nuestra propia precisión (original vs. estimado) y mejoramos cada Sprint. Supervisamos nuestra
propia capacidad durante la planificación y ejecución de Sprint.
30. Somos verdaderos con nosotros mismos.
Figura 3-6. Ejemplo de reglas de equipo
Bloques e impedimentos
El papel de ScMa es resolver bloques e impedimentos. Por lo tanto, es muy importante que la ScMa sepa
sobre ellos. Además, la ScMa debe estar en el centro de todo lo que va en el equipo y el proyecto; Esto
permite poder resolver diferentes situaciones teniendo la imagen completa.
Para resolver bloques e impedimentos, la ScMa debe contar con los siguientes recursos: sentido común
imparcial, una descripción general de la exposición a los roles en cada aspecto del proyecto, comunicación
con miembros del equipo, una red externa de expertos y conexión con externos a -los interesados del
equipo.
Si la ScMa no puede resolver un bloqueo / impedimento, es importante contar con un proceso de escalado
predefinido.
Por lo general, el proceso de escalado incluye la identificación de algunas partes interesadas internas y
externas al equipo capaces que tienen la capacidad de resolver problemas dentro de la organización. Es
muy importante que la ScMa sea proactiva y evite posibles bloqueos antes de que ocurran.
Velocidad
La velocidad es la palabra mágica que es fundamental para cualquier administrador de proyectos.
Básicamente, la velocidad es la cantidad de trabajo que podemos ejecutar en un determinado período de
tiempo.
Hay diferentes maneras de ver la velocidad, pero ninguna es perfecta. Veamos varias posibilidades y posibles
desafíos para cada uno de ellos.
I. Puntos de historia para medir la velocidad: este es el enfoque más común en Scrum. Los puntos de
historia son estimaciones del esfuerzo asignado a las historias de usuario según la cantidad de trabajo, la
complejidad, la incertidumbre y el riesgo.
31. Finalmente, el equipo aprenderá cuántos puntos de historia puede tomar durante un Sprint y se considerará
como la velocidad del equipo. Para medir la velocidad, se puede usar el promedio de los últimos tres Sprints.
Sin embargo, hay algunos problemas con él:
Para un equipo dominar cómo determinar los puntos de la historia de una manera que tenga sentido puede
ser complicado.
Además, cada equipo usará su propia escala de medición para calcular los puntos de la historia. Como
resultado, a menudo las partes interesadas se confunden y juzgan cuando la velocidad del equipo A es de
2,000 puntos de historia, pero el equipo B es de 50,000 por Sprint, pero en realidad el equipo A es más
productivo.
Además, por lo general, la capacidad se calcula en horas y las partes interesadas operan con PD (días por
persona) y horas, por lo que la conversión entre puntos de historia y horas puede convertirse en un punto
difícil para la ScMa y la OP cuando se requiere para generar informes.
También en los casos en que las tareas en el equipo no son repetitivas, podría ser muy difícil operar con tales
métricas para obtener una velocidad precisa.
2. Velocidad en horas en el nivel de tarea: mida y estime la velocidad por el nivel de horas por tarea y
derive de esta velocidad del equipo en un nivel de Sprint.
Esto también se puede derivar de la adición de las estimaciones de las tareas que se han completado o del
tiempo real que se tomó para ejecutar esas tareas.
Si bien esto puede parecer la forma más precisa de obtener la velocidad, en realidad podría ser lo contrario.
Se proporcionarán muchos gastos generales para la ScMa y una gran cantidad de datos engañosos que se
incluirán en los cálculos.
A menudo, los miembros del equipo se ven afectados por sus compañeros cuando realizan estimaciones de
planificación, y a menudo el tiempo ingresado para la ejecución de las tareas también puede verse afectado
debido a la presión social / entre pares (por esta razón, los puntos de historia pueden proporcionar un
resultado más preciso durante la planificación).
3. Velocidad de alto nivel por expertos: las estimaciones aproximadas de los desarrolladores / arquitectos
principales del equipo de trabajo son capaces de completar en un Sprint. Un desarrollador más
experimentado y capacitado, al observar al equipo como un todo y aprender desde la perspectiva histórica,
es capaz de determinar cuánto se puede lograr durante un Sprint y si el equipo mejora.
Este enfoque es holístico y se basa en un individuo que sabe mejor y no en ninguna medida en particular.
Los problemas con este enfoque son:
• No siempre es posible encontrar una persona tan talentosa en el equipo.
32. • Este individuo se convierte en un cuello de botella para el equipo. El equipo perderá
su estimador de velocidad (punto de referencia) una vez que se haya ido.
• Este enfoque de alimentación con cuchara no contribuye al desarrollo del equipo,
incluso si da buenos resultados en algunos casos.
Herramientas
Existen diferentes herramientas en el mercado para la gestión de proyectos, además de la pizarra con
adhesivos. Por ejemplo: Jira, Trello, proyector de Microsoft, incluso Excel.
Sin embargo, el uso de cualquier herramienta no garantiza el éxito. En el caso de los equipos remotos, el
software de gestión de proyectos puede ser útil, pero con un equipo local, la pizarra puede estar bien.
Use herramientas solo cuando simplifican el proceso y no lo hacen más complejo. Establezca el proceso e
introduzca herramientas más adelante si hay un beneficio claro de ellas.
Para usar algo digital, una simple página wiki con estados y una pizarra con post-its pueden ser suficientes.
Las herramientas de lujo no son algo que impulsa el proceso; ¡Es importante no ser un sirviente de la
herramienta!
A menudo, la ejecución de Scrum se monitorea con un gráfico de reducción, que es básicamente una
visualización de las estimaciones de tiempo de las tareas de Sprint actuales frente a lo que se completó
hasta ahora vs. La Figura 3-7 es una muestra de un gráfico de quemado tomado de la herramienta Jira. En
este gráfico de reducción, la línea azul indica la cantidad de horas dedicadas por los desarrolladores durante
el Sprint y la línea verde indica la reducción de la acumulación. La línea roja es solo un marcador que indica
el progreso ideal de burndown.
105
s & & & ™ s
33. z z z z z z
Figura 3-7. Gráfico de Burndown tomado de la herramienta Jira
Esta quemadura describe un Sprint cuando las estimaciones fueron precisas y todas las tareas se han
ejecutado.
Si las estimaciones son realistas, los datos están actualizados y todos están registrando su tiempo y progreso
con precisión, esta tabla podría agregar valor. Pero hay demasiados ifs ...
Desde mi práctica, no siempre se requiere tener un gráfico de quemado y tiempo de registro. Creo que si el
desarrollador simplemente se compromete con algunas tareas durante un Sprint, es su responsabilidad
entender qué capacidad tiene y si un desarrollador puede hacerlo (no hay microgestión). En este caso, es
responsabilidad del desarrollador resaltar cualquier problema con los compromisos de Sprint.
Importante tener siempre presente
Scrum se basa en iteraciones controladas: Sprints, donde un equipo mejora de iteración a iteración y tendrá
un punto de control al final de cada iteración. Tres factores principales que forman la base del éxito de la
metodología Scrum son: transparencia, inspección y adaptación.
Sin embargo, a pesar de que hemos hablado principalmente sobre los procesos en este capítulo, es
importante reflejar que Scrum es una metodología centrada en el equipo aplicada a equipos
autoorganizados.
Es más exitoso cuando cada miembro del equipo se compromete a lograr el objetivo del Sprint para todo el
equipo.
Se requieren muchas habilidades, personalidades y talentos técnicos y personales diferentes para que el
equipo tenga éxito, y los miembros del equipo Scrum deben respetarse mutuamente para tener un equipo
exitoso.
Scrum es como un vino: debería mejorar con el tiempo, pero si no se hace correctamente, se convertirá en
vinagre.
Los métodos y técnicas de la metodología Agile Scrum están diseñados para respaldar los principios ágiles
de:
• Individuos e interacción sobre procesos y herramientas.
• Software de trabajo sobre documentación completa.
34. • Colaboración del cliente sobre negociación de contrato.
• Responde al cambio sobre el siguiente plan
La metodología es una herramienta que está aquí para ayudar. La creación de hermosas quemaduras y el
uso de las últimas palabras de moda, acrónimos y técnicas no es la meta. El objetivo es ofrecer un software
excelente que el cliente realmente quiere y necesita; En la más alta calidad de la manera más óptima; En el
entorno laboral más motivador, performativo y dinámico. La clave es un equipo autónomo y multifuncional
que mejore de iteración a iteración y que sea divertido ser miembro.
Siguiendo religiosamente diferentes métodos y técnicas no es la meta. Siempre empieza simple. En
http://scrumyes.com/ describo una versión simplificada de la implementación de Agile Scrum para facilitar la
adopción inicial de Scrum.
CAPÍTULO
Scrum Master: de qué se
trata
Scrum Master (ScMa) es un líder servidor que supervisa y mejora los procesos de la Metodología Ágil Scrum.
La ScMa no tiene autoridad como un Gerente de línea que puede contratar y despedir, y con frecuencia
controla la distribución de salarios y bonos. Además, la ScMa no tiene autoridad como el propietario del
producto (PO), quien tiene autoridad y responsabilidad sobre el producto y está dictando al equipo cómo
debe ser el producto.
Entonces, en este contexto, la ScMa realmente no tiene una autoridad definida y se trata de poder blando.
El rol puede ser desafiante y no satisfactorio, ya que en caso de éxito, ScMa casi nunca recibirá ningún
crédito del equipo y, en caso de fracaso, podría ser el primero en ser culpado.
Cuando la OP es responsable del producto, la ScMa no tiene una parte definida de la responsabilidad que no
sea los procesos generales, pero, sin embargo, será responsable de casi todo, ya que los procesos se
36. Scrum Master Admin Work Trap
Si ya ejecutas el rol ScMa y todo lo que haces es mantener las tareas de administración y ocupar tu tiempo
solo con ellas, estás en el lugar equivocado. Las tareas de administración pueden ser muy disruptivas, pero
son solo una pequeña fracción de sus responsabilidades de rol. Su objetivo es entregar software y no
producir gráficos, tablas, sobresalir y organizar reuniones extravagantes utilizando terminología sofisticada.
El exceso administrativo que compensa la sensación de inutilidad de la ScMa es muy perjudicial para el
equipo. Es mejor no hacer nada y simplemente observar las dinámicas e intervenir cuando sea necesario en
lugar de crear una burocracia innecesaria y distraer al equipo para justificar la existencia del rol, en caso de
que la ScMa no sepa nada mejor.
Combinando otros roles con el rol Scrum Master
Puede ser que en su organización el rol ScMa no se considere un rol de tiempo completo y se combine con
otros roles.
Vamos a discutir algunas combinaciones posibles y cuáles podrían ser los problemas.
Scrum Master / Desarrollador
Tiene sentido que la ScMa tenga antecedentes de desarrollador, pero no necesariamente tiene sentido que
la ScMa sea un desarrollador en el equipo. La razón es que la carga de trabajo del rol ScMa no está
determinada,por lo tanto, existe un problema para que la ScMa se comprometa con las tareas durante el
Sprint, especialmente durante los Sprints cortos, ya que la función de ScMa puede tomar el 100% de la
capacidad. Otro problema es la mejora de la capacitación: si el equipo tiene que aumentar las nuevas
tecnologías, es posible que ScMa no tenga la misma oportunidad que el resto de desarrolladores debido a la
carga de trabajo de la función ScMa. Además, el rol de ScMa es muy disruptivo y no siempre brinda la
oportunidad o el marco de tiempo para aumentar y obtener experiencia práctica durante un período de
tiempo suficiente. Por esta razón, la función de desarrollo funcionará mejor cuando haya tareas de desarrollo
que no forman parte de los Sprints, por ejemplo, escribiendo un prototipo para la próxima versión durante la
primera versión o escribiendo scripts de automatización para todo el proyecto pero no en base a Sprint .
Scrum Master / Calidad
37. Esta combinación podría tener los mismos problemas que la combinación con el rol de desarrollador
(compromiso en el nivel de Sprint y la curva de aprendizaje). Sin embargo, la curva de aprendizaje podría ser
menos pronunciada que en el rol de desarrollo, por lo que podría funcionar mejor, especialmente en caso de
que haya un experto en calidad adicional en el equipo y la ScMa contribuya cuando sea posible sin ser el
cuello de botella.
Scrum Master / Line Manager
Esto podría ser un punto dulce para la ScMa, ya que el rol cambia de no tener autoridad a autoridad real.
Esto puede funcionar, pero depende totalmente de la personalidad de la ScMa. ¿Este individuo mantendrá al
equipo como rehén o podrá superar la tendencia de microgestión y entregar lo mejor de ambos roles?
■ Tenga en cuenta que la dictadura también puede ser positiva pero realmente depende del dictador. Realmente es contra los principios
de Agile tener un dictador en un equipo autoorganizado, pero aún puede funcionar en caso de un buen dictador y un equipo que
realmente lo necesite.
Scrum Master / Propietario de producto / Analista de negocios
La orden de compra es diferente de una organización a otra: a veces la orden de compra del equipo es solo
el miembro del equipo que aporta requisitos al equipo y no el que los define. Podemos llamar a este PO /
Business Analyst. En algún momento el PO puede definir requisitos por sí mismo. Así que no creo que
funcione para ScMa tener ambos roles de ScMa y PO; sin embargo, definitivamente veo que la ScMa en el
equipo puede ser PO / BusinessAnalyst. Una vez más, la cola depende de la complejidad del proyecto y de la
situación particular. La práctica general en la industria no recomienda fusionar esos dos roles, debido a un
posible conflicto de intereses.
■ Nota Lo que no hemos discutido aquí son diferentes roles de expertos que podrían ser obligatorios en su organización, como
seguridad, rendimiento, automatización, usabilidad, etc. Algunos de ellos también pueden estar en la placa de ScMa, especialmente si
los entregables expertos se difunden a lo largo de la duración del proyecto y no tienen compromisos duros en un nivel de Sprint.
Percepciones, personalidades y condiciones
38. Hasta ahora hemos discutido diferentes metodologías y roles y adaptaciones de ScMa; Sin embargo, lo que
lo hace realmente difícil es la gente. Cada miembro del equipo es una persona individual con su propio
conjunto de percepciones, diferentes antecedentes y diferentes niveles de desarrollo personal y profesional.
Entonces, en primer lugar, ningún equipo será perfecto; siempre habrá miembros del equipo con los que
podría no estar contento, así como miembros del equipo que podrían no estar contentos con usted como
ScMa. Esto puede ser justificado o injustificado, ya que todo es una cuestión de percepciones individuales. La
ScMa no siempre puede ganar un concurso de popularidad en el equipo, no es que ScMa necesariamente
tenga que ser popular (sin embargo, sí ayuda).
Hay un conjunto común de personalidades que podrías tener en tu equipo: la diva; El tímido, compensador
de inseguridad; el inseguro el fuerte y el inútil; el individualista el vencedor el niño; lo asombroso; etc.
Además, hay diferentes situaciones que no dependen de las percepciones sino de ciertas desviaciones. La
ScMa debe estar familiarizada con las condiciones más comunes del síndrome de Asperger, el autismo, el
TDA, los psicópatas, los narcisistas, etc.
Para que la ScMa pueda cumplir su función de manera efectiva, se requieren tres cualidades principales: ser
maduro, consciente de sí mismo y emocionalmente inteligente.
Compromiso de Scrum Master para tareas adicionales
A menudo, se espera que la ScMa contribuya al desarrollo u otras tareas, asumiendo que la ScMa no es una
función que consuma toda la capacidad del miembro del equipo, por ejemplo, 50% / 50%. El problema con
esto es que a veces el rol tomará el 100% del tiempo con las horas extraordinarias, pero en algunos casos
del 30% al 40%, y es muy difícil predecir qué dirección tomará un Sprint con respecto a la participación de
ScMa. La fórmula mágica es no comprometerse con tareas productivas en un nivel de Sprint. Por lo general,
hay temas que se ejecutan en todo el nivel del proyecto. Por ejemplo, en el caso de desarrollo, la ScMa
puede funcionar en trabajos pendientes que no están comprometidos para el Sprint actual, o en temas
generales que se aplican al proyecto en general, como la automatización de pruebas, el rendimiento, los
datos de prueba, la gestión de calidad, etc. También,
Es importante que el ScMa sea transparente con el equipo sobre lo que está haciendo, ya que a menudo el
rol y los deberes de ScMa no son claros dentro del equipo, y la contribución y entrega de ScMa no siempre
son visibles para los miembros del equipo.
Sin embargo, en el caso de un equipo maduro y autónomo, el rol de ScMa puede ser menos exigente y, en
este caso, el ScMa puede comprometerse realmente en un nivel de Sprint.
Habilidades técnicas Scrum Master
39. Hay una buena probabilidad de que la ScMa provenga de un fondo técnico. Entonces, si el equipo está
trabajando en un dominio técnico donde la ScMa tiene experiencia, no debería haber ningún problema para
poder comprender mejor el tema en el que está trabajando el equipo. Sin embargo, si el equipo está
cambiando las tecnologías y los proyectos, la ScMa tendrá dificultades para ampliar los nuevos temas, ya
que la naturaleza de este rol es una interrupción constante que hace que sea difícil concentrarse en lo
mismo durante un largo período de tiempo y dominar nuevos temas. temas
Es mación y seguimiento de su equipo
Las estimaciones a menudo no son precisas a menos que el trabajo sea realmente repetitivo.
Por esta razón, si usted, como ScMafeel, está atrapado en los juegos de números y en el monitoreo sin ver
ningún beneficio, tal vez el conteo de horas se pueda eliminar.
Si el Sprint es lo suficientemente corto, digamos dos semanas, en lugar de hacer coincidir la capacidad con la
estimación de tareas, una salida simple puede ser que los desarrolladores tomen ciertos retrasos y se
comprometan con ellos durante la planificación y será responsabilidad del desarrollador hacer un
seguimiento del tiempo. Y mejorar en las próximas iteraciones de Sprint. De esta manera, todas las tareas se
asignan previamente y no hay seguimiento del tiempo en el nivel de Sprint; además, no está poniendo a
nadie en el foco de atención por el tiempo que les lleva ejecutar ciertas tareas. Por supuesto, puede afirmar
que al no medir el tiempo individual le faltan temas como el cálculo de la velocidad, el seguimiento del
progreso del Sprint y la mejora del seguimiento. Sin embargo, mi argumento es que el equipo es una
unidad, por lo que si desea realizar un seguimiento del tiempo, realizar un seguimiento en el nivel del
equipo y medir la velocidad y la mejora en el nivel del equipo.
También con respecto al progreso de la ejecución de Sprint, si su Sprint no excede la duración de dos
semanas, el seguimiento de tiempo individual no agrega mucho valor. En mi experiencia, un enfoque
holístico funciona mucho mejor.
Desafortunadamente, a veces la administración presionará para obtener los números con el fin de satisfacer
sus instintos de informe y, por lo tanto, no necesariamente tendrá una opción.
Aceptando el cambio por el equipo
Cuando se impone un cambio a un equipo o individuos, tanto los individuos como los equipos
generalmente se resisten al cambio y la ScMa que tiene que lidiar con él y lo implementa.
Hay diferentes maneras de lidiar con la resistencia al cambio. Antes de cambiar cualquier cosa, observe el
proceso existente que planea cambiar y cuáles son los puntos / dificultades frustrantes que el equipo está
experimentando en este momento.
40. Explique al equipo el problema que tienen, asegurándose de que el equipo comprenda el problema y la
causa raíz.
Después de que un equipo a bordo recoja los comentarios, procesarlos y lanzar la solución.
Como regla general, cada cambio debe ser fácil de implementar, fácil de entender y debe sentirse natural.
Además, no implemente demasiados cambios para cada iteración, menos es mejor.
Pero no siempre hay tiempo para eso, también. No todos los temas tienen sentido abrir para discusión, por
lo que la ScMa debe actuar en función de la situación.
Para superar la resistencia, los cambios deben explicarse y tener sentido y, si no se aceptan o no se
entienden, se posponen o se rechazan.
Sin embargo, algunos cambios deberán aplicarse y podrían crear una situación de conflicto entre la ScMa y
algunos de los miembros del equipo.
Es importante identificar cuándo tiene sentido utilizar algún recurso externo al equipo para imponer el
cambio, a fin de no destruir la relación de la ScMa y el equipo.
Por ejemplo: digamos que una organización está implementando la migración de Waterfall a Agile Scrum, y
se contrató una nueva ScMa. El equipo es un equipo senior que se resiste al cambio. En un caso donde la
ScMa implementa el proceso, el equipo podría volverse disfuncional en el futuro. Sin embargo, si un cambio
es un lanzamiento por parte de la administración superior y la ScMa se presenta como un PM ágil que tiene
experiencia Scrum y ayudará al equipo a superar los difíciles tiempos de transformación, la ScMa será
percibida como una ayuda y no como una imposición.
Construye Scrum Master Confidence
Cuando ejecute el rol de ScMa, su confianza puede ser desafiada a menudo. Es muy difícil ser un líder sin
autoridad, y puedes convertirte fácilmente en un objetivo de tiro para tu equipo y para los jugadores
externos al equipo. Tener piel de elefante ayuda, pero no importa qué tan gruesa sea la piel, puede ser
penetrada; Cuantas más penetraciones obtengas, más se puede sacudir tu confianza.
Sin embargo, en este caso, recuerda esto: “El conocimiento genera confianza y la confianza crea dominio”.
Comienza a entrenar mucho. Cuanto más lea y escuche sobre el proceso, más confianza tendrá. Libros,
preguntas de Quora, wiki, podcasts, YouTube: hay muchas fuentes de información. Llegar a otros ScMa;
Entender los retos. Utilice a su gerente para hablar sobre sus problemas y buscar soluciones; también, una
ScMa debe construir un sistema de soporte que pueda incluir a algunos colegas y gerentes que brindarán
apoyo, asesoramiento y asistencia durante períodos difíciles.
41. Scrum Master = Project Manager?
Considero que la afirmación de que la ScMa no es un PM es un punto controvertido. Así que vamos a aclarar
la diferencia:
• Scrum Master trabaja en proceso
• El jefe de proyecto trabaja en el proyecto.
Muchas personas piensan que la ScMa no es un PM, aunque comparten algunas responsabilidades cuando
una parte de esas responsabilidades están en la OP, y la ScMa debe ser un líder de servicio que se concentre
en el proceso y la mejora continua.
Sin embargo, no importa lo que digan esos artículos, el rol eventual de la ScMa, así como cualquier otro
miembro del equipo, también es entregar el proyecto.
Creo que el rol ScMa no solo facilita el proceso y lo mejora constantemente, resolviendo bloqueos e
impedimentos, sino que también asegura que los equipos cumplan. Todo este proceso no vale mucho si
mejoramos continuamente pero no lo logramos. Incluso si el proceso es grande; Sin embargo, siempre hay
algo que puede caer a través de las grietas.
El ScMa junto con el PO reemplazan al PM convencional, por lo que si no ejecutarán partes esenciales del rol
de PM, ¿quién lo hará? Al trabajar con las partes interesadas, mitigan las expectativas, predicen riesgos,
detectan cosas que se pasan por alto y supervisan todo el proyecto y sus líneas de tiempo y no solo una
iteración. Entonces, tal vez la ScMa no sea un PM desde el punto de vista clásico. Sin embargo, creo que la
ScMa recibe diferentes piezas de un rompecabezas y trata de ayudar a ensamblarlo de una manera que
satisfaga al cliente. Tal vez esto se haga observando más el proceso que el proyecto, pero el objetivo es el
mismo: el equipo tiene que cumplir.
Entonces, ¿es la ScMa un PM? Realmente no lo sé y no me importa. Solo haz que suceda y ponlo en
cualquier título. Algunos comparan el rol de ScMa con el de un perro pastor, pero creo que el mejor nombre
/ título que describe el rol de ScMa es un "lubricante" o "aceite". El rol de la ScMa es lubricar todo para que
el equipo pueda Alcanzar su máximo potencial. El lubricante es algo que no se ve, pero sin él, nada funciona
o, incluso si funciona durante algún tiempo, eventualmente el mecanismo se desgasta muy rápido.
Para concluir: el rol de ScMa no es un rol simple. Se necesita mucho para poder influir sin autoridad y ser un
líder de servicio del equipo. La ScMa es la responsable de promover y respaldar la adaptación de la
metodología Scrum en el equipo. La ScMa es un líder de servicio para el equipo Scrum, al mismo tiempo que
ScMa proporciona servicio a la PO para permitir que la PO ejecute su función de una manera óptima. ScMa
optimiza el proceso en el equipo para ayudarlo a lograr el mayor valor y protege a los miembros de su
equipo de sí mismos y de las interrupciones externas.
CAPÍTULO
42. Dinámica del equipo
Es esencial estar consciente de lo que está sucediendo con la dinámica de su equipo, y ayuda tener al menos
una pequeña pista sobre cómo describir las etapas del equipo. Recomiendo familiarizarse con las etapas de
desarrollo grupal de Tuckman.
1
Hay cuatro etapas: formación, asalto, normalización y ejecución.
• Formación. Esta es la etapa inicial después de la formación del equipo. Los miembros
del equipo intentan ser aceptados por sus compañeros. Con ciertas excepciones, los
miembros del equipo intentan evitar conflictos y concentrarse en la organización del
equipo y los procesos. Los miembros del equipo intentan recopilar información y
comentarios sobre los demás, sobre las tareas futuras y la mejor manera de abordarlas.
Esta no es una etapa muy productiva, en la que todos los miembros del equipo
intentan permanecer en su zona de confort inicial y el equipo se siente cómodo en esta
etapa mientras pueda. Sin embargo, evitar el conflicto y el paraguas de los procesos de
formación iniciales que justifican la falta de productividad generalmente significa que
no se hará mucho en esta etapa.
• Asalto. Después de la cómoda etapa inicial de formación, la etapa menos
conformista de los inicios de asalto y los conflictos y desacuerdos generalmente
comienzan. Algunos de los miembros del equipo de Scrum estarán involucrados en
conflictos menores. Usualmente el
'BW Tuckman, "Secuencia de desarrollo en grupos pequeños", Psychological Bulletin, 63 (6), 384-399, 1965.
44. Sin la ScMa o cualquier otro líder en el equipo, es posible que el equipo no esté operativo y no llegue a las
siguientes etapas. Las situaciones de conflicto serán insoportables y harán que el entorno del equipo sea
totalmente ácido.
Una vez que se establezcan las reglas y los valores del equipo, el equipo puede autorregularse y alcanzará
las etapas de Norming y Performing.
■ Nota A veces, la regresión en un equipo puede suceder y, a veces, diferentes partes de los equipos pueden estar en diferentes etapas.
Por ejemplo, los miembros senior del equipo pueden lograr las etapas de Norming y Performing en un subgrupo relativamente rápido,
mientras que más miembros junior del equipo pueden permanecer en la etapa Storming o Forming durante un período de tiempo más
prolongado.
Se logran diferentes etapas en el equipo al experimentar mejoras propias durante las iteraciones de Sprint y
también en parte debido a los saludables conflictos visibles e invisibles. El equipo debe asegurarse de que
los conflictos, incluso cuando están sanos, no se vuelvan destructivos y no interfieran con la dinámica de
formación del equipo.
Relaciones entre roles en el equipo
Otro factor crítico para el éxito del equipo es la relación entre diferentes roles en el equipo.
En primer lugar, necesitas dos para el tango. Una relación no puede ser sostenida solo por un lado. Por lo
tanto, es una función crítica del Gerente de línea (o de cualquier persona que forme parte originalmente del
equipo) asegurarse de que se establezcan relaciones de trabajo saludables entre las funciones clave. El solo
hecho de tener el mejor desempeño que no puede trabajar bien entre sí puede ser menos efectivo a veces
que tener individuos con menos desempeño que se integren bien en el equipo como una unidad.
Para que un equipo tenga éxito, hay muchas personalidades y muchos conjuntos de habilidades que se
deben organizar correctamente juntos. Crear un equipo es como armar un rompecabezas que nunca se ha
ensamblado antes.
Obviamente, ser un jugador de equipo es la habilidad más crítica que garantiza que una persona pueda
contribuir en el entorno del equipo, no será perjudicial y eventualmente desarrollará relaciones de trabajo
con otros miembros del equipo.
45. Scrum Master-Product Owner
La relación ScMa y PO es la relación más crítica en el equipo; Debe haber un 100% de confianza y
comprensión entre los dos roles. Cualquier conflicto entre los dos tendrá un impacto muy negativo en el
rendimiento y desarrollo del equipo. Si hay un problema entre esos dos roles, el rol de los gerentes de línea
es hacer los ajustes necesarios lo más rápido posible.
Arquitecto-Propietario del producto / Arquitecto-Scrum Master
La relación Architect-PO / Architect-ScMa también es una relación muy crítica en el equipo. A menudo, el
Arquitecto será el que traduzca los requisitos de la PO en un diseño ejecutable, por lo que cualquier
problema de comunicación entre la OP y el Arquitecto puede imponer un riesgo importante para el
proyecto. Además, el nivel de ejecución ScMa debe trabajar en estrecha colaboración con el arquitecto para
que la planificación y el proceso de desarrollo sean lo más suaves y efectivos posible.
Scrum Master-Quality Manager
La relación ScMa-QM (Gestor de calidad) también es importante, ya que hay muchos procesos relacionados
con la gestión de la calidad en el equipo y la función de ScMa es mejorar y optimizar los procesos. La ScMa
por lo general debe estar estrechamente comprometida con el experto en calidad del equipo.
Arquitectos-Desarrolladores
El arquitecto es el líder técnico y, a veces, también es el entrenador de los otros desarrolladores del equipo.
Esta es otra relación muy importante para el éxito del proyecto. Es importante que la ScMa garantice el flujo
de la comunicación y, en caso de cualquier problema, mediar entre el Arquitecto y el desarrollo utilizando
habilidades interpersonales o habilitando procesos existentes que hagan posible la comunicación.
Por ejemplo, si los desarrolladores se sienten intimidados por las críticas del Arquitecto, la ScMa puede
configurar sesiones de revisión de código en las que la ScMa será la moderadora y asegurará un proceso sin
problemas de la revisión del código. A veces, la formalización del proceso puede ser una herramienta eficaz
que eliminará las emociones negativas y el estrés de los comentarios proporcionados.
46. Otro problema podría ser el temor de hacer preguntas por parte del equipo al Arquitecto. La formalización
del proceso y el uso de herramientas como el correo electrónico o el panel de preguntas y los espacios de
preguntas pueden ayudar a superar las emociones negativas, evitando que el Arquitecto se enoje por las
interrupciones constantes.
Scrum Master-Desarrolladores
Muchas personas tendrán diferentes personalidades. Dado que puede haber de cuatro a cinco
desarrolladores en el equipo, podría ser difícil para ScMa tener relaciones perfectas con todos los miembros
del equipo. Sin embargo, dado que las personalidades en el equipo no necesariamente tienen un clic
perfecto entre ellas, es fundamental que ScMa y Line Manager ayuden a construir una estructura de relación
viable en el equipo. Se requiere el uso de habilidades de comunicación personal y actividades de formación
de equipos.
Producto propietario-equipo
El PO debe ser parte del equipo y no estar aislado. El PO no debe dar al equipo la sensación de ser superior
y no uno de los miembros del equipo. El PO debe estar al tanto de lo que está sucediendo en el equipo,
pero al mismo tiempo no debe tratar de microgestionar otros roles. La orden de compra debe ubicarse junto
con todos los miembros del equipo, participar en las actividades del equipo y ser transparente con el equipo
sobre su carga de trabajo.
Si la PO se auto-aísla y se vuelve inaccesible, será un camino hacia la falla del equipo y hará que el ambiente
del equipo sea muy tóxico.
Equipo Técnico Escritor
A pesar de que la documentación es una parte menos importante del desarrollo Agile, todavía puede haber
una función separada del escritor técnico. Los escritores técnicos no siempre son técnicos, y será difícil para
un escritor técnico encajar en la dinámica del equipo simplemente porque no entienden las realidades del
proceso. Para el papel del escritor técnico es fundamental tener una relación de trabajo con la OP. Dado que
la OP es la que tiene una visión final de lo que se entrega y por qué, la comprensión de los entregables por
parte de la OP se debe reflejar en la documentación. Además, para un escritor técnico es útil construir una
relación de trabajo con el Gerente de Calidad (QM) en el equipo, ya que el trabajo de ambos roles es seguir
los entregables de los desarrolladores de una manera similar.
47. ■ Nota Dado que los roles de Arquitecto, PO, ScMa y QM son únicos en el equipo, puede ocurrir que ciertos individuos se sientan a la
defensiva dentro de la ejecución de su rol. Por ejemplo, QM puede sentir que ScMa se está excediendo en las responsabilidades de QM
al optimizar los procesos de calidad. O la OP intentará microgestionar la ejecución del proyecto e intentará sobrepasar las dinámicas de
autoorganización del equipo y las responsabilidades de ScMa. Es importante que el Gerente de línea se involucre en tales situaciones y
entrene a los roles principales en modos de operación aceptables.
Comunicaciones externas a equipos
Es muy importante definir los canales de comunicación correctos entre el equipo y las partes interesadas
externas. Si esas relaciones no están definidas correctamente, puede ser causa de grandes niveles de estrés y
capacidad perdidos en el equipo.
Team-Line Manager
Cada miembro del equipo es supervisado por un Gerente de Línea; sin embargo, el rol ScMa debe tener una
relación cercana y basada en la confianza con el administrador de línea para poder resolver los problemas
relacionados con el equipo. A menudo, los gerentes de línea ven a sus ScMa como sus "tenientes" en el
equipo.
Equipo-Programa
En las grandes organizaciones, los procesos de desarrollo a menudo se ejecutan bajo algún programa que se
basa en la línea de tiempo, el paisaje y los estándares de calidad. Por lo general, los miembros del equipo
que tienen que coordinar con el programa son Calidad para los estándares de calidad, ScMa / PO para líneas
de tiempo y paisajes, y Arquitecto para las pautas de la arquitectura central.
Equipo de partes interesadas
Por lo general, hay muchas partes interesadas en cada proyecto. Y, según la naturaleza humana, muchos de
ellos asumirán que saben más y que podrían intentar contactar directamente a los miembros del equipo.
48. También es posible que los miembros del equipo intenten evitar los canales de comunicación establecidos
en el equipo por razones de conveniencia o por razones de ganancias egoístas individuales.
Es importante establecer que las comunicaciones externas siempre irán a los canales definidos, por ejemplo,
para ir a la PO para conocer los requisitos y a la ScMa para los temas relevantes del proceso. Situaciones en
las que el PO principal o incluso el cliente cambiarán los requisitos directamente con los desarrolladores, sin
pasar por la
PO, puede crear problemas importantes en el largo plazo. Además, si otros equipos intentan usar los
recursos del equipo de manera no autorizada, esto debe ser monitoreado y ser parte del retraso acumulado
por el PO si requiere un esfuerzo sustancial por parte de los miembros del equipo. Es responsabilidad de la
ScMa proteger al equipo de las distracciones e identificar esas situaciones, y cada miembro del equipo debe
informar cuando suceda.
■ Nota El propósito no es eliminar a los miembros del equipo de la exposición a partes interesadas externas o del desarrollo de redes
con otros miembros del equipo; Es todo lo contrario: los miembros del equipo deben estar expuestos tanto como sea posible a los
interesados. El propósito es iluminar las desalineaciones durante la ejecución del proyecto donde hay pocos centros de información y
toma de decisiones que contribuirán a la falla del proyecto a largo plazo, y cuando la capacidad perdida no se contabiliza.
La responsabilidad general de la ScMa es proteger al equipo y a los miembros individuales del equipo de
ataques de fuentes externas al equipo. Es responsabilidad de la ScMa poder transformar los ataques en
retroalimentación constructiva, para evitar daños al individuo y a la dinámica del equipo en general. Por
supuesto, en caso de que algo se haya hecho de manera incorrecta, se debe comunicar y abordar, pero se
debe hacer de una manera constructiva y la ScMa debe garantizarlo.
Conflicto / Resoluciones de problemas
Hablemos más sobre conflictos, los conflictos no son algo que se pueda evitar por completo y, a menudo,
los conflictos y su resolución se convierten en una parte importante del rol de ScMa.
A veces casi no hay conflictos en el equipo. Si esta es su situación actual, apéguese a este equipo y este rol
siempre que pueda, no importa cuánto trabajo esté obteniendo y si su salario no es excelente.
Lamentablemente, o en algunos casos, afortunadamente, no siempre es así.
Por lo general, la mayoría de los conflictos los crean los gerentes que forman el equipo. No lo hacen a
propósito; es muy difícil de entender si se combinan ciertas personas cómo funcionará.
49. La tasa de divorcio es más del 50% en América del Norte; ¿Qué esperas de un equipo a menudo? Si
tomamos la tasa de divorcio como medida, entonces un equipo de diez está garantizado para obtener el
divorcio.
Pero en el equipo, no puedes pedir a algunos de los miembros del equipo que duerman en el sofá de la sala
de estar o que vuelvan a la casa de sus padres. Así que el equipo, y la ScMa en particular, tienen que lidiar
con los conflictos y prevenirlos cuando sea necesario. Esta es una parte invisible muy importante y muy
importante de las responsabilidades del rol de ScMa.
Identifico cuatro tipos de conflictos:
• Tipo I - El mal puro (juegos políticos): el poder y la política son especialmente
comunes en una gran organización. Puede ser un conflicto entre gerentes,
stakeholders, etc.
Cuando alguien abre una campaña destructiva contra otra persona por cualquier razón,
esos conflictos pueden ser devastadores para el equipo y para cualquiera que intente
resolverlos. Realmente lastima a la compañía también. La gestión de líneas debe ser
capaz de identificarlos y prevenirlos.
(A menudo, no podrán hacerlo). No hay otra forma de salir de la mayoría de los
conflictos malvados aparte de huir buscando nuevas oportunidades en el mercado.
Este tipo de conflicto siempre es malo.
• Tipo 2: impulsos instintivos (naturaleza humana): esto sucede cuando un individuo o
individuos no son capaces de controlar su ego y operar puramente por instintos y
emociones.
Cualquier individuo puede entrar en el modo impulsado por la emoción; sin embargo,
para algunos individuos, sus impulsos instintivos son dominantes y no pueden ser
controlados por su super ego o racionalismo.
• Por lo general, el término políticamente correcto para este término es "no es un
jugador de equipo". La gerencia de línea debe encargarse de este tipo de conflicto al
asesorar o eliminar a la persona del equipo. En caso de que un Line Manager no trate
con tales individuos, la productividad y el desarrollo del equipo en su totalidad se verán
afectados.
• Otra situación de este tipo de conflicto a veces es cuando un individuo rechaza a otro
en un nivel emocional. No hay ninguna razón en particular: es solo que algunos
individuos no se toleran entre sí; a veces pueden proporcionar una explicación, pero a
menudo esta explicación solo intenta racionalizar sus emociones profundas.
• Muy a menudo, algunos miembros del equipo entrarán en una discusión solo para
tratar de demostrar que tienen razón y otros están equivocados. Esta situación puede
ser muy contraproducente.
50. A menudo es difícil manejar un caso de este tipo, ya que siempre se puede argumentar
que una persona tiene su opinión y el derecho a ser escuchado y proporcionar los
argumentos. Como resultado, los intentos de moderar tales situaciones pueden
interpretarse como una dictadura.
Por ejemplo, esto puede surgir durante las reuniones retrospectivas, ya que es
relativamente fácil encontrar ideas para el cambio y la mejora cuando realmente no lo
dice en serio, pero intente demostrar que está en lo correcto. Muy a menudo esos
argumentos contraproducentes destruyen el propósito de las reuniones y discusiones,
y deben ser suprimidas por la ScMa; De lo contrario el equipo perderá el control y la
motivación.
Este tipo de conflicto siempre es malo.
• Tipo 3 : conflicto de comunicación: cuando algunos mensajes se interpretan de
manera incorrecta. Puede obtener cualquier forma y forma. Este conflicto es
innecesario. La comunicación ayuda a resolverla; Es el rol de la ScMa habilitar el canal
de comunicación entre los individuos.
• Este conflicto siempre es malo pero a menudo es fácil de resolver.
• Tipo 4: El conflicto saludable: por lo general, esto se relaciona con un simple
desacuerdo entre los miembros del equipo por razones genuinas, y este tipo de
conflicto se analiza en la mayoría de los libros y documentos de manejo de conflictos.
Este tipo de conflicto no siempre es malo, y la resolución de este conflicto se
discutirá más a fondo.
A pesar de la naturaleza negativa del conflicto, un equipo en el que todos estén de acuerdo siempre no será
un equipo de muy alto rendimiento y no mejorará. Necesita una lluvia de ideas y utilizar diferentes opiniones
para tener éxito.
ScMa y Line Manager en segundo plano tienen un papel importante en la resolución de conflictos en el
equipo y ambos deben saber cómo manejarlos.
Es importante que el equipo establezca un valor para que todos los miembros del equipo sean escuchados y
que cada miembro del equipo pueda ajustar su ego, la agenda personal y las emociones y ser parte del
equipo.
Desafortunadamente, no todos son capaces de reprimir su ego y sus emociones. En esta etapa, comienza el
arte de la moderación del conflicto.
Las técnicas para resolver conflictos son estándar en todas partes; No importa si se trata de un entorno Agile
o no.
51. • COLABORAR (Ganar-Ganar): En este caso, ScMa / Line Manager puede servir como
facilitador en lugar de una parte activa de la solución. La entrada de ambos lados se
puede acomodar. Esta es la situación ideal: ganar-ganar.
• COMPROMISO (Perder-Perder): En este caso, ambas partes deben estar de acuerdo
en no estar de acuerdo, pero el espectáculo debe continuar y ambas partes lo
entienden. El ScMa / Line Manager podría estar muy involucrado como intermediario
en este tipo de problema.
• FORCE (Win-Lose): Idealmente, forzar es cumplir con las reglas, pero tales reglas no
siempre existen. En este caso, la ScMa debe tratar de no ser el ejecutor, sino utilizar a
alguien más con un rol de comunicación menos crítico o incluso externo al equipo. Esta
forma de lidiar con el conflicto puede eventualmente escalar a más conflictos; Sin
embargo, podría ser la única manera a veces. Puede resultar en el uso de la autoridad
de línea o del administrador de línea para forzar a uno de los lados a trabajar de cierta
manera.
• SUAVE o ACOMODADO (Haga que se deslice): ScMa puede hacerlo si tiene buenas
habilidades de comunicación, al suavizar la situación entre los lados del conflicto de
manera individual. Lo más probable es que el alisado aparezca en una etapa posterior.
Sin embargo, la ScMa debe saber cuándo elegir sus batallas y esta técnica podría tener
sus beneficios.
• RETIRAR (No hacer nada): Esto también puede suceder, especialmente cuando
ambas partes están equivocadas. Por lo tanto, el ScMa / Line Manager puede observar
de cerca la situación sin ponerse en la línea. En este caso, una oportunidad para
resolver el conflicto puede llegar con el tiempo.
• LIDERAR el conflicto (tomar un lado): a veces tiene sentido que ScMa tome partido
en un conflicto y lo dirija, con el fin de controlar la situación y minimizar el daño.
Los conflictos pueden ser saludables cuando promueven discusiones constructivas. Es importante que se
aliente la resolución de conflictos y que se cree un entorno donde los miembros del equipo expresen sus
opiniones e inquietudes entre ellos y sobre el proyecto, y eventualmente estén de acuerdo en las cosas,
utilizando el sentido común y la razón en lugar de argumentar por el bien de. El argumento y las emociones
como razonamiento.
Sin embargo, a pesar del posible resultado positivo del conflicto, al mismo tiempo las situaciones conflictivas
pueden reducir considerablemente la productividad del equipo y es muy importante abordar la situación y
mantenerla bajo control.
Debido a la naturaleza de Agile y debido a la descentralización y la presión de trabajar en iteraciones cortas,
Agile puede aumentar el número de conflictos en el equipo en comparación con el modelo de cascada. Esto
hace que la capacidad de ScMa y Line Managers para resolver conflictos sea crítica para la dinámica y la
productividad del equipo.
Por otro lado, el miedo al conflicto en un equipo Scrum no siempre es una buena señal para el equipo. La
falta de conflicto puede significar la apatía del equipo.
52. Estas son algunas lecturas adicionales que recomiendo sobre el tema:
• Las cinco disfunciones de un equipo: una fábula de liderazgo (Jossey-Bass, 2002) de
Patrick Lencioni. El autor nombra "miedo al conflicto" como una de las disfunciones del
equipo.
• “13 Pasos para navegar por el conflicto de manera efectiva” es un artículo de Carl
Robinson ( http: // leadershipconsulting.com / 13-steps-navigating-con lict-e icaz).
El mensaje principal es que la mayoría de las personas esperan hasta que los
problemas polémicos se intensifiquen y se conviertan en un problema mayor antes de
tratar de resolverlos: evitar conflictos.
• “Coaching Through Conflict: Effective Communication Strategies” es un artículo de
Ryan Hedstrom (http: // www.appliedsportpsych.org/resources/ resources-for-
coaches / coaching-through-con lict-Effective-communication-strategies /).
Aunque este material está destinado a entrenadores deportivos,
Encuentro muchas similitudes entre el entrenador de deportes y especialmente los
roles de Scrum Master, y este material es definitivamente una buena lectura.
Scrum Master como parte del conflicto
Hasta ahora hemos discutido los conflictos en el nivel donde la ScMa no es parte de ellos; sin embargo, en
un rol activo, la ScMa puede estar más directamente involucrada directamente en la situación conflictiva.
A menudo, cuando la ScMa es parte del conflicto, no significa necesariamente que esa persona en particular
en el rol de ScMa genere conflicto. Puede significar que el rol de ScMa está más expuesto a situaciones de
conflicto, y esas situaciones de conflicto deben resolverse con medios regulares de resolución de conflictos.
■ Nota La ScMa trabaja con dinámicas de equipo, conflictos de equipo y promueve cambios y mejoras, y como resultado, a menudo la
ScMa misma puede ser parte del conflicto. Sin embargo, Line Manger también se ocupa de los conflictos, pero tiene la autoridad real
que ayuda a Line manager a estar menos expuesto a ser parte de un conflicto.
Línea inferior del conflicto
