"El Agilismo es como el Tenis: Simple pero no fácil"

En el día de hoy, en nuestro espacio de autores invitados tenemos al Ingeniero de Sistemas y Especialista en Mercadeo Juan Andrés Ochoa, quien es el Director General en Castor S.A. - compañía que genera mejoras disruptivas en sus clientes y colaboradores mediante la transformación digital con enfoque Ágil y humano - quien amablemente nos ha permitido publicar en nuestro sitio este artículo, que originalmente se encuentra en el siguiente Link:

https://castor.com.co/el-agilismo-es-como-el-tenis-simple-pero-no-facil/

"El Agilismo es como el Tenis: Simple pero no fácil"

Jugar Tenis es algo simple: Dos jugadores en una cancha golpeando una una pelota para que pase por encima de una red, intentando anotar puntos así: Que alguno no responda, que la pelota caiga fuera del campo, que quede atrapada en la red o que rebote más de una vez.

Simple ¿cierto? ¿Lo has intentado? Yo sí, varias veces, y los resultados fueron fatales, nunca he podido jugar algo mejor que fatal.

Miremos algunas similitudes:

Durante un partido de Tenis es posible que la estrategia de juego esté funcionando y que el resultado sea positivo, sin embargo el haber ganado un set no es garantía de victoria definitiva.

Cada pelota a jugar es diferente a la anterior, con la condición de ese preciso instante. Se necesita aprender rápidamente de lo que pasó en la bola anterior para capitalizarlo de forma inmediata.

El contrario puede adaptarse a nuestro juego, elaborar un contraataque y respondernos con cambios que lo pueden llevar a tomarnos ventaja, además aspectos del entorno como el viento, la llovizna, el desgaste del terreno y el público pueden provocar cambios.

Solo falta ver el estado en el que queda Wimbledon luego de un torneo.

Los buenos agilistas actúan como los buenos jugadores de Tenis: Todo el tiempo están inspeccionando y adaptándose al contexto. Es mas, abrazan y aman el cambio y saben que es posible que lo que dio resultado en el pasado no funcione aquí y ahora.

Jugar Tenis nos pone a prueba, los niveles de atención y concentración son exigidos al máximo en un escenario de toma de decisiones en cortísimos intervalos de tiempo. No es sólo tu capacidad física, es también tu capacidad de mantenerte atento a los cambios, aprender inmediatamente de ellos y ajustar tu juego en cada bola.

Los buenos agilistas saben y practican que la adaptación al cambio y el mejoramiento continuo son fundamentales para llegar a resultados diferenciales y finalmente a ser mejores trabajadores y personas.

Recuerdo a un gran tenista, Stanislas Wawrinka. Ha sido el único fuera de los 4 maestros (Federer, Nadal, Djokovic y Murray) que logró ganar más de un torneo de Grand Slam durante los últimos 16 años.

Stan tiene un tatuaje en su brazo que dice “Siempre lo intentaste. Siempre fallaste. No importa. Inténtalo otra vez. Falla de nuevo. Falla mejor” .

«Siempre lo intentaste. Siempre fallaste. No importa. Inténtalo otra vez. Falla de nuevo. Falla mejor » Samuel Beckett

En Agilismo y Transformación digital es igual: Hay que darse (y darle a los equipos ) permiso a equivocarse de manera fácil, rápida, barata y aprendiendo.

Los buenos agilistas promueven el desarrollo sostenible, son capaces de mantener un ritmo constante de forma indefinida, y saben que la entrega de valor (resultados y felicidad sostenible) es la medida principal de progreso.

El Tenis es uno de los deportes que mayor destreza técnica exige, puesto que debes desarrollar capacidad física, alta coordinación, timing , velocidad, precisión, sensibilidad y una increíble fortaleza mental para mantenerte a lo largo de un partido.

Sin excelencia técnica no tendrás resultados, por lo que debes tener una preparación a nivel conceptual, psicológica y física y además practicar en diferentes contextos, siempre buscando mejorar.

Así mismo los buenos agilistas practican excelencia técnica, preparación, mejora continua, trabajo, constancia y enfoque en los resultados de valor y en la felicidad de los equipos.

Para ser un gran agilista, así como para ser un gran tenista, se requiere trabajar mucho, caerse y pararse una y otra vez, en entornos Volatiles, Con incertidumbre, Complejos y Ambiguos (VUCA).

Y no es lo único difícil, porque el agilismo no lo puedes jugar tú sólo, entonces en la organización hay que promover temas como liderazgo, comportamientos, valores, cultura, mindset, experiencias y resultados y no basta con invertir dinero, contratar o certificar personal.

Transformarse al agilismo sólo se logra con mucho trabajo duro, alineación de propósitos , mucha reflexión, gestión del cambio y motivación intrínseca de muchas personas de la organización, entre otros aspectos. Ya no suena ni simple, ni fácil cierto?

Pero creéme que vale el esfuerzo , sino pregúntale a Stan Wawrinka, Nadal, Federer, o a directivos de empresas como Phillips, Seguros Sura, Apple o Bancolombia.

Como Bonus track te tengo este video donde muestra cómo para Serena Williams el Tenis es increiblemente Simple, Fácil y Divertido: Haz clic aquí para verlo.

Además te quiero compartir una experiencia: Sé muy poco de Tenis, la escritura de este artículo fue un experimento alucinante, convoqué a varios amigos que si juegan y saben del tema y que además saben de transformación ágil y les propuse que lo escribiéramos juntos . La experiencia fue buenísima.

Y si has leído hasta aquí es porque algo tuvo que haber salido bien!. Si quieres que te comparta algo de esta experiencia no dudes en contactarme.

Este artículo fue co-creado con :

Julian Andrés Prieto , Denys Reyes y Diego Marín

Autor : Ing.Juan Andrés Ochoa

Fuentes consultadas: 

https://castor.com.co/el-agilismo-es-como-el-tenis-simple-pero-no-facil/

https://www.linkedin.com/pulse/el-agilismo-es-como-tenis-simple-pero-f%C3%A1cil-juan-andres-ochoa?articleId=6571053917122162688#comments-6571053917122162688&trk=public_profile_post

Fuente de la imagen:

http://royaltennisclub.com/tennis/ 

¿Qué es Agile? Mitos y Verdades

En el día de hoy en PMPMedellin queremos compartir un artículo de nuestro amigo agilista que pertenece a la comunidad de Agiles Latinoamérica. Andrés Salcedo quien es Certified ScrumMaster (CSM), Agile Team Facilitator (ATF) y es  Ingeniero de Sistemas egresado de la universidad ICESI, en la actualidad es Coordinador de Proyectos de TI en Banco de Occidente. Él cuenta con más de 5 años de experiencia ayudando a dicha organización en el desarrollo productos de excelente calidad y co-creando grandes espacios de trabajo. Andrés  ha facilitado sesiones de Agile Inception, eventos Scrum y ha sido Speaker en diferentes talleres, entrenador de más de 250 personas sobre diferentes prácticas ágiles como Scrum, Management 3.0, Lean & Kanban.

 

¿ Qué es Agile?    Mitos y Verdades

Siempre que facilito algún taller de agilismo, pido a los asistentes escribir en 60 segundos todas las palabras que lleguen a su mente cuando escuchan: “ágil”, “agile” o “agilismo”. Los términos más comunes suelen ser: “rápido”, “rapidez” o “velocidad”. Aunque los proyectos ágiles pueden dar la sensación de ser más “rápidos” que los tradicionales. No es correcto calificarlos con estas palabras.

Es una falacia creer que un proyecto gestionado con agilismo tardará menos en terminar la totalidad de su alcance que si se trabaja bajo metodologías tradicionales. Sería un error querer aplicar alguna práctica ágil buscando este fin.

Si agilismo no es sinónimo de hacer las cosas más rápido, entonces ¿qué es agilismo?

Mito #1: Agile es terminar las cosas más rápido.

Probablemente la definición real de agilismo decepcione a algunos, por parecer idílico o genérico.

Agile es un mindset, es decir una estructura mental. No se practica agilismo, se es ágil.

