domingo, 27 de noviembre de 2016

¿Qué ventajas tienen los puntos de historia frente a las horas ideales?

Estimación relativa, en ambos casos, en uno por tamaño y en
el otro por complejidad un elemento es del doble del otro
Las horas ideales como unidad de esfuerzo o tamaño no son una buena unidad de medida por dos razones:

Primero porque se confunden muy fácilmente con la duración, con las horas reales, la unidad de tiempo, confusión que nos lleva a hacer cálculos y cuadres que no funcionan.

En segundo lugar las horas ideales son una unidad absoluta, y los seres humanos somos bastante malos estimando en absoluto mientras no tengamos bastante experiencia acumulada. Es difícil adquirir experiencia de estimación en horas ideales que sea transversal a proyectos, ya que todos ellos son singulares y con condiciones y situaciones especiales, por ende un proyecto siempre es algo nuevo.

Lo que propone la Agilidad es utilizar puntos de historia, una medida que permite relativizar aspectos como tamaño, complejidad, incertidumbre, conocimiento y riesgos y compararlos con estimaciones de otras historias de usuario dando así la posibilidad de ajustar y afinar dichas estimaciones a medida aprendemos y maduramos. Recordemos que los seres humanos estamos entrenados para comparar desde nuestra niñez, nos pasamos la vida comparando precios, cantidades, objetos, nuestros logros con nuestras metas y tenemos expresiones llenas de comparaciones: "Mi profesor es sabio cual monje tibetano", "Tus ojos son como estrellas", "Tan liviano como una pluma"... la comparación está en nuestra naturaleza.

Otra ventaja de los puntos de historia es que no están conectados a ninguna unidad de medición específica y por tanto no dan lugar a cuadres y cálculos.

Desde el punto de vista psicológico las estimaciones por puntos de historia nos liberan de la carga psicológica de la estimación por horas cuando se excede el tiempo previamente estimado para terminar una tarea o historia de usuario.

También evitan la ley de Parkinson, una ley empírica que dice que cuanto más tiempo tengamos para hacer algo, más divagará la mente y más problemas nos plantearemos:

El trabajo se expande hasta llenar el tiempo disponible para que se termine

Y por último, dado que los puntos de historia no tienen nada que ver con el tiempo, nos ayudan a mitigar e síndrome del estudiante, fenómeno de la naturaleza humana por el cual comenzamos a dedicarnos seriamente a una tarea solamente cuando se acerca la fecha de entrega.

viernes, 25 de noviembre de 2016

¿Cómo sería un buen juego de simulación de un proyecto ágil con Scrum?

Este es un ejercicio del curso de Scrum de
En mis clases presenciales uso una simulación de Scrum que es una gran evolución de "Una simulación Ágil completa en 75 minutos" de Brian Bozzuto y Giora Morein (BigVisible Solutions). El objetivo de las misma es:
Value Stream Mapping

Value Stream Mapping de la compra on-line
La simulación empieza por la selección de un flujo de valor, un proceso de negocio, sobre el que trabajar. Recordemos que la mecanización a través de software trata diferentes flujos de valor a los que hay que dar solución. La propuesta del ejercicio se basa en la construcción de una tienda de venta on-line de libros, un buen ejemplo, ya que la mayoría de nosotros estamos familiarizados con tiendas on-line como Amazon.

El ejercicio se centra en el flujo de valor que cubre el flujo de compra desde la perspectiva del cliente, ¿qué pasos ha de dar un cliente cuando llega a nuestra web y quiere comprar un libro? Hay otros flujos de valor, como la logística de la entrega o la gestión de devoluciones, pero la simulación requiere un solo flujo y el más conocido por todos es el flujo de compra.

User Story Mapping

En este punto le explico a los alumnos que son un equipo de negocio y que han de definir de forma colaborativa cuales son los pasos de su flujo de valor. Comúnmente estos pasos son algo como:
  • Encontrar libro
  • Seleccionar libro
  • Entrar dirección de entrega
  • Pagar
  • Confirmación de compra
