CONFERENCIA AGILE SPAIN 2018 (CAS 2018) PRIMERA JORNADA

Los pasados días 13 y 14 de diciembre, se celebró en Alicante la Conferencia Agile Spain 2018 en su novena edición.  Es un punto de encuentro internacional para los profesionales interesados en las metodologías ágiles.

Los objetivos del CAS 2018 buscan promocionar y divulgar el uso de las metodologías ágiles en organizaciones españolas, así como tratar de crear sinergias mediante la compartición de conocimientos y experiencias , además de servir como plataforma para la realización de proyectos de cooperación entre todos.

Nuestra empresa fue uno de los patrocinadores del evento. Y dado que la Dirección está comprometida con la transformación cultural enfocada a la mejora y a la eficiencia, un buen grupo de compañeros pudimos disfrutar de la experiencia de asistir a este interesante evento.

A nivel general, destacar que las salas donde se desarrollaron las ponencias eran muy desiguales en cuanto a aforo disponible, unas salas eran muy pequeñas y otras muy grandes. Respecto a los contenidos de las ponencias, la organización de CAS 2018 se comprometió a proporcionar los vídeos grabados de todas ellas a través del canal de Agile Spain de Youtube a partir de enero. A los talleres solo se podía asistir mediante inscripción y sorteo. Por otra parte, la comida que se sirvió fue abundante y variada.

Por cuestiones de agenda, no pudimos asistir a  la primera ponencia, a cargo de Lyssa Adkins llamada «We are the Leaders we have been Waiting For». No obstante, a la espera del vídeo oficial, desde aquí se puede acceder a una grabación de su misma charla en otro evento, fechada en marzo de este año, en formato vídeo:

Las ponencias a las que asistí fueron las siguientes.

PRIMERA JORNADA:

1 ING: HAZ EL CAMBIO Y LUEGO HAZ QUE FUNCIONE –  IVÁN CORPS

Iván comento, para dar contexto, que ING en un grupo holandés que tiene 160 años y cuenta con 34 millones de clientes (10% en España) . Están en España desde 1982. Son 52.000 profesionales en todo el mundo  (2% en España).

Para ING transformar significa:

  1. Ejecutar eficientemente la estrategia (ejecutar las prioridades, tener foco y ser adaptativos)
  2. Aumentar el compromiso de los empleados (pues al final son los que cuidan a los clientes)
  3. Mejorar la manera de colaborar entre todo el equipo.

Iván Corps lleva dos años y medio ejerciendo de Agile Coach en ING. Con dos misiones específicas:

  1. Acompañar a una «tribu». En concreto a la del «Daily Banking» (medios de pago, cuentas, servicios digitales)
  2. Formar parte del equipo de transformación

Hubo varias etapas  en la transformación. Un primera etapa fue desde el nacimiento ING hasta enero 2018, para preparar la transformación. Se dedicaron 40 días a esta labor.

Hay que tener en cuenta de que desde 2012 al 2017 ING ya tenía una cultura de mejora continua, (Scrum , WIP con Kanbam, PMO Agil…), y que la cantidad de servicios digitales entregados ya era muy grande.

Se lanzaron dos iniciativas: una con dos proyectos célula (con un equipo multi disciplinar)  y otra referida a compartir ideas  con los compañeros de ING Holanda.

El equipo holandés  comentó que en la empresa habían delimitado cuatro áreas fundamentales: Delivery, Ventas, Servicios (operaciones) y Soporte. Ellos ya habían generado un modelo de referencia con su aprendizaje, que le pareció muy interesante y aprovechable cara modificar la unidad de Delivery. Contenía a Marketing, Negocio, IT, Comunicaciones e Innovación (sobre 700 profesionales)

Al CEO esto le «sonó» familiar, pues cuando él estuvo en la empresa en una primera etapa y se convirtió en un enorme apoyo. Es más, quería el cambio para ya mismo.

Se pusieron a trabajar en el CÓMO con un equipo de transformación, con cuatro características que debería de cumplir: relevante, influyente, balanceado y empoderado.

Y empezaron a trabajar  en la transformación con un backlog dividido en cuatro grandes bloques:

  1. Un nuevo diseño organizacional, basado en el modelo de Spotify y basado en buscar cadenas de valor independientes. Formado por nueve tribus y cinco COES. (Center of Expertise)
  2. Un nuevo modelo de RRHH. Nuevas funciones y nuevos roles
  3. Actualización del entorno de trabajo. Las Tribus deberían trabajar juntas. Fuera despachos y dentro «Salas Obeya«,  basado en experiencias de Toyota.
  4. Nueva manera de trabajar. Explicando los valores, los principios, los frameworks  y las formas  de trabajar (en tres oleadas). Compartiendo toda la información con las personas impactadas por el cambio. Durante la Agile Week se explico el porqué del cambio, el cómo del cambio, roles, tribus, squads, chapters, y se porporcionó formación. Lo mas interesante fue el ejercicio del «vaciado de bolsillos» (en qué estaba trabajando cada uno y estas tareas se repartían en el backlog a un responsable, squad o tribu).

Ya llevan ocho meses en Delivery, donde han recolectado unas enseñanzas básicas.

Mejoras:

  1. Los niveles directivos estaban muy comprometidos
  2. Soporte local y del grupo. Se consultaba  a otros grupos. sobre los problemas y sus soluciones. Escuchar las preocupaciones de las personas, pues las personas van a diferentes velocidades. Les funcionó muy bien seguir el modelo de gestión del cambio ADKAR (Awareness, Desire, Knowledge, Ability, Reinforce).
  3. Equipos multi disciplinares. Es ideal para producir conversaciones inspiradoras.
  4. Mecanismos de alineamiento, por ejemplo, las Salas Obeya ya mencionadas construidas para uso de todas las tribus.
  5. Convivir con los objetivos de la organización. Se obtuvo un máximo de clientes de  «cuenta nómina» con un mínimo de incidencias. Es el «Learn by Doing» , es decir, aprender haciendo.

Aprendizajes:

  1. Llevó tiempo explicar que esto no era solo una reorganización, sino que era una reorganización y también un cambio en la forma de trabajar.
  2. Se necesita mucho más aprendizaje que el inicialmente planificado. Hubieran sido necesarios más talleres.
  3. Se sufre cuando se rompen «silos». Hay que volver  a aprender  a trabajar (Modelo de Tuckman)
  4. Equipo de agile coaches. Todos los coaches tienen ideas sobre cómo hacer las cosas, como todos saben qué hacer es agotador. Ya han cambiado tres veces de forma de trabajar.
  5. Asumir la pre asignación de roles a personas. Todos los empleados tienen un nuevo rol. Pero hay personas que, a pesar de todo, deciden abandonar la empresa.

Como resumen, Iván destacó que un proyecto de este tipo hay que ser valientes, ser humildes y tener claras las batallas en las que merece la pena pelear (o no). Disfrutar del viaje, recomendó Iván, pase lo que pase.

Los archivos de las presentaciones aportadas por el ponente se pueden consultar aquí:     Presentación 1    Presentación 2

 

2 LIDERAZGO PARTICIPATIVO, UNA NUEVA MANERA DE DESARROLLAR ORGANIZACIONES CAÓRDICAS – ISRAEL ALCAZAR

