19 de diciembre de 2012

14 de diciembre de 2012

Las medallas...




"Las medallas se ganan en los entrenamientos. En los torneos solo pasas a buscarlas" - Anónimo

16 de noviembre de 2012

Retrotip #23


SAP vs Scrum, un choque de culturas


Hace unas semanas un cliente que le tomo el gusto a Scrum nos pregunto si se podía implementar seriamente Scrum en proyectos SAP.

Junte algunas experiencias personales de implementación parcial de Scrum en proyectos SAP y otros enlatados, investigué un poco lo que hay en la web, y pedí experiencias y material en la comunidad ágil. Gracias en particular a Martin Alaimo y Ezequiel Kahan por su ayuda!

Con todo eso armé una presentación, para tener como disparador de una charla con este cliente, que comparto: Scrum vs SAP, un choque de culturas.

Más allá el Agile Business Add-On para ASAP y algunos mapeos menos elegantes de procesos, no he encontrado formas muy convincentes de reunir los dos mundos.

Me interesa mucho poder conocer distintas experiencias al respecto, porque a pesar de todo creo que hay luz en el fondo del túnel...




15 de noviembre de 2012

14 de noviembre de 2012

Mi Slice de Agiles 2012 - Día 3

Después de haber presentado mi slice del día 1 y 2 de la conferencia Agiles 2012, sigo con el ultimo día:





El día empezó con un Open Market Place, facilitado por Alan Cyment y Fernando Claverino, donde creo que había alrededor de 100 personas.

Ahí se propusieron los distintos temas y se consolido entre todos una agenda del día. De esta agenda, pude recorrer solo una parte de los temas que me interesaban, que cuento a continuación...






11. Sesión - Supervivencia en la nieve - Leonardo De Seta y Sergio Gianazza
En esta sesión los chicos de Ideas Agiles armaron una actividad para estudiar los mecanismos de consenso en el equipo. La actividad fue divertida en mi grupo, con muchos debates y al final cierto éxito en el consenso.

La explicación posterior de los presentadores fue muy clara y enriquecedora.
Se hablo de distintos mecanismos de decisión en equipo: "mayoría", "sin oposición aparente", "El jefe decide", "consenso/unanimidad". Me gusto mucho el mecanismo propuesto para la decisión y resolución en equipo, y en particular la pregunta: "¿Como cambio la propuesta para que la votes?"

Me quede con ganas de leer:
  • El libro "Software for your head", de Michelle and Jim Mc Carthy.

12. Sesión - Cambio de Paradigma - Ingrid Astiz
En está sesión, Ingrid facilito la identificación grupal de temas que caracterizan al paradigma actual o viejo, luego lo mismo para el paradigma nuevo o del futuro, y finalmente se identificaron posible tips y ayudas concretas para pasar de uno al otro. 

Me gusto la dinámica (más en el blog de Ingrid), de todo lo que salio algunas cosas no son para mi, pero otras me dejaron pensar, en particular:

  • Probar Reiki y/o Meditación
  • El concepto de "Enjoy the flight"
  • El concepto de "Mapa del Tesoro" para visualizar hacía donde quiero ir
El cierre de a dos me gusto, donde en pareja nos contamos que queríamos empezar a hacer a la brevedad, y luego hacernos mutuamente un seguimiento (me doy cuenta ahora que no lo hice!). 

13. Coach Clinic - Valor de Negocio
Al mediodía volví a hacer de coach en la clínica  está vez con Carlos, que se había perdido mi sesión y quería hablar de Valor de Negocio. Primero me contó de su contexto, y luego le conté de la sesión que había dado (Jugando con el Valor de Negocio). Luego repasamos varias alternativas para definir el valor de negocio.

Finalmente repasamos varias referencias que pueden ser de utilidad para lograr un algoritmo para definir el valor de negocio que sea TRANSPARENTE, EXPLICITO y RETRO-ALIMENTADO, entre otras: 
Estuvo buena la charla!

14. Sesión - SAP vs Scrum
Como eramos 2 en la sesión decidimos movernos a otra sesión y charlar del tema entre nosotros en otra oportunidad.

15. Sesión - Contratos Agiles
En esta sesión se hablo de la tradicional problemática de los contratos en los proyectos ágiles. Estuvo bueno porque había gente muy escéptica y otros muy convencidos, con lo cual el debate fue interesante.

En particular resalto los puntos siguientes:
  • Lo fundamental es la confianza entre cliente y proveedor. Sin eso no podemos evolucionar hacía otros tipos de contratos.
  • Trabajar siempre con dos valores de estimación: min y max
  • Mecanismo a incluir en el contrato: luego del 30% del proyecto, el cliente puede terminar después de cualquier sprint
  • Manejar precio por sprint
  • Si se termina el proyecto antes de los sprints acordados, el cliente paga el 30% del restante
Se mencionaron las referencias siguientes: 

Luego tuve que escaparme para tomar mi avión de regreso y perderme las ultimas sesiones....
Pero bueno, la verdad fue una muy buena conferencia, con contenidos variados. Lo que me hace feliz es ver gente nueva con muy buenas ideas y actitud, veo que la comunidad agile está muy viva...

Espero estar el año que viene en Perú!

13 de noviembre de 2012

Mi Slice de Agiles 2012 - Día 2

Después de haber presentado mi slice del día 1 de la conferencia Agiles 2012, sigo con el día 2:



7. KeyNote - Organizaciones y Liderazgo Ágiles – Martín Salias
Fue una charla muy llevadora, donde Martín nos hizo pasear por varios dominios científicos y revisando comportamientos organizacionales a la luz de varios principios de estos dominios.


