lunes, 16 de octubre de 2017

¿Cómo liderar el crecimiento de equipos impulsados por las motivaciones intrínsecas?

Porqué tenemos POCLACs
Aquellos con roles de liderazgo ágil deben de hacer todo lo posible para que los equipos aprendan y crezcan de forma continua, en un ambiente adecuado con el objetivo de hacer equipos más productivos y motivados. En Agilidad el liderazgo se hace en equipo y por aquellos roles que pueden facilitar las motivaciones intrínsecas de los miembros del equipo: propósito, maestría y autonomía.

En los diferentes marcos de Agilidad, desde Scrum a los marcos escalados, nos encontramos con un liderazgo distribuido en una coalición de tres roles:
El modelo Spotify define un evento denominado POCLAC para que estos roles de liderazgo trabajen en cómo ayudar a los equipos a desarrollarse. POCLAC viene de las siglas de la coalición de Propietario del Producto (PO), Chapter Lead (CL) y Agile Coach (AC), y es el evento que da respuesta al post, a cómo liderar el crecimiento de equipos impulsados por las motivaciones intrínsecas.

El evento se materializa en una reunión informal y regular dentro de la cadencia establecida, al menos debe de efectuarse una vez por sprint. Dentro de la misma se discute acerca de cómo está funcionando el equipo y sobre qué podría hacerse para que trabajen mejor. Podemos apoyarnos en diferentes fuentes de información:
El resultado de la reunión se materializa en una serie de acciones a poner en macha para hacer crecer a los equipos; reconocimientos, adquisición de recursos, resolución de impedimentos, eventos de team-building, formaciones, …

No debemos tratar a los miembros de forma individual, sólo sería adecuado discutir una contribución individual si esta estuviera directamente vinculada al rendimiento del equipo. El resultado de tal discusión puede variar desde dar un gran cumplido a alguien que haya influido positivamente en el rendimiento del equipo, o tener una charla con alguien que está teniendo problemas y hacer un plan para ayudar a ese miembro de equipo a crecer.

Una de las disfunciones más comunes de POCLAC es que se covierta en una reunión de discusión sobre la pila de producto o los hitos de la hoja de ruta, por tanto como facilitadores de la reunión hemos de estar alerta y si ocurre refocalizar la reunión en el equipo. También debemos cuidar que cada rol se mantenga dentro de sus responsabilidades y no asistan otros interesados.

viernes, 13 de octubre de 2017

¿Cómo planificar utilizando hitos en Scrum?

Los hitos son una serie de etapas dentro de un mismo proyecto, provienen de la gestión de proyectos en cascada, son una forma de conocer el avance del proyecto sin estar familiarizado con el mismo y simbolizan el haber conseguido un logro importante en el proyecto.

La gestión clásica se basa en montar líneas de tiempo con hitos (planificaciones) atadas a un alcance inicial y dotar la línea de tiempo de los recursos para cumplir con esa línea, sin tener en cuenta capacidades ni dependencias. Trae la gente al trabajo. La dotación de recursos, tanto de personas, infraestructuras, herramientas...  a una planificación no deja de ser intencional, algo que puede ser muy lejano a la realidad posterior. Marcar hitos en este tipo de gestión suele dar resultados frustrantes, los desvíos y mala calidad del software de proyectos tradicionales suele venir de hitos marcados sin tener en cuenta realidades.

Agilidad mide la capacidad de flujo de los sistemas incluidos los equipos existentes, para poder así ajustar el trabajo a la capacidad y poner el foco en mejorar el flujo de forma continua, alineando, sincronizando y teniendo en cuenta las dependencias. Trae el trabajo a la gente y en la cantidad de la capacidad de ésta.

Se determinan en la fase de incepción y marcan la hoja de ruta. Estos se van revisando a medida que avanza la construcción del producto y se van ajustando a los cambios de necesidades del producto o cliente. Correctamente gestionados dan flexibilidad a la construcción del producto, como por ejemplo en el desarrollo software.

Mike Beedle, con quién he compartido cursos como co-trainer, dejó en mi impresa una de sus frases que suelo utilizar en todas mis clases cuando hablo de métricas:

Quién predice sin medir, se equivocará

Para poder marcar hitos factibes necesitamos métricas basadas en la evaluación objetivas de sistemas funcionando. SAFe lo resalta de forma muy clara, incluye en sus principios, en el quinto concretamente, "Basar los hitos en la evaluación objetiva de sistemas funcionando".