Israel comentó que vivimos en un mundo VUCA,  acrónimo utilizado para describir o reflejar  la Volatilidad, incertidumbre (Uncentainly), Complejidad y Ambigüedad de condiciones y situaciones. Los móviles Nokia o las cámaras Kodak son un buen ejemplo de esto.

El mundo actual plantea nuevos retos y nuevas estructuras organizacionales. Se debería buscar la anti-fragilidad, es decir, aprovechar el cambio para hacerse más poderoso. O el enfoque de Federic Laloux en su libro «Reinventar las Organizaciones«. Lo ideal sería llegar a ser una organización modelo TEAL (que son las empresas que fomentan la auto organización, el auto propósito y la plenitud de las personas).

Todos los modelos hablan de la importancia de la adaptación y de tener un propósito. Y que haya un equilibrio entre el orden y el caos. Se necesitan organizaciones de este tipo. La naturaleza cumple con este esquema. La naturaleza se adapta continuamente, tiene un propósito, es auto organizada, y tiene un orden y una estructura. Como todo sistema tiende al caos, es necesario aportarle energía para evitar el caos absoluto. El propio cuerpo humano tiende al orden. Se necesitan unas estructuras mínimas para evitar el caos.

Es lo que se llaman Organizaciones Caórdicas, que están entre un exceso de caos y el exceso de orden. Este término lo acuñó Dee Hock, en su libro «The Chaordic Organization: Out of Control and Into Order». Fue fundador de VISA.

Usando metáforas podemos contemplar a las organizaciones como sistemas vivos:

  • Solo acepta sus propias soluciones. En las organizaciones, si no implicamos a las personas impactadas en la solución, no la harán suya y no desearán participar.
  • Sólo prestan atención a lo que tiene sentido para ellos en el aquí y en el ahora. Es decir, hay que prestar atención a la tensión existente pero no a todas las tensiones, pues sería agotador.
  • Participa en el desarrollo de sus vecinos. Un departamento que se aísla se hace cada vez más pequeño y perjudica al resto.
  • Está en continuo cambio, pero no tiene un sistema de gestión del cambio. El cambio es y debe ser algo natural
  • Busca diversidad, de género, de edades, de culturas. Los equipos con más diversidad son los equipos más exitosos y los que aportan más valor, aunque no sean fáciles de gestionar.
  • Buscan las mejores soluciones que funcionen, no las soluciones perfectas. Es buscar la solución que sirva
  • No pueden ser controlados en su totalidad. Se pueden monitorizar, pero no controlar completamente. Solo se puede gestionar el trabajo, pero no a las personas.
  • Todos sus miembros obtienen mejores resultados juntos que por separado. Es usar la inteligencia colectiva frente a la individualidad.

Pero en las organizaciones actuales  la mayor parte son estructuras piramidales, que fomentan la estabilidad y la eficiencia. Y  de forma paralela, se crean estructuras informales para solucionar problemas, que tienden al caos, pues nadie puede obtener sus objetivos sin la ayuda de los demás. Se deberían de fomentar las estructuras informales, pero añadiendo  un poco de orden y orientadas a la generación de valor.

Y el ponente se preguntó qué tipo de liderazgo debería de existir en este tipo de organizaciones. Serian líderes que fomenten el liderazgo de otros y la auto organización de las personas. Y esto se fomenta poniendo algunos límites,  pero dejando que el equipo busque sus propias soluciones. Se debe buscar una situación equitativa, que no igualitaria. Se necesitan solo establecer unos principios guía, las reglas básicas de juego. Por ejemplo, si se presupone la transparencia, que cada persona decida cómo actuar respetando ese principio-guía.

Los líderes deben promover la diversidad en los equipos. Aunque sea complicada. Y ver el conflicto como una oportunidad de desarrollo. Y se debe promover el  liderazgo participativo, que potencie las nuevas estructuras organizaciones, que fomente el liderazgo de otros y que fomente la auto organización y la auto gestión.

Las mejores herramientas de ingeniería social para buscar soluciones son sencillas: la conversación y el feedback.  Parecen sencillas, pero son complejas de llevar a la práctica.

Herramientas más concretas son:  Art of Hosting, la Estructura en Círculo, Open Space, herramientas sociales que fomentan conversaciones productivas. Liberating Structures , Visual Thinking. O  A3 Thinking.

Conclusiones:

  • La complejidad solo puede ser gestionada con complejidad.
  • Es útil usar la metáfora de las organizaciones como seres vivos y no como máquinas.
  • Se debería fomentar el Liderazgo Participativo.
  • No hay solución para todo. Las soluciones deben ser adaptadas a los problemas actuales de la empresa. Las soluciones de Toyota solo eran válidas para Toyota y adaptada a ese momento concreto. Son difícilmente exportables a otras situaciones.

Acceso al SlideShare de la Presentación:

 

3 RIGHTS AND RESPONSABILITIES OF A DELIVERY TEAM – SANDRO MANCUSO

Sandro lleva trabajando en agilidad desde los 17 años de edad. En un único proyecto en concreto fue feliz porque la agilidad funcionaba. El producto no funcionó pero en  11 meses lo supieron. Y la empresa no necesitó invertir más, es de decir, ahorraron dinero.

Es decir, solo un proyecto de 11 meses en un lapso de tiempo de 14 años fue considerado como ideal al efectos de metodología ágil. En el resto hubo problemas. A partir de esta situación, el ponente se preguntó si sería posible que el equipo de Delivery  llegara a un acuerdo satisfactorio con Sponsors y como sería eso. Implicaría establecer responsabilidades y derechos para el equipo de Delivery. La regla de oro para los equipos de Delivery sería:

  • Reducir el lapso de tiempo entre las ideas y el software funcionando
  • Habilitar a negocio a que trabajen estratégicamente (probando cosas)
  • Concentrarse en las entregas útiles a negocio (no solo en cumplir con  los tickets de Jira)
  • Entrega continua

Cual sería la composición ideal del equipo de Delivery. Según Scrum, debería de estar formado por: un Product Owner (PO), un Scrum Master (SM) y un Delivery Team.

Pero vieron que el PO rara vez es parte del equipo. En teoría, el PO debería de tener estas funciones:

  • Ser parte del equipo. Pero no  lo suele ser.
  • Ser responsable de maximizar el valor del producto
  • Debería ser el único que controla el Product Backlog del producto
  • Debe ser una única persona, no un comité. El es el único que debe marcar la prioridad de los items en el backlog
  • Se deben respetar las decisiones del PO por parte de la organización. Las decisiones del PO deben ser visibles. Nadie debe forzar al equipo a trabajar en otro tipo de requerimientos

Cómo se debería gestionar el backlog:

  • Debe expresar claramente los items
  • Ordenados los items para obtener mejor los objetivos
  • Optimizar el valor del trabajo del equipo de desarrollo
  • Asegurarse de que el backlog del producto es visible, transparente y claro
  • Asegurarse de que el equipo de desarrollo entiende el los items del backlog, al nivel adecuado
  • El PO debe hacer todo esto mencionado, o dejar que el equipo lo haga. Sin embargo, el propietario del producto sigue siendo responsable