Al conformar un equipo ágil, es común pensar que para conseguirlo basta con encerrar en una misma sala a un conjunto de personas que se reúnan todos los días de pie durante 15 minutos, además de dotarlos de un televisor, post-its, tableros y marcadores.

Nuestro proceso tradicional de aprendizaje se basa en imitar comportamientos de un experto. Si queremos aprender a nadar no inventamos nuevos movimientos, en su lugar adoptamos los comportamientos o movimientos que aprendemos de un tutor.

Cuando se pretende implementar agilismo de forma empírica imitando los comportamientos de otros equipos ágiles, sin tener el paradigma mental (mindset) alineado hacia agilismo, lo único que se conseguirá es lo que Ángel Medinilla y Jhonny Ordoñez llaman agilidad cosmética.

Mito #2: Con post-its en la pared, un play station y puffs en la sala de reuniones se es ágil.

Cada uno de nosotros interpreta las cosas de forma diferente, porque lo que aceptamos como verdad es el resultado de las experiencias propias que coleccionamos durante nuestras vidas.

Desarrollamos una forma de ver el mundo a partir de este paradigma mental que se construye de lo que aceptamos como válido, por eso asumimos que trabajar prácticas ágiles es algo sencillo, cuando realmente es todo lo contrario.

Para ser ágil, es necesario en la mayoría de los casos renunciar a algunas “verdades”, reaprender y aceptar que puede haber formas diferentes de hacer las cosas.

Las personas que hemos trabajado con enfoques metodológicos tradicionales y pasamos por este proceso de reaprender, aceptamos que hay formas diferentes de liderar a las personas, entendemos que son personas y no recursos. No está mal cometer errores y fallar, lo importante es aprender. Un diagrama de Gantt no aporta valor en contextos de incertidumbre.

 

 

Figura 1. El corazón de ágil

Alistair Cockburn habla de 4 elementos clave que conforman el corazón de este paradigma mental:

Colaborar: Los equipos son colaborativos e incluyen al cliente. Con un propósito. Auto-organizados. Cross-funcionales.

Entregar: Entregar valor de manera continua y temprana.

Reflexionar: Inspeccionar y reflexionar sobre qué hemos hecho bien, y qué podemos hacer mejor.

Mejorar: Adaptarse para mejorar continuamente.

Una vez aceptamos los cambios de mindset, descubrimos que valores como la confianza, compromiso, coraje, respeto y apertura, van más allá de lo que creíamos.

Un jefe puede afirmar que confía ciegamente en sus colaboradores, pero si hace seguimiento y control de sus actividades es porque realmente no hay una confianza real, o por lo menos, no ciegamente. Lo mismo podemos decir cuando hacemos actas de reuniones o dejamos por escrito las definiciones con un usuario, realmente lo hacemos porque creemos que en un futuro nos fallará y es mejor evitar sorpresas.

Una vez se reaprende el alcance de cada valor, se desarrollan diferentes actitudes, interpretaciones y principios.

El foco ya no es el producto o el proceso, sino el cliente. Las entregas tempranas de valor se hacen importantes. Aceptamos el feedback como un regalo y no como un regaño. Hablamos de equipos autónomos, de alto rendimiento y multifuncionales. Liderazgo servicialMejora continuaColaboraciónEmpoderamiento.

 

Figura 2. ¿Hacer Agile o ser Agile?

Jhonny Ordoñez habla de agilismo como un iceberg de hielo, donde la parte que sobresale de la superficie del mar son las prácticas, herramientas, los comportamientos visibles de los equipos ágiles. Mientras que la mayor parte de este iceberg se encuentra bajo la zona visible. Estos son los valores y principios.

Para que una organización pueda conseguir una transformación digital efectiva, debe concentrar su esfuerzo en la cultura: creencias, valores y principios.

Las prácticas o marcos ágiles son solo herramientas, dependiendo de nuestro contexto y necesidad, una será más valiosa que otra. No existe una práctica universal que produzca mejores resultados.

Si se requiere hacer un dibujo en una hoja de papel, un lápiz es una herramienta viable para satisfacer esta necesidad. Si se requiere pintar las paredes de un edificio, pensar en un lápiz es una locura. Lo mismo ocurre con las prácticas ágiles, existen muchas herramientas como Scrum, Lean, Kanban, Management 3.0, DevOps, SAFe, LeSS, Nexus, FDD, XP, BDD, entre otras.

La locura del lápiz universal que pinta paredes se hace real cuando desde la alta gerencia se ordena a los equipos aplicar Scrum para “acabar más rápido los proyectos”. 

Mito #3: Scrum aplica para cualquier equipo y contexto.

No hacemos dailys, ni pegamos post-its en paredes para decir que somos ágiles, lo hacemos porque creemos en el trabajo colaborativo, entregas tempranas de valor, transparencia y feedback temprano para adaptarnos al entorno.

Autor : Andrés Salcedo 

Referencias

Las Organizaciones Duales (Kotter)

En el día de hoy en PMPMedellin queremos compartir un artículo elaborado por nuestro invitado Daniel Blanco  quien se desempeña como Consultor profesional independiente en temas de calidad, estrategia y liderazgo de empresas, él es egresado de la Universidad Politécnica de Madrid y ha permitido que publiquemos en nuestra página su artículo titulado "Las Organizaciones Duales (Kotter)". Mismo que esperamos sea de su agrado y que lo compartan en sus redes empresariales y redes sociales.

Las Organizaciones Duales (Kotter)

El éxito actual de cualquier organización es garantizar su rapidez e innovación para conseguir competir con éxito en la economía de grandes cambios actuales.

Esta agilidad estratégica precisa según John P. Kotter de la gestión de las llamadas organizaciones duales que combinan la gestión de sus procesos mediante la jerarquía tradicional y su “esperanza” a medio y largo plazo mediante la llamada redarquía.

El libro de Kotter “Acelerar” aboga por el diseño de las empresas con dos sistemas de trabajo donde uno se encuentra orientado a la consecución de los resultados en el día a día y el otro sistema, actuando como complementario, actúe de forma similar a una red ágil explorando y analizando oportunidades a medio y largo plazo. El objetivo final es la generación de entidades competitivas y capaces de gestionar las amenazas y aprovechar correctamente las oportunidades de modo que las entidades sean capaces de combinar la eficiencia en sus tareas y responder a los cambios cada vez más rápidos que se producen en su entorno.

Las entidades jóvenes suelen carecer de una estructura excesivamente rígida actuado más “en modo red” con objeto de aprovechar el máximo de las oportunidades el medio ambiente de la empresa pueda ofrecer (la continua búsqueda de una ventaja competitiva), en este punto los directivos actúan como centro de la entidad y el resto de personal actúa con bastante autonomía en diferentes actuaciones teniendo un elevado grado de implicación del personal y manteniendo una visión compartida.

El éxito de las empresas provoca, en muchas ocasiones, la necesidad de dotar de una estructura jerárquica, una elevación de la burocracia y una división de las funciones (con el fin último de minimizar riesgos y ganar en eficiencia) por lo que las entidades se vuelven más lentas y rígidas y su capacidad de adaptación al cambio se ralentiza*.

Aclaración*. Para Kotter los problemas de la jerarquía se traducen en la existencia de silos de comunicación (impiden que la información vaya de Dirección a la base de los trabajadores de un modo ágil), la burocracia y exceso de procedimentación (suponen barreras a la velocidad estratégica), cortoplacismo (los resultados trimestrales o semestrales no suelen concordar con la misión y visión de la entidad), miedo a tomar iniciativas (los superiores mandan) y autocomplacencia (si el pasado ha sido bueno para que vamos a cambiar).

Asumiendo que la jerarquía y la “cadena de mando” es necesaria para la gestión de cualquier empresa (recomiendo consultar los 14 principios del Henri Fayol), actuaciones como grupos interdepartamentales, círculos de calidad, aplicación de estructuras más horizontales y generación de procesos dinámicos logran mejorar y agilizar las entidades*.

Nota*. Desde el punto de vista de Kotter hasta cierto punto. Mi punto de vista es que estas actuaciones mejoran bastante la gestión empresarial. Kotter resumen que la jerarquía como estructura no fue diseñada para el entorno de fuerte cambio imperante en los últimos años.