Obtenidos los pasos del flujo de valor, los alumnos desarrollan cada paso con funcionalidades que lo cubran, por ejemplo:
  • Encontrar libro:
    • Búsqueda por título
    • Búsqueda por autor
  • Seleccionar libro:
    • Añadir al carrito
    • Modificar carrito
    • Quitar del carrito
  • Pagar:
    • VISA
    • PayPal
    • Contrareembolso
Obtención de las funcionalidades que cubren el flujo de valor a través de un User Story Mapping
Una vez obtenidas las funcionalidades resalto a los alumnos que el conjunto es el "big picture" de nuestro flujo de valor, el proceso que cubre esa parte del producto. Recordemos que a través del User Story Mapping hemos obtenido las funcionalidades de forma colaborativa, lo que implica que están representadas todas las perspectivas del equipo de negocio. Les suelo preguntar a mis alumnos si ese conjunto de funcionalidades sería un buen software... lo es sin duda, todos conocemos la compra on-line y de seguro que no falta nada importante.

Planificación de release

Amazon se fundó en 1994
y vendió su primer libro en 1995
Para ser una pila de producto es necesario que las funcionalidades estén priorizadas por valor de negocio y en la simulación lo hacemos con una primera planificación de release. Dividimos una hoja de rotafolio en tres áreas con tres releases, R1, R2, R3.

Les explico a los alumnos que la R1 es el MPV, el Mínimo Producto Viable, para salir al mercado y validar que existe una necesidad de mercado, y que decidan qué funcionalidades van a trasladar del tablero User Story Mapping a esta release, de forma se lance a producción lo mínimo de lo mínimo de lo mínimo.

Les muestro una imagen de como era la página web de Amazon en sus primeras versiones a mediados de 1990, y les hablo del consejo de Reid Hoffman, cofundador de LinkedIn que dice:

"Si no te avergüenzas de tu primer producto, es que lo lanzaste muy tarde"

En la planificación de release los alumnos trasladan las funcionalidades a 3 releases en función del valor de cada una
En R2, el segundo lanzamiento al mercado, van las MMF, las Minimum Marketable Features, el paquete mínimo de las siguientes funcionalidades importantes que no son necesarias en el MPV, pero son determinantes para nuestro negocio. En R3 va el resto de las funcionalidades, no tiene mucho sentido desglosar en releases más allá, ya que simplemente no sabemos hacia donde nos llevará el mercado. A media que avancemos, entreguemos releases y tomenos feedback del mercado irán apareciendo las subsiguientes, de manera que con 3 releases a la vista es suficiente para una buena hoja de ruta de nuestro proyecto.

En este punto finaliza la primera parte de la simulación, el equipo se ha sentido en la piel de negocio, ha experimentado la priorización por valor y obtenido una pila de producto inicial.

Planificación de sprint

Pila de producto con tareas preparadas
En este punto comienza la segunda parte de la simulación en la que los alumnos se ponen en la piel del equipo de Scrum (equipo desarrollo, Propietario del Producto y Scrum Master).

Es necesario una primera fase preparatoria en la que ocurren las siguientes actividades:

En primer lugar consideramos que el orden de izquierda a derecha y de arriba a abajo es el orden de prioridad según valor de negocio.

Hay que poner un ID en cada funcionalidad y esto lo hacemos enumerándolas del 1 en adelante. Otra propiedad de un elemento de la pila de producto es que ha de estar estimado, por tanto han de buscar el elemento más pequeño en esfuerzo, asignarle el 1 y estimar el resto de forma relativa. (Les invito a no ser minuciosos y hacer estimaciones muy rápidas, realmente no importan las estimaciones, lo que importa es que haya variedad de valores).

Para experimentar autoorganización les indico a los alumnos que deben de dividir todas las funcionalidades en tres tareas (A-Análisis, D-Desarrollo y T-Testing) y que desglosen el valor de la estimación en las tareas de forma que sumen. Esta actividad la han realizar todos ellos en paralelo de manera que en poco tiempo se obtengan todas la tareas. Es interesante observar las diferentes formas que tienen los equipos de organizarse, en algunos casos cada miembro desglosa funcionalidades, en otros casos algunos miembros calculan y otros preparan post-its... cada equipo es único.

