jueves, abril 28, 2016

Sin excelencia técnica no hay agilidad

Hola a todos

Hace unos días me encontré con este excelente post de Michael Sahota @MichaelSahota - Agile vs Waterfall en donde compara rápidamente Agile y Waterfall


Y donde se presenta que al final de cascada lo que se genera es un lío para por fin entregar el producto.

Pero he visto este mismo lío en la entrega en muchos equipos Scrum cuando no se pone atención a la excelencia técnica, con prácticas como:
  • estándares de codificación
  • buenas prácticas de programación
  • revisión por pares
  • TDD
  • ATDD
  • refactoring
  • propiedad colectiva de código
  • integración continua
  • pruebas unitarias
  • revisiones estáticas de código
  • pair programming
  • mob programming (4)
  • pruebas funcionales automatizadas
  • principios de diseño OO (SOLID)
  • clean code
  • etc

Termina sucediendo que los bugs en producción van en aumento (incrementando la deuda técnica (1)) y lo que inicialmente se usaba como el patrón de desenfoque o interrupción (5)


Que por buena práctica debería tomar aproximadamente el 10% al 20% del sprint backlog, termina por acaparar ciclo tras ciclo toda la capacidad del equipo durante un sprint.

Y en definitiva el tiempo del sprint que inicialmente se iba a emplear para crear incrementos de valor para el negocio termina usándose para corregir bugs y deuda técnica.

Así las cosas, por más que tengamos:
  • retrospectiva (2)
  • mejora continua
  • sprints
  • dailys 
  • reviews 
  • cultura ágil/agile
  • scrum
  • etc, 
No servirá de nada sino entregamos software de valor y bien construido cada sprint, pues esta sencilla omisión se vendrá en nuestra contrá

la deuda técnica siempre se paga


Cerrando

Hasta aquí este deber social de poner foco sobre este tema que como principio ágil, reza:

La atención continua a la excelencia técnica y al buen diseño mejora la Agilidad.

Y por experiencia me atrevo a corregir una parte de ese enunciado de la siguiente manera:

Sin excelencia técnica no hay agilidad

La parte del diseño si la dejo igual.





Saludos ágiles
Jorge Abad



Notas, aclaraciones y referencias

  1. Deuda técnica un enfoque holistico por Ángel Nuñez - @snahider http://es.slideshare.net/snahider/software-debt-que-es-y-como-gestionarlo
  2. Que debería entre otras cosas, invitar/retar al equipo hacia la mejora técnica, y sería un error del Scrum Master no hacerlo.
  3. Ver los principios ágiles aquí - http://agilemanifesto.org/iso/es/principles.html
  4.  Mob programming como forma de auto organización de un equipo Agile por Oscar Amelunge - @oscaramelunge (clic aquí)
  5. El patrón de desenfoque o de interrupción (expuesto por Jeff Sutherland - @jeffsuhterland en Scrum The Future Of Works (clic aquí) ) tiene por objeto dejar un porcentaje pequeño del sprint (10 al 20%) para atender interrupciones que tienen como fuente temas del ahora como bugs en producción críticos, funcionalidades urgentes para el PO, etc.
  6. Unas diapositivas de Israel Antezana Rojas - @israelantezana que invitan también a esta reflexión : SCRUM no es suficiente... (clic aquí)

lunes, abril 25, 2016

No esperar hasta la retrospectiva para mejorar

Hola a todos

El corazón de Ágil como lo expone Alistair Cockbourn (clic aquí) es:

  • Colaboración
  • Entrega temprana y continua de valor
  • Adaptación
  • y Mejora

Esto debe ser vivido por todo equipo que se identifique como ágil.

Hoy quiero centrarme justo en la mejora, pues identificamos que esta por lo general se da en la retrospectiva cuando el equipo decide que experimentos y mejoras realizar al siguiente ciclo en todos o cualquiera de los siguientes aspectos:
  • Personas e interacciones
  • Procesos
  • Herramientas
o cualquiera de sus variaciones como
  • Calidad (corresponde a procesos)
  • Felicidad (corresponde a personas)
  • Tecnología (corresponde a herramientas)