La “solución” pasa por la premisa de una empresa y dos estructuras: la jerarquía para optimizar el trabajo a corto y medio plazo y la redarquía para gestionar la innovación y las oportunidades que puedan presentarse.

De este modo el primer sistema (jerarquía) se basa en una buena estructura de procesos, tanto de gestión como operativos, que permiten a la organización la obtención de los resultados de un modo eficiente gestionando sus recursos de un modo óptimo. Por otro lado el segundo sistema (redarquía) contituiría una red más ágil y dinámica totalmente fuera de la burocracia de la entidad y formado por un conjunto de personas (voluntarias) que abarquen todos los niveles y área de la empresas y que aporte la “materia prima” para la creatividad y la innovación.

La clave se encuentra en que ambas estructuras deben encontrase “conectadas” principalmente a través de los trabajadores que se sitúan en los dos sistemas* lo que posibilita el aprendizaje organizativo y que la información se trasvase entre ambos sistemas “derribando” los límites entre departamentos y niveles. El objetivo final es la consecución de una empresa eficiente pero con su visión puesta en el largo plazo.

Observación*. Un punto muy importante a considerar es que la redarquía no se gestiona como un proyecto, pues no precisa de control sino de un liderazgo por influencia.

El sistema operativo dual de Kotter se basa en cinco principios:

Muchos voluntarios para el cambio (1)

La necesidad de que el cambio alcance a todos los niveles de la organización precisa de su impulso por un buen número de personas y su participación en el sistema dual. El sistema jerárquico consolida un número reducido de personas de confianza a la Dirección de la entidad lo que genera el riesgo de no incluir a todos los estamentos y áreas de la organización. Kotter los define claramente “se necesitan más ojos para ver, más cerebro para pensar y más piernas para actuar con el fin de acelerar”.

Una mentalidad de “llegar a” en lugar de “tener que hacerlo” (2)

La necesidad de que el trabajo en red sea totalmente voluntario es vital para el correcto desarrollo de la redarquía. Las personas deben “sentir” la necesidad de trabajar bajo un propósito común y en una iniciativa relevante.


Acción impulsada por la cabeza y el corazón (3)

Los cambios precisan de un sentido y propósito más allá de la lógica numérica. Se trata de un trabajo para crear el futuro de la organización y precisa que el personal involucrado encuentre un sentido en su trabajo.


Más liderazgo y menos gestión (4)

El aprovechamiento de oportunidades y la detección de amenazas que “rodean” a la organización precisan de un liderazgo por influencia que consiga la participación activa de todos sus componentes con el fin de “aprovechar” las ventajas. La visión defendida por Bennis y la agilidad son componentes necesarios para garantizar la redarquía.

La asociación inseparable entre la jerarquía y la redarquía (5)

Se trata del gran reto: ambos sistemas deben funcionar con uno sólo con un intercambio constante de información y trabajo. El secreto se sitúa en que las personas que trabajan de un modo voluntario en la red ya se encuentran dentro del organigrama. No hay tiempos diferentes para ambos sistemas se precisa del trabajo simultáneo aunque deban “instalarse” espacios y tiempos para la innovación.

Considerado el texto del propio Kotter en relación a los 8 pasos para liderar el cambio se observan algunas diferencias como que los pasos se emplean en forma secuencial y los aceleradores con concurrentes; los pasos se impulsan por un grupo pequeño de elegidos y aceleración debe “contener” al mayor número de personas; los pasos se diseñan para una estructura jerárquica “pura” y los aceleradores demandan un sistema dual.

En resumen y como consecuencia de la aceleración del cambio que afecta a empresas y que demanda de éstas una mayor capacidad de reacción, flexibilidad y adaptación sus estructuras y relaciones deberán adaptarse a la gestión de dicho cambio y como modelo para "gestionar el futuro" por lo que la metodología de organización dual se posiciona como salida para conseguir “lo mejor de ambos mundos” es decir la efectividad en los procesos del día a día y consecución de una agilidad estratégica que tenga en cuenta las oportunidades que se generan en el entorno que rodea a la entidad.

“Las estructuras jerárquicas y los procesos organizativos que se han utilizado durante décadas para gestionar y mejorar las empresas ya no están a la altura de los desafíos a los que nos enfrentamos en un mundo de cambios acelerados.”
John Kotter, consultor y experto estadounidense de gestión y liderazgo.

Autor: Daniel Blanco

NOTA: El artículo original pueden encontrarlo en la siguiente fuente : http://dbcalidad.blogspot.com.co/2017/05/las-organizaciones-duales-kotter.html

El trío infernal : Scrum, Kanban y XP

En el día de hoy en nuestro sitio PMPMedellin tenemos como autor invitado al ingeniero Giovanny Cifuentes quien se desempeña actualmente como Scrum Máster con experiencia en gestión de proyectos ágiles. Él en su vida profesional ha sido desarrollador, diseñador, jefe de proyectos, emprendedor y ha tenido experiencia en la mayoría de dedicaciones del desarrollo e implementacion de software.

En el día de hoy en su artículo nos cuenta su visión sobre la implementación de Scrum  y metodologías ágiles en nuestro país. El artículo se titula "El trío infernal: Scrum , Kanban y XP" veamos lo que tiene para decirnos...

"El trío infernal : Scrum, Kanban y XP"

Autor: Giovanny Cifuentes

Se está volviendo popular en las organizaciones el entusiasmo de aplicar “métodos agiles”, debido a la fuerte tendencia que está teniendo en el mercado .

Pongamos un caso hipotético, imaginen a fulanito que es gerente de una organización, día a día ve que muchas personas están hablando de Scrum y otras cosas más, también se da cuenta que algunas van dirigidos a algo llamado “Trasformación Digital”, la cual esta apalancada por algunas prácticas de marcos de trabajo ágil. Fulanito decide empezar a aprender un poco sobre agile ,ve videos en internet, lee algunos artículos y asiste a algún evento donde se habla de tema.

De un momento a otro se le ilumino el bombillo y dice: "esto es lo que necesita mi organización!!" -Entrega frecuente y de valor.

Al siguiente día se reúne con sus colaboradores y les comenta la idea de implementar Metodologías Agiles en la organización, delega la responsabilidad y espera los resultados extraordinarios que se prometen. Sus colaboradores deciden capacitarse en temas agiles haciendo el curso de certificación de Scrum Master, contratan unas horas de un consultor ágil. Después de formarse durante unas semanas y aprender todo del consultor, deciden emprender el camino e iniciar a aplicar Scrum, arman un par de equipos, crean un Backlog y comienzan las iteraciones.

Al pasar las iteraciones observan que los resultados no son los esperados y que las cosas no son tan fáciles como lo dice la receta mágica.

Comienzan los cuestionamientos ¿Sera que los métodos agiles si funcionan? ¿Si estamos haciendo las cosas al pie de la letra, porque no funciona?¿Esto no me lo enseñaron en el curso? ¿Por qué no somos extraordinarios?.

El caso anteriormente mencionado, es la historia del día a día de muchas personas que creen que entrar en el mundo ágil es cuestión de días, y que debe ser una implementación a la velocidad de la luz , ¡Ya es ya!.

Cuando estamos iniciando en la aplicación de algunos métodos agiles, muchas veces nos sesgamos por la utilización de un marco de trabajo en específico (Moda), intentando aplicarlo al pie de la letra pasando por alto que los procesos adaptativos se deben evolucionar con el aprendizaje generado por la experimentación de los mismo. Agilidad es un mindset que debe ser interiorizado para conseguir los fabulosos resultados que algunos han encontrado, es cultural y la cultura no se adhiere de la noche a la mañana, pueden durar años para conseguirlo, trabajando codo a codo, interiorizando los valores y principios agiles.

Es ahí donde tenemos que construir híbridos de diferentes herramientas, prácticas, técnicas y demás , para encontrar cual es la mejor forma de trabajo que se acomoda a lo que necesita la organización y permitirá mejorar el desempeño de los equipos. Saber utilizar la herramienta de proceso en el momento y lugar adecuado es el principal trabajo de un facilitador de equipos que implementa agilidad en una organización.