En Scrum la velocidad es la métrica objetiva por excelencia, nos da la capacidad media por sprint de un equipo en la misma medida que los tamaños de la pila de producto, por tanto habiendo medido la velocidad en un equipo estabilizado, podemos proyectar la pila de producto a fechas futuras en forma de hitos con gran grado de acierto y poblar la hoja de ruta. De la misma manera que tratamos velocidades de equipos, en Agilidad a escala hemos de tratar velocidades de equipos de equipos.

Ejemplos de métricas objetivas:

jueves, 12 de octubre de 2017

¿Cómo lidiar con la incertidumbre inherente a los proyectos/productos?

Los principios de un proyecto son una situación de gran incertidumbre, conocemos los problemas de negocio más urgentes de forma general pero no al detalle, no tenemos aún sentido de su evolución en el tiempo, aún estamos sin experiencia en el mercado y por tanto desconocemos las necesidades reales, realmente es un momento en el que se puede saber muy poco.

En gestión clásica se suele tener la convicción de que existe una solución única e ideal y que esta se puede conocer al principio, y la tenemos en ese momento de máxima ignorancia. En gestión ágil si observamos el comportamiento de Scrum a lo largo del cono de la incertidumbre vemos que con cada sprint hay un punto de aprendizaje que nos permite reconducir la construcción hacia la mejor solución posible.

Recordemos el método INVEST para medir la calidad de una historia de usuario, en concreto la N de negociable: los detalles de una historia deben de ser acordados con el cliente o usuario durante la fase de conversación poco antes de su inclusión en un sprint, en el último momento responsable, cuando la información es más fresca. De la misma manera debemos de decidirnos por diseños o componentes en el último momento posible, ya que de esta manera tendremos la opción más adecuada.

La Agilidad se basa en realidades, la variabilidad es inherente a todo producto y si eliminamos la variabilidad demasiado temprano limitamos ganar experiencia de lo que funciona y lo que no.
A través de puntos de aprendizaje terminamos en la solución óptima
SAFe incluye entre sus principios el tercero, el que nos habla de "asumir variabilidad y preservar opciones", este nos hace considerar un abanico de opciones en las soluciones de diseño y no pretender determinar las opciones al principio, los puntos de aprendizaje a lo largo del proyecto nos enseñarán cuál es la opción ideal:

miércoles, 11 de octubre de 2017

¿Cómo combinar un software de gestión de tareas con tableros físicos?

Elena Moreno dándo el seminario ¿Cómo Confluence y Jira
nos pueden ayudar en nuestros proyectos ágiles?
Hace poco asistí a un seminario que dio Elena, una compañera coach ágil, sobre cómo Confluence y Jira pueden ayudarnos en los proyectos ágiles. Al final de la sesión le dije que me había hecho feliz, ya que me dio la solución a la dicotomía de conciliar los tableros físicos y los virtuales.

Cuando las compañías se plantean introducir una herramienta con la que registrar y hacer seguimiento de sus historias de usuario y tareas suelen decantarse por una herramienta tipo JIRA o Redmine en su versión agile. Son herramientas que suelen estar ya instaladas y que se utilizan para la gestión de proyectos con las metodologías establecidas, usualmente en cascada. Lo que suele gestionarse en estas herramientas son tareas, de las que se registran las horas estimadas y se hace seguimiento a través de las horas realizadas.

Uno de los inconvenientes es que se mezclan peras con manzanas, ya que las horas estimadas, que se miden en horas ideales, son una medida de esfuerzo (trabajo), y las horas realizadas, se miden en tiempo transcurrido y representan duración. Realmente la métrica que reflejamos en la herramienta es el tiempo invertido, y esta métrica no representa la productividad del equipo.

En Agilidad ponemos el foco en la entrega, considerando esta como un conjunto de elementos que tienen valor de negocio, como lo son las historias de usuario, finalizadas según la definición de hecho e instaladas en un entorno al que los usuarios finales tengan acceso. La suma de las estimaciones, en horas ideales o puntos de historia, de aquellas que el equipo entrega a final del sprint, representa la velocidad del equipo, y esta si es una métrica de la productividad. 

Como podemos ver, los elementos de los que es interesante hacer seguimiento son las historias de usuario, aquellos elementos que agregan valor una vez entregados y que al fin y al cabo recorren la cadena de valor del producto y de los que es interesante tener trazabilidad.