Por otra parte, el rol del Scrum Master (SM) implica:

  • Ser responsable de apoyar al equipo, como se define en la Guía de Scrum (19 páginas). Ayudan a entender la teoría scrum y sus reglas, valores y prácticas.
  • Ser un líder sirviente del equipo. Ayudar a los que están fuera del equipo a entender la utilidad de sus interacciones con el equipo y ayudar a cambiar estas interacciones para maximizar el valor creado por el equipo de scrum.
  • El ponente afirmó que el papel del SM es un papel demasiado especializado. El equipo podría hacer esto solo.

En el modelo de organización de Spotify, que es uno de los más avanzados que existen, existen las squads, equipos multifuncionales, cada una con una misión diferente y mucha autonomía trabajando con una estrategia global. El problema de los equipos autónomos es que es difícil mantener a los equipos alineados en un único objetivo. Y ellos tienen a un PO que forma parte del equipo como en scrum. Todos son responsables. Y no tienen un SC dentro del equipo, pues no hace falta. Esta es la principal diferencia entre el modelo Spotify y el modelo Scrum. Y ojo, llamar a los equipos «squads» y a los SM llamarlos «squad masters», no convierte a tu empresa en un modelo como el de Spotify. Es un error.

En un modelo ágil,  en un lado están los stakeholders, de otro el equipo de desarrollo, en otro los PO y en otro los Coach Ágiles/Scrum masters. Pero es que los SM no son parte del equipo, lo único que hacen es decir al equipo lo que tienen que hacer, y esto es un problema, pues va en contra de la autonomía de los equipos.

Los problemas en la composición del equipo que el ponente manifestó fueron los siguientes:

  • El SM es inútil y puede ser sustituido por el equipo fácilmente
  • El PO frecuentemente no es parte del equipo. Perteneces a una organización vertical.
  • PO se comporta como un Project Manager autoritario, pues ve al equipo como una entidad separada que trabaja para el
  • El equipo de desarrollo responde no solo ante el PO sino también ante el CTO, los arquitectos y a veces, ante los coaches agiles
  • El equipo de desarrollo es responsable, pero pocas veces tiene suficiente autonomía para gestionar sus problemas.

Una mejor aproximación es hacer a los equipos autónomos y que el PO realmente forme parte de ellos. Y que no se resuma el trabajo del equipo en contar cuantos tickets de Jira se han cerrado sino en hacer caso a problemas de negocio, por ejemplo, evaluar cuanto se ha vendido o si se ha incrementado el número de clientes. Esos son  las necesidades de negocio que deben ser cubiertas. Y que el PO ayude al equipo a entender los problemas que sufre negocio, pues es el más adecuado para esta labor.

Un buen acuerdo  sería «establecer un contrato de trabajo entre el equipo y los stakeholders en le cual los derechos y responsabilidades estén acordados».

DERECHOS DEL EQUIPO DE DESARROLLO:

  • A definir la estructura del equipo.
  • Acceso a la estrategia de negocio y  a los stakeholders
  • Definir el proceso de trabajo
  • De no ser responsables de las cosas que no controlan
  • A entender los objetivos de negocio
  • A tener autonomía para crear soluciones
  • A controlar el tiempo o el alcance
  • A obtener apoyo cuando se enfrentan a factores externos
  • Al intercambio de feedback regular
  • A trabajar con colegas respetuosos
  • A experimentar y a aprender

RESPONSABILIDADES DEL EQUIPO DE DESARROLLO:

  • A proporcionar un servicio profesional
  • Actuar en el mejor interés de negocio
  • A maximizar el valor proporcionado
  • A entregar valor de forma contínua
  • Habilitar  a los stakeholder para que puedan planificar
  • Alinear las estrategias de negocio y de las tecnología
  • Buscar la excelencia
  • Proporcionar continuidad
  • Asegurarse de que el equipo está siempre desarrollando
  • Entregar objetivos del equipo, no objetivos de individuales
  • Crear un entorno de desarrollo respetuoso

Es obligatorio alinear la intersección entre negocio (diseño de producto) y tecnología (diseño de software). Si este área es pequeña hay un problema. Estas dos áreas no pueden ignorarse.

Por último, el equipo debe pasar de ser un equipo de desarrollo a ser un equipo de resolución de problemas

Conclusiones:

  • Se tienen derechos, en tanto en cuanto las responsabilidades estén cumplidas
  • Los derechos y responsabilidades deben estar equilibrados
  • Pueden servir como un compromiso de trabajo entre el equipo de negocio y de entrega.
  • Negocio y tecnología son un solo equipo
  • Debe ser un equipo solucionador de problemas, en lugar de equipo de desarrollo
  • Proceso de diseño de producto y de software entrelazados

Me ha parecido una ponencia muy recomendable. Es valiente contar realidades, aunque estas sean incomodas y  vayan en contra de los estándardes.

 

4 NO RETROSPECTIVES – TONI TASSANI

Aunque esta ponencia estaba planificada que fuera desarrollada en castellano, el ponente preguntó a la audiencia si había algún impedimento para explicarla en inglés. Y así lo hizo.

El principal objetivo de la sesión es permitir a los asistentes que lanzara una mirada crítica a la agilidad, poniendo foco en las Retrospectivas y pasarlas por el tamiz de la experiencia y el sentido común.

Toni trabaja como «Catalyst» en la empresa Ocado.  Su labor se resume en hacer que el trabajo sea mas efectivo.

Llegó a sus oídos que las sesiones de Retrospectiva no estaban funcionando correctamente. Dado que esto impide la mejora continua se puso a estudiar qué es lo que estaba pasando.

Estudió la «Ladder of inference». Esta llamada Escalera de la Inferencia fue desarrollada por el estadounidense Chris Argyris, un ex profesor de la Escuela de Negocios de Harvard. Muestra cómo los modelos mentales se forman inconscientemente.  Las personas observan la realidad, seleccionan los hechos de los eventos, interpretan los eventos, hacen suposiciones, sacan conclusiones, buscan en sus creencias y entonces la persona procede a actuar. Para evitar este error se debe asumir que estamos mediatizados por las experiencias previas  y nuestras creencias (que no cuestionamos).

Las limitaciones se pueden convertir en oportunidades de mejora.  Una primera limitación es la obligación de hacer sesiones retrospectivas obligatorias. En los Principios del manifiesto ágil podemos leer: «A intervalos regulares, el equipo reflexiona sobre cómo ser más efectivo, luego ajusta y ajusta su comportamiento en consecuencia». Muchos agilistas traducen esta declaración directamente a «Retrospectivas». Pero no son obligatorias. No se quiere caer en los «Scrum buts» y por eso se hacen.

Otra limitación es la inercia.

Problemas detectados en las retrospectivas, que pueden convertirse en riesgos:

  1. Evitar conversar sobre los problemas específicos. Es decir, limitarse a poner una nota sobre el problema en la retrospectiva, que no puede valer entonces para nada.  No se debe esperar y se debe tratar el problema en el  momento en el que se produce a través de una conversación.
  2. El llamado Teatro de los Post-It. Es un escenario de un equipo enel cual no hay mejora sino mucho  movimiento de notas post it.
  3. Optimizaciones locales. Es el problema de estar centrados solo en el equipo (team centrics). Y no pensar en la estrategía o en lo global, sino solo en el equipo.
  4. Solucionar problemas individuales, uno detrás de otro. este enfoque de los problemas evita encontrar una causa raiz y obtener una única solución.
  5. Cambiar por cambiar, pero no producen una mejora.
  6. Malos experimentos, que parecen buenos pero no van a ser valiosos por la forma de enfocarlos y realizarlos.