Es muy importante entender que los cambios deben ser pausados y orgánicos, un bebe no aprende a caminar de un día a otro, se tropieza y vuelve a levantarse, por medio de la práctica y el aprendizaje llega a su objetivo.

Los métodos agiles más comunes utilizados para iniciar en agilidad son Scrum, Kanban y Programación Extrema. Cada uno tienes sus complejidades y serie de aprendizajes que se deben adquirir para poder aplicarlos efectivamente, juntos conforman una fórmula para generar muy buenos resultados, puden ser el inicio para una transformación ágil.

Scrum

-Se divide parte de la organización en equipos auto organizados con conocimientos multidisciplinarios, con todas las habilidades necesarias para construir un producto y/o servicio de punta a punta.

-Se Entrega una cantidad de trabajo priorizada para su desarrollo y entrega entre 1 a 4 semanas.

-Se deja a los equipos estimar y comprometer a entregar un incremento en un periodo de tiempo fijo.

-Se revisa el incremento y brinda feedback para que lo que se construye sea lo que se necesita.

-El equipo realizar inspección para buscar mejora del proceso y se adapten a las circunstancias.

Kanban

-Se busca los diferentes flujos que se tiene en los procesos.

-Se identifican los diferentes pasos para asígnale una columna y ponerle un nombre.

-Se visualiza el flujo de trabajo para cada paso.

-Se limitar el trabajo en progreso.

-Se mide el tiempo que dura en pasar por cada uno de los pasos (Lead Time).

Programación extrema

-Se busca la aplicaciones de buenas prácticas de programación :

Programación en Pareja, código limpio, pruebas automatizadas, integración continua, entrega continua, despliegue automatizado y algunas más.

Proceso = Como hace algo.

Herramienta = Medio para realizar un propósito.

Técnica = Habilidad para ejecutar cualquier cosa.

Este “trio infernal “ podría ser el camino para iniciar una trasformación organizacional hacia agilidad, es bueno implementarlos pausadamente, realizando pilotos con pocos equipo y contar con personas calificadas que tengan lecciones aprendidas (Heridas de guerra) y pueden brindar los consejos adecuados, no es algo de semanas, un buen acompañamiento puede durar años.

Es un proceso que puede llegar a ser muy lento, no nos dejemos cejar por buscar resultados a poco tiempo, es algo orgánico y lento que siguiendo los principios de inspección y adaptación se logran resultados realmente extraordinarios.

Fuentes:

Kanban y Scrum –obteniendo lo mejor de ambos (Henrik Kniberg & Mattias Skarin 2010).
http://giovannycifuentes.com

 

A Benedetti le gusta la gente Agile

En el día de hoy queremos en PMPMedellin compartir un artículo escrito por el profesor, consultor y Agile Coach Gustavo Bonalde - quien cuenta con más de 18 años de experiencia en el Desarrollo y Gerencia de proyectos de TI y ha sido Docente en diversas universidades de Venezuela.  Dicho artículo nos ha gustado no solo por nuestro gusto por el escritor Mario Benedetti sino también porque esta muy bien logrado y las analogías propuestas por el autor hacen que leerlo sea muy grato y complaciente para quienes estamos en el camino de aprender de SCRUM y agilismo. 

"A Benedetti le gusta la gente Agile"

Autor : Gustavo Bonalde

Luego de leer el poema del gran escritor Mario Benedetti  "La Gente que me Gusta", tengo la firme convicción que debe ser una lectura mandatoria para quienes quieren entender con palabras los valores de la agilidad.

Allí Benedetti nos habla de muchas características presente en los equipos ágiles.

Auto-Organización:
"Me gusta la gente que vibra, que no hay que empujarla, que no hay que decirle que haga las cosas, sino que sabe lo que hay que hacer y que lo hace."
Claramente podemos hacer referencia a equipos auto-organizados, donde las tareas son tomadas por los miembros del equipo, en lugar de ser asignadas (sistema pull en lugar de push).

Retrospectiva - Kaizen, mejora continua.
"Me gusta la gente de criterio, la que no se avergüenza en reconocer que se equivocó o que no sabe algo. La gente que, al aceptar sus errores, se esfuerza genuinamente por no volver a cometerlos."
El primer paso para la mejora continua, es reconocer las oportunidades de mejora, estar consciente que siempre podemos mejorar. Cada vez que un equipo o miembro de un equipo reconoce que cuando fallamos, hay toda una inmensa oportunidad de aprendizaje. #FailFast

Coraje:
"Me gusta la gente sincera y franca, capaz de oponerse con argumentos razonables a las decisiones de cualquiera."
En muchas ocasiones evitamos decirnos cosas o hacer alguna observación de manera de evitar un posible conflicto. El secreto de los equipos esta en tener el coraje en poder conversar sobre temas que pueden ayudarnos a reflexionar.

Respeto:

"Me gusta la gente capaz de criticarme constructivamente y de frente, pero sin lastimarme ni herirme. La gente que tiene tacto."

Sin mucho que comentar... la base de todo es el respeto.

Compromiso:
"Me gusta la gente fiel y persistente, que no desfallece cuando de alcanzar objetivos e ideas se trata."
El compromiso es algo voluntario, no se impone. La única forma de comprometernos es que queramos hacerlo realmente. Un equipo comprometido, no lo detiene nada.

El poema es una fuente interminable de valores y principios ágiles, les dejo el poema completo para que ustedes sigan haciendo su propia analogía.

Termino diciendo: Agile es "Gente que vibra"!

"La gente que me gusta"

Autor : Mario Benedetti

Me gusta la gente que vibra, que no hay que empujarla, que no hay que decirle que haga las cosas, sino que sabe lo que hay que hacer y que lo hace. La gente que cultiva sus sueños hasta que esos sueños se apoderan de su propia realidad. Me gusta la gente con capacidad para asumir las consecuencias de sus acciones, la gente que arriesga lo cierto por lo incierto para ir detrás de un sueño, quien se permite huir de los consejos sensatos dejando las soluciones en manos de nuestro padre Dios.

Me gusta la gente que es justa con su gente y consigo misma, la gente que agradece el nuevo día, las cosas buenas que existen en su vida, que vive cada hora con buen ánimo dando lo mejor de sí, agradecido de estar vivo, de poder regalar sonrisas, de ofrecer sus manos y ayudar generosamente sin esperar nada a cambio.

Me gusta la gente capaz de criticarme constructivamente y de frente, pero sin lastimarme ni herirme.

La gente que tiene tacto.

Me gusta la gente que posee sentido de la justicia.

A estos los llamo mis amigos.

Me gusta la gente que sabe la importancia de la alegría y la predica. La gente que mediante bromas nos enseña a concebir la vida con humor.

La gente que nunca deja de ser aniñada.

Me gusta la gente que con su energía, contagia.

Me gusta la gente sincera y franca, capaz de oponerse con argumentos razonables a las decisiones de cualquiera.

Me gusta la gente fiel y persistente, que no desfallece cuando de alcanzar objetivos e ideas se trata.

Me gusta la gente de criterio, la que no se avergüenza en reconocer que se equivocó o que no sabe algo. La gente que, al aceptar sus errores, se esfuerza genuinamente por no volver a cometerlos.

La gente que lucha contra adversidades.

Me gusta la gente que busca soluciones.

Me gusta la gente que piensa y medita internamente. La gente que valora a sus semejantes no por un estereotipo social ni cómo lucen. La gente que no juzga ni deja que otros juzguen.

Me gusta la gente que tiene personalidad.

Me gusta la gente capaz de entender que el mayor error del ser humano, es intentar sacarse de la cabeza aquello que no sale del corazón.

La sensibilidad, el coraje, la solidaridad, la bondad, el respeto, la tranquilidad, los valores, la alegría, la humildad, la fe, la felicidad, el tacto, la confianza, la esperanza, el agradecimiento, la sabiduría, los sueños, el arrepentimiento y el amor para los demás y propio son cosas fundamentales para llamarse GENTE.

Con gente como ésa, me comprometo para lo que sea por el resto de mi vida, ya que por tenerlos junto a mí, me doy por bien retribuido.


