Todos reconocemos y experimentamos que el 100% de CPU constate en nuestra máquina la relentiza y la hace ineficiente; me impacta es que no podamos reconocerlo en nosotros mismos y en nuestros colaboradores, y los/nos terminemos quemando.
Te invito a leer este artículo, donde está el sustento científico de esta "ineficiencia" en los humanos y una sugerencia para solucionarlo: "Exigir el 100% de ocupación de las personas esta destruyendo la eficiencia de tu equipo y organización"
Hola a todos,
Hace poco cuando compartía con un equipo de Scrum Masters, hablando sobre prácticas y métodos revisábamos la famosa imagen (1) en la cual se presentan los valores, principios, prácticas y frameworks,
 |
| Imagen adaptada de Ahamed Sidky |
y que si la giras un poco, vas a ver los elementos visibles e invisibles de la cultura,
aquellos que consisten en "Hacer" y "Ser", y en nuestro contexto "Hacer Ágil" y "Ser Ágil".
En donde, todo viaje de transformación parte desde los elementos visibles hacia los invisibles, transformándonos de afuera hacia adentro,
o ¿Quién cambia por arte de magia? La verdad, desde mi punto de vista y experiencia, no creo en los cambios repentinos, creo en los procesos, todo cambio requiere un esfuerzo, un delta que me permita pasar de un estado A a un estado B, y parte de algo afuera que te lleva a mover cosas adentro.
Pero bueno, el punto acá es como ha sido mi jornada de cambio, recuerdo mucho a mis inicios en el mundo ágil me reencontré con un gran estudiante que tuve en la clase de Taller de Ingeniería de Software en Eafit, Jorge Luis Valderrama, recuerdo que estaba por Colombia, pues vivía en Londres, y en varias charlas suyas y conversaciones a la que asistí, hablaba siempre desde el Manifiesto Ágil - http://agilemanifesto.org/-, y recitaba sin titubear sus valores y principios, y ante cualquier duda buscaba que principios promovía o violaba aquello sobre lo que era cuestionado. Debido a esto, me animé a imprimir y pegar en frente mío, en mi escritorio de oficina los valores y principios del manifiesto ágil, y ante cualquier duda me remitía al manifiesto ágil, frase que repite constantemente mi gran amigo Juan Andrés Ochoa:
"Ante una duda en cómo actuar, remítase al Manifiesto Ágil" -Juan Andrés Ochoa
De esa manera, emprendí mi viaje desde los principios y valores, luego aprendí en orden Scrum, Nexus, el Modelo Spotify, Kanban, SAFe, LeSS, Scrum at Scale, Discipline Agile. No fue fácil esa jornada, recuerdo que me tomó al menos 6 meses dejar el micromanagement y hacer gestión de horas, para comenzar a confiar en los puntos de historia.
En ese viaje de regreso, he tenido bastantes libros, charlas y conversaciones como compañeros, y recomiendo revisar detalladamente:
 |
| El Corazón de la Agilidad (2) |
A este punto de la historia, he logrado sintetizar lo que es para mí el mindset Lean-Agile, la clave que desencadena la productividad, la felicidad y alto desempeño:
 | |
|
Al tuétano, al núcleo de este asunto que me apasiona y por el cual llegaste hasta este punto del artículo, lo comparto constantemente, lo considero fundamental, para poder desenvolverse en este mundo disruptivo y exigente; mis entrenamientos y conversaciones tienen un énfasis en el mindset lean-agile y cómo este funciona independiente del framework, marco, metodología o proceso y con esta perspectiva acompaño a equipos y organizaciones en su jornada de transformación.
Sé que no hay que dejar de hacer una cosa sin descuidar la otra, es decir, avanzar en el conocimiento de nuevas aproximaciones y marcos, pues hace parte de "estamos descubriendo formas mejores de"(5), sin dejar el corazón, el corazón te permite moverte con propósito y libertad entre las diferentes interpretaciones, implementaciones o, más aún, desarrollar tu propia versión de la agilidad y de lean.
Yo no sé cómo será tu viaje, te he compartido el mío, con seguridad en tantos ires y venires nos terminaremos encontrando. Solo te quiero hacer tres preguntas:
Hasta acá este compartir, bienvenidos sus comentarios.
Saludos Ágiles
Jorge Abad
Hola a todos
Recuerdo hace más de 15 años cuando enseñaba taller de ingeniería de software, casos de uso, programar en Java en Eafit y otras cosas antiguas, que le explicaba a los estudiantes que las especificaciones de software según el estándar IEEE 830-1998 (1) deberían ser:
"Las historias de usuario no son requisitos de software, son solo necesidades de un usuario",