Todo esto va de obtener «mejora continua». Y de evitar restricciones. Para obtener esa mejora continua puede ser útil conocer estas herramientas:

  • Improvement Board
  • Popcorn Flow
  • Improvement Kata
  • Service Delivery Review

Y siempre manteniendo un espíritu de investigación sobre lo que puede ser interesante para obtener mejora continua.

 

5 IMPLANTACIÓN  DE AGILE LPM EN LA FIRMA DE ABOGADOS CUATRECASAS – JOAN OLIVERAS

Fue una lástima que esta ponencia se desarrollara en la sala más pequeña, la sexta, porque había público a reventar,  y muchos tuvieron que asistir a la misma de pie.

Se presentó el caso real de la implantación del LPM (Legal Project Management) en la firma de abogados Cuatrecasas, en su versión agile.

Joan dividió su ponencia en tres partes.

Problema:

La crisis ha hecho que el crecimiento de la facturación año tras año de los despachos de abogados se diera por finalizada. A los despachos  no les preocupaba la gestión porque se facturaba mucho dinero. Ahora se deben hacer cosas que no se les había planteado, como es mejorar la gestión de los casos y trabajar con márgenes más ajustados.

Solución:

Joan comentó que, en un primer momento, se tuvo en cuenta la gestión predictiva de los casos, pero rápidamente se dieron cuenta de que los abogados no veían útil este enfoque basado en proyecto predictivo y pasaron al enfoque agile del LPM. Los abogados son muy pragmáticos y si algo no funciona no lo van a utilizar.

Los abogados no están acostumbrados a gestionar, son muy buenos en lo que hacen pero necesitan obtener la capa de gestión, y lo saben. Por ello, comenzaron a gestionar los casos de los equipos estables utilizando kanban en un proceso definido que incluía litigios. La transparencia es un problema porque los abogados trabajan en un entorno de «Up or Out» (Arriba o fuera) que está alejada de la colaboración. Joan explicó la forma en la que se delega, diciendo: «haz esto» pero sin explicar el entorno. Y unos abogados están sobrecargados y otros hacen pocas tareas.

Se introdujo el Visual Management para obtener una visión global de todos los asuntos abiertos y realizar su seguimiento. Les ayuda  a obtener una visión global del asunto  y ofrece transparencia y colaboración. Cuando los abogados vieron en un panel todo lo que gestionaban (algunos de ellos llevan hasta 50 casos a la vez) les pareció interesante porque les proporcionaba una visión global de sus tareas (toda la información sobre tareas y deadlines estaba solo en su cabeza).

Y también agregaron una reunión semanal para explicar la situación de los casos delante del tablero físico.  Posteriormente se añadieron las reuniones diarias (dailys). En esa media hora de la daily se ganó colaboración  y transparencia, que antes no existía.

Se buscó al abogado más involucrado para que hiciera de kanban leader. Porque el cambio debe ser interiorizado por ellos mismos.

Ahora trabajan en dos niveles:

  • Kanban de los socios. Con todos los casos
  • Dashboard de los abogados. Con todas las tareas

Ambos tableros están unidos. Fácilmente se puede ver la dedicación de cada abogado en todo momento. Han dado el paso de usar tableros físicos a tableros digitales (www.leankit.com).

Por último se montaron unos KPIs para hacer seguimiento, pero no son todavía operativos.

Cambio provocado:

El objetivo de entregar valor está cumplido y esto justifica el proyecto. Los abogados lo ven interesante y lo usan. Buscan que sean los propios abogados hagan de «obispo negro», es decir, que los propios abogados vendan el proyecto y otros compañeros pidan este cambio.

Progresivamente, se van introduciendo nuevas funciones y herramientas ágiles (CoS, WIP, etc…)

Este proyecto se lanzó en el año 2016 y sigue vigente (abarca ya a unos 70 abogados y 9 equipos).

Me quedé con ganas de más información. Esta ponencia me pareció una experiencia de lo más interesante. Y de lo más pragmática, los profesionales solo usan lo que consideran útil.

Como nota curiosa, anotad que Joan, siendo una persona muy cercana y accesible,  no acepta contactar  en Linkedin de quien no conozca personalmente.

 

6 «¿AGILE FUERA DE SOFTWARE? VMF FRAMEWORK + ENDESA COMO CASO DE ÉXITO»- XAVIER QUESADA, JOSÉ A. RANEA

Xavier y José Antonio presentaron el caso de la implantación de un marco de trabajo basado en VMF (Visual Management Framework) para extender Scrum  a tareas complejas en entornos productivos que no son del mundo de software, tales como las gestión de tareas recurrentes, tareas delegadas, tareas con deadlines, etc..

Comentaron que lo primero en un proyecto ágil es trabajar el liderazgo, cultura y valores. Pero la mentalidad ágil no es suficiente. también se debe reincorporar un rediseño organizacional . Y finalmente se necesita trabajar con las practicas del día a día, como son scrum y kanban. Y esto fuera de software puede quedar un poco corto. De esto hablan en esta ponencia.

Y para ilustrar el caso, pusieron el caso de «encargar» un bebé, como si fuera un proyecto ágil. Con tablero y todo.

El desarrollo y testeo se enfocó en equipos de logística y transporte, con un día a día compuesto de proyectos, tareas recurrentes, tareas con deadlines y tareas no planificadas. Para suplir carencias  de scrum y kanban en la gestión de un equipo se agregó el concepto de «calendario» (a tres niveles: macro, semanal y diario).

Otras diferencias con la agilidad en software son:

  • El Product Owner y de Scrum Master pueden ser la misma persona (algo prohibido en Scrum de software). No existe tanto trabajo del Product Owner con los stakeholders como en el entorno de software
  • Se pueden unir en una las sesiones de Retrospectiva más las sesiones de Sprint Review (R2).
  • Quizás la agilidad (como el flamenco) no es para todos los públicos, o al menos, hay que adaptarlos a la empresa y enfocarlo a la entrega de valor.
  • Había tareas derivadas de proyectos, tareas recurrentes y  tareas no recurrentes. Fundamental es que todos los equipos tengan claro el «Definition of Done» de las tareas, pero especialmente de las tareas recurrentes, pues es la única forma de mantener la calidad
  • Los equipos debe ser auto organizados. Y se debe meter auto reflexión en el equipo.
  • Fundamental es medir la capacidad del equipo, para no saturar al equipo con tareas que realmente no se van a hacer.

Como conclusión, un enfoque visual de este tipo proporciona grandes ventajas en materia de seguimiento del trabajo.

 

7 UNA VIDA DESCUBRIENDO AGILE – TOÑO DE LA TORRE

El ponente desea que conozcamos su trayectoria en el mundo de la agilidad, a modo de retrospectiva vital.

Toño descubrió el Manifiesto Ágil, complementado con  los valores del sprint de scrum (compromiso, coraje y foco) y con los de kanban, (transparencia y flujo).

En Madrid, en el año  2004 se incorporó a la empresa DIA y descubrió el agilismo. Su jefe allí, que se comportaba como un líder y no como un jefe  le recomendó un libro: «Pragmatic Programmer«.