MARIO BENEDETTI

Fuentes consultadas:

Web sites del autor: http://www.agitrend.com y http://gbonalde.blogspot.com

LOS BUGS EN SCRUM

El siguiente artículo fue escrito por el Ingeniero Dami Buonamico quien se desempeña como Agile Coach de la compañía Kleer y es nuestro invitado. Su blog es un referente de agilismo: http://www.caminoagil.com

Los Bugs en SCRUM

Metodología de Testing

¿Cómo se priorizan los Bugs en el product backlog? ¿El Product Owner debe hacerlo? ¿Interesa discriminarlos de los Requerimientos? ¿Cómo se estima el esfuerzo de corregirlos? ¿Es un Bug o una Mejora?

Si alguna vez te encontraste envuelto en una discusión similar en un Equipo ágil, no dejes de leer este artículo.

Advertencia:

Se trata de un artículo algo extenso, ya que intento cubrir todos los aspectos importantes. Se divide en las siguiente partes:

1) Definición: ¿Qué es y que no es un Bug?
2) Cómo se priorizan
3) Los costos escondidos
4) La estimación de esfuerzo
5) Cómo se gestiona la calidad en Scrum
6) Etimología de la palabra
7) Lectura Recomendada

1) Definición

1.1 ¿Es un Bug?

Hablamos de un Bug cuando nos referimos a un comportamiento del software que cumple con tres características básicas: es defectuoso, es indeseado y es inesperado.

Pero... ¿inesperado por quién? Inesperado para el Product Owner que solicitó la funcionalidad (O cliente en su defecto), para el Analista que escribió la especificación del requerimiento, para quien diseño la solución o para el Desarrollador que la programó. Como veremos más adelante, no siempre para el usuario final.

¿Y para el Tester que se encontró con el comportamiento inesperado? Para el Tester también, pero ojo, el Tester encontrará muchos puntos donde la experiencia de usuario podría y/o debería ser mejor. Pero no todos los casos serán Bugs. El Tester deberá contar con un criterio muy refinado, conocer bien el sistema, los requerimientos, las reglas de negocio, el nivel de calidad acordado y validar con el Product Owner en caso de dudas. El nivel de calidad debe estar acordado entre el Product Owner y el Equipo. (Ver caso 4 más adelante).

Es un Bug, aunque la funcionalidad haya sido programada tal como se especificó en el requerimiento. No importa de quien es la "culpa", puede ser un error de codificación, un error de diseño de la solución, una inconsistencia en la especificación de requerimientos. Sigue siendo un Bug.

1.1 ¿Cuando NO es un Bug?

No toda mala experiencia de usuario representa un Bug en el sistema. Veamos los casos más relevantes:

Caso 1: Incidentes. El sistema no funciona como corresponde por condiciones externas al software. Se cayó un servidor o se saturó su capacidad, un ataque de DoS de un hacker, un Servicio externo requerido que no está disponible, etc. En este caso hablamos de Incidentes.

Caso 2: Carencia de funcionalidades básicas que todavía no se implementaron. Cuando es intencional, por lo tanto no es inesperado. Ej. Puedo registrarme, pero no encuentro cómo recuperar la contraseña o editar mis datos personales.

Caso 3: Regla de negocio que perjudica el usuario. Ejemplo: El sistema no permite efectuar una transferencia bancaria luego del horario normal de operación del banco. El sistema no permite al usuario copiar, extraer, descargar o compartir la información. Este es el caso decimos que es una funcionalidad. Una regla de negocio diseñada para el beneficio de otro que no es el usuario final. El usuario se puede ver frustrado y quejarse, pero no será tratará de un Bug.

Caso 4: Mejora. Cuando el sistema funciona, pero podría ofrecer una mejor experiencia de usuario, ser más amigable, más lindo, más cómodo, con accesible. Aquí la distinción no es objetiva. Dependerá del nivel de calidad acordado en el Equipo para el sistema y de los criterios de aceptación. Cuando no hay un acuerdo formal, habrá que discutir cada caso particular, teniendo en cuenta la subjetividad de cada una de los involucrados.

Caso 5: Estándar de Calidad. Cuando el Bug es tan pequeño e insignificante que invertir tiempo en solucionarlo sería pecar de perfeccionistas. Este punto, al lugar que el anterior también es subjetivo y debe ser un acuerdo del Equipo entender cual es el nivel de calidad esperado.

 

2) La Priorización de Bugs

La importancia es discriminarlos radica en darles el tratamiento adecuado. Los Bugs no se gestionan como los requerimientos: tienen un ciclo de vida distinto, la estimación de esfuerzo es distinta, los datos requeridos son distintos. Pero lo más importante aquí son los criterios a emplear para la priorización y planificación.

Entendemos por priorización a la decisión de qué hacer primero: ¿Resolver un Bug o desarrollar una funcionalidad nueva?

Cuando compiten con los nuevos requerimientos en el Backlog, empleando el mismo criterio de priorización, pueden perder prioridad y comenzar a acumularse. Sobretodo cuando hay mucha presión puesta sobre el Equipo de desarrollo para entregar funcionalidad cuanto antes.

Tanto Product Owners como desarrolladores pueden verse tentados a no solucionar Bugs pendientes. Existen varios motivos por lo que esto puede ocurrir:

  • Los Bugs en el backlog de alguna manera molestan, son indeseados y puede resultar incómodo hablar de ellos. Por ejemplo, hacer transparente que una funcionalidad no va ser desarrollada porque en su lugar vamos a estar arreglando Bugs detectados. 

  • La presión del mercado por reportar nuevas funcionalidades productivas, antes que la competencia, tiende a reducir el estándar de calidad.

  • El Product Owner puede desentenderse de los Bugs asumiendo que es un problema del Equipo de desarrollo y no querer invertir tiempo en analizarlos y priorizarlos. 

  • Para los desarrolladores solucionar Bugs no es tan motivante o interesante como desarrollar nuevas funcionalidades. 

  • La satisfacción de tener nuevas funcionalidades siempre es mayor que solucionar Bugs.  

     

    Un Bug se puede interpretar como un requerimiento con valor de negocio negativo. 

    Mientras que un requerimiento agrega valor de negocio o Satisfacción al usuario; un Bug lo resta. Por este motivo, no corresponde emplear el mismo criterio de priorización.

    Los requerimientos se priorizan teniendo en cuenta dos variables: Beneficio o Valor de Negocio por un lado y el esfuerzo o costo de implementación. La relación entre ambos nos da el Retorno de la Inversión.

    Esta priorización no funciona para los Bugs porque no aportan valor de negocio y tampoco se estima el esfuerzo (veremos por qué más adelante).

    Los Bugs se priorizan teniendo el cuenta el Costo de NO solucionarlos. En inglés este criterio de priorización se conoce como Cost of Delay.

    Ahora bien, el desafío radica en que los Bugs tienen "costos" escondidos que son difíciles de "ver" para tenerlos en cuenta y ponderarlos apropiadamente.

    Te propongo que antes de seguir leyendo este artículo, armes una lista con todas las consecuencias y costos que la organización sufre por tener Bugs sin resolver.

    1. ___________

    2. ___________

    3. ___________

    4. ___________


Ahora comparalos con lista a continuación, ¿Estabas considerando todos estos costos? Seguramente también hayas encontrado algunos que no figuran en esta lista. Te invito a aportar dejando tu comentario abajo.

3) Los costos escondidos

Factores que hacen al Costo de tener Bugs en el Sistema sin resolver

1) Impedir al usuario completar la operación. Todo el desarrollo de la misma es en vano si el usuario no puede completarlo. El usuario se sentirá frustrado y sentirá que le hacen perder el tiempo.

2) Experiencia de usuario negativa. Reduce su nivel de satisfacción con nuestro producto o servicio. Lo contrario de lo que cualquier Organización está buscando cuando diseña un producto.

3) El usuario podría no volver a elegir nuestro producto la próxima vez. En el caso de servicios y aplicaciones pagas, implica anular suscripción, devolución de dinero, etc. Tener usuarios registrados inactivos también es un costo adicional.