Las tareas son elementos fungibles, nacen al principio del sprint en la planificación de sprint, y mueren al finalizar este. Por supuesto debemos de ser capaces de hacer seguimiento y poder ver el avance del sprint a partir de las mismas, pero su ciclo de vida es muy corto.

Informes de Jira Agile
Las herramientas como JIRA aportan multitud de informes y gráficos para el seguimiento, son una opción ideal para hacer seguimiento de los elementos que dan valor a negocio. Estos son elementos de larga duración, nacen en la pila de producto y su ciclo de vida acaba una vez están instalados en producción y se hayan tomado métricas como el ROI (Retorno de Inversión). Por tanto las herramientas como JIRA, con sus tableros virtuales, son una herramienta excelente para la gestión y seguimiento de epics, historias de usuario y releases.

A nivel de tareas, y recordemos que estas las definen los equipos y se las autoasignan los miembros en las sucesivas reuniones diarias, las necesidades que debe de cubrir un tablero son ser punto de referencia, conectar a las personas y ser herramienta de comunicación en el equipo. A diferencia de un tablero que refleja historias de usuario con ciclos de vida largos y para un número relativamente reducido de Propietarios del Producto, el tablero para tareas con un ciclo de vida corto, debe de ser útil para un grupo mayor, de entre 3 a 9 miembros de equipo.

La solución ideal para los equipos y sus tareas son los tableros físicos, muestran la imagen completa del sprint, son fáciles de gestionar (mover los post-its), siempre están visibles con lo que irradian con fuerza y se vuelven punto de referencia con facilidad. El hecho de que los equipos tengan que dibujar los burndowns es otra ventaja, porque al hacerlo los miembros interiorizan el avance del sprint conviertiéndo este gráfico en una poderosa herramienta para la toma de decisiones en equipo.

Tablero de Scrum físico
La conclusión, y de ahí mi alegría, es que la conjunción de tableros virtuales para elementos que agregan valor y que requieren seguimiento a largo, junto tableros físicos para elementos de trabajo de vida corta y que requieren de microplanificación con todos los miembros del equipo presentes, es una solución excelente.

Tuve un equipo que por razones ajenas a los mismos tuvo que dejar de trabajar con Scrum, llevaban ya tres meses con las ceremonias de Scrum reuniéndose diariamente ante el tablero físico, y cuando apenado tuve que notificarles que dejaría de ser su Scrum Master, me pidieron que por favor les dejara el tablero físico, que aunque tuvieran que volver a su metodología clásica el tablero les estaba siendo de gran utilidad facilitándoles mucho la coordinación.

Mis agradecimientos a Esther, Dani, Juan, Raúl, Daniel, Noelia y Santi y a su tablero que les ayudó a ser un equipo ganador.

sábado, 7 de octubre de 2017

¿Cuál es la diferencia entre un enfoque de consultoría y de coaching en una transformación ágil?

La cultura se merienda a la estrategia - Peter Drucker
Uno de los temas que son más complicados de comprender por parte de la empresas tradicionales que inician su transformación ágil, es la el enfoque de como debe de acometerse las misma.

Están acostumbradas a los consultores de negocio, como Price Waterhouse Cooper, McKinsey&Company y Accenture, esos expertos que revisan y analizan la organización para entregar finalmente un informe que cuesta su peso en oro con todo aquello que deben de hacer para una transformación ágil exitosa.

Estos informes hablan de estrategia, del proceso de como hacer la transformación, de procedimientos a implantar, de un gran plan que llevará e nuestra organización a ser un compañía Agile.

El punto débil de este enfoque es obviar que la Agilidad implica un cambio cultural, un profundo cambio en los valores de la compañía y de los principios por los que esta deberá rigirse. La resistencia al cambio, los secretos existentes que no pueden gestionarse y la inercia al cambio cultural pueden hacer que la estrategia fracase. Como dice Peter Drucker, considerado el mayor filósofo de la administración del siglo XX, cuando estrategia y cultura colisionan: "La cultura organizacional se merienda toda estrategia".

Toda compañía es singular en todos sus aspectos y no podemos conocer, ni por tanto concebir, la estrategia adecuada en todas sus vertientes al principio, en el punto en el que se hace la consultoría es el de mayor ignorancia. Por ello es necesario otro enfoque, un enfoque de aproximación sucesiva a la Agilidad.