En el año 2008 el paso a una consultora no fue una buena experiencia. Pero se trasladó al departamento de software libre, y de un jefe controlador pasó a a trabajar en un entorno Scrum, con responsabilidad y acceso libre al cliente. La CAS del año 2010 fue un festival donde conoció el mundo Agile y especialmente cuando pudo conocer a la comunidad, donde se compartía todo el conocimiento.

Un hito importante fue  la creación de la empresa Kaleidos y la ventaja de no estar en una empresa grande les permitió trabajar de forma ágil con sus clientes.

En el año 2012 oyó el termino Agile Coach y se quiso convertir en uno. Convocó la «Comunidad de Scrum Masters», que era un espacio para compartir experiencias. Pero en Kaleidos no había Scrum Master  y no era efectivo en su transferencia de conocimiento. Esto producía frustración. La enseñanza fue que cuando un grupo de gente no quiere hacer algo, no lo va a hacer.

Y llegó la crisis del Agile Coach.  En el año 2013, durante la CAS de Bilbao anunció que dejaba de ser Agile Coach. Solo quería ser uno más en el equipo.

Durante el año 2014 vivió una doble vida, pues en la comunidad ágil estaba en lo más alto, pero en su empresa (Kaleidos) estaba en crisis.

En el año 2015 tuvo la gran crisis, pues nada le llenaba. Buscó coaching y encontró a Hana Kanja, que fue una ayuda. Y quiso dar un giro a la situación. Volvió de Madrid a Oviedo y ya en Asturias se sumó a la empresas Codesai. Esta empresa está basada en  la desestructuración de cualquier concepto de procesos y herramientas, pues para ellos lo más importante son las relaciones y la entrega de valor. Adicionalmente, aprendió el proceso de dar y recibir feedback y la forma en la que la confianza de los equipos puede destruirse si suceden cosas graves.

En el año 201 8 Codesai se convirtió  en una cooperativa de siete socios. Actualmente el ponente está en un proceso de investigación acerca de cómo realizar una entrega de valor constante a los clientes.

Aprendizaje:

  • Siempre hay que volver a revisar cómo gestionar personas. Ser líder y no jefe.
  • Se debe aprender siempre.
  • El mentoring es muy recomendable.
  • Se debe agradecer lo recibido. La comunidad ha dado mucho y hay que responder para que la rueda siga girando.

Gran aprendizaje:

  • La respuesta ante el cambio y hay que vivir sin miedo

Los fallos técnicos sufridos durante el evento hacen difícil valorar la charla (una lámpara falló y el proyector dejó de funcionar). Una verdadera lástima.

 

8 EMPRENDIMIENTO CORPORATIVO- NESTOR GUERRA

Nestor comenzó su charla con una cita de Drucker: «Una organización tiene solo dos funciones básicas: marketing e innovación. El resto son costes».

Hay diferencia entre  riesgo y  la incertidumbre.  El riesgo se gestiona. No es lo mismo. La incertidumbre es lo desconocido. Los nuevos productos fracasan no por el riesgo sino por la incertidumbre. La innovación no es divertida, siempre es agresiva. Y se mueve en la incertidumbre.

Es un hecho que las compañías cada vez duran menos.  Los modelos de negocio de las empresas caducan y muchas eran excelentes en lo que hacían. Por ejemplo, el Banco Popular, que llegó a ser el cuarto banco mejor gestionado de Europa. Un indicador muy importante es que las compañías nuevas crecen más rápido. Y como nos enfocamos para resolver este paradigma. Pues innovando, claro, pero la pregunta es cómo hacerlo.

Y aquí surge el intra emprendimiento. Para entenderlo hay que entender el pasado y lo que fue mal. Un ejemplo fue caso de la quiebra de Iridium (fabricaron y lanzaron 77 satélites).  Que el producto funcione no significa que el negocio funcione.

En este punto de la charla, el ponente solicitó a todos los asistentes que completaran una encuesta en el móvil sobre lo que cada uno consideraba que fue el motivo del éxito de AIRBNB.

El intra emprendimiento es llevar adelante una actividad emprendedora en el interior de una organización existente con sus empleados y en actividades que no tienen nada que ver con su «core» de negocio. Pero hay dos dinámicas contradictorias que deben convivir en la empresa, una es la de tratar de innovar y la otra es la de ejecutar el plan de negocio, que es el que da de comer a la empresa. Las organizaciones ambidextras son las que saben hacer compatibles estas dos dinámicas.

Eric Ries, creador de Lean Startup, dijo que las compañías modelo son aquellas en los empleados pueden experimentar y que haya algún mecanismo en la empresa para que esa idea pueda llevarse al mercado.

Existen cuatro modelos de intra emprendimiento, en base al estilo de liderazgo y a los recursos asignados:

  • Oportunista (no existe una estrategia, los recursos se definen de manera informal y espontánea),
  • Facilitador (la empresa provee recursos a los intra emprendedores, siempre que consigan el apoyo de un directivo),
  • Productor (Existen mecanismos de apoyo integrales y formalizados para el conjunto  de los intra emprendedores),
  • Independiente (la empresa promueve activamente  el intra emprendimiento, pero es cada unidad de negocio la que asigna los recursos)

Estos modelos deben construir ecosistemas para que haya muchas ideas y que alguna de ellas germine. Y así se crea cultura.

Tres bloques dentro de la innovación:

  1. La estrategia de innovación:
    • Es importante la tesis de la innovación, hacia donde mirar a largo plazo
    • El portafolio de innovación. Cómo categorizar las ideas (por horizontes de innovación)
  2. Gestión de la innovación:
    • Framework de innovación
    • Contabilidad de la innovación, cómo medir el progreso de la innovación
  3. La puesta en práctica:
    1. Aceleradoras. Significa atraer talento de fuera
    2. Intra emprendedores, de dentro de la empresa

Nota importante. No se puede puede saber cuantos experimentos se deben hacer hasta llegar a iniciativas innovadoras. Matar proyectos es casi tan importante como hacerlos nacer.

Tres escenarios de las hipótesis:

  1. No es válida. Y se debe pivotar
  2. Que siga siendo incierta
  3. Que se valide. Y se debe avanzar a la siguiente fase.

Innovar es difícil por el mal uso que se hace de la palabra «experimento». Por ejemplo, solo hacer una pagina web no es un experimento. No se debe frivolizar con la experimentación.  La hipótesis define el método de investigación (Francis Bacon dixit). Se puede utilizar Lean Startup y Agilidad en la innovación, pero también hay mucho ya inventado.

Y hay umbrales en los cuales más experimentos no ayudan a reducir la incertidumbre. Y hay que tomar decisiones.

Lecciones:

  1. Es una iniciativa de arriba a abajo. El CEO debe estar implicado
  2. Sin recursos no se puede hacer nada, se requieren tanto recursos económicos como humanos
  3. Es una apuesta a largo plazo
  4. Hay que crear cultura  de la experimentación
  5. Hay que formar a la gente, para que aprendan de otros
  6. Hay que llevarlo a toda la compañía, para  conocer lo que hacen los otros
  7. Existe un componente de suerte, pero hay que crear una cultura de sistematización de todo el proceso

PD. Por cierto, el éxito de www.airbnb.com se debió a que al público le gustaron las «fotos bonitas» de las casas.

Seguirá en la entrada: …CONFERENCIA AGILE SPAIN  (CAS 2018) SEGUNDA JORNADA