Algunas frases y conceptos que me gustaron:
  • “En el caos hay orden” (hablando de un hormiguero)
  • “En juegos de suma 0, si haces visible tu estrategia, generas colaboración”
  • “Si no podes cambiar tu organización, cambia de organización”
  • La Salud Empresarial como concepto separado de la Inteligencia Empresarial
  • El concepto de "Death by meeting" 
  • Usar el mecanismo de Open-Space para manejar reuniones 
  • La secuencia de crisis típicas en las PYMES: crisis de liderazgo, crisis de delegación, crisis de burocracia...
 Libros que suenan interesantes:
  • La ventaja, de Peter Senge
Links: 


8. Sesión - Dojo de Product Owner – Ricardo Colusso y Fernando Claverino
Fue una sesión que me gusto mucho, con muy buena dinámica levada por los maestros Ricardo y Fernando. Sin darme cuenta, me habían llevado por varios conceptos y técnicas bastante profundas en un ambiente simple, eficiente y relajado. A pesar de contar con una audiencia de nivel muy dispar, lograron que cada uno se lleve cosas interesantes y practicas...

Entre otros, exploramos los requisitos de Inteligencia Emocional vs. Inteligencia Técnica de un Producto Owner, las responsabilidades del Product Owner y la técnica de Visual Story Map.


9. Sesión - Jugando con el Valor de negocio - Thomas Wallet
Intenté a través de esta sesión de juego llevar a los participantes a armar su propio algoritmo de valor de negocio. Y fue una sorpresa ver a que punto los dos equipos se prestaron al juego, se compenetraron con todo y lograron buenos resultados.

Me divertí facilitando el juego, y por el feedback de los participantes, la pasaron bien. Todo el material de la sesión está disponible en este link

Sobre el final reserve un espacio de "take-away" para que cada uno escriba en un post-it una cosa que se llevaba de la sesión, y al final cada uno se llevo el post-it de otro. Gracias a todos los participantes!


10. Sesión - El eneagrama en los equipos ágiles - Claudia Ruata
En esta sesión Claudia Ruata presento los 9 tipos de personas del eneagrama, con algunas ilustraciones de su posible uso en las metodologías ágiles. Me pareció un tema interesante, pero aun con los buenos ejemplos presentados, a mi gusto requiere un dominio y un estudio profundo del tema para poder sacarle el jugo. Me quedé con ganas de investigar un poco más...


El día terminó con cervezas y pizzas en "Canario Negro", y varias charlas distendidas con gente amiga de la comunidad ágil en Sudamérica... Por suerte pude huir antes que empiece el karaoke ;)

En breve mi slice del día 3...

12 de noviembre de 2012

Mi Slice de Agiles 2012 - Día 1

Tuve la oportunidad de participar de la conferencia Agiles 2012, en Córdoba, Argentina, los días 24, 25 y 26 de Octubre del 2012.

Quiero compartir algo de lo que me quedó de esta conferencia, siguiendo mi elección de sesiones durante la conferencia, o si tomamos los términos de la técnica Visual Story Mapping, mi slice de la conferencia:



1. KeyNote - Shut Up and Play Yer Guitar – David Hussman
Me gusto esta charla, y me viene bien ver gente grossa que está muy orientado al resultado más allá de las prácticas y procesos, y en particular muy orientado a la experiencia de usuario.

Algunas frases que me impactaron:
  • “It’s not about your process, it’s about what you produce with the process”
  • “It takes 10.000 hours to master something”
  • Hablando de interacción con el negocio: “Normalizing the language is the key point”
  • Hablando de estimación: “Shifting from how big to too big
  • “If you don’t know where to go, it’s easy to iteratively not getting there”
  • “Done is when people are using stuff”
  • “Everybody should be able to talk about user experience”

Algunos conceptos interesantes:
  • Regression Deficit = Quantity (in story points) / Quality (Automated test coverage)
  • Dude’s Law: Value = Why / How
  • Agregar Wireframes y Test Cases en el slice del Visual Story Map

Herramientas que pintan bien:
  • Cardboard: tool for Visual Story Mapping, que está desarrollando con Jeff Patton


2. Break - Un cálido Café Cordobés
Primer break del evento, el momento ideal para tomarme un cálido café cordobés y charlar con varios conocidos… Pero, en una momento de gran afluencia a la mesa de café, debo haber hecho un movimiento no muy ágil y se me volcó el café en la muñeca… Me re-quemé (2do grado) y por suerte fui muy bien atendido en el puesto de enfermería de la universidad… Que torpe! Les aseguro que ahora le tengo un respeto enorme al café cordobés!


3. Sesión - How to succeed in Agile without really trying – Matt Gelbwaks y Federico Zuppa
Hace un par de conferencias que me pierdo charlas de Matt Gelbwaks, así que venía motivado para escucharlo, pero llegué tarde a la sesión por mis aventuras con el café, y me perdí algo que parecía re-interesante sobre la teoría de X,Y,Z de Douglas Mc Gregor – The Human Side of Enterprise). Tendré que averiguar…

Algunas frases que me dejaron pensando:
  • “The most common way we listen is not listenning” (Adam Kahane): you’re quiet but you’re preparing your rebuttal
Algunos conceptos rescatados:
  • El loop de: culture is Shared Values & principles, Shared Values drive behavior, which can change culture.
  • Herding Cats

Libros de interés:
  • Business Agility
Links:



4. Coach Clinic – Integración QA/Desarrollo Multi-teams
Al mediodía pude participar a la Coach Clinic como coach. Tuvimos una charla interesante en un grupo de 3 sobre cómo organizar equipos de QA con múltiples equipos de desarrollo con Scrum, y como integrar los QAs en las actividades de desarrollo. Exploramos varias ideas a probar y se me paso volando el momento.


5. Sesión - Buenas prácticas y lecciones aprendidas en QA en proyectos agiles – Mónica Colombo
La charla tenía ritmo y parecía divertida, pero se presento tanta información que me perdí y al final no entendí el objetivo de la charla…

Algunas cosas que me marcaron:

  • Comenta que en su experiencia tiene un QA cada dos desarrolladores! Qué relación!
  • Recomienda siempre hacer kick-off en proyectos distribuidos, con webcam