En ese punto entra en juego el enfoque del coaching, a través de un equipo de agentes de cambio con roles de coach ágil. Estos son expertos en Agilidad y su misión para una transformación ágil es estirar a la organización sin piedad ni culpabilidad hacia los valores, los principios y las prácticas ágiles. Los procesos y procedimientos están escritos, llámese Scrum, SAFe, LeSS o modelo Spotify, lo que hará un coach ágil es acompañarnos hacía éstos haciendo que los detalles específicos para nosotros emerjan de la organización de forma paulatina a través de la mejora continua.

Dos enfoques para una transformación ágil
Un coach impregnará a la compañía de mentalidad ágil, marcará en cada evento y ceremonia la dirección adecuada. Observará e intervendrá en cada crisis y en cada decisión no alineada con la Agilidad, formará a quién lo requiera y mentorizará a Propietarios del Producto, Scrum Masters, lideres y a todas las personas de la compañía que lo requieran.

Se ocupará de organizar retrospectivas periódicas a diferentes niveles de la organización, en cada una de ellas habrá como resultado un punto de mejora que de tener éxito hará a la compañía más ágil. En ocasiones invitará a las mismas a lideres y directivos para que escuchen de primera mano lo que su gente tiene que decir, éstos son al fin y al cabo los que pueden desbloquear impedimentos sistémicos y organizacionales e impulsar la Agilidad. A veces habrá retrocesos, los puntos de mejora hay que probarlos y a veces simplemente no funcionan. Como nos dice William Edwards Deming "es mejor mejorar un poco cada día que intentar mejorar todo de una sola vez".

Un coach ágil no tiene un gran plan, sabe exactamente cual es la dirección de la Agilidad, dispará a la Luna y estirará de la organización en esa dirección, sabiendo que no llegará a la misma, pero si sabiendo que llegará a la mejor aproximación posible según las singularidades de la organización. Lo hará a través de la mejora continua, concibiendo pequeños planes en base a métricas ágiles, a modo de "think big, act small".

Un coach ágil no tiene la solución a la transformación ágil, pero si actuará de aceite para mover a la gente para que se se produzca la mejor transformación posible.

viernes, 29 de septiembre de 2017

¿Qué ocurre con las tareas de un jefe de proyecto en Scrum?

En Scrum no existe la figura del jefe de proyecto, y siendo así ¿qué ocurre con las tareas que implican sus funciones?

En los cursos dirección de proyectos PMP un jefe de proyecto aprende a dar respuesta a cuestiones como:
  • ¿Qué es lo que se va a hacer?
  • ¿Cuándo se va a hacer?
  • ¿Por qué se va a hacer?
  • ¿De cuánto presupuesto se dispone para hacerlo?
  • ¿Cómo se está desarrollando el proyecto?
Scrum busca optimizar el flujo del trabajo, para ello descentraliza la toma de decisiones, ya que la forma más rápida de tomar una decisión es que la tome quién tenga la información local, y un jefe de proyecto puede convertirse en un cuello de botella si no está en contacto directo con esta. Por tanto en Scrum las tareas del mismo se distribuyen en sus roles, en aquel rol que tenga la responsabilidad y la información en su desempeño.
Cómo se distribuyen las tareas en los diferentes roles de Scrum
Imágenes cortesía de Pixabay (Jefe de proyecto,
Propietario del Producto, Equipo de desarrollo y Scrum Master)
Tareas de gestión de los diferentes roles
de un ejercicio de Alexandre Magno
El Propietario del Producto es quién desempeña las tareas de macrogestión, al fin y al cabo es el responsable de comprometerse con el objetivo que se quiere lograr, elaborar y comunicar la visión de negocio, definir los requisitos de lo que hay que hacer y dar el contexto en el cuál se va a utilizar lo que ha de construir el equipo de desarrollo. Se encarga de tareas, que en un contexto clásico hace un jefe de proyecto, como:
  • Comunicación con el cliente
  • Definición de requisitos
  • Gestión de prioridades
  • Retorno de inversión
  • Estrategias de entrega del producto
  • Planificación del proyecto
  • Costes/tiempos/alcance
  • Gestión de dependencias
  • Pruebas de aceptación
  • ...
