 |
| Thanks to Oliver from Geek & Poke |
1. DoAD.
La imagen la izquierda, una disfunción clásica: DoAD o definición de casi hecho, que a veces también se presenta como DoD seguido de DoDD; cuando finalmente está "done done".
Hay que comprender que si queremos ser ágiles y poner nuestro foco en generar valor este solo está presente en una funcionalidad si esta está acabada al 100%, sino simplemente no está, una funcionalidad acabada al 99% tiene valor = 0. Una de las lecciones más difíciles para algunas compañías es aprender a permitir que sus equipos encuentren el ritmo en el que sprint a sprint entreguen funcionalidades acabadas al 100%.
2. Ante un vaso medio lleno algunos lo verían medio lleno y otros medio vacío, pero, ¿qué diría un Scrum Master? ... pues preguntaría ¿porqué el vaso es tan grande?
Este chiste proveien del pensamiento Lean y me encanta ya que pone foco en las dos características clave de un Scrum Master: las personas y el proceso. Desde la perspectiva de las personas con un vaso más pequeño todo el mundo lo vería lleno, lo que se puede traducir en un aumento de motivación, y desde la perspectiva del proceso un vaso demasiado grande es puro desperdicio o muda.
3. ¡Jajaja, tu lado del barco tiene un agujero!
Muchas veces confundimos un equipo con un grupo de trabajo, un equipo integrado tiene un objetivo común por el que todos van a "muerte". Este chiste ilustra la disfunción clásica de supuestos equipos en los que podemos escuchar frases como "esta no es mi tarea" o "a mi no me pagan para hacer esto"...
Este chiste refleja uno de los malentendidos más corrientes sobre la Agilidad: el que con métodos ágiles la velocidad de los equipos aumenta mucho.
El malentendido nace de la palabra "ágil", tal como confesó Mike Beedle, quién acuñó el término, hubiera sido más claro utilizar "flexible" y "Flexibilidad".
La Agilidad acelera potentemente la entrega de valor, no porque los equipos desarrollen más rápido, sino porque entregan las cosas correctas que dan solución a las verdaderas necesidades de nuestros clientes.
8. Historias de usuario. Es un chiste tan simple como delicioso :-)
9. Van cinco subidos a un caballo y este camina raro. De repente dice el cuarto al quinto, "¡quieres dejar de perculizar al caballo!" y el quinto dice "es que si la saco me caigo"...
Este chiste ilustra de forma políticamente incorrecta, pero muy clarificante, la perspectiva de los desarrolladores de como se sienten y como les entorpece cuando cargan con la estructura empresarial y jerárquica de mando y control en muchas de las realidades de empresas tradicionales.
Recordemos que en Agilidad las personas que realizan el trabajo, y que son trabajadores de conocimiento, deben de ser las que tomen las decisiones frecuentes y las que requieran información local, sean creadores de sus planes y se autoorganicen en equipos. Esto Ilustra la importancia de lideres system-thinkers que apoyen a los equipos en sus decisiones y resuelvan impedimentos sistémicos en sus áreas, lo que probablemente lleve a un aplanamiento o un desescaldado de mando y control en la organización.
Si alguien supiera un chiste relacionado con la Agilidad le invito a añadirlo en los comentarios, mis agradecimientos de antemano.
Hay que comprender que si queremos ser ágiles y poner nuestro foco en generar valor este solo está presente en una funcionalidad si esta está acabada al 100%, sino simplemente no está, una funcionalidad acabada al 99% tiene valor = 0. Una de las lecciones más difíciles para algunas compañías es aprender a permitir que sus equipos encuentren el ritmo en el que sprint a sprint entreguen funcionalidades acabadas al 100%.
2. Ante un vaso medio lleno algunos lo verían medio lleno y otros medio vacío, pero, ¿qué diría un Scrum Master? ... pues preguntaría ¿porqué el vaso es tan grande?
Este chiste proveien del pensamiento Lean y me encanta ya que pone foco en las dos características clave de un Scrum Master: las personas y el proceso. Desde la perspectiva de las personas con un vaso más pequeño todo el mundo lo vería lleno, lo que se puede traducir en un aumento de motivación, y desde la perspectiva del proceso un vaso demasiado grande es puro desperdicio o muda.
 |
| Cortesía de Lean Popup |
 |