Para acabar el equipo ha de elegir un rol para cada miembro:
Un dado determina el trabajo hecho en un día
La unidad en que se estima el tamaño de las funcionalidades es el punto de dado. Les explico a los alumnos que para introducir variabilidad en la simulación el que va a determinar el trabajo hecho por un miembro de equipo en un día será el dado. Una tirada aplicada a la especialidad del que ha tirado el dado, puntúa doble, sino simplemente puntúa lo que marca. A veces es mejor ayudar a un compañero para así terminar y entregar un sprint con más valor.
A partir del segundo sprint animo al Propietario del Producto a cambiar las prioridades de la pila de producto y a introducir nuevas funcionalidades. Entre otras les propongo explicar que hemos observado que los clientes de nuestra web están siendo predominantemente padres de familia que están comprando libros de texto, y que hay que introducir una nueva funcionalidad muy prioritaria, la búsqueda por ISBN.

El equipo ejecuta las tareas, cada miembro del equipo lanza el dado para determinar el esfuerzo que realizará en ese turno:
  • Más de una persona puede trabajar sobre la misma tarea
  • No hay dependencias entre tareas, se puede testear antes de desarrollar
  • Una vez que una persona finaliza su tarea (por ejemplo, análisis) puede colaborar en otra
  • Recordar que las personas que trabajan en su especialidad trabajan el doble de rápido (se multiplica por 2 el resultado de lanzar el dado)
  • Si un analista lanza un 1, entonces no trabaja porque hay una cuestión sobre una funcionalidad. El equipo debe añadir 2 puntos a la funcionalidad de análisis
  • Si un desarrollador lanza un 1, entonces no trabaja porque hay una cuestión sobre una tarea. El equipo debe añadir 2 puntos a la funcionalidad de análisis
  • Si un tester lanza un 1, no trabaja porque se ha encontrado un error en las pruebas. El equipo debe añadir 2 puntos a la funcionalidad de desarrollo para corregir el error
Tablero Kanban con tareas avanzando
Burndown

Tablero de gráficos burndown
A lo largo de las reuniones diarias de los tres sprints el equipo registra los puntos de dado pendientes en un gráfico burndown para hacer visible su avance y tomar decisiones en caso de alejarse de la linea ideal.

Empezado el tercer sprint sorprendo al equipo a medio sprint y me presento con el "Presidente de la compañía" que intenta colarles de forma "dura" una funcionalidad: el informe de ventas. La idea es intentar romper el sprint y el compromiso del equipo, cosa que de seguro pasará en su realidad, y así impregnar al equipo de Scrum con que no deben de permitir que rompan su compromiso. Guío primero al equipo, luego al Scrum Master y finalmente al Propietario del Producto en como argumentar al presidente que es una mala idea:

El equipo simplemente debe de tomar nota de la nueva funcionalidad, mencionar que se la trasladarán al Propietario del Producto quién es el quién conoce el negocio y es responsable del producto. No deben de aceptar la funcionalidad, incluirla en el sprint y comprometerse, su foco debe de estar en seguir trabajando en el sprint actual tal como se planificó.

El Scrum Master debe de argumentar al presidente desde el marco de Scrum, explicar que Scrum funciona por sprints de 5 días en los que el trabajo está en consonancia con la capacidad del equipo, y por tanto incluir algo no planificado pone en riesgo la entrega para el siguiente viernes. ¿Seguro que quiere eso Sr.Presidente? ¿El informe no puede esperar al lunes que viene cuando empiece el siguiente sprint?