4) Reputación e imagen negativa de la organización. El usuario no solamente no vuelve a usar el producto sino que estará menos dispuesto a probar cualquier otro producto de la organización. Se pierde la confianza del usuario.

5) Recomendaciones. Bajo nivel de Net Promoter Score (NPS). Los usuarios sólo recomiendan a los amigos los productos con los que se sienten satisfechos. Con los que tienen buena experiencia de usuario.

6) Calificaciones en el Market Place. El usuario deja bajas calificaciones y comentarios negativos en el App Store, Play Store, etc. Provocando que otros usuarios No descarguen. Las calificaciones y comentarios negativos no pueden ser eliminados.

7) Perder la posibilidad de ser figurar entre los productos Destacados y Promocionados y en el Ranking Top 10. Los Market Place destacan las aplicaciones con buenas calificaciones. Esto es publicidad gratuita, reconocimiento, motivación para los empleados, más tráfico y descargas y reputación para la Organización. Todo esto se pierde por un producto con malas calificaciones que los usuarios dejan cuando se sienten frustrados con una producto con Bugs.

8) Costos de personal de atención al cliente. Los defectos en el sistema incrementan los reclamos de los usuarios, la necesidad de soporte técnico. Los costos de servicio de atención al usuario se incrementan.

9) En ciertos rubros, un Bug podría implicar daños y perjuicios al usuario que demanden resarcimiento (por ejemplo, los sistemas que involucran manejo de dinero o en la privacidad de información sensible).

10) Dentro del sistema, buscamos que los usuarios cumplan un determinado objetivo: que compren, que realicen un pago, que conecten con otros usuarios para potenciar la red de contactos, etc. Un Bug puede demorar este proceso hasta que el servicio de atención al usuario resuelva el caso. Demorando ingresos para la Organización. Las demoras uno de los 7 tipos de Desperdicios identificados por Lean Software Development.

11) Desperdicio del dinero invertido en Marketing. El dinero invertido en publicidad y estrategias para atraer a los usuarios a probar el producto se ve desperdiciado cuando el usuario, luego de probar el producto decide no regresar.

12) Métricas Erróneas. Las empresas de tecnología se apoyan mucho en métricas de todo tipo que explican como los usuarios utilizan el sistema. Los Bugs pueden también interferir en los datos y llevar a tomar decisiones incorrectas.

13) Un defecto puede significar una vulnerabilidad de seguridad del sistema. En ocasiones los errores que no son debidamente controlados revelan información sensible acerca del estado interno del sistema, esa información podría ser usada por usuarios mal intencionados para vulnerar la seguridad y causar daños mayores.

14) Los desarrolladores tienen que lidiar con los Bugs existentes para desarrollar nuevas funcionalidades. De la misma manera, se dificulta el refactoring, creando una barrera para que el código evolucione. Como consecuencia, el desarrollo se hace cada más lento y tedioso. Se incrementa la Deuda Técnica.

15) Los logs o registros de errores del sistema se "ensucian" con datos de Bugs conocidos, haciéndose difícil detectar la presencia de nuevos errores.

16) El testing de nuevas funcionalidades también es más lento y tedioso con la presencia de Bugs pre-existentes. El tester debe lidiar también con ellos y tenerlos en cuenta cuando se prueban nuevas funcionalidades. Algunas funcionalidades no podrán ser verificadas. El Tester deberá discernir si un comportamiento incorrecto se debe a un Bug conocido o la nueva funcionalidad. Lo cierto es que genera confusión y ante un apuro es más fácil culpar a un Bug pre-existente.

17) Cuando hay Bugs conocidos que no se resuelven, los tests automáticos generan alertas que son desestimadas porque son atribuidas a dichos Bugs. Los tests que fallan terminan siendo desactivados reduciendo la cobertura de test.

18) Una porción de código defectuoso es como un ladrillo roto: es más fácil cambiarlo cuando todavía está fresco el cemento que después de que se hayan edificado otros ladrillos arriba. Si los Bugs no se solucionan en el momento y tienen baja prioridad, el día que se decida solucionarlo el costo será mayor. Este costo está asociado como el desperdicio de Re-aprendizaje de Lean Software Development. Si la persona que lo resolverá es otra persona distinta del que desarrollo la funcionalidad, también el costo es mayor.


19) La motivación de los desarrolladores disminuye cuando deben trabajar con un producto con errores. Peor aún, la motivación del Tester disminuye, porque los Bugs que reporta no se solucionan, entonces ¿Para qué seguir poniendo empeño a encontrar y reportarlos?

20) El Orgullo y motivación de todas las personas detrás del producto decae. No es lo mismo lo que se siente trabajar desarrollar un producto de alta calidad y reputación que para un producto con bajas calificaciones.

21) Se dificulta la planificación a largo plazo (Roadmap) del producto. El Backlog de producto es más difícil de gestionar y menos claro de entender cuando los nuevos requerimientos se encuentran mezclados con Bugs. Para el Product Owner es más trabajoso invertir tiempo en entender los Bugs reportados y priorizarlos.

22) Se forja una cultura organizacional de tolerancia a la mala calidad y donde producir con defectos es aceptado por todos. Es moneda corriente escuchar en las conversaciones que hay un Bug interfiriendo y nadie se alerta demasiado.

Como corolario, podemos inferir que la decisión sistemática de No resolver los Bugs inmediatamente genera un efecto de Bola de Nieve. Se comienzan a acumular a una tasa cada vez mayor. Comiendose la motivación y la productividad hasta que el sistema no podrá responder más a cambios y deberá rehacerse por completo.

La Teoría de las Ventanas Rotas describe justamente este patrón de comportamiento, recomendando siempre arreglar los problemas cuando todavía son pequeños. Cuando no hay Bugs, un sólo atrae la atención de todos. Cuando el sistema está lleno de defectos. ¿Qué le hace una mancha más al tigre?

¿Hay más motivos a considerar? Te invito a dejar comentarios al respecto.

4) La estimación de esfuerzo

Métricas Honestas. Por qué los Bugs no llevan estimación de esfuerzo.

Las métricas de esfuerzo en Scrum con Puntos (Story Points) ayudan al equipo a entender cuanta funcionalidad pueden completar en una iteración. En base a una Velocity promedio del Equipo el Product Owner puede planificar varios Sprints y armar un Roadmap de Producto.

Una funcionalidad "Completada" significa que no tiene Bugs pendientes. Si el desarrollo produce Bugs y los estos tienen una estimación aparte, se genera una métrica de Velocity engañosa que los esconde y no permite planificar.

Veamos un ejemplo para comprenderlo mejor: Un equipo tiene una Velocity de 30 puntos por Sprint y planifican los requerimientos Story A, B, C y D según el siguiente cuadro.

La User Story "A" fue desarrollada en una semana, pero se encontró un Bug. El equipo debe seguir trabajando en la misma unos días más. Como resultado, no alcanzó el tiempo para completar la User Story "D". Quedará para el próximo Sprint.

Veamos qué ocurre en la planificación cuando los Bugs no llevan estimación (Caso Correcto) y cuando sí llevan estimación (Caso Incorrecto)



En el caso correcto, no completar la Story D, implica Sprint Velocity menor a la esperada (25 vs 28). Además, la Velocity promedio del equipo se ve un poco reducida para ajustarse más a la realidad.

En el caso incorrecto, se estima y se asigna 3 puntos al Bug detectado. Al finalizar el Sprint, la Velocity del Sprint refleja lo planificado, pero la User Story "D" no está hecha! La Velocity sigue siendo 28, cuando el equipo en realidad no es capaz de completar un Sprint planificado de 28 puntos.

Ahora bien...

Qué sucede si el Bug no fue corregido dentro del mismo Sprint. Ya sea por priorización, porque se encontró a posteriori del Sprint y se agregó al Backlog. ¿Le asignarías Story Points? Por supuesto que NO. El criterio es el mismo.

Si la Story "A" se consideró como terminada y se imputaron los 13 puntos a la Velocity, cuando en realidad tiene un bug pendiente, se está acumulando Deuda Técnica. La deuda técnica debe ser pagada, para lo cual se debe arreglar el Bug sin imputar puntos a la Velocity del Sprint por el esfuerzo invertido en solucionarlo. Incluso, si el Bug es antiguo (Legacy).