| Un "equipo" con objetivo común |
Muchas veces confundimos un equipo con un grupo de trabajo, un equipo integrado tiene un objetivo común por el que todos van a "muerte". Este chiste ilustra la disfunción clásica de supuestos equipos en los que podemos escuchar frases como "esta no es mi tarea" o "a mi no me pagan para hacer esto"...
4. El problema de los post-its es que se caen a los seis meses.
Este chiste ilustra disfunciones como el agilipostureo y la ignorancia, utilizar post-its por razones que nada tienen que ver con la Agilidad. Si un equipo trabaja con Scrum y hace sprints de digamos dos semanas, sus post-its tienen una vida de dos semanas, no se van a caer. En ambientes escalados la vida de un post-it seria cómo máximo de 3 meses. Si los post-its se caen a los seis meses es que no hay cadencia, seguramente se trate de un waterfalling encubierto.
Este chiste ilustra disfunciones como el agilipostureo y la ignorancia, utilizar post-its por razones que nada tienen que ver con la Agilidad. Si un equipo trabaja con Scrum y hace sprints de digamos dos semanas, sus post-its tienen una vida de dos semanas, no se van a caer. En ambientes escalados la vida de un post-it seria cómo máximo de 3 meses. Si los post-its se caen a los seis meses es que no hay cadencia, seguramente se trate de un waterfalling encubierto.
No es inusual observar gráficos burn-down como los de la imagen de la izquierda, en la que se puede leer que el equipo ha hecho muchas cosas a lo largo del sprint pero no ha acabado nada hasta el final... no ha aprendido a empezar a terminar cosas y a terminar de empezar cosas a nuevas.
Eso puede suele ser por dos razones: el equipo realmente hace waterfalling o no ha aprendido a focalizarse como equipo al completo en una historia de usuario acometiendo las tareas de forma ágil.
6. Un desarrollador aprende a disparar y no hay manera de que acierte en la diana, y dice: "desde mi punto la bala ha salido, si no ha llegado debe de ser problema de la diana".
Este chiste es tan sutil como real, ¿cuántas veces los desarrolladores desconocen de qué forma parte el código que escriben? ¿y lo que escriben otros con los que están directamente relacionados? A veces su visibilidad es solo sobre sus tareas particulares, quizá hasta QA, donde puede que desconozcan las pruebas que se aplicaran a su código... por no hablar de los despliegues de su código que hacen terceros de forma independiente. Es como intentar acertar en una diana que no ves y todo tu foco está en la tarea, en disparar la bala.
También es un chiste disfuncional de DevOps, con DevOps un desarrollador tiene visibilidad y responsabilidad hasta el mismo despliegue en producción, es el responsable directo de la calidad de lo que se despliega, y eso fomenta y crea compromiso.
7. Con Agilidad 9 madres hacen un hijo en 1 mes...
6. Un desarrollador aprende a disparar y no hay manera de que acierte en la diana, y dice: "desde mi punto la bala ha salido, si no ha llegado debe de ser problema de la diana".
Este chiste es tan sutil como real, ¿cuántas veces los desarrolladores desconocen de qué forma parte el código que escriben? ¿y lo que escriben otros con los que están directamente relacionados? A veces su visibilidad es solo sobre sus tareas particulares, quizá hasta QA, donde puede que desconozcan las pruebas que se aplicaran a su código... por no hablar de los despliegues de su código que hacen terceros de forma independiente. Es como intentar acertar en una diana que no ves y todo tu foco está en la tarea, en disparar la bala.
También es un chiste disfuncional de DevOps, con DevOps un desarrollador tiene visibilidad y responsabilidad hasta el mismo despliegue en producción, es el responsable directo de la calidad de lo que se despliega, y eso fomenta y crea compromiso.
 |
| Agilidad ≠ velocidad |
7. Con Agilidad 9 madres hacen un hijo en 1 mes...
Este chiste refleja uno de los malentendidos más corrientes sobre la Agilidad: el que con métodos ágiles la velocidad de los equipos aumenta mucho.
El malentendido nace de la palabra "ágil", tal como confesó Mike Beedle, quién acuñó el término, hubiera sido más claro utilizar "flexible" y "Flexibilidad".
La Agilidad acelera potentemente la entrega de valor, no porque los equipos desarrollen más rápido, sino porque entregan las cosas correctas que dan solución a las verdaderas necesidades de nuestros clientes.
8. Historias de usuario. Es un chiste tan simple como delicioso :-)
 |
| Del post "Historias de usuario, ¿por qué?" de enciendelaluz :-D |
¡Atención! El siguiente chiste es políticamente incorrecto...
 |
| El caballo arrecho, cortesía de Pixabay |
Este chiste ilustra de forma políticamente incorrecta, pero muy clarificante, la perspectiva de los desarrolladores de como se sienten y como les entorpece cuando cargan con la estructura empresarial y jerárquica de mando y control en muchas de las realidades de empresas tradicionales.
Recordemos que en Agilidad las personas que realizan el trabajo, y que son trabajadores de conocimiento, deben de ser las que tomen las decisiones frecuentes y las que requieran información local, sean creadores de sus planes y se autoorganicen en equipos. Esto Ilustra la importancia de lideres system-thinkers que apoyen a los equipos en sus decisiones y resuelvan impedimentos sistémicos en sus áreas, lo que probablemente lleve a un aplanamiento o un desescaldado de mando y control en la organización.
Si alguien supiera un chiste relacionado con la Agilidad le invito a añadirlo en los comentarios, mis agradecimientos de antemano.
No hay comentarios:
Publicar un comentario