Volviendo al tema que nos interesa, muchas veces durante el sprint identificamos mejoras (cualquiera dentro del equipo puede hacerlo - todos somos responsables de hacer las cosas mejor - ) y resulta que nos cuestionamos si esperar hasta la retrospectiva para la mejora o podemos implantarla ya.

La respuesta es muy simple
  • Si la mejora es fácil de implantar y son obvios sus beneficios, la implementamos (¿que nos impide hacerlo, sabiendo que nos beneficiará?)
  • si la mejora es compleja de implantar, lo decidimos en la retrospectiva
Bueno hasta acá esta pequeña reflexión.


Saludos Ágiles

Jorge Abad

Diatriba: Una salida a la sobresimplificación de nuestros problemas en proyectos

Hola a todos

Hoy quiero compartir una situación común en los proyectos y organizaciones, que se repite una y otra vez, adicionalmente creo que tanto ustedes como yo lo hemos vivido

El escenario es sencillo:
Se reúnen varios líderes asociados a la construcción de un proyecto (1) a deliberar ¿por qué este se encuentra mal o en riesgo?, Y la primera respuesta que sale es:
  • ¡El problema son los RECURSOS! ( - refiriéndose al equipo de trabajo - ,wow ¿estudiamos 5 años, más las experiencias, diplomados, certificaciones, especializaciones y maestrías para responder esto?)
y acá veo varios  problemas en esta óptica que quiero compartirles:
  1. En primer lugar no son recursos, son personas, esta eterna lucha por que comprendan que el trabajo lo hacen personas tan valiosas como quienes dirigen y que al pensar en una forma reduccionista sobre las personas lo que logran es ignorar o desperdiciar la capacidad creativa e innovadora del ser humano, y del equipo que los acompaña.
  2. ¿Quién en sus cinco sentidos quiere hacer mal su trabajo? La verdad no dudo que los hayan (serán muy pocos), pero no es lo común, todos queremos hacer cosas que ayuden a otros, que sirvan, que sean útiles y que estén alineadas con el propósito para el cual sentimos que estamos acá en esta tierra, por lo tanto culpar al equipo de trabajo es una costumbre simplista que indica que no se quiere abordar con el debido interés la causa y la solución del problema.
Pero cuando lo opinión mágica no está orientada a los "recursos" se centra en otro tema (9), todos concuerdan, se abrazan y sonríen, deciden que hacer y salen de la reunión hasta que después sean convocados a otro comité para hablar sobre lo mismo y notar que los problemas no fueron resueltos o todos lo olvidan pues surgió otro proyecto en problemas para analizar.

¡Rayos! Y recuerdo siempre a la cita del periodista del siglo pasado H.L. Mencken
Para cada problema complejo hay una solución clara, simple y equivocada,( H.L. Mencken)
No lo niego, al principio yo era así, además cuando asumes posiciones de liderazgo tiendes a adoptar los mismos lenguajes y análisis de tus pares, pero luego cuando en el 2012 conocí las metodologías ágiles y el poder de las retrospectivas para mejorar un equipo y su forma de trabajo, realmente cambió mi forma de ver las cosas.

Con esta nueva óptica, encontrarme en reuniones como esta no niego que me daba enojo, pues tendemos a la simplificación o sobresimplificación por herida newtoniana, ¿cómo así? Todos hemos sido heridos en nuestra lógica por Newton y su causa y efecto y tendemos a creer que todo se resuelve así, por lo tanto, buscamos desesperada y angustiosamente una causa que explique nuestro problema (o efecto) y dado esto encontrar la solución y continuar con el siguiente problema pues hay muchos líos en la fila esperando a ser resueltos.

Algunos ejemplos de nuestra común sobresimplificación:

  • ¿por qué el país está mal, por el presidente?
    • como si todos no hiciéramos parte de un país y fuéramos parte de la maquinaria que lo mueve.
  • los proyectos de software fallan principalmente por los requisitos
    • es una de las causas pero no es la única causa
  • ¿Y por qué fracasó su relación de pareja?, por una infidelidad de él/ella
    • es muy probable que la infidelidad sea el síntoma y no la enfermedad, y la enfermedad era una serie de disfunciones en la pareja que hicieron que hubiese esa infidelidad,
  • etc.