NOTA: Fotos de Ángel de la Iglesia (mucho mejores que las mías, dónde va a parar)

CERTIFICACIÓN SCRUM MANAGER

Después de leerme un par de libros sobre Scrum decidí que era momento para tomar una certificación.

Después de buscar un poco por Internet, comprobé que hay tres certificaciones que sobresalen del resto:

  • Scrum Alliance
  • Scrum.org
  • Scrum Manager

El modelo de Scrum Alliance es con diferencia el más conocido (fue creado por los fundadores de Scrum) se basa en cursos de dos jornadas presenciales (que son obligatorias) y un examen muy sencillo que se puede hacer desde casa. Este es uno de los puntos más criticados de este modelo.

De Scrum.org me llamaron la atención varias cosas:

  • Que lo fundó uno de los creadores descontentos de  Scrum Alliance (Ken Schwaber).
  • Que ni siquiera está traducido al español. Este es un punto negativo a tener en cuenta.
  • No es necesario haber tomado ningún curso para poder examinarse de la certificación. Eso sí, tiene fama de tener los exámenes más duros (y en inglés) especialmente PSM II.

Y busqué información sobre Scrum Manager y lo que encontré me hizo decidirme por esta certificación:

  • Tiene una de las comunidades de apoyo más activas de España y Latinoamerica.
  • La diferencia entre Scrum técnico y Scrum avanzado es un enfoque muy interesante.certificacion_scrum_manager
  • Sus cursos oficiales presenciales no son obligatorios. Se puede tomar el examen sin  pasar por ellos.
  • El manual en el que se basa su curso es gratuito y público. Se puede descargar desde aquí en formato Epub y PDF: …Manual SCRUM MANAGER.
  • El enfoque del curso de ampliación llamado  Scrum Level es decir, del «Modelo de Evaluación y Mejora de la Agilidad Organizacional» me parece muy interesante. Es muy difícil tener éxito en un proyecto ágil sin que la empresa esté formada en estas prácticas.
  • Me gustó su declaración de intenciones: «Scrum Manager no forma “gestores técnicos”: gestores conocedores de marcos de Agilidad con la implantación de las correspondientes reglas y técnicas. Scrum Manager forma “gestores expertos” que lejos de radicalizarse en el “agilismo”, amplían su inventario de conocimiento y práctica de gestión con las aportaciones de la Agilidad, facilitando así la creación de su propia síntesis de conocimiento para mejorar la gestión de su entorno“.

Y me puse manos a la obra.

Su formación sigue el esquema de dividir los diplomas en Certificación (si se examina uno en un centro asociado) o Acreditación (si se toma  el examen de la web sin ninguna supervisión).

Lo primero es darse de alta en su web. Se debe aprobar la llamada «parte troncal» de la certificación.

Para aprobar la parte «troncal» se puede recurrir a un curso de apoyo de un centro certificado (cuyo coste oscila entre unos 500 €)  o acceder al curso on line (disponible todo el año) en el apartado E-Learning de su web y que cuesta unos módicos 40 € (IVA incl.)

El curso «on line» está formado por doce lecciones, seis prácticas y un examen. Si se aprueba  este examen se obtiene la Acreditación y 150 PDA (puntos de autoridad) similares a los PDU del PMP.

Para obtener la certificación se debe tomar el examen presencialmente en un centro examinador autorizado (que cuesta sobre 180 euros) o hacerlo desde la web pero en un centro que disponga del sistema de  supervisión web. Se debe obtener un 70 % de rescertificado_2_largepuestas válidas para aprobar el examen presencial.

El examen si se prepara bien no es complicado de aprobar. Ayuda mucho la batería de las preguntas de prueba que se pueden comprar  en la propia web de Scrum Manager.

Los 150 PDA (puntos de autoridad)  que se obtienen por haber aprobado la certificación otorgan el nivel de «Experto». Estos PDA se van perdiendo a razón de un 20% por año. Se pueden incrementar realizando cursos adicionales ( y se puede pasar al nivel «Autoridad» que implica disponer de más de 200 PDA).

 

 

 

MÉTODOS ÁGILES Y SCRUM

Título original: Métodos ágiles y Scrum mays

Autores: Alonso Álvarez, Rafael de las Heras, Carmen Lasa

Editorial: Anaya Multimedia, año 2012, 350 páginas, 

ISBN: 978-84-415-3104-8

Palabras clave: metodología, proyectos, software, scrum, métodos ágiles

QUÉ ES:

En la empresa hemos comenzado a gestionar varios proyectos por medio de metodologías ágiles, así que me he comprado este libro para ver de qué va la moda de los métodos ágiles y en concreto de Scrum.

Una peculiaridad de este libro es que el prólogo lo firma Mike Breedle, unos de los firmantes del llamado » Manifiesto Ágil», del que ya hablaremos. además, para ser prácticos, utilizan la realización de este libro como ejemplo de proyecto realizado en Scrum

Entrando en materia, los autores destacan que el origen de los métodos ágiles se basó en la frustración del mundo informático de poder tener éxito cuando los requerimientos son indefinidos, es decir, en proyectos donde la incertidumbre de lo que se busca es alta, pues si el cliente tiene claros los requisitos entonces es mucho más adecuado optar por una metodología de proyectos clásica (en cascada o waterfall).  El cambio de paradigma que implica es adoptar el enfoque de señalar un presupuesto y una fecha de entrega y que el trabajo sea lo que se pueda hacer aplicando el principio de que el desarrollo será interactivo.

Scrum es solo uno de los muchos métodos ágiles que existen, aunque es sin duda el más popular.

Un resumen rápido del modo en el que se trabaja en Scrum es el siguiente:

  • Ante al solicitud de un proyecto, el Product Owner crea un equipo, solicita unos recursos y fija los primeros requisitos.
  • Desarrolla el Product Backlog con los trabajos detectados necesarios, que se compone de temas, épicas e historias.
  • Se debe dividir el trabajo en varios Sprints, que se agrupan en Releases o entregas.
  • El equipo de trabajo valora el esfuerzo implicado y traduce las historias en las que se compone el proyecto en unidades menores o tareas.
  • El trabajo se va realizando y se expone en la Daily Meeting.
  • Los impedimentos detectados van a a un Impediment Backlog y el Scrum Máster vigila que se resuelvan.
  • El final del Sprint lo señala la Review Meeting
  • En la reunión de Retrospectiva el equipo revisa lo realizado y lo que se ha hecho bien y lo mejorable.
  • Y vuelta a empezar.

Y esto es todo…

Vamos a verlo con un poco más de detalle.

VALORES:

  • Mejora continua
  • Calidad
  • Time Boxing
  • Responsabilidad
  • Multidisciplinar
  • Flexibilidad
  • Ritmo (latido)
  • Compromiso
  • Simplicidad
  • Respeto
  • Coraje
  • Foco
  • Predictibilidad
  • Personas

cambio-de-paradigma2

 

 

 

 

 

 

 

 