El equipo de desarrollo es quién hace la microgestión, son los que estiman y deciden lo que cabe en la pila de sprint, para luego construir el incremento a lo largo del sprint, son ellos los que seleccionan las tecnologías adecuadas y organizan su trabajo de la forma más óptima posible, y lo hacen a través de microplanificación diaria. Asumen tareas de una jefe de proyecto clásico como:
Finalmente está el Scrum Master quién desempeña las tareas de gestión de personas y del proceso. Él es quién se encarga de formar y acompañar al equipo en su camino hacia la autoorganización, impulsa su desarrollo profesional y desbloquea sus motivaciones intrínsecas. También es quien se encarga de optimizar el proceso a través de la mejora continua. Se encarga de tareas de un jefe de proyecto como:
Como podemos ver en Scrum todas estas tareas las realizan los roles que tiocan las realidades que requiere las mismas.

Mi agradecimiento a Alexandre Magno quién arrojó mucha luz sobre esta cuestión.

domingo, 24 de septiembre de 2017

¿Qué hace un Chapter Lead para coordinar los equipos en la disciplina en que es experto?

Chapters transversales por equipos en una tribu
Henrik Kniberg & Anders Ivarsson
Vivimos en tiempos en que los equipos Scrum, más o menos bien entendidos, ya son una realidad, y en diversidad de casos ya nos encontramos ante la necesidad de que los especialistas de diferentes equipos se encuentren alineados y coordinados. Para ello quiero hablar del Chapter Lead, un rol transversal entre squads (equipos) de una tribu, originario del modelo de Spotify.

Recordemos que los chapters los forman miembros de equipos que trabajan dentro de una misma disciplina. Los equipos podrían estar formados por ejemplo por desarrolladores de front, algunos del back, DBAs y QA. En ese caso un chapter podría ser el del front, donde los desarrolladores de los diferentes equipos se reúnen para intercambiar ideas, obtener ayuda en sus retos y compartir y discutir sobre nuevas tecnologías.

De ahí nace el rol del Chapter Lead, un experto y responsable del chapter para esa disciplina específica. Es un líder al servicio que se centra en entrenar y ayudar a los miembros del chapter a crecer en su función.

Responsabilidades
  • Ser líder al servicio del chapter, ser responsable de, inspirar y hacer crecer al equipo, ser punto de referencia dentro del chapter
  • Ayudar a los miembros del chapter en su desarrollo, tanto en sus habilidades duras como en las blandas, a explotar sus fortalezas y a manejar sus debilidades, a través del coaching, tutoría y feedback
  • Organizar, estimular y alentar la colaboración entre los miembros del chapter
  • Asegurarse de que los miembros están debidamente equipados para realizar su trabajo lo mejor que puedan y entregar grandes cosas
  • Ayudar a desarrollar y evangelizar grandes prácticas de ingeniería así como Impulsar las prácticas de desarrollo más punteras en el equipo y la organización
  • Dado que tiene visibilidad en varios equipos, aplicar estrategia a los diferentes desarrollos transversales en su disciplina y asegurarse de que todos los miembros del chapter estén alineados
  • Garantizar que los miembros del chapter respeten los valores, normas y políticas definidas por la organización
  • Formular proactivamente recomendaciones sobre cuestiones de organización y posibles cambios en la organización de los equipos como intercambiar miembros del chapter de un equipo a otro
  • Colaborar con los demás roles de la tribu, como Propietarios del Producto, Scrum Masters, Agile Coaches, Tribe Leads... para liderar la tribu
  • Trabajar con el equipo de recursos humanos para atraer, reclutar y retener a los mejores talentos de su disciplina
Chapter Lead Meeting :-D
Un Chapter Lead pertenece a uno de los equipos de la tribu, por tanto, a diferencia de un jefe de desarrollo técnico, es un miembro más de su equipo que está involucrado en el diseño y la construcción de lo que está desarrollando en su equipo.

Una parte de su tiempo, entre un 20% y un 40%, la dedica a liderar el chapter, no interviene directamente en lo que otros equipos estén desarrollando, pero si puede apoyar y ser consultado si se le solicita.

Un buen Chaper Lead siente completitud con como los miembros de chapter crecen y se desarrollan, con lo que entre todos se construye y aporta al propósito de la organización. Si fue un jefe de desarrollo técnico debe de comprender que debe de abrazar esta nueva mentalidad y alejarse de darle importancia a la autoridad implícita que pudiera tener como experto y sentir el impulso de llevar al equipo por el camino adecuado, más bien se trata de hacer que encuentren el mejor camino acompañándolos y guiándolos como experto.