Finalmente vienen los argumentos del Propietario del Producto, en la realidad este tiene muchos ya que conoce el negocio. En la simulación hago para que con ese sprint se finalice una release, así que el Propietario del Producto tiene un argumento muy sólido ya que con ese sprint salimos a producción y cualquier interferencia puede poner en riesgo el lanzamiento, ¿Quiere eso Sr.Presidente?
Aspecto de los tableros y post-its de la simulación
Los alumnos se lo pasan francamente bien y aprenden motivados con esta simulación de cuatro horas, os animo a probarla, es muy completa y sin duda la recordarán por mucho tiempo :-)

Historias técnicas en la pila
Las buenas ideas siempre surgen cuando hay choques de ideas de diferentes personas. En un curso reciente el equipo le pidió al Scrum Master que intentara conseguir un segundo dado... y nos pusimos el reto de como podría hacerse eso.

¿Cómo podemos aumentar la velocidad de un equipo de una forma tan espectacular? Pues reduciendo el coste de transacción, en otras palabras, implementado integración continua y pruebas automatizadas.

Equipo que pidió un segundo
dado en plena simulación :-D
Creamos dos post-its con ambas historias técnicas, azules en la imagen, el equipo las estima y las da al Propietario del Producto para que las añada a la pila de producto. Tendrán que negociar con él, esas historias no tienen valor de negocio, y explicarle las consecuencias deseables si se realizan. El dado también se lo damos al Propietario del Producto, en cuanto este priorice las historias técnicas y se hayan completado en un sprint, el equipo recibe el dado para incrementar su velocidad.

Quiero dar mis agradecimientos a todos los asistentes a mis clases que han hecho la simulación conmigo, ellos han aportado ideas, sus tableros para las fotos y sus ganas de aprender :-D

viernes, 18 de noviembre de 2016

¿Cómo hacer una retrospectiva creativamente y que nos hable del sentimiento que se llevan las personas?

Collage que representa lo llevado con nosotros en un curso
Una de las cosas que me encanta de las retrospectivas es que en ellas está presente el lado emocional de las personas. Esto ocurre tanto en las retrospectivas del marco Scrum como en las retrospectivas de final de curso.

Pero, ¿cómo mostrar el lado emocional en una retrospectiva de un curso on-line?

Así que Gertrudis y yo nos pusimos a buscar, y, gracias a la gran inteligencia emocional de mi compañera, diseñamos una actividad en la que los alumnos pudieran soltar su creatividad e imaginación sobre lo que habían vivido curso: un collage :-)

Os quiero invitar a leer el post en el blog de Scrum Manager, post que hemos escrito conjuntamente y que allí fue publicado en primicia.

No es lo mismo leer un informe sobre la satisfacción de un cliente (proceso) que averiguar si este está contento con el producto o servicio que le hemos prestado (personas). De la misma manera y como profesores, lo que deseamos es hacerles sentir a nuestros alumnos muy en su interior todo lo que Scrum conlleva e implica, hacerlo visible y mejorar nuestras habilidades para transmitirlo.

Como dice Jurgen Apello en su libro "How to Change the World":

La forma en la que el trainer enseña es tan importante como el mensaje en sí mismo...
Es mejor comunicar una idea usando historias, ejercicios, juegos y discusiones.
Tratar de hacer que la gente ría o llore.
Mover sus mentes y sus cuerpos y permitirles enseñarse unos a otros.

Con base en esta idea, y también al haber leído el post de Luis Gonçalves "LEGO a great tool for your Agile Retrospectives", donde plantea una manera de hacer retrospectivas usando piezas de LEGO para que el equipo pueda expresarse de una manera creativa y donde las reglas del mundo real se reemplazan con las reglas del juego, nos pusimos a pensar cómo hacer para que nuestros participantes de cursos on-line pudieran hacer una retrospectiva de una manera diferente, donde pudieran ir más allá de lo cotidiano y despertar su lado creativo y emocional. Tuvimos la idea de usar LEGO digital, pero nos pareció muy complicado, habría que descargar la herramienta en sus equipos con una interfaz solamente en inglés, y al hacer la prueba nos dimos cuenta que no es lo mismo hacer algo con LEGO digital que con piezas de LEGO reales. Entonces se nos ocurrió una idea a través de la cual pudieran expresar su creatividad, su lado emocional y artístico, y decidimos incluir una nueva actividad en un curso on-line:

¿Qué te llevas de este curso? Expresarlo con un collage creativo

Cómo última actividad invitamos a los alumnos a soltar su creatividad e imaginación y al mismo tiempo a reflexionar y compartir que es lo que pensaban y sentían sobre lo que se llevan del curso. La idea fue hacerlo a través un collage de imágenes que lo reflejase y que en un hilo del foro hicieran un breve comentario sobre su significado. Teniendo las dos formas de expresar lo que se llevan del curso, una que implicaba su lado creativo y emocional con imágenes visuales, y otra describiendo con palabras el significado de su collage, buscábamos también activar de una manera integradora sus dos hemisferios cerebrales, para establecer conexiones y relaciones más profundas con respecto a lo que consideraban de más valor en el curso, y que a su vez estas conexiones pudieran perdurar por más tiempo en sus mentes y transformarse en un aprendizaje emocional que quedase grabado de una forma más contundente y significativa en cada uno de ellos.

Invitamos a los alumnos a hacer collages de distintos modos:
  • Con imágenes digitales: Word, Powerpoint, Paint, Canva o cualquier otra herramienta que sirviera para hacerlo.
  • Con collages físicos, en una cartulina o folio con imágenes recortadas de periódicos o revistas, o dibujos propios, tomar una foto y subirla al hilo.
Otro aspecto importante del diseño de la actividad es que participamos todos, alumnos y profesores. Cada uno con su perspectiva, aportó el collage que expresaba lo que se llevaba del curso en particular y, para lograr un efecto sinérgico, fuimos uniendo las aportaciones en un gran collage de collages, que evolucionó hacia la siguiente composición:
Versión final del Collage de collages de lo que nos llevamos del curso troncal de ScrumManager Abril-Mayo 2016
En el collage se expresan ideas como las de poder y hacer funcionar el músculo más valioso que tenemos las personas, lo aprendido y asimilado en el curso como los valores de Agilidad y la importancia de las personas y los equipos.

Gracias Álvaro

Equipos unidos, con respeto, trabajando unidos con un objetivo común, cuidando y haciendo crecer lo que hemos creado y aprendido juntos. Scrum, Agile y Lean Startup están transformando el mundo del trabajo. Creo que la gente apasionada dará lugar al cambio. Mi objetivo como trainer es ayudar a descubrir Scrum y cómo puede ayudarle a transformar su mundo.
Gracias Alex

El cofre con el tesoro que tiene, entre sus muchas joyas, la mentalidad ágil, las herramientas y técnicas aprendidas, el esfuerzo realizado y la magia de poder cambiar al mundo con todo ello, cruzando un puente que nos lleva a un nuevo comienzo, donde podemos usar todo lo que hemos atesorado en nuestro cofre durante el curso.

Gracias Gertrudis

Las ganas de seguir aprendiendo y de adoptar y adaptarse a los cambios y de convertirse en agentes de cambio para conseguir la visión compartida de un destino mejor a donde llegar y en donde trabajar.
Gracias Vero

Las personas son la base, por lo que conseguir un buen trabajo en equipo es el principio de todo. Un equipo unido, con respeto, ganas de aprender y una gran adaptación al cambio puede conseguir todos los objetivos que se proponga.
Si a ello le añadimos una buena metodología de trabajo que nos ayude en el control de las tareas sabiendo el estado de cada una de ellas y teniendo grandes valores, estaremos en disposición de alcanzar el éxito mientras disfrutamos con lo que hacemos.

Gracias Ana

Frases del curso dentro del contexto que nos proporciona Scrum.

Gracias Reynaldo

Ha abierto mi mente a un nuevo mundo en la gestión y/o ejecución de proyectos, he entendido que es en el trabajo colaborativo y en la interiorización de las metas comunes donde puede lograrse mejores resultados y un balance perfecto entre los límites y la libertad.

Gracias Claudia Patricia