Veamos como queda en el ejemplo, la planificación del segundo Sprint. Notemos que la Velocity en el caso incorrecto es mayor, pero no es realista. ¿Podría contar el Product Owner con esa velocity para planificar nuevas funcionalidades en el Sprint 3?

 



Otros Motivos que desalientan estimar el esfuerzo (incluso en estimación con Horas)

1. Motivo de Estimar. Los requerimientos llevan estimación de esfuerzo para planificación y priorización. Sin embargo, en el caso de los Bugs ya hemos visto que esto es distinto.

2. Incertidumbre. En muchos casos, no sabemos por qué ocurre el Bug, con lo cual estimar el esfuerzo requerido para solucionarlo es difícil y tiene un margen de confiabilidad demasiado bajo. 
 
3. Los Bugs, por su naturaleza tienen un mayor esfuerzo en análisis e investigación para encontrar el origen del error y muchas veces el esfuerzo de solucionarlo puede ser tan pequeño como agregar un punto y coma.

4. Costo y más costo. La existencia de un bug en el sistema representa un costo hundido. Es uno de los desperdicios identificados en Lean Software Development. Emplear tiempo extra en obtener una estimación de esfuerzo para arreglar un Bug implica incrementar el costo el mismo.

5) Priorización Ágil ¿Cómo se gestionan los bugs en Scrum?

Scrum (y las metodologías ágiles en general) valoran y promueven la calidad. La tolerancia a Bugs debe ser muy baja en un ambiente de desarrollo ágil. Los Bugs producidos por el desarrollo de una funcionalidad deben ser resueltos dentro del mismo Sprint o en el próximo momento posible.

Los Bugs tienen prioridad por sobre el desarrollo de nuevas funcionalidades, debido a que resolver un Bug no es un trabajo aparte que deba ser planificado, sino que es una tarea más del trabajo de desarrollo. Es como barrer el aserrín luego de haber estado cortando madera.

Una funcionalidad que se desarrolló y tiene Bugs, no se considera "Terminada" hasta que todos los Bugs sean solucionados, y a su vez, un trabajo que está comenzado y cerca de terminarse siempre mayor prioridad que otro requerimiento que aún no se comenzó.

En Scrum, el objetivo está puesto en prevenir que los Bugs. Esto se logra con atención a la calidad, adoptando las conocidas buenas prácticas de desarrollo, buenas prácticas de diseño, apropiada comunicación y colaboración entre todos los roles involucrados. La adopción de los principios ágiles soportan la Calidad, por ejemplo el principio de simplicidad:
 

"El código que nunca fue escrito no tiene Bugs y no requiere mantenimiento"

Por último, la Mejora Continua y el aprendizaje. Ante un nuevo Bug, ¿Te preguntás por qué se produjo y cómo se puede evitar que vuelva a ocurrir un Bug similar?

6) Etimología del término "Bug"

Si todavía estas conmigo, te felicito! este fue uno de los artículos más extensos que escribí. Para terminar voy a hablar un poco del término Bug utilizado como defectos de Software.

La traducción del inglés es "insecto". Irónicamente muy lejos de los defectos, los insectos son tan perfectos como toda obra de la naturaleza...

También es curioso notar que utilizado como verbo, "bug" se traduce como "molestar". Tanto los insectos como los defectos en el software tienen la capacidad de "molestar" a usuarios y desarrolladores. Muchos insectos tienen una gran capacidad para esconderse, así como los Bugs se esconden en el Software y tienen costos escondidos.

Otra forma de verlo, tener un "Bug" es estar enfermo. Nuestro sistema también está "enfermo" si tiene defectos o bugs.

Pero lo cierto, es que el primer uso del término se remonta a 1946, cuando ingenieros de Harvard encontraron que una polilla atrapada en la Computadora era el origen del mal funcionamiento de la misma. Adosaron la polilla a la planilla de registro. Ese fue el primero registro formal que se conoce del uso de Bug para referirse a los defectos de software.

7 ) Lectura Recomendada

Si te resulta interesante el tema te recomiendo leer los siguientes artículos

(En inglés)
That's Not a Bug, It's a Feature Request (CodingHorror.com)
It’s Not a Bug, It’s a Feature (AgileManiac.com)
The Bug Myth (Business Craftsmaship)
The Broken Window Theory (CodingHorror.com)
One way to handle Bugs and Production Support in Scrum (Scrumcrazy.com)

Twitter: @dbuo
LinkedIn: http://www.linkedin.com/in/buonamico

El agilismo y el conocimiento de Chofer

En PMPMedellin queremos iniciar nuestra Sección de Guest Posting con un artículo escrito por nuestro autor invitado Jorge Johnson quien se desempeña como Arquitecto de Software y Agile Coach de la compañía de desarrollo de software colombiana - Ceiba Software.

"El agilismo y el conocimiento de Chofer"

Desde hace algunos años fuimos invadidos por una extraña y colorida energía que hoy llamamos agilismo, de tal suerte que hoy casi toda empresa de desarrollo de software y las áreas de TI de muchas empresas privadas son hipotéticamente “ágiles”, o dicen ser ágiles, o al menos están intentando serlo hace años. “Hace ya tres años lo estamos haciendo ágil en mi empresa”, dicen. O, “Nosotros ya comenzamos a ser ágiles porque usamos metodologías ágiles” (si como usar una metodología ágil te volviera automáticamente ágil). Pero, ¿realmente son esas empresas ágiles? ¿Entendemos de qué se trata el tan mencionado, anhelado, e impactante agilismo? ¿Por qué es tan intimidante no ser ágil?

Tenemos ya un mercado rebosante de consultores ágiles con tarjetas de presentación que los presentan como “coach”, “trainers”, “experts”, “scrum developers”, “scrum masters”, etc. A toda hora somos bombardeados por eventos sobre agilismo, cursos de scrum, cursos de scrum masters, cursos de product owners, cursos de management, y cursos de facilitación gráfica. Ya somos certificados en 4 o 5 “cosas” relacionadas de algún modo con agilismo. Y toda empresa que se respete y quiera ser competitiva deberá tener en alguna parte de su portafolio la palabra “ágil” ligada a la palabra “metodología”, y en particular, un alto predominio de la palabra “scrum”, (que ya es casi una marca). De hecho, hoy conseguimos scrum masters en “la calle”, como si sólo se tratara de etiquetar gerentes de proyectos, o como si simplemente se tratara de contratar personas que han asistido a eventos ágiles y les encanta el tema del agilismo. Para complicar las cosas, las empresas son expertas en redefinir analistas de negocios como “scrum product owners”, o como “scrum master”.

Además, ¿quién va a querer que digan por ahí que uno no es ágil?

Según los diccionarios de antónimos, no ser ágil significa ser “burocrático”, “incompetente”, “mediocre”, “incapaz”, “lento”, “lerdo”, “tardío” o “torpe”. (Mejor digo que soy ágil, y evito que piensen esas cosas “malucas” de mi, o de la empresa donde trabajo).

No es el propósito de este corto texto decirle qué es ser ágil: sobre ser ágil en procesos de desarrollo de software ya hay demasiada literatura (es sólo cuestión de buscar la correcta y no leer tanta basura disponible); el verdadero propósito es sugerir superficialmente “QUÉ NO ES” agilismo (muy a modo personal, y que caiga toda la responsabilidad sobre mí).

En 1918, un gran físico alemán recibió el premio Nobel de física. Ese físico del que casi todos hemos oído hablar desde el colegio o universidad, es Max Planck. Como gran científico y Nobel, fue invitado muchísimas veces a distintas partes de Alemania a dictar charlas sobre mecánica cuántica. El profesor Plank normalmente daba un discurso muy similar en todos los lugares académicos. Plank siempre era trasladado de un lugar a otro por su chofer que siempre lo llevaba a todas las conferencias y siempre se sentaba en primera fila. Una y otra vez, el chofer escuchaba con interés el tema de mecánica cuántica que el científico ofrecía (tema bastante complejo para los no físicos) .