sábado, 16 de septiembre de 2017

¿Cómo representar Scrum técnico en una imagen?

El póster Scrum - @mariadelamareria
Habéis oído el refrán "Una imagen vale más que mil palabras". Yo andaba hace tiempo dándole vueltas a tener una imagen que sirviese para explicar lo que es Scrum técnico.

Según Scrum Manager hay dos formas de adopción de Scrum: técnica y pragmática. Cuando se adopta Scrum técnico se siguen unas reglas definidas, mientras que en la pragmática los equipos basándose en la experiencia acumulada pueden ir rompiendo las reglas para ejecutar un Scrum más acorde a sus necesidades específicas.

Ha sido hace unas semanas cuando alguien muy cercano a mí, me dijo: "si quieres preparo las imágenes". Y hala, nos pusimos a trabajar. Aunque esto no ha sido un desarrollo de software, la forma de trabajo se ha ajustado a los valores y principios del Manifiesto Ágil.

Empezamos por tener tres charlas a modo de sprints en las que le explicaba a la diseñadora cual es el proceso a seguir para desarrollar software con Scrum. Después de cada charla, ella me enseñaba algunos personajes y dibujos que representaban lo que le explicaba. Cuando ya tenía algunos personajes y dibujos seleccionados, me pidió que escribiera el proceso que le estaba contando. Tras esto realizó el diseño y me mostró la primera versión del póster. Sobre este le pedí cambios y este proceso lo repetimos 3 veces. En todo momento durante el proceso, aclarábamos las dudas que surgían manteniendo comunicación cara a cara o por whatsapp.

Tras esto le pedí su visto bueno a mi amigo Alex que puso su granito de arena, sugiriendo el cambio de algunos textos.

Tras este proceso en el que empleamos una gran dosis de ilusión obtuvimos el póster de la imagen.

Descargas / Downloads

martes, 12 de septiembre de 2017

¿Cómo aplicar Agile y Scrum en proyectos de infraestructura?

Proyecto de actualización en el CPD - Cortesía de Pixabay 
Los proyectos de infraestructura son aquellos que se producen en las áreas de sistemas y de arquitectura, suelen ser cosas como:
  • Actualizaciones de hardware o de software
  • Instalación de la infraestructura necesaria para que una aplicación de producto se pueda desarrollar y/o ejecutar
  • Instalación masiva de BBDDs distribuidas
  • Cambios de plataformas de correo
  • Migraciones masivas de BBDDs por cambio de versión del SGBD
A diferencia de los proyectos de producto, en los que siempre se construye algo "nuevo", los proyectos de infraestructura no siempre implican algo nuevo, pueden tener requisitos bien definidos y dependencias conocidas, lo que ocurre es que la incertidumbre emerge en forma de problemas imprevisibles. Por tanto la complejidad de los proyectos de infraestructura puede ser de menor grado, pero cosas como los problemas y otras restricciones, como que algunas de sus tareas solo se puedan realizar dentro de ventanas permitidas (fines de semana o fuera de horas de oficina) por ejemplo, hacen que Agile y Scrum puedan aportar grandes beneficios. También aquí la creatividad de las personas es esencial para la resolución de problemas, así como para encontrar maneras de hacer el trabajo de la forma más eficiente posible.

En este tipo de proyectos hay que averiguar qué ofrece valor, habitualmente suele tratarse del ahorro de costes o del coste de la demora para habilitar la construcción de funcionalidades de producto que si tienen valor de negocio. En un proyecto de migración a la nube por ejemplo, puede medirse el ahorro de costes asociado con el espacio de disco y la utilización de la CPU, y en un proyecto de infraestructura para un producto puede medirse el coste que representa el retraso en la puesta en marcha de una determinada funcionalidad.

La ejecución de Scrum se hace de la misma manera que en un proyecto de producto, la clave siempre está en los puntos de feedback y de integración que ocurre a final de cada uno de los sprintsPor ejemplo, si te tratara de un cambio de la plataforma de correo, se puede empezar por un grupo reducido de usuarios, los que estén a favor del cambio, se migran y se toma feedback, se hacen los ajustes correspondientes y se migra el siguiente grupo. Lo mismo para las BBDD, se empieza por una, se comprueba, se toma feedback y a por la siguiente.