Diferentes formas de trabajo cobijadas por el paraguas de los valores y principios del Manifiesto Ágil.
Gracias Daniel

Lecciones cortas donde se explican claramente los conceptos que debemos aprender y con prácticas donde se aplica perfectamente la teoría.

Gracias David

El trabajo en equipo es esencial para conseguir que las metas propuestas de una forma ágil, eficiente y rápida.
Gracias Marta

Sumándole a todo esto Scrum como marco de trabajo que, dirigido por los valores y principios del Manifiesto Ágil, y pensado por y para personas, ayuda a llevar adelante ese cambio en la gestión de proyectos, los alumnos se han llevado el core del curso, y estarán en disposición de alcanzar el éxito mientras disfrutan con lo que hacen en su día a día profesional.
Gracias Nicolás

sábado, 12 de noviembre de 2016

¿Cuáles son las competencias de un Enterprise Agile Coach?

Entre los agentes del cambio para una transformación hacia la Agilidad, los Scrum Masters y los coaches ágiles son roles cuyas funciones son bastante conocidas y comprendidas.

Las transformaciones ágiles en las compañías suelen empezar por los equipos de forma independiente, luego escalan a equipos de equipos que trabajan alrededor de un producto o linea de producto en común a los que hay que imprimir cadencia, alineación y sincronización, y finalmente la transformación llega al nivel de toda la organización. A este nivel se requieren de coaches empresariales, o Enterprise Agile Coaches, cuyas competencias están enfocadas a la estrategia ágil a nivel holístico, son coaches que acompañan a los equipos directivos a adoptar la mentalidad ágil y a convertirse en líderes al servicio de la transformación y de la compañía.

Cartel anunciado el Open Space
En el Global Scrum Gathering Munich 2016 Olaf Lewitz y Evelyn Tian lideraron un Open Space de tutoria a coaches ágiles para que se comprenda el conjunto de habilidades que las compañías esperan de un CTC (Certified Team Coach) y de un CEC (Certified Enterprise Coach). Por supuesto asistí y me llevé las competencias de un Enterprise Agile Coach.

Recordemos la definición de coaching: "es un método que consiste en dirigir, instruir y entrenar a una persona o a un grupo de ellas, con el objetivo de conseguir alguna meta o de desarrollar habilidades específicas".

¿Qué es lo que se espera del Enterprise Agile Coach?
  • Haber liderado una transformación ágil completa a nivel de compañía o departamental en una o más organizaciones.
  • Haber trabajado con un equipo de coaches ágiles para llevar a cabo la transformación
  • Haber definido el marco Agile de la organización y asegurar que existe convencimiento en todos los niveles.
  • Haber leído la mayoría de los libros clave de Agile y Lean, y haber comenzado a leer prácticas y técnicas que están fuera de Agile como la gestión de la complejidad, las finanzas, las métricas, el comportamiento y el cambio organizacional.
  • Haber formado, entrenado, tutorizado y asesorado no sólo a equipos y líderes, sino también a ejecutivos de alto nivel (CXOs).
  • Haber tratado de resolver problemas organizacionales complejos como gobierno, finanzas y recursos humanos (Management 3.0).
Olaf Lewitz facilitando el Open Space
En el Open Space el punto de partida fue identificar la mentalidad del coaching ágil, las creencias fundamentales:
  • El coachee, quién recibe el coaching, sabe más sobre su realidad, sus opciones y los riesgos y la solución a sus problemas.
  • La tarea del coach es ayudar al coachee a traer a la superficie tanto el problema como la solución.
  • El coach considera que lo que haya hecho el coachee lo ha hecho con la mejor intención y con el mejor uso de sus conocimientos en esas circunstancias.
  • El coach no juzga al coachee ni sus decisiones.
  • El objetivo de un coach es acompañar y hacerse prescindible cuanto antes - su tarea es habilitar al coachee para que sea autosuficiente.
  • El coach debe ser auténtico, coherente con sus valores. Si el coach está en contradicción con los valores fundamentales debe de retirarse del coaching.