Con el paso del tiempo, el chofer aprendió el discurso del científico de memoria, y de regreso a su casa comentó: “Debe ser muy aburrido dictar una y otra vez la misma conferencia, Profesor Plank. ¿Quiere que se lo dicte yo en Múnich? Usted me puede esperar sentado en primera fila como yo hago, y se pone mi sombrero de chofer. Eso nos dará a los dos algo de variedad para romper la monotonía”.

Planck disfrutó la idea. La noche de la conferencia, el conductor dictó una larga conferencia sobre mecánica cuántica frente a una distinguida audiencia. Más tarde, un profesor se levantó con una pregunta. El conductor respondió con cara de asombro: “Nunca me imaginé que alguien de esta avanzada ciudad como es Múnich haría una pregunta tan simple! Mi chofer se la contestará.” [Dobelli, 2013].

No voy a hacer comentarios sobre cómo esta anécdota puede aplicar al tema de agilismo en nuestra ciudad, en otras ciudades, o incluso en otros países. Cada cual saque sus conclusiones. Lo que sí voy a decir es lo que creo: usamos mucho conocimiento de chofer en agilismo, y eso puede afectar mucho nuestros procesos y productos.

A medida que nos movemos en el “mercado del agilismo”, vemos preconcepciones problemáticas de lo que es ser ágil, ya que si se quiere ser ágil, pues simplemente muchas veces escuchamos y aplicamos lo que se diga en el medio en eventos, paneles, blogs (como este texto que estás leyendo), cursos, y comentarios. Damos por sentada una “realidad ágil”, que no necesariamente apunta a la verdad. El problema es que los eventos, los cursos, y los blogs te dan herramientas útiles que mal usadas son inútiles y hasta contraproducentes. Tome como ejemplo el uso de scrum: hay proyectos en los que el uso de scrum es contraproducente, pero scrum casi siempre se usa para matizar el proyecto como ágil, o porque pensamos que scrum siempre es el marco adecuado porque es el que conocemos. Entonces, el error de pensamiento inductivo es: si un proyecto es Scrum, es un proyecto ágil.

La falacia radica en el hecho de no comprender de qué trata ser ágil. Ser ágil no es tener un proyecto montado en scrum con roles bien definidos. Ser ágil no se trata de tener tableros con post-its, ni evolucionar al uso de herramientas como Jira. Ser ágil no se trata de hacer retrospectivas. Ser ágil no se trata de hacer planeaciones cortas. Ser ágil no se trata de hacer sprints. Ser ágil no se trata de tallas de camiseta o de estimar con planning poker. Ser ágil no se trata de hacer reviews. Ser ágil no se trata de hacer ‘Dailies’. Tampoco se trata de hacer ‘user story maps’, ni de tener equipos autoorganizados o autogestionados o altamente motivados. Ser ágil no es tener equipos felices. Ser ágil tampoco se trata de que antes de comenzar un proyecto hagamos un impact mapping, o que definamos un product backlog, ni de que sepamos refinar una historia de usuario, o la sepamos escribir muy bien. Ser ágil no se trata de definir un sprint o un sprint backlog. Tampoco nos hace ágiles entender los requisitos, o ser hábiles en facilitación gráfica. Tampoco te hace ágil que en vez de escribir código y hacer una prueba, escriba primero la prueba y luego el código (TDD). De hecho, no te hace ágil escribir código muy mantenible que se pueda refactorizar fácilmente. Todo lo anterior lo puedo hacer en proyectos no ágiles.

No me lea mal: lo que pretende el párrafo anterior es decirle a algunos: “Hey, pssss”, pilas que primero debes entender qué es ser ágil antes de ponerte a ensillar un equipo ágil, ya que todo lo mencionado son sólo meras herramientas. Así hagas uso de ellas, no serás ágil.

Ser ágil es un tema de negocio y competitividad a través de la adaptabilidad.

Día a día los clientes definen sus hipótesis sobre el software que necesita su negocio para hacerlo más competitivo. Su negocio correrá sobre la base de software presumiblemente creado para hacer la empresa más apta para enfrentar el mercado: una excelente alineación a las metas de negocio, una adecuada priorización, planes de liberados con horizontes cercanos, y requisitos funcionales de corto alcance que permitan hacer validaciones tempranas de hipótesis de requisitos que faciliten abrazar el cambio para ser adaptables en un mundo altamente competitivo.

La necesidad de una entrega continua, sólo posible con iteraciones cortas con entregables de alto valor y calidad, usables y validables, es totalmente fundamental sobre la base de que no es posible tener una predictibilidad a largo plazo, pues la complejidad siempre va a estar presente haciendo de las suyas, modificando todos los planes, y haciendo el proyecto inmanejable. “Predictability has a devious sister named Complexity” [Jurgen 2011].

Toda esta adaptabilidad lograda por medio de la entrega continua con valor, no es posible sin una estrecha colaboración entre todos los involucrados, y es aquí donde fallan muchas herramientas, y otras se vuelven ganadoras. En colaboración, por ejemplo, el trabajo estrecho con altos niveles de confianza entre las partes, alcanzada sobre la base de valores de la credibilidad como la integridad, intención, capacidad y resultados: [Covey 2006 ], se vuelve fundamental. La herramienta que uses es meramente un medio, y debe ser seleccionada sobre la necesidad para solucionar problemas concretos, y no sobre la aplicación de una literatura.

La mejora continua por otro lado, se logra sobre la base de frecuentemente entender el pasado y redefinir el futuro, para lo cual hay que dar espacio a la reflexión para perseguir la adaptabilidad adecuada de los procesos.

Concluyo diciendo, que no podemos seguir cayendo en las mismas disfunciones procedurales una y otra vez, sólo por el hecho de que no tenemos muchas veces un sano entendimiento del verdadero propósito de ser ágiles. Puedes seguir usando scrum y puedes seguir haciendo producto con buena calidad; puedes tener equipos autoorganizados felices y motivados, y puedes usar todas las herramientas que te sugieren los eventos y los libros. Pero no serás ágil hasta no entregar software de alta calidad evolucionando de forma frecuente ante el día a día de las necesidades de mi negocio.

Agilismo no es entregar un producto de alta calidad al final del proyecto hecho con scrum o con cualquier otra guía, porque puede que ya sea demasiado tarde para el negocio. El reto es lograr la entrega continua de alta calidad con retroalimentación del negocio sobre la validación de hipótesis, y con alto valor para la competitividad de mi negocio, y un mínimo desperdicio. Cuando estés a ese nivel, podrás decir “soy ágil” o “somos ágiles”. Mientras tanto, sigue tu camino de aprendizaje por la senda adecuada mi pequeño shaolin, porque para lograrlo, se necesita mucho pelo para la moña.

“No puedes depender de tus ojos cuando tu imaginación está fuera de foco”

-Mark Twain-

Bibliografía:

[Mayer 2014], Bertrand Mayer, Agile! the Good, the Hype and the Ugly, 2014

[Dobelly 2013], Rolf Dobelli, The Art Of Thinking Clearly, 2013

[Jurgen 2011], Jurgen Appelo, Management 3.0, 2011

[COVEY 2006], Sthepen M. R. Covey, The Speed of Trust

Fuente de Referencia : https://www.ceiba.com.co/es/agilismo-de-chofer/

 

Guest Posting

Si eres experto en alguno de los siguientes temas: Social Media, Marketing Digital, Gerencia de Proyectos, SCRUM , Agilismo , si además tienes tu certificación CAPM o  PMP del PMI y te gustaría compartir tu experiencia sobre estos temas con nosotros.  

Este espacio es para tí...

El Guest Posting es el pilar de la cultura colaborativa - consiste en tener la oportunidad de escribir entradas en el blog de otro autor. 

Queremos poder tener las visiones de otras personas de diversos sectores para poder enriquecer nuestro web site con sus experiencias, dándole a cada autor visibilidad en nuestra comunidad y la posibilidad de ser reconocido como experto en el tema.

Si estás interesado en publicar tu experiencia y conocer un poco más sobre esta iniciativa no dudes en contactarnos al correo electrónico: administrador@pmpmedellin.com

¡ Gracias por compartir tu tiempo con nosotros y deseamos que tengas buen día!