ROLES:

  • Product Owner:
    • Es el intermediario entre el cliente y el equipo. Es la voz del cliente.
    • Fija las fechas de entrega y prioriza los distintos requisitos
    • Mantiene la «visión» actualizada del producto o proyecto. La «visión» es un resumen de las metas a medio y largo plazo donde se quiere llegar. es muy importante por ello disponer de un «caso de negocio». La «visión» del producto implica:
      • Unas características básicas u obligatorias, que el producto debe tener
      • Unas características de rendimiento o lineales
      • Características inesperadas o emocionantes
    • Mantiene al día el Product Backlog. Describe los elementos, con las condiciones de aceptación y priorizadas)
    • Traduce los requisitos de negocio en elementos del Backlog (temas, épicas e historias)
    • Es quien acepta o rechaza las entregas de trabajo
    • Asiste  a la Review y al Planning
    • Es el responsable del éxito o fracaso del proyecto y de su ROI. Controla el presupuesto
    • Gestiona las expectativas del cliente y de los stakeholders
    • Qué no debe ser un PO: Que no tenga poder, que esté saturado de trabajo.
    • Hay una interesante historia acerca de los roles dentro de Scrum y de lo que es estar implicado y estar comprometido.  Pues bien, el PO tendría el rol de «cerdo», pues está totalmente comprometido con el proyecto
  • Scrum Manager:
    • No es un jefe de proyecto. No tiene autoridad formal ante el equipo.
    • Supervisa todo el proceso. No está subordinado al PO.
    • Es un experto en la metodología Scrum debe enseñar esta metodología a cada integrante implicado en el proyecto, preocupándose de poner la metodología en práctica de modo que se encuentre dentro de la cultura de la organización y así entregue las ventajas previstas, asegurándose de que cada uno siga las Reglas y prácticas de Scrum.
    • Pilota los Sprints.
    • Debe velar por la productividad del equipo.
    • Debe procurar que fluya la comunicación y la colaboración.
    • Analiza la velocidad del equipo y debe buscar la calidad
    • Los roles de Scrum Manager y Product Owner son muy diferentes y es incompatible con que sean la misma persona.
    • Último objetivo: no ser necesario
  • Equipo:
    • El equipo se debe auto organizar
    • Debe estar comprometido con el proyecto
    • Su responsabilidad es entregar el producto, en base a lo que existe en el Product Backlog
    • Los equipos autosuficientes, auto organizados y funcionales, tienen la responsabilidad, en cada iteración, de transformar el Product Backlog en un incremento en la funcionalidad del producto y planificar su propio trabajo para lograrlo.
    • Debería de elegir al Scrum Máster, porque es su representante. debe confiar en él.
    • Debería de tener dedicación suficiente y continuada
  • Coach:
    • No es una figura obligatoria
    • Es un formador y mentor. Elabora las guías de actuación.

EL PROCESO:

  • Lo primero de todo, el Sprint Cero: 
    • Es responsabilidad del Product Owner
    • El él se define la misión, herramientas y el equipo
    • El objetivo es definir las condiciones y el contenido del trabajo
    • De esta forma se establece la primera versión del Producto Backlog
    • También se elige la duración de cada sprint y el calendario de releases o entregas
  • Sprints:
    • El Sprint Backlog contiene aquello que se llevará a cabo en cada sprint.
    • Hay tres etapas:
      • Sprint Planning, donde se realizan los criterios de aceptación y la valoración de los trabajos
      • Daily Meetings. Reunión diaria donde se revisa de forma rápida qué se hizo, que se va a hacer y los problemas encontrados
      • Review.
    • Sesión de Retrospectiva. Los resultados obtenidos en el sprint o fase se valoran aquí. Es una mirada al pasado para mejorar el futuro.

scrum de un vistazo

 

 

 

 

 

 

 

 

 

 

 

 

 

 

ENTIDADES:

  • Tareas
  • Historias de usuario.
  • Épicas. Son agrupaciones de historias

ARTEFACTOS:

  • Product Backlog:
    • Es la lista de requerimientos. Los requisitos del sistema o del producto desarrollado se enumeran en el Product Backlog. Es responsabilidad del PO.
    • No contiene todos los requisitos. Cualquiera puede crear requisitos, es si, requieren de la aprobación del PO. El Backlog es dinámico
    • Tipos:
      • Funcionales. Son las Historias de Usuario.
      • No funcionales. Son las cualidades que debe tener el producto.
    • El nivel de detalle debe ser alto para los requisitos prioritarios y no tanto para el resto.
    • Estructuración:
      • Temas
      • Épicasscrum_2-4_week
      • Historias de Usuario
      • Tareas
    • Características de un buen Product Backlog:
      • Card. Deben caber en una tarjeta
      • Conversation. Deben ser resultado de conversaciones
      • Confirmation. Deben ser fácilmente confirmables
      • Con historias de usuario bien definidas
    • El mejor producto Backlog debe ser DEEP: Detallado, Emergente, Estimado, Priorizado
    • Es una lista ordenada por prioridad, esta tarea de priorización es del PO, pero el equipo le debe ayudar.
    • Técnicas de priorización del Product Backlog:
      • Priority Poker
      • Moscow (Must, Should, Could, Won’t)
      • Kano
      • Criba de temas
      • Puntuación de elementos
      • Posibles problemas del Product Backlog:
        • Es muy grande y detallado. Encubre una especificación de requisitos encubierta. En este caso no se debería de trabajar con Scrum
        • Historias de usuario siamesas. Encubre un problema con las dependencias. Se debería de dividir en partes más pequeñas y hacer historias de usuario conjuntas.
        • No se cierran las Historias de Usuario. Encubre un problema con las tres C’s: Card, Conversation, ConfirmationExample_Sprint_Task_Board
        • Infección Operativa. Si se dice cómo hay que hacer las cosas y no lo que hay que hacer. Se deben eliminar del PB las tareas operativas
        • Plaga de requisitos. Es síntoma de que el PB se está usando como una lista de peticiones.
        • No hay requisitos no funcionales. El PB no está completamente definido. Solución: prestar atención tanto a las Historias de Usuario como a los requisitos no funcionales
        • Inmunización tardía. Se deben priorizar todos los elementos sobre los que se tengan incertidumbres para poder trabajar sobre ellos. Si esto nop se hace pronto, luego será un problema
        • Muerte dulce por contrato. Si el PB funciona como un contrato con el cliente. El PB no es un acuerdo formal con el cliente.
        • No se debe consentir que el PO delegue la gestión del Product Backlog en el Scrum Master o en otra persona
  • Sprint Planning:
    • Los sprints son fijados en el Sprint 0. En el Sprint Planning el equipo junto con el PO y el SM planifican los sprints.
    • Cada Sprint se divide en:
      • Planificación del contenido del sprint
      • Desarrollo del trabajo
      • Revisión de los resultados
    • Se deben establecer los límites temporales adecuados (time boxing)
    • Se debe garantizar que el objetivo, mecánica y resultados sean conocidos
  • Sprint Backlog:
    • Son los trabajos a realizar durante un determinado Sprint
    • Es propiedad del equipo, que es quien lo gestiona y actualiza.
    • Su contenido es mucho más detallado y debe de disponer de una definición de lo que se debe alcanzar para poder saber cuándo se ha alcanzado el resultado
    • Dimensiones:
    • Prioridad
    • Detalle
    • Estado.  Será pendiente, en curso, terminado, impedida (se documenta y se asigna)
    • El Tablero de Tareas permite visualizar cómo va el sprint
  • Impediment backlog:
    • Es una lista de incidencias que tienen que ser resueltas por el equipo y que el Scrum Máster debe gestionar y asignar al alguien para que trabaje en ellas, y que será revisada en la reunión Scrum diaria
  • Burndown Chart.
    • Mide la evolución del trabajo. Lo mantiene el Scrum Master