La Scrum Alliance describe las 5 competencias del Enterprise Agile Coach en su aplicación CTC & CEC:

Evaluar - Descubrimiento y Dirección
Los coaches de Scrum actúan como un espejo para la organización, trayendo a la superficie los sistemas subyacentes que influyen a la misma para concienciación, reflexión y guía a una mayor Agilidad y un mejor rendimiento. Ven por debajo de la superficie, exponen los síntomas difíciles y aíslan las causas raíz.

Balancear - Coaching y Consultoría
Los coaches de Scrum equilibran su propio expertise sobre Agilidad con los objetivos y la intención del cliente. Entienden y respetan la naturaleza de una relación cliente-consultor, ya sea como empleado o como consultor. Hacen preguntas poderosas, conducidas por ejemplos, comparten sus conocimientos, y guían al cliente en su auto-descubrimiento.

Catalizar - Liderazgo y Organizaciones
Los coaches de Scrum son los agentes de cambio para las organizaciones cliente. Se involucran con todo el sistema de la organización y con los líderes que lo guían. Mejoran las habilidades y capacidades existentes en el cliente. Conectan interdependencias e impactan en la reflexión, el aprendizaje y el crecimiento organizacional.

Facilitar - Enfoque y Alineación
Los coaches de Scrum facilitan la adopción, implementación y alineamiento de la Agilidad del cliente. Trabajan el compromiso de los interesados con conversaciones focalizadas en lo fundamental y actividades de fomento de alineación. Mantienen puntos de vista no sesgados y fortalecen estrategias de colaboración y resolución para la identificación de resultados creativos.

Educar - Conciencia y Comprensión
Los coaches de Scrum guían el aprendizaje en Agilidad del cliente mediante la aplicación y el descubrimiento. Se centran en la estabilización de los principios y variando las prácticas para un alienamiento situacional de la madurez del cliente con la aplicación efectiva de la Agilidad. Son un mentor y líder en el desarrollo de la comprensión y la concienciación de la Agilidad en el cliente.

En el Open Space se se creó el documento "CEC Coaching Definition" dónde se recogen preguntas que un Agile Enterprise Coach puede hacerse sobre si está aplicando correctamente las 5 competencias. Es un documento abierto dirigido a solicitantes de las certificaciones CTC y CEC y empresas interesadas en conocer las habilidades de los CTCs y CECs.

viernes, 11 de noviembre de 2016

¿Cómo llegar a una aproximación del tamaño de la primera release o del MPV?

Tamaño estimado de un MPV de una librería on-line
Acabamos de hacer un User Story Mapping para obtener la pila de producto inicial, hemos distribuido los epics en releases y queremos tener una idea sobre el tamaño de la primera release o del MPV (Mínimo Producto Viable). Para ello sugiero utilizar la tercera de las actividades de la Incepción Ágil que se centra en el cómo, la que trata de estimar el tamaño (size it up) a un muy alto nivel.

Con esta técnica nos podemos hacer una idea de la complejidad y del tiempo que nos puede llevar realizar la release con los recursos de los que disponemos. No se trata de comprometerse a una fecha, pero sí de tener una estimación a groso modo de si serán 3, 6 o 9 meses. Quizá necesitaremos hacer una estimación de los epics.

Estimar el tamaño del Agile
Inception Deck de Jonathan Rasmusson
Con el resultado de esta actividad el Propietario del Producto y los interesados pueden tomar decisiones sobre la viabilidad de la release y si es necesario dividirla o ampliar los recursos para cumplir con las expectativas.

La actividad consta de dos partes:
  • Buscar consenso a la pregunta ¿llevará de 1 a 2 meses? ¿3-4? ¿6 meses?
    • Si el tamaño superara los 6 meses se debería de dividir la release, superar los 6 meses implica un riesgo alto, hay demasiadas cosas que pueden cambiar en ese marco de tiempo.
  • Desglose del tiempo en tiempos de desarrollo, pruebas de usuario, capacitación, etc.