Y me topé con Cynefin

Cynefin es un framework para entender qué tipo de problema estamos enfrentando y proporciona herramientas de cómo resolverlo, este framework me fue presentado por mi estimado Ricardo Colusso (@rcolusso) y desde ahí comencé a aficionarme a el, y recientemente leí un minilibro sobre el tema en Infoq.com (4) y muchas ideas se aclararon - recomendada su lectura -. Explicaré brevemente en qué consiste.

El framework de Cynefin fue elaborado por el Investigador Dave Snowden, y el término significa "hábitat", divide los tipos de problema en 5 áreas y propone herramientas para solucionarlo

  • El obvio:
    • Problema conocido
    • tiene relación directa causa efecto
    • Ejemplo: Se chuzó la llanta, solución cambiar la llanta o parcharla
    • Se resuelve con una mejor práctica
    • Pasos de solución: inspeccione - categorice - responda
  • El complicado
    • Problema que se puede llegar a conocer
    • Tiene relaciones causas y efectos conocidas
    • Ejemplo: Se daño un vehículo y el mecánico luego de inspeccionarlo sabe los diferentes arreglos que hay que hacer para poner nuevamente el vehículo en marcha y estado óptimo.
    • Se resuelve con las mejores prácticas, juicio de expertos, todo es perfectamente planeado (cronogramas, tiempos, planeación predictiva, PMP) y los expertos resolverán este tipo de problemas de la misma manera teniendo el mismo éxito.
    • Pasos de solución: inspeccione -analice - responda
  • El complejo
    • Problema es entendido en retrospectiva
    • las relaciones causa y efecto no son repetibles
    • Ejemplo: La economía es excelente prediciendo el pasado y explicándolo pero no es precisa hacia el futuro
    • Se resuelve con la multiexperimentación
    • Pasos de solución: inspección - adaptación
  • El caos
    • El problema es incoherente
    • las relaciones causa efecto no son perceptibles
    • Ejemplo: Escenarios de I+D
    • La solución es novedosa
    • Pasos de solución: ensayo y error
  • El desorden
    • Corresponde al punto cuando llegamos a un problema y aún no lo hemos categorizado en los cuatro anteriores





Bajo todo lo expuesto quisiera invitarlos a varias cosas:

  1. No caer en la sobresimplificación de los problemas que enfrentan, identificar si hay causa y efecto directamente relacionada o explicable, ya sea en el espacio de lo obvio o de lo complicado o realmente no.
  2. Si lo anterior no se cumple trate de identificar si está en el espacio de lo complejo, desde mi punto de vista y de otros muchos en la industria del software (5) la gestión y ejecución de proyectos de software cae allí, o sino díganme ¿qué gerente de proyecto de software es capaz de predecir todos los percances que le van a presentar en la ejecución del mismo, por más buena gestión del riesgo que haga? La verdad no conozco el primero, son capaces de explicar que les pasó y porqué les paso pero no de predecirlo por más que llenen el cronograma de colchones para la gestión del riesgo..
  3. Si estás en una reunión de estas de análisis de problemas, propón lo siguiente:
    1. Identifiquen las causas
    2. las prioricen (cuales son las que consideran más importantes)
    3. Propongan soluciones
    4. Las prioricen (cuales consideran claves, 3 o 4) (6)
    5. las ejecuten y observen en un ciclo de no más de un mes (ojalá menos) los resultados de ese experimento y decidan qué pasos seguir, tal vez sea necesario otro experimento.
Para este último escenario existen diversas herramientas de 
  • análisis de causa raíz
  • retrospectivas (que incluyen lo anterior)(8)
  • Toyota Kata (7)
que son bastante fuertes y útiles.

Por tanto, quisiera invitarlos a que abracemos la complejidad de nuestros proyectos y organizaciones y abandonemos la sobresimplificación.




Cerrando

Y bueno, propongo que los líderes de proyecto, gerentes, etc, seamos más creativos y demostremos nuestros años de estudio, experiencia y certificaciones identificando las verdaderas causas y dejemos la sobresimplificación de los problemas que enfrentamos, entendiendo que nos movemos en un espacio complejo sobre el cual no tenemos control, esta actitud, será mucho más útil, que ignorarlo.



"No estamos en las organizaciones para ofrecer soluciones rápidas sino para ofrecer las soluciones correctas"



Saludos ágiles
Jorge Abad


Notas, Referencias y Aclaraciones


  1. También puede ser una empresa, un área organizacional.
  2. Es un trabajo arduo remover este vicio de la gerencia tradicional de proyectos
  3. Expicación de Cynefin segun wikipedia -https://en.wikipedia.org/wiki/Cynefin_Framework
  4. Excelente libro sobre Cynefinby por Greg Brougham, corresponde a la colección de minilibros gratuitos de infoq.com - (clic aquí)
  5. Debo esta referencia, pero no dudo que los firmantes del manifiesto ágil hacen parte de este grupo,
  6. No se deben hacer todas las mejoras, al menos 3 o 4 para saber cual fue la mejora, solución o experimento que más influyó en la solución del problema.
  7. Excelente presentación sobre el tema de Hiroshi Hiromoto (@hhiroshi) (clic aquí)
  8. Retrospectivas (ver más acá)
  9. He también visto como se centran estos comités en culpar a las pruebas y acusan de la calidad del software solo a esta actividad del proceso, o cualquier otro chivo expiatorio ¡OMG!



domingo, abril 24, 2016

Algunos Tweets sobre Contratos Ágiles







sábado, abril 23, 2016

Saber escuchar, escucha activa


Hola a todos

Les comparto un excelente video donde se nos enseña la escucha activa, y nos muestran problemas que tenemos al escuchar, como :
- escuchar para responder
- escucharnos a nosotros
-etc


saludos ágiles y espero les sirva como a mí.



Liderazgo Agil y otros temas por Gustavo Quiroz

Una excelente Charla de Gustavo Quiroz, donde habla del Liderázgo Ágil, Adiciional toca temas como:

  • Liderazgo servicial
  • Rol de Scrum Master
  • Escucha atenta
  • Comunicación asertiva
para verlo hagan clic aquí https://www.youtube.com/watch?v=HmQ-fwPP9NQ

Taller de Retrospectivas

Imágenes del taller de Retrospectivas del curso de Scrum


En este taller cada equipo reflexiona como pudo haber realizado mejor susimulación de Scrum, basados en las actividades aleatorias generadas por Retromat - http://plans-for-retrospectives.com/index_es.html








lunes, abril 11, 2016

La "Zona de Valor de Negocio". Una reflexión sobre ¿cuándo termina un release en un proyecto Ágil / Scrum?

Hola a todos

Hace unos días discutía con mi estimado amigo Lucho Salazar (@luchosalazarc) sobre la forma de medir el progreso en proyectos ágiles y él me exponía de forma muy radical de acercarse al concepto:


  • Ajá Jorge, como dice el principio del manifiesto: "El software funcionando es la medida principal de progreso"(1), y para de contar, por lo tanto, cuando el Product Owner -PO- diga llegamos al valor de negocio, pues llegamos, antes no. (2)


Wow, reconozco que es una posición muy radical y liberadora, que no dudo que existan escenarios y empresas donde esta se puede aplicar, pero, mientras logramos generar (o encontrar) esos contextos liberadores, para adentrarnos en el concepto que quiero compartir de "zona de valor de negocio" es necesario poner ciertas bases:


Concepto de Valor de Negocio

Es el propósito para el cual fue creado el software que cumple con una o varias necesidades dentro del entorno en que fue creado (3).



La ley de Pareto se Cumple para los Productos de Software

En general solo empleamos entre el 20 y el 50 por ciento del software que creamos (ver la siguiente imagen) (4), por lo que si nos enfocáramos en lo realmente esencial, construiríamos software más rápido, con menos desperdicio y menos funcionalidades a las cuales darle soporte y mantenimiento.