MECÁNICA DE TRABAJO:

  • El PO lee la primera historia de usuario junto con su criterio de aceptación. los miembros del equipo le asignan «Story points» y se suman hasta que alcancen la velocidad media del equipo (si se sabe). Estas historias deben ser divididas en tareas.
  • El compromiso del equipo es muy importante. Por eso no se aceptan presiones del PO. La calidad debe ser el criterio que debe primar
  • La cantidad de historia de usuario cerradas por el equipo según el Product Owner es el valor de la velocidad real de ese equipo
    • el valor de la complejidad, dificultad o cantidad de trabajo se mide en story points
    • También puede medirse la velocidad por días ideales que se requerirían para hacer esas historias.
    • O también se podría poner un porcentaje, un focus factor.
  • La estimación es una acción colectiva. Puede usarse el Planning Poker
  • Si la estimación coincide se acepta, si no, se discute sobre ello.
  • Sumando todos los story points se obtiene la velocidad estimada de la iteración.
  • El seguimiento del cumplimiento se realiza a través de la  Burndown Chart

PILOTANDO EL SPRINT:

El Scrum Master:

  • No tiene poder real
  • No es el jefe del proyecto
  • Es un facilitador
  • No está subordinado al Product Owner
  • No persigue a los demás
  • Cometido: velar por el seguimiento de los principios del Scrum
  • Cómo lo hace:
    • Velando por la productividad del equipo
    • Procurando que fluya la comunicación y la colaboración
    • Responsable de introducir y fomentar las prácticas ágiles
    • Supervisa el backlog
    • Analiza la velocidad
    • Es el intermediario entre el mundo exterior y el equipo de trabajo
    • Es responsable de la formación del equipo
  • Muy importante: es incompatible que una sola persona sea el PO y el SC
  • Objetivo último: no ser necesario

Planificación detallada:

  • Objetivo: pasar las historias de usuario a unidades más manejables, como son las tareas
  • En esta tarea no se necesita al PO
  • La tarea es una descripción simple de lo que se va a hacer. No es validable

Mantenimiento del backlog, el grooming:

  • Es muy recomendable hacerlo mucho antes de cada planificación del Sprint Backlog
  • El PO revisa el product Backlog para depurarlo.
  • Es un trabajo continuo y puede asistir todo el equipo.

 DESARROLLO DEL SPRINT:

  • Duración de los sprints. es mejor que sean cortos al inicio o en actividades poco definidas o si el equipo es inmaduro
  • Frecuencia de los releases: es responsabilidad del PO
  • Aspectos del sprint: estabilidad, obtención de resultados, mejora continua, anticipación

Quien lo lleva a cabo: el equipo de trabajo:

  • Características: diversificado, autónomo, auto organizado, responsable, sin jerarquías o niveles, estable y dedicado
  • Responsabilidades:
    • Realizar el trabajo del proyecto
    • Identificar formas de mejorar su productividad, junto con el SC
    • Hacer la estimación de los elementos del backlog
    • Dividir las historias en tareas
    • Comprometerse a realizar una lista de historias en cada sprint
  • Dimensión del equipo: sobre 4 a 10 miembros
  • Es muy recomendable la proximidad física

La Daily Meeting:

  • Lo realizan el equipo y el SC, que no la dirige.
  • El PO puede asistir o no.
  • Contenido:
    • Qué se ha hecho
    • Qué se hará
    • Impedimentos

Backlog de impedimentos:

  • Recoge todo lo que impide alcanzar los objetivos
  • Se recogen los impedimentos, se describen y se asignan a un responsable
  • Es gestionado por el SC
  • Deben priorizarse

Sprint Review:

  • También llamado Customer Sprint Review
  • Se revisa qué se ha hecho y como se ha hecho
  • Finalidad:
    • Recoger comentarios
    • Recoger la aceptación de las tareas seleccionadas
    • Analizar si se necesitan mejoras en el trabajo realizado o si se precisan nuevos items
    • Pueden acudir personas de fuera del equipo
  • Posibles problemas:
    • Cambiar la fecha de la reunión frecuentemente
    • Que sea una presentación de resultados
    • Que se trabaje solo para el sprint review
    • Foco en los items del backlog y no en los objetivos
    • Desviación del propósito de la reunión por los asistentes
    • Convertir la review en una reunión de aprobación de requisitos
  • La mejor práctica:
    • Establecer normas y reglas.
    • Repasar los objetivos
    • Recapitulación del PO sobre lo finalizado y no finalizado
    • Revisión por el equipo de estadísticas y métricas

La retrospectiva:

  • Objetivo: mejorar la forma de trabajar de forma más efectiva
  • Debe concluir con las acciones de mejora que deben implementarse
  • Cuando: al final de un sprint, después de un release y al final del proyecto
  • Etapas: que se hizo bien, que se debe mejorar, que se va a hacer en la nueva iteración
  • Consejo: se debe ser positivo y debe haber un moderador (el SM)

LOS SCRUM BUTS:

  • Son malas prácticas. Se debe diferenciar entre Scrum Ands, que son modificaciones positivas, y Scrum Bad, que son modificaciones negativas
  • Los Scrum Buts exponen una disfuncionalidad que hay que solucionar. La culpa no es de Scrum.
  • Top 10 de Scrum Buts:
    1. No hacemos reuniones de fin de sprint
    2. No se eligen voluntariamente las tareas. Ojo esto es micro gestión
    3. No hacemos mejoras o corrección de problemas porque hay demasiadas funcionalidades que implementar.  A esto se le llama la Death March
    4. No hacemos retrospectivas. Esto puede ser un síntoma de que hay conflictos internos en el grupo
    5. No hacemos reuniones diarias ya que nos las necesitamos
    6. El Scrum Master y el Product Owner son la misma persona. Ojo, son roles que consumen mucho tiempo y que son incompatibles porque sus atribuciones pueden entrar en conflicto
    7. Usamos Scrum pero no hacemos el diseño, la implementación y las pruebas de cada historia de usuario en el mismo sprint, porque no os da tiempo a llevar a cabo todas estas tareas en el mismo sprint y las hacemos en sprints consecutivos. esto puede tener dos causas: el equipo no está estimando bien las historias de usuario y el product backlog no está suficientemente trabajado
    8. No se hacen iteraciones cortas porque todo está claro y las hacemos cada 3 meses. Entonces, ¿Por qué se usa Scrum? Puede ocultar disfuncionalidades
    9. No hacemos reuniones diarias porque no está el Scrum Master. Ojo, esto no es un reporte
    10. Nosotros no lo llamamos Srum pero ya estábamos haciendo todas esas cosas.

¿Cómo detectar Scrum Buts?. Con el método de los 5 porqués (Un ejemplo. ¿Por qué no asiste el SM al Daily Meeting del proyecto? –> Porque está muy ocupado. ¿Por qué está tan ocupado? —> Porque gestiona muchos proyectos— > ¿Por qué gestiona muchos proyectos? —> Porque no hay más SC en toda la empresa…)

En fin. la teoría del método Scrum es muy sencilla. Pero hacerlo bien es muy difícil.