6. Sesión - El tamaño “SI” importa: los desafíos de escalar Scrum – Fernando Di Bartolo y Gastón Algaze
Me compro el titulo de la charla. Me gusto visualmente la presentación.
Fue interesante la experiencia en dos proyectos muy grandes que aparentemente pasaron por muchas problemáticas en las cuales Scrum ayudo a resolver algunas parcialmente.
Quizás me hubiera gustado que entraran más en detalle sobre las buenas prácticas y no solamente sobre los desafíos, aunque en poco tiempo eso es difícil…

Me gustaría conocer más de:

  • El juego “Ubiquitous Language”

Y así termino mi primer día de la conferencia, con mucha información a digerir, además de charlas con varias personas muy interesantes. 

En breve mi slice del día 2...






Jugando con el Valor de Negocio en Agiles 2012

El 25 de octubre del 2012 di una sesión de juego en la conferencia Ágiles 2012.

Comparto la presentación de la sesión. Jugando con el Valor de Negocio. 

El juego se llama Business Value Game y está disponible en varios idiomas acá.

Reuse and enjoy!

20 de octubre de 2012

Alex Kid, South Park, Dados y el Valor de Negocio

Ya tengo todo listo para mi sesión de las 14h30 el próximo jueves (25/10) en Agiles 2012, en Córdoba  Argentina: Jugando con el Valor de Negocio.

En esta sesión hablaremos de Alex Kid, jugaremos con South Park y dados para  encontrar EL valor de negocio.

Con el juego aprenderemos que la verdadera priorización es la que permite eliminar trabajo y muchas otras cosas.

Los espero el jueves!

También estaré participando como coach en la coach clinic de la conferencia, y seguro de alguna sesión del Open Space...




10 de octubre de 2012

28 de septiembre de 2012

26 de septiembre de 2012

19 de septiembre de 2012

El mejor freno a la creatividad...



"Nada es más eficiente para frenar la creatividad que el miedo a equivocarse" - John Cleese

18 de septiembre de 2012

Primera Edición del Curso Online de la UTN de Preparación a la Certificatión PMI-ACP

Después del éxito de nuestro curso online de la UTN sobre Metodologías Ágiles para el Desarrollo de Softwarecon Ulises Martin y Hernán Ricchio lanzamos un nuevo eLearning:

El próximo 15 de Octubre del 2012 iniciaremos la primera edición del curso online de la UTN de Preparación a la certificación Agile Certified Practitioner (PMI-ACP) del Project Management Institute (PMI).

El PMI ha reconocido el crecimiento de los enfoques ágiles en la gestión de proyecto e introdujo en el 2011 una nueva certificación (PMI-ACP), que está tomando cada vez más fuerza en la comunidad profesional. En mi opinión está certificación permite realizar un recorrido amplio y contundente de las practicas ágiles más interesantes hasta el momento.

El curso está diseñado para repasar las practicas, herramientas, conocimientos y habilidades ágiles alcanzados por la certificación y entender los principios y valores subyacentes. Se complementa con referencias seleccionadas para profundizar temas de interés y ayuda practica para el proceso de certificación. 

Más información e inscripciones en este link.

Los esperamos!

14 de septiembre de 2012

La cultura del gran proyecto de desarrollo (Q.E.P.D.): ¿Cómo derribar sus 6 excusas?


Aviso al lector: Con este post me estoy postulando para el Premio Bin Laden del festival de la polémica y a la vez para el Premio Ghandi del festival del idealismo. Para eso escribo...


Compañeros, ya empezó la lucha!


Veo muchas preguntas en los medios ágiles sobre como hacer convivir el agilismo frente al paradigma de grandes licitaciones de desarrollo, gestión de proyectos largos con desarrollos de alcance fijo, estimaciones gigantescas al inicio, etc. Crece cada vez más mi creencia de que no hay que convivir sino tratar de cambiar el paradigma. Creo que hay esperanza y que hay que armarse de coraje para intentar cambiar las cosas, quizás de a poco, a veces con violencia.

Así que estoy luchando, a veces con timidez, a veces con más violencia, a veces me sale y a veces no. Estoy luchando contra la Cultura del Gran Proyecto de Desarrollo.


¿Que es la Cultura del Gran Proyecto de Desarrollo?

Escucho y veo una fuerte tendencia en empaquetar desarrollos de software en proyectos enormes (mayor a un año de duración). Muchas veces es la única forma de desarrollar algo en estas empresas. Y para mi genera muchos riesgos y problemas comparado con sus pocas ventajas. Los problemas generados por esta cultura son muchos, como por ejemplo:

  • Pasamos meses/años antes de iniciar el desarrollo, y eso sale caro.
  • Cuando más largo es el proyecto, mayor chances tiene de cancelarse y/o de desviarse de sus estimaciones.
  • El contrato inicial con el proveedor elegido nos obliga a terminar el proyecto como fue pensado inicialmente, aunque surgieron nuevas necesidades y cambios importantes.
  • No podemos cortar el desarrollo antes del final, cuando quizás el costo/beneficio del resto del proyecto no rinde.
  • Se dimensiona al inicio una infraestructura, que luego se vuelve inadecuada a medida que se avanza, por los descubrimiento que se hacen en el camino y/o los cambios que surgen.
  • Sale mucho más caro de lo que se estimo al inicio con la poca información que estaba disponible.



¿Porque esta Cultura del Gran Proyecto de Desarrollo? ¿Cómo podemos luchar?

No tengo una respuesta muy elaborada a la primera pregunta. Sin embargo relevé algunas excusas comunes para gestionar los desarrollos como grandes proyectos. A continuación enumero las excusas más comunes y aporto algunas ideas o contra-argumentos para derribarlas:


Excusa 1
"Los altos costos de infraestructura hacen que debamos tomar antes de empezar una decisión de go o no go sobre el gran proyecto de desarrollo." 

Mi pequeño aporte extremista: en el 2012 eso no puede ser una excusa. Existen variadas soluciones de hosting, virtualización y cloud para poder montar una infraestructura casi sin gastos y luego hacerla escalar a medida que se necesita. Y si la infraestructura actual no se banca eso, quizás antes de pensar en desarrollar algo nuevo habría que pensar en modernizarla...


Excusa 2
"Deployar la solución es costoso/complicado, por las siguientes razones: hay que instalar en muchas maquinas, capacitar a muchas personas, hacer un cambio importante en la forma de trabajar, etc. Eso hace que preferimos armar un gran proyecto para deployar una sola vez."

Mi pequeño aporte extremista: dos ideas: 1/ Toma un porción pequeña de la organización como equipo piloto donde se puede trabajar en proyecto chicos (iteraciones), y después de un tiempo razonable se podrá hacer el deploy completo, aprovechando la experiencia del piloto. 2/ Justamente el problema del gran proyecto es que el cambio final es muy importante/violento. Hacer proyectos más chicos permite minimizar este cambio, y quizás simplificar el deploy, la capacitación, los cambios organizacionales, etc.


Excusa 3
"Necesitamos definir al inicio la arquitectura de toda la solución del gran proyecto, porque sino los cambios arquitectónicos posteriores van a ser muy costosos." 

Mi pequeño aporte extremista: en general no coincido, y en varias oportunidades pude observar exactamente el contrario: el big up front design donde se trata de pensar toda la arquitectura para poder sostener una cantidad impresionante de requerimiento lleva mucho tiempo y sale caro, y luego a medida que avanza el proyecto cambian los requerimientos. Y ya no podemos volver atrás en la arquitectura y seguimos desarrollando para una arquitectura no adecuada, lo cual trae muchos problemas al final. 


Excusa 4
Los usuarios tenemos muy pocas oportunidades de pedir (y lograr) algo de software, entonces cuando aparece una posibilidad de proyecto intentamos sumar todos los posibles requerimientos que quizás nos podrían ser de utilidad de acá a 10 años. 

Mi pequeño aporte extremista: es una consecuencia misma de la cultura del gran proyecto. Trabajar con proyectos chicos permite manejar mejor la ansiedad de los usuarios y darles varias oportunidades de pedir soluciones a sus verdaderas necesidades a intervalos periódicos (iteraciones).


Excusa 5
Cuesta mucho dividir un gran proyecto en pequeños proyectos de valor para el negocio, y poder definir el costo/beneficio de estos pequeños proyectos. Por eso mejor gestionar proyectos grandes. 

Mi pequeño aporte extremista: En este caso dudo que el proyecto grande sea exitoso, y tendría muchas dudas sobre un eventual análisis de costo/beneficio del gran proyecto. Si no se puede dividir, es probable que estemos sufriendo las consecuencias de varias de las otras excusas, pero quizás antes de meterse en un gran proyecto de desarrollo sería conveniente dedicarle tiempo en entender mejor los pequeños problemas o necesidades que se busca resolver para el negocio, y organizarlo en pequeñas unidades en lugar de un solo gran proyecto ambiguo.


Excusa 6
Para poder desarrollar tenemos que contratar a un proveedor. Y nos conviene más contratar un solo proveedor por proyecto grande (para negociar descuentos, no tener que cambiar de proveedor todo el tiempo, etc.). 

Mi pequeño aporte extremista: dos cosas: 1/ Si el proceso de contratación hace que así sea, quizás convenga mejorarlo antes de pensar en contratar nuevos desarrollos. 2/ Hay mucho riesgo en contratar un solo proveedor para un proyecto grande, y necesito tener mucha confianza en este proveedor para estar seguro que va a funcionar bien. También el contrato grande se vuelve una limitación en muchos casos a cambiar el alcance del proyecto, terminarlo antes, etc. Y finalmente escuché de varias subastas de desarrollos para elegir proveedores, donde seguramente se consiguió muy buen descuento  para el gran proyecto, pero al final no funciono para nada, se cancelo el proyecto, se fundió el proveedor,o se entrego algo de mala calidad o que no sirve, y eso hace que al final sale mucho más caro con un alcance entregado menor a lo planificado.


Te enfrentaste también a estas excusas? Encontraste otras?

Animo compañeros: ¡Muerte a la Cultura del Gran Proyecto de Desarrollo!

11 de septiembre de 2012

Séptima Reunión de la Comunidad Ágil de Neuquén


Tema¡No estimarás!

CuándoMartes 18 de Septiembre del 2012, a las 17h45

Dónde: Salón Azul del la Biblioteca Central - Universidad Nacional del Comahue - Buenos Aires 1400, Neuquén 

FacilitadorThomas Wallet

Descripción:

Estimación: Mecanismo esotérico que se solía usar hasta mitad del siglo XXI para intentar predecir con técnicas pseudocientíficas tiempos y esfuerzos en la construcción de software. Cuestionado a final del siglo XX por el movimiento revolucionario agile, el uso de este mecanismo fue decayendo con la aparición de metodologías agiles de segunda generación como Kanban y erradicado definitivamente en las posteriores metodologías agiles de tercera generación.

Los enfoques predictivos han dado a las estimaciones un lugar preponderante en los proyectos de desarrollo de software. Existen supuestos beneficios de las estimaciones, como elegir y priorizar requerimientos, organizar el tiempo, etc. Por otro lado, estimar lleva mucho tiempo, las estimaciones son altamente sensibles a los cambios y la productividad misma del equipo se ve afectada cuando la estimación es impuesta o irreal.

¿Qué sucedería si no estimáramos? ¿Es tanta la diferencia entre una estimación pobre y ninguna? ¿El esfuerzo adicional en mejorar una estimación justifica los beneficios?

Esta charla invita a los asistentes a animarse a patear el tablero… ¿podemos reducir el esfuerzo asignado a estimaciones o incluso trabajar sin estimar?




La reunión es gratuita, solo hay que inscribirse a través del siguiente link.

7 de septiembre de 2012

27 de agosto de 2012

22 de agosto de 2012

6ta Edición del Curso Online de la UTN de Metodologías ágiles para el Desarrollo de Software


El próximo 5 de Septiembre del 2012 iniciará la 6ta edición del curso online de la UTN sobre Metodologías Ágiles para el Desarrollo de Software, en el cuál soy professor, junto con Ulises Martin y Hernán Ricchio.

El curso está diseñado para adquirir una visión introductoria pero integral en las practicas más reconocidas de gestión de proyectos de desarrollo de software, tanto del enfoque predictivo como del enfoque ágil. Permite conocer las distintas técnicas y sus diferencias para poder elegir y combinar las practicas de gestión más eficientes según el contexto del proyecto.

Más información e inscripciones en este link.

Algunos comentarios de alumnos de ediciones anteriores:
"El curso online de la UTN fue mi primer contacto con las metodologías ágiles. Pasó un año y ahora estoy trabajando todos los días con metodologías ágiles y muy metido en la comunidad ágil y sus eventos." (Juan) 
"Quería agradecerles y felicitarlos porque el curso estuvo muy bueno, la documentación muy práctica y amigable." (Lucas)
"Me gustaron los debates que se generaron en los foros, cada uno aportando desde su contexto y experiencia personal." (Fernanda) 
"Ya estamos implementando scrum con algunas de las practicas de XP y trataremos de implementar kanban a los procesos de desarrollo nuestros. Muy bueno el curso!" (Gaston)
"Finalizo este curso habiendo logrado lo que esperaba, tener una una visión integral de las metodologías ágiles y mucho material para investigar! Realmente ha sido una valiosa experiencia haber realizado este curso. Me gustó mucho como se trató cada temática, tanto en sus amenos y prácticos contenidos como en su excelente disposición para focalizarse en nuestras consultas y experiencias." (Silvana)
"Lo más interesante para mí fue contrastar la teoría contra experiencias concretas y prácticas."(Juan Pablo) 
"La clase sincrónica fue muy útil porque nos permito bajar a tierra los conceptos. Me voy con ganas de introducir los primeros cambios." (Claudia) 
"Me resulto util el curso, espero poder empezar de a poco a introducir algunos cambios en el trabajo." (Carla) 




Retrotip #16


14 de agosto de 2012

Dinámica de Retrospectiva: North Check

Existen múltiples formas de implementar Scrum, y es común que un equipo solo lo esté implementando en forma parcial, por limitaciones propias, por limitaciones de la organización o por elección (por ejemplo se puede consultar el enfoque Scrum Orgánico).

Si bien considero Scrum como un framework esencial en el sentido que sus definiciones son bastante minimalistas y con fuerte nivel de acoplamiento, no creo que todos los equipos deberían aplicar al pie de la letra todas las prácticas "oficiales" de Scrum. Sin embargo me parece importante que puedan reflexionar cada tanto sobre las prácticas que no están implementando, para definir si por el momento quieren seguir así o si de a poco se puede ir agregando a su forma de trabajo.

La dinámica de retrospectiva que presento a continuación ayuda a los equipos a reflexionar sobre su implementación de Scrum, comparando su adherencia actual al framework de Scrum y su "norte", o sea la dirección a seguir para completar la implementación de las practicas de Scrum que el equipo quiere/puede sostener en el tiempo.

  • Nombre: North Check (Chequeo del Norte)
  • Participantes: 5 a 10 personas
  • Duración: 45 minutos
  • Alcance: al finalizar una iteración corta (4 semanas o menos), típicamente después de varios meses de trabajo con Scrum
  • Propósito: recabar información e indagar
  • Facilitador: opcional, ayuda tener uno
  • Objetivos: Usando el Scrum Checklist de Henrick Knibbergcomparar la adherencia actual del equipo al framework de Scrum y su "norte", o sea la dirección a seguir para completar la implementación de las practicas de Scrum que el equipo quiere/puede sostener en el tiempo. 

Scrum Checklist - Henrick Knibberg

  • Material y Preparación 
    • Imprimir un Scrum Checklist por cada participante, y uno más para recopilar resultados.
    • Una lapicera por participante 
  • Pasos
    1. Introducción - El facilitador (o un miembro del equipo si no hay facilitador) explica el objetivo de la actividad. En particular se introduce el Scrum Checklist. Se pueden repasar cada ítem del mismo para aportar las aclaraciones necesarias a su entendimiento.
    2. Checklist Individual - Cada participante completa por su cuenta su checklist: para cada ítem se evalúa si el participante está "De acuerdo", "Más o Menos", "En Desacuerdo".
    3. Puesta en Común - Se consolida las respuestas del grupo: para cada ítem del checklist se registra la cantidad de respuestas de cada tipo: "De acuerdo", "Más o Menos", "En Desacuerdo".
    4. Debate Puntos Polémicos - Se debaten en grupo los puntos donde hay mucha variabilidad en las respuestas del grupo, para entender los distintos puntos de vista. 
    5. Acuerdo Puntos a Mejorar - Se revisan en grupo los puntos del checklist donde el equipo percibe que no lo tiene bien implementado (los puntos donde hay mayoría de "En Desacuerdo"). Para cada uno de estos puntos, se puede debatir: 
      1. Las razones de la no implementación (cuáles son los impedimentos)
      2. Si el equipo quiere y puede avanzar en la próxima iteración con la implementación de mejoras en este punto (recomiendo dejar para una actividad posterior de la retrospectiva la definición de las acciones a realizar).
    6. Priorización Mejoras - Priorizar en grupo el orden de los puntos a trabajar.
  • Variantes:
    • Hacer el paso 2 en pareja y no individualmente.
    • Si hay poco tiempo, hacer el paso 2 todos juntos y no hacer el paso 3.
    • Usar otra escala de valuación de los puntos: 
      • de 1 a 10
      • Fuertemente de acuerdo, De acuerdo, Más o menos, En desacuerdo, Fuertemente en desacuerdo
      • Verdadero, Más verdadero que falso, Ni verdadero ni falso, Más falso que verdadero, Falso
    • Trabajar solo sobre una parte del checklist.
    • Usar otros checklists, como por ejemplo: Nokia TestAssess Your AgilityComparative Agility, Agile Kalskrona TestAgile Assessment ThoughtWorks 
  • Tips:
    • Esta dinámica puede ser muy útil cuando se percibe que las practicas de Scrum se vuelven muy rutinarias y/o no aportan mucho valor al grupo.
    • A la hora de elegir los puntos a mejorar me parece importante enfocarse en pocos a la vez, y elegir bien las batallas cuando hay resistencia, en particular cual es el mejor momento para implementar una cosa nueva (Paso 6)
    • Contar con un facilitador puede ser útil para ayudar en el entendimiento de los puntos del checklist (Pasos 1 y 2)
    • Contar con un facilitador también permite ayudar a identificar bien los impedimentos que hacen que ciertas prácticas no se implementen (Paso 5.1).
    • Es interesante hacer esta dinámica de retrospectiva periódicamente (por ejemplo cada 3 meses), y comparar resultados con las anteriores.
    • Esta actividad se puede complementar luego con otra actividad para identificar acciones concretas para implementar las mejoras priorizadas en el paso 6.
  • Origen: Thomas Wallet, aplicando el Scrum Checklist de Henrick Knibberg para retrospectivas

Para cerrar, como dice Henrik Knibberg: "La perfección no es un lugar, es una dirección", o la versión simplificada de mi hijo de 4 años: "No es una carrera". Deberíamos usar estas evaluaciones de adherencia para identificar mejoras. Es más importante seguir moviéndonos en la mejora continua que donde estamos ubicados o cual es nuestro ranking.  

    7 de agosto de 2012

    Retrotip #15


    Jugando con el Valor de Negocio en Cordoba


    Estaré facilitando una sesión de juego en la conferencia Agiles 2012, en Córdoba, Argentina los días 24, 25 y 26 de Octubre del 2012.

    Aceptaron mi propuesta "Jugando con el Valor de Negocio". Se trata del juego Business Value Game, de Vera Peeters and Pascal Van Cauwenberghe, en el cual los participantes experimentarán alrededor de la definición de valor de negocio de distintos proyectos e historias de usuarios, de la priorización y planificación para aportar valor al negocio. Los participantes van a aprender por qué y cómo construir y usar un “modelo de valor de negocio”.

    También estaré participando de la Clínica de Coaches en la conferencia.

    Nos vemos en Córdoba!


    2 de agosto de 2012

    Sexta Reunión de la Comunidad Ágil de Neuquén (Juego Scrum)


    Próxima Reunión de Comunidad Ágil de Neuquén

    CuándoMiércoles 8 de Agosto del 2012, a las 17h45
    Dónde: Salón Azul del la Biblioteca Central - Universidad Nacional del Comahue - Buenos Aires 1400, Neuquén 
    Tema: Juego de simulación de Scrum


    En esta sesión se va a facilitar un juego con rastis para experienciar en un entorno seguro y sin presión los mecanismos de Scrum. Seguro nos vamos a divertir y aprender!

    FacilitadoresEmiliano Pereyra y Emiliano Gonzalez

    La reunión es gratuita, solo hay que inscribirse a través del siguiente link.

    30 de julio de 2012

    27 de julio de 2012

    La pieza perfecta - Clases de Cerámica y Desarrollo de Software

    Intento traducir a continuación una anécdota del libro Art & Fear, de David Bayles y Ted Orland, que leí en el post When good is bad de John Sonmez:
    "El primer día del curso de cerámica, el profesor dividió el grupo en dos partes. Dijo que todos aquellos en el lado izquierdo del estudio, serían evaluados únicamente en función de la cantidad de piezas que produzcan, mientras todos los de la derecha serían evaluados en función de la calidad de las piezas producidas. 
    Su procedimiento era simple: en el último día de clase pesaría con su balanza de baño las piezas de calidad "A" (la mejor calidad), luego las piezas de calidad "B" (la segunda calidad), y así sucesivamente. Para los evaluados únicamente en función de la calidad (el segundo grupo), alcanzaría haber producido una sola pieza perfecta, de calidad "A".
    Llego el momento de la evaluación, y paso algo curioso: el trabajo de mejor calidad fue producido exclusivamente por el grupo "cantidad". Parece que mientras el grupo "cantidad" estaba ocupado en producir pilas de piezas -y en aprender de sus errores-, el grupo "calidad" estaba teorizando el concepto de perfección, y al final no tenían para mostrar como fruto de sus esfuerzos mucho más que teorías grandiosas y una pila de arcillas muertas."
    Más allá de la muy buena reflexión que propone John Sonmez en su post, me surgen muchos paralelos para el grupo "Calidad" con algunos vicios que se ven en el desarrollo de software, como por ejemplo el Big Upfront Design, el Análisis-Parálisis, el Sprint 0 Eterno, el ante-proyecto que dura meses/años, los 6 meses de especificaciones, etc.

    Y para el grupo "Cantidad" veo muchas relaciones con algunos conceptos y valores claves de las practicas ágiles como el empirismo, el descubrimiento continuo de las necesidades, la inspección y adaptación del producto, la mejora continua, aceptar el cambio, etc.

    Creo que muchas veces perdemos mucho tiempo antes de empezar un trabajo, tratando de predecir algunas cosas que es más fácil descubrir sobre la marcha, aunque no parezca muy natural.

    Para cerrar me gustaría citar a Pitágoras:
     "El inicio es la mitad de todo"

    25 de julio de 2012

    19 de julio de 2012

    16 de julio de 2012

    13 de julio de 2012

    Las 3 métricas claves del kanban

    Me gusta explicar Kanban a equipos de TI con las siguientes tres reglas esenciales:

    1. Mostrar el proceso y el trabajo en curso
    2. Limitar el trabajo en curso
    3. Optimizar el flujo de trabajo

    En este post quiero detenerme en particular sobre 3 métricas que me parece fundamental monitorear para trabajar la tercera regla.

    ¿Cuáles son las tres métricas?

    Cycle Time: Es la métrica que registra el tiempo que sucede entre el inicio y el final del proceso, para un ítem de trabajo dado. Se suele medir en días de trabajo. 

    Lead Time: Es la métrica que registra el tiempo que sucede entre el momento en el cual se está pidiendo un ítem de trabajo y el momento de su entrega (el final del proceso). Se suele medir en días de trabajo. 

    La siguiente traducción de la explicación de Corey Ladas sobre la diferencia entre Cycle Time y Lead Time ayuda a entender mejor estos conceptos:
    "El reloj del Lead time se inicia cuando se hace el pedido y termina cuando se entrega. El reloj de Cycle Time se inicia cuando el equipo empieza a trabajar sobre el ítem y se termina cuando el ítem está listo para la entrega. El Cycle Time es una medición más mecánica de la capacidad del proceso. El Lead Time es lo que ven los clientes. El Lead Time depende del Cycle Time, pero también depende de la buena disposición para mantener un backlog de ítems de trabajo, de la paciencia del cliente y de la disponibilidad para recibir la entrega del cliente. Otra forma de mirarlo: el Cycle Time mide el ritmo de terminación, mientras el Lead Time mide el ritmo de entrega."


    Touch Time: Descubrí el concepto en el libro Lean From The Trenches, de Henrick Knibberg (y al poco tiempo lo empezamos a registrar en el kanban de un equipo de testing):

    Es la métrica que registra el tiempo en el cual un ítem de trabajo fue realmente trabajado (o "tocado") por el equipo. Dicho de otra forma: cuantos días hábiles pasó este ítem en columnas de "trabajo en curso", en oposición con columnas de cola / buffer y estado bloqueado o sin trabajo del equipo sobre el mismo.

    Con lo cual, para un mismo ítem: 

    ¿Cómo registrar las tres métricas?

    No soy muy amante de las herramientas para soportar los tableros kanban, pero en el caso de usarlos, seguro tendrán funcionalidades muy lindas para registrar y monitorear estas 3 métricas (y mucho más).

    Para los suertudos que usan tableros fiscos de kanban, es bastante fácil mantener el registro de estas métricas sin que sea una carga administrativa pesada. Lo que en mi experiencia funciona bien es anotar en los post-its de los items de trabajo alguna información y luego completar una planilla digital con esta información en el momento de finalización del proceso de trabajo de cada ítem.

    • Información a registrar para Cycle Time y Lead Time
    El tablero debería contar con una columna "Backlog" donde se agrega un post-it de ítem de trabajo cada vez que se hace un pedido de trabajo. La idea es anotar en el mismo post-it la fecha en la cual se agregó el post-it al tablero (=fecha de pedido). Por otro lado, cuando un ítem de trabajo se empieza a trabajar (y su post-it ingresa a la primera columna de trabajo del tablero), se registra la fecha en el mismo post-it (=fecha de inicio).

    • Información a registrar para Touch Time
    Un mecanismo simple para eso es agregar un punto rojo en el post-it de un ítem de trabajo para cada día en el cual el equipo no hizo nada para este ítem. Tipicamente esto ocurre cuando un ítem permanece en una columna de cola / buffer, cuando surge un bloqueo externo al equipo o cuando el equipo está trabajando sobre otros ítems. Si el equipo hacer reuniones diarias de actualización del tablero, es bastante fácil de implementar durante la reunión. 



    • Planilla de calculo de las métricas
    El ultimo paso es ingresar esta información en una planilla de calculo. La idea es que cada vez que un item se entrega (=ingresa a la columna de "Terminado" del tablero), se vaya guardando cierta información del post-it en una planilla de calculo. En particular: la fecha de pedido (1), la fecha de inicio (2), la fecha de entrega (3)  y la cantidad de días bloqueados (4)

    En esta planilla se pueden armar los cálculos siguientes para las 3 métricas: 
      • Cycle Time = DíasHabilesEntre(3-2)
      • Lead Time = DíasHabilesEntre(3-1)
      • Touch Time = Cycle Time - 4


    DiasHabilesEntre(fecha1, fecha2) se puede resolver por ejemplo con la función "NETWORKDAYS" en las planillas de google docs. Ver esta planilla de ejemplo (con los feriados del 2012 de Argentina).


    ¿Qué monitorear?
    En mi experiencia, es importante revisar periódicamente o durante retrospectivas los números a continuación. En la tabla también explico posibles interpretaciones de las tendencias y algunas pistas para mejorar: 
    ¿Qué monitorear?
    Tendencia
    Posibles Interpretaciones
    Posibles Acciones
    Promedio del Cycle Time Está bajando - El equipo está mejorando
    - Proceso más fluido 
    - Seguir así!
    Promedio del Cycle Time  Está subiendo - Se complejiza el trabajo
    - Hay bloqueos y/o cuellos de botella
    - Se desmotiva el equipo
    - Analizar cuellos de botella y bloqueos de trabajo
    - Revisar motivación del equipo y/o capacidad del equipo para el trabajo 
    Promedio del Lead Time  Está bajando - No hay pedidos
    - El equipo está sobre-dimensionado
    - Mejoramos 
    - Analizar si no deberían llegar más pedidos
    - Analizar dimensionamiento del equipo
    Promedio del Lead Time  Está subiendo - Hay muchos pedidos
    - El equipo está sub-dimensionado
    - El ritmo de trabajo no es suficiente

    - Revisar validez de los pedidos
    - Analizar dimensionamiento del equipo
    - Revisar motivación del equipo y/o capacidad del equipo para el trabajo 
    Variabilidad Cycle Time Muy variable- Muchas diferencias de complejidad entre los items
    - Deuda técnica acumulada surge en cualquier ítem en forma aleatoria
    - Separar items en varias clases de servicios o según complejidad (alta, media, baja)
    - Atacar la deuda técnica e implementar prácticas para bajarlas (XP)
    Promedio Touch Time / Promedio Cycle TimeBaja proporción- Mucha espera en el proceso
    - Muchos bloqueos en el proceso y cuellos de botella
    - Mucho mult-tasking
    - Bajar los limites de WIP y trabajar sobre puntos de bloqueos y cuellos de botella
    - Identificar puntos de espera externa y trabajar sobre su optimización
    Promedio Cycle  Time / Promedio Lead TimeBaja proporción - El equipo está sub-dimensionado
    - El ritmo de trabajo no es suficiente
    - Analizar dimensionamiento del equipo
    - Revisar motivación del equipo y/o capacidad del equipo para el trabajo 

    ¿Usan estas métricas? ¿Tienen otras en su Kanban?

    10 de julio de 2012

    5 de julio de 2012

    Retrotip #9


    4 de julio de 2012

    Dinámica de Retrospectiva: Back to the Future


    Vi esta dinámica de retrospectiva en varios lugares, y si bien la usé una sola vez y hace mucho tiempo, me parece muy interesante.
    • Nombre: Back to The Future
    • Participantes: 5 a 12 personas
    • Duración: 1 hora
    • Alcance: al principio de un proyecto o al principio de una etapa importante
    • Propósito: identificar y elegir acciones de mejoras, definir una visión compartida del éxito
    • Facilitador: necesario 
    • Objetivos: con esta dinámica el equipo va a intentar imaginar en el futuro el éxito del proyecto, y luego pensar los mecanismos claves para poder concretarlo.
    • Material y Preparación: un pizarron con marcadores. Eventualmente post-its y hojas si se hacen brainstorming y/o votaciones.
    • Pasos
      1. Establecer el marco - El facilitador explica el objetivo de la actividad y setea el marco: en que momento del futuro nos estamos proyectando y en que situación. Por ejemplo: "nos encontramos el día del cierre del proyecto X, y el Gerente de Negocio da un discurso de felicitaciones a todos los involucrados", o "se comunican los resultados del concurso del proyecto más exitoso del año, y sale nuestro proyecto", o "pasaron 20 iteraciones y estamos trabajando muy bien y logrando resultados superiores a las expectativas".
      2. Definir el éxito futuro - El equipo trata de imaginar, en el marco ficticio acordado, cuales son los resultados exitosos logrados. Se puede facilitar como un brainstorming, o una reflexión de grupo. Es importante que el facilitador vaya anotando a la vista de todos  los entregables o resultados concretos que se mencionan, con sus principales características (por ejemplo: "hubo 50.000 downloads del producto en una semana", "se cubrieron todas las expectativas del sector de marketing", "nos hicieron una nota en una revista", "después de 2 semanas en producción no surgieron bugs importantes", etc.). Si son muchos puntos identificados, se pueden priorizar en función se su importancia en el éxito
      3. Identificar mecanismos claves del éxito - En sub-grupos de 2 o 3 personas, trabajar sobre cada punto identificado en el paso anterior. El objetivo es identificar lo que permitió llegar al resultado exitoso correspondiente. Por ejemplo, para el resultado "después de 2 semanas en producción no surgieron bugs importantes", se podría identificar los mecanismos siguientes: "implementamos TDD en todos los módulos" y "hicimos una prueba piloto de una semana con la sucursal X". Luego cada grupo presenta sus mecanismos y el grupo completo vota por los mecanismos que parecen más eficientes para cada resultado exitoso. 
      4. Volver al presente - Ahora se vuelve al presente. Sobre los mecanismos más votados, el equipo identifica las acciones concretas que el mismo grupo podría implementar en la próxima iteración (o a corto plazo). Eventualmente se pueden priorizar las acciones si surgen varias, de tal forma que el grupo se quede al final con pocas acciones concretas a implementar en el corto plazo.
    • Variantes
      • Para el paso 2, el facilitador puede pre-definir los resultados exitosos logrados y no dejar que el equipo lo defina. Eso permite ahorrar tiempo de retrospectiva, pero por otro lado la visión propuesta no tiene la misma fuerza que si la define el mismo equipo.
      • En el paso 3, se pueden elegir solamente algunos resultados del paso 2 para trabajar.
      • En el paso 2, se puede hacer primero un trabajo personal donde cada uno escribe en su hoja 2 o 3 resultados exitosos y luego hacer una puesta en común grupal y eventualmente priorizar los resultados. 
    • Tips
      • Recomiendo guardar registro de los resultados del paso 2, y eventualmente dejarlo bien visible en algún lugar de trabajo del equipo. Es un buen material para referenciar y volver a consultar a lo largo del proyecto y al final. Cuando más identificación del equipo haya con estos logros a conseguir mejor.
      • En el paso 3 es importante que el facilitador mantenga el foco sobre lo que está al alcance del equipo. El riesgo es que se identifiquen mecanismos fuera del alcance del equipo: "la empresa competidora entro en banca rota", "nos pagaron premios millonarios", que no son muy útiles a la hora de identificar acciones de mejora. 
      • En el paso 4 es importante llegar a acciones concretas, que el mismo equipo pueda implementar y de corto plazo.
    • Origen: no se exactamente de donde sale esta dinámica, pero la vi en varios lados como por ejemplo  el post Future-spectives de Anders Laestadius.
    ¿Ya usaron esta dinámica o algo parecido? ¿Como les fue?