Nunca es buena idea cambiar todo a la vez, cuando puede haber imprevistos es mejor empezar de forma acotada y expandir paso a paso, a través de sprints y priorizando por criticidad, ahorro de costes, coste de la demora, valor... una migración de servidores, por ejemplo, se podría afrontar incrementalmente incorporando en cada sprint nuevos servidores para dar servicio a los productos de más valor en función de los segmentos de cliente que más importen.

lunes, 11 de septiembre de 2017

¿Cuáles son las 50 mejores prácticas de Scrum para un Dream Team?

El otro día estábamos compartiendo un post de Kevin Wood, publicado en febrero de este año, que nos habla de las 50 mejores prácticas de Scrum "50 Best Scrum Practices for Dream Team" y nos pareció tan útil y tan relevante para cualquiera que esté involucrado con Scrum, que decidimos traducirlo al castellano para que todos los interesados puedan tener acceso a él. Aquí os compartimos nuestra traducción:

Scrum es uno de los frameworks más populares para implementar Agile. De hecho, muchas personas creen que Scrum y Agile son la misma cosa, aunque definitivamente no lo son. Agile es un grupo de metodologías de desarrollo de software basado en el desarrollo iterativo, y Scrum es un subconjunto de Agile pero con sus propias peculiaridades debido al compromiso con iteraciones cortas.

Con Scrum, los productos se construyen en una serie de iteraciones de longitud fija (sprints). Esto permite a los equipos entregar software a intervalos regulares, recibir retroalimentación rápida y adaptarse rápidamente a los requisitos cambiantes.

Aquí se presenta una lista de las mejores prácticas de Scrum que han demostrado su efectividad para ayudar a mejorar la calidad y aumentar la productividad, para entregar un producto que aporte valor y que cumpla con los objetivos de negocio.
Equipo
  • Los miembros del equipo trabajan en roles multifuncionales
  • El equipo tiene el equilibrio adecuado entre los desarrolladores y el QA (2: 1 o 4: 1)
  • Los miembros del equipo colaboran para entregar en primer lugar historias de alta prioridad
  • Los miembros del equipo piden ayuda proactivamente
  • Los miembros del equipo se dan feedback constructivo mutuamente y de manera oportuna
Scrum Master (SM)
  • El SM facilita la autoorganización del equipo
  • El SM se enfoca en remover impedimentos (problemas de recursos, problemas o desobediencia en la implementación de prácticas de Scrum)
  • El SM protege al equipo de distracciones externas e internas
  • El SM permite una estrecha cooperación en todos los roles
  • El SM interactúa con la alta dirección
Propietario del Producto (PP)
Definición de Hecho o Definition of Done (DoD)
Estimación
Reunión de planificación de Sprint
Sprint
Pila de Sprint (PS)
  • La PS está visible y es de fácil acceso para el equipo
  • La PS se actualiza todos los días
  • Las estimaciones de las tareas se actualizan todos los días
  • Los miembros del equipo actualizan la PS por ellos mismos
  • Las historias están claramente mapeadas
Scrum Diario (SD)
  • El SD tiene ocurre a la misma hora y lugar todos los días
  • El SD comienza y termina puntualmente
  • Todos los miembros del equipo están involucrados
  • El PP participa en la reunión por lo menos unas pocas veces por semana
  • El equipo revisa el gráfico de burndown y toma medidas si van retrasados
  • El SD dura como mucho 15 minutos – todas las discusiones tienen lugar después
Revisión de Sprint
  • La demo formal se realiza después de cada sprint
  • Sólo las historias aceptadas por PP se demuestran
  • Todos los interesados se han invitado para la demo con antelación
  • Se anima a las partes interesadas a dar su opinión durante la demo
Retrospectiva
Sobre el autor: Kevin Wood es Gerente de Desarrollo de Atlaz y tiene una gran experiencia en finanzas y administración de negocios. Su profunda comprensión de los principios de mercadotecnia y sus excelentes habilidades analíticas, le ayudan a identificar ideas de tendencia, a evaluar riesgos y a encontrar los mejores potenciales para las necesidades y metas de sus socios.

Mis agradecimientos a Gertrudis López por la traducción conjunta, link al post en su blog "Agile: lo bueno, lo feo y lo malo"