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 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?

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 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.
Reunión diaria

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 argimento 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, sobre 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? Exprésalo 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 agilidadlos Scrum Masters y los coaches ágiles son roles cuyas funciones son bastante conocidas y comprendidas. Las transformaciones suelen empezar por los equipos, luego escalan y hay que imprimir cadencia, alineación y sincronización, y finalmente la transformación llega al nivel de organización, dónde se requieren de coaches empresariales o Enterprise Agile Coaches cuyas competencias están enfocadas a la estrategia ágil a nivel holístico.

Cartel anunciado el openspace
En el Global Scrum Gathering Munich 2016 Olaf Lewitz y Evelyn Tian lideraron un openspace 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 openspace
En el openspace 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 entrenador 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 openspace 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 de 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.

martes, 8 de noviembre de 2016

¿Hay correspondencia entre documentos a reportar a la PMO de proyectos en cascada y proyectos con Scrum?

La oficina de proyectos - cortesía de Tamer
Recientemente un jefe de proyecto que estuvo en uno de mis cursos de Scrum me escribió contándome que ya estaba aplicando el marco, pero que la oficina de proyectos le demanda los documentos más habituales de un proyecto en cascada, y me pidió asesoramiento sobre cuál podría ser una correspondencia de los mismos en Agile-Scrum.

No hay correspondencias, una oficina de proyectos ágil tienes las funciones de:
  • Asignar y asegurar la financiación en base a la estrategia de la compañía
  • Guiar, asistir y apoyar la ejecución de los proyectos
  • Tomar métricas de productividad, satisfacción de cliente, salud en las relaciones con los partners, motivación del personal y presentación de informes que den valor a la compañía como calidad, nivel de agilidad y time-to-market
y el cuadro de artefactos clásico sobre el que mi pidió asesoramiento tiene este aspecto:


Bien, fijémonos que el cuadro trata puntos de control que son de proceso, no de productividad como sería en el caso de agilidad.

Hace más ruido un árbol que cae que todo un bosque que crece
(Oscar Andrés Rodriguez)

Hice el ejercicio por curiosidad y diversión, y busqué correspondencias aunque fuera como comparar peras con manzanas.

C1 Stage Gate

Project Charter with Tier determination
Correspondería a un plan de proyecto con determinación de nivel; lo más cercano a un plan de proyecto serían las actividades de la incepción ágil en la que se crea la visión, se identifica a la comunidad de comprometidos e interesados, se muestra a muy grandes rasgos la solución y se estima de forma preeliminar su tamaño.

(Draft) Business Case
Correspondería a la exploración del modelo de negocio mediante un Business Model Canvas.

High level timeline
Correspondería a la hoja de ruta de la planificación ágil, en caso correspondería a la hoja inicial que debería de ajustarse con cada en entrega a mercado o producción.

Cost estimates +/- 50
Podríamos asociarlo a una de las actividades de la incepción ágil, al ¿Cuánto cuesta? que es una estimación de costes muy a grandes números que sirve para situarnos en el orden de magnitud.

C2 Stage Gate

Completed requirements matrix/document
Correspondería a la pila de producto inicial a nivel de epics obtenida en un User Story Mapping.

Approved Business case
Correspondería al Business Model Canvas aprobado, pero ojo, en agilidad hasta que no obtengamos feedback del mercado no habremos madurado lo suficiente... a medida que entregamos y obtenemos feedback del mercado deberemos de seguir explorando con el canvas.

Detailed Project Plan and sign-off
Correspondería a un documento que recogiera el plan del proyecto, quizá como lo propone SAFe con un lightweight epic-only business case.

Timeline
Correspondería a la planificación de release, que también está viva y se iria actualizando con cada sprint entregado.

Resource Plan
Para Scrum utilizaríamos el sprint 0 para aseguramos que todos los recursos están disponibles. Los riesgos se mitigan rápidamente en Scrum, el sprint 1 fallará si algo no está disponible ya que entregamos de forma temprana algo totalmente funcionando y potencialmente instalable en producción. 

Vendor Management Plan
En Scrum se trata de trabajar de forma cotidiana y cara a cara a lo largo de todo el proyecto. Para trabajar en Scrum no debe de haber diferencias entre el personal del cliente y el del proveedor, realmente se trata de partners, y absolutamente todos los integrantes del equipo global deben de estar comprometidos con el proyecto.

Cost estimates +/- 10%
El enfoque de la agilidad es distinto; la compañía decide desde la estrategia el presupuesto a invertir en el producto y confía en sus equipos de negocio, representados por sus Propietarios de Producto, para darles el poder de decisión para inviertir en todo momento en las funcionalidades que más valor de negocio tengan. El proyecto se acaba cuando el presupuesto se acaba, pero garantizando que con el presupuesto asigando se ha construido el mejor producto posible.

Implementation Gate

Test Plan
Se acomete sprint a sprint, cada sprint debería de incluir el testing hecho al 100%, aunque podemos seguir un patrón semiágil para ser más clásicos y estar alineados con la oficina de proyectos. :-P

IT testing sign-off
Podríamos asociarlo a lo que ocurre en la revisión de sprint cuando repasamos todos los criterios de aceptación. En un entorno con pruebas automatizadas ocurre cuando todos los indicadores están de color verde.

Performance testing sign-off
Se deberían de hacer a los largo de los sprints o antes de subidas a producción por el equipo de testing de sistemas.

UAT sign-off
Se deberían de hacer por parte del usuario o equipo de negocio después de cada sprint entregado.

Training plan
Debería de ocurrir con cada subida a producción, recodemos que en Scrum practicamos la entrega frecuente con lo que la curva de aprendizaje es muy corta.

Project Delivery Gate checklist and sign-off
El equipo de gestión de entregas a producción deberá de tener su lista DoD de definición de hecho que deberá de cumplir antes de subir a producción.

Project Status prepared by Project Managers
No hay project managers, el avance real del proyecto se conoce con cada sprint entregado, recordemos el séptimo principio del Manifiesto Ágil: "El software que funciona es la principal medida del progreso". El progreso del sprint se conoce de forma diária en las reuniones diárias y a través del gráfico de burndown.

Steering Committee organized by Project Mgr
El gobierno de la construcción del producto debería de garantizar que en cada momento se esté construyendo lo que más valor de negocio aporte, y eso es reponsabilidad de negocio, concretamente de los Propietarios de Producto, y en un marco escalado del equipo de Product Managment.

Project Financials prepared by Project Mgr & Project Sponsors
Es responsabilidad de los Propietarios de Producto conocer el valor de negocio y el ROI de cada historia de usuario y epic, métricas que se deben de actualizar con cada sprint.

Project Closeout lead and organized by Project Manager Participate lessons learned
El enfoque de la agilidad es distinto; la forma ágil de conocer el éxito de un proyecto es hacer una encuesta de satisfacción al usuario final, identificar el nivel de "contento" del mismo con el producto resultante. Respecto a las lecciones aprendidas recordar que Scrum se basa en la mejora continua, una mejora que se produce poco a poco en cada sprint y a través de las retrospectivas. La cuestión es si tiene sentido buscar mejoras cuando el proyecto ya está acabado. Desde el punto de vista ágil lo ideal es que un producto/proyecto no tenga fin, ya que eso significa que está vivo y que produciendo beneficios para la compañía. Un producto que no evoluciona probablemente esté obsoleto.

Mis a agradecimientos Fidel que me ha instado a hacer este ejercicio... :-D