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