Tomada de SlideShare (5)

Asociado a cada Release debe estar Asociado un Objetivo de Negocio (Capacidad de Negocio) a Cumplir

Como norte para un equipo scrum y aun más para un Product owner (con todos sus stakeholders / interesados) debe estar asociado un objetivo o capacidad transversal y usable a cada liberación del producto (6) , de esta forma cuando el PO esté solicitando funcionalidades que no le aportan al objetivo de negocio, tanto el Team como el Scrum Master puedan cuestionar al PO y evitan construir producto desperdicio. Por lo general, sugiero que se busque una capacidad de negocio a cumplir. Por ejemplo en un sistema de gestión de salas de cine, podríamos tener el siguiente listado de releases:

  • Release Cero, Walking Skeleton o Minimo Producto Viable (MVP): Poder realizar reservas en el sistema telefónicamente con el DI (documento de identidad) y registrar ventas y asignación de sillas en el punto de atención antes de la entrada a las salas de cina.
  • Release 1: Poder realizar las reservas de asientos de salas de cine online. Aun sin pago.
  • Release 2: Poder reservar sillas y comprar de cine via internet
  • Release 3: Poder realizar compra de comida en la tienda del teatro de cine
  • Release 4: Poder acumular y redimir puntos por compra de boletería y consumo de alimentos vendidos por la sala de cine.
  • Release 5: Generar boleteria QR, para ingreso a la sala.
  • etc.


La Zona de Valor de Negocio

La zona de valor de negocio es aquella zona donde creemos que vamos a lograr la capacidad de negocio esperada para un Release, es decir, el equipo puede lograr llegar a esa capacidad:
  • antes del sprint planeado
  • luego del sprint planeado
  • antes de la cantidad de alcance inicialmente estimada
  • con mucha más cantidad alcance de la estimado
El llegar o no en el tiempo y con un alcance identificado dependerá de dos variables:
  • de la velocidad del equipo de generar alcance
  • y de la capacidad de priorización del PO, que haga que el equipo sea productivo y realmente construya producto con valor que le aporte a la necesidad de negocio (7)




Si el PO hace una priorización adecuada, con seguridad llegaremos antes de lo identificado  al valor de negocio esperado, y podamos exponer como dice mi estimado:




Concluyendo

  • Es una buena práctica asociar a los Releases un Objetivo de Negocio (Capacidad de Negocio) a cumplir
  • La zona de valor de negocio puede encontrarse antes o después (tanto en tiempo o como en alcance) del punto estimado al inicio de la planificación del Release
  • La labor del PO puede ayudarnos a encontrar el valor de negocio antes (cumpliendo Pareto)
  • Las discusiones con el estimado Lucho son bastante enriquecedoras y generarn post valiosos ;)

Saludos ágiles

Jorge Abad





Notas, comentarios y referencias

(1) Principio 7 del manifiesto ágil - http://agilemanifesto.org/iso/es/principles.html
(2) En lo posible léase este comentario con acento de Costeño colombiano.
(3) Concepto de elaboración propia y que se encuentra en revisión
(4) Para una mayor precisión sobre el tema sugiero leer el Chaos Manifesto del 2013, del Standish Group( https://www.versionone.com/assets/img/files/CHAOSManifesto2013.pdf  ) el cual cito textualmente:  "Our analysis suggests that 20% of features are used often and 50% of features are hardly ever or never used. The gray area is about 30%, where features and functions get used sometimes or infrequently. The task of requirements gathering, selecting, and implementing is the most difficult in developing custom applications. In summary, there is no doubt that focusing on the 20% of the features that give you 80% of the value will maximize the investment in software development and improve overall user satisfaction. After all, there is never enough time or money to do everything. The natural expectation is for executives and stakeholders to want it all and want it all now. Therefore, reducing scope and not doing 100% of the features and functions is not only a valid strategy, but a prudent one. "
(6) Ojalá el sistema cuente con al menos dos liberaciones y la primera máximo a los seis meses - es una buena práctica imponerse estas metas -.
(7) Productividad mejor que velocidad (ver más aquí)