Camino Ágil

La Ventana a la Cultura del Equipo En una entrevista, una vez me preguntaron: como Agile Coach, ¿cuál sería la primera intervención que harías en un equipo? Sin haberlo pensado antes lo primero que se me vino a la mente fue: Asistir a la Daily Scrum en calidad de observador. Años después y tras haber trabajado con muchos equipos desde  Kleer , me encuentro validando mi punto de vista inicial y sosteniendo que: La Daily Scrum es el momento de mayor ancho de banda y eficiencia sobre la dinámica y la cultura de un equipo Scrum que un Agile Coach puede aprovechar. El ancho de banda es la cantidad de información disponible por unidad de tiempo. Y la eficiencia es relación entre ambas dimensiones: la gran cantidad de información y la breve duración de la reunión. En tan sólo 15 minutos, un Agile Coach puede obtener mucha información valiosa. Y la gran ventaja es que a diferencia de otros eventos de Scrum, es una oportunidad de aprendizaje que ocurre todos los días....

Me lo preguntan los participantes de talleres ágiles y durante sesiones de agile coaching. Se la hacen a sí mismos todos los Scrum Masters cuando son designados a cumplir su rol: ¿Qué debería hacer durante el resto del día? ¿A qué me dedico cuando no estoy facilitando eventos de Scrum? La tendencia natural es continuar haciendo las mismas actividades del rol que se desempeñaba antes de ser designado Scrum Master. De esa manera, terminamos obteniendo Scrum Masters con dedicación part-time. Dentro de ese esquema, la persona permanece dentro de su zona de confort: no necesita seguir emprendiendo y aprendiendo el nuevo desafío de ser Scrum Master para crecer en su carrera profesional. Así, el nuevo rol se reduce a un conjunto de tareas a cumplir planificadas para cada Sprint, que se adicionan a las tareas del antiguo rol. Otra situación que se suele dar, es la de los Scrum Masters que trabajan para dos equipos o, incluso tres. Estos casos también tienen como consecuencia Scrum ...

La agilidad organizacional tiene impacto en todos los niveles de una organización. Para una adopción exitosa de metodologías ágiles no sólo de metodologías debemos hablar. La cultura de la organización debe, eventualmente, transicionar a una cultura ágil,   el estilo de liderazgo debe ser acorde, los valores y los principios que la organización promueve deben estar alineados con los principios ágiles ( Agile Manifesto ), las habilidades, conocimientos y capacidades deben estar alineadas con la mentalidad ágil (Agile Mindset). Esto es particularmente importante entre los líderes de la organización. Con el Modelo de Cebolla Organizacional podemos analizar esta idea en mayor detalle. Veamos cada capa en el ámbito del Desarrollo de Software. Herramientas y Técnicas:  En la capa más superficial encontramos las Herramientas que la organización emplea en el día a día y la Técnica, es decir cómo utiliza dichas herramientas. Pueden ser aplicativos de software, elementos físico...

El Barómetro de Equipo es una herramienta poderosa para ayudar a un equipo de trabajo a elevar su nivel de conciencia como tal y evaluarse frente a características de los Equipos de Alto Rendimiento. Se trata de una recopilación que integra diversas fuentes y permite disparar conversaciones significativas. Aquí podés descargar todo el material para emplearlo en tu organización!

¿Terminan tus Sprints con todo el trabajo planificado completamente testeado? ¿Es el testing una tarea más del trabajo o una etapa del proceso? ¿Hay una persona dedicada a Testing o todo el equipo toma la tarea? En este post voy a contar las formas en la que distintos equipos resuelven la problemática de desarrollo & testing en el proceso iterativo e incremental, siguiendo un orden desde los casos menos ágiles hasta los más ágiles. Para terminar, un listado de buenas prácticas de testing ágil.

Para que una sesión de Retrospectiva de Scrum sea efectiva debe tener como resultado mejoras a implementar durante el próximo Sprint. ¿Si..? Una pequeña reflexión para mejorar tus Retrospectivas de Scrum.

Kanban es un método para visualizar y optimizar el flujo de producción en cualquier industria. Con esta dinámica podemos facilitar una simulación que permite verlo en acción!

Cuando adoptas para tu empresa una solución creada en otro contexto, ¿Tenés en cuenta la idiosincrasia de tu organización y de tu país? El contexto es un factor crítico para el éxito! El artículo de Luis Gonçalves " Cinco motivos por los que Agile no funciona en Alemania " me llevó a pensar sobre los aspectos culturales y contextuales en Argentina. Podemos encontrar diversos ejemplos en la industria intentando imitar modelos y soluciones, como en el caso de Toyota (Lean, Toyota Kata) y el  Modelo Spotify , sin lograr los resultados esperados. Esto ocurre cuando se intenta copiar una solución como si fuera seguir una receta sin comprender las diferencias culturales y el contexto en la que esa solución particular funcionó bien. La cultura japonesa (Toyota) y la sueca (Spotify) son muy distintas a la forma de pensar de los argentinos. Considero que Agile sí funciona en Argentina, siempre y cuando tengamos en cuenta algunos factores que nos caracterizan. ...

El Kaizen Board es una herramienta visual, simple y poderosa. Basada en principios ágiles facilita la efectividad de las Retrospectivas Ágiles, prevenir algunas patologías comunes y agregar una pizca de sabor para probar algo nuevo motivando al equipo a seguir mejorando. La Retrospectiva es un momento crítico para un equipo ágil. En ella el equipo debate sobre los distintos aspectos que funcionan bien y aquellos aspectos que deberían ser modificados. El objetivo es ir adaptando la dinámica de trabajo para mejorar continuamente y superar los problemas.Cumplir con ese objetivo no es tarea fácil: algunas malas prácticas, anti-patrones o como me gusta llamarlo : patologías , afectan a la dinámica.

¿Qué sentido tiene trabajar en ciclos? ¿Cuál es el valor real? 19 motivos que justifican trabajar en Sprints.

Ser " ágil " está de moda entre las empresas de desarrollo de software. Los gerentes exigen a sus empleados ser "Ágiles". Las empresas, productos y procesos dicen ser "ágiles" como una estrategia de marketing para atraer clientes. Muchas discusiones se generan en torno a la agilidad debido a diferentes interpretaciones de su significado. Suelo escuchar la palabra ágil para referirse a trabajar de manera más eficiente, producir menos costos, moverse más rápido, aceptar más riesgos, completar en menos tiempo, producir sin análisis previo, etc, etc.  ¿Qué de todo esto es así? En este artículo defino el concepto clave de la Agilidad de manera concisa, clara y precisa.

Propongo una idea interesante para filosofar en una tarde de Domingo: cuando Dios creó el mundo, ¿Siguió un proceso comparable con las metodologías ágiles de desarrollo o con la metodología tradicional? ¿Podría ser Darwin el primero en describir el proceso de desarrollo iterativo e incremental?

Cuando se decide adoptar metodologías ágiles se presume muchas veces que es un cambio que solo afecta al equipo de desarrollo. Sin embargo, una adopción exitosa requiere de un cambio también en la línea de Management.  ¿En que se diferencia la gestión de proyectos tradicional de la gestión de proyectos ágiles? Aquí las clave para entender la diferencia y el impacto en algunos roles tradicionales.

En este artículo voy a mencionar una de las diferencias más importantes entre la gestión de proyectos ágiles y la tradicional y por qué esta última tiene una tasa de fracaso tan elevada . Como cliente de cualquier producto o servicio voy a querer saber qué voy a obtener, en qué medida se van a satisfacer mis necesidades, con qué calidad, cuanto tiempo voy a tener que esperar para comenzar a utilizarlo, que garantía me ofrecen y cuánto me va a costar todo eso. Toda esta información es relevante para decidir si es conveniente ejecutar el proyecto o no. Luego de cerrado el acuerdo, si alguna de las condiciones mencionadas no se cumple me voy a sentir en derecho de reclamar, cancelar el trato y obtener mi dinero de regreso por incumplimiento de contrato.

La mejora continua del proceso es un factor fundamental de cualquier equipo de trabajo ágil. Este proceso se conoce comúnmente como "kai-zen"  ( カイゼン )  del Japonés: cambio bueno. Para aumentar progresivamente la productividad, el equipo debe identificar y eliminar sistemáticamente los impedimentos . Entendiendo como impedimento a cualquier situación que disminuye la productividad. El patrón " Scrumming the Scrum " propuesto por Jeff Sutherland, describe el proceso de mejora continua, considerando a la mejora como una User Story adicional en el Sprint.

Sabemos hoy en día que las metodologías ágiles de desarrollo son la mejor y más productiva forma de trabajar en proyectos de software, evidencias de ésto sobran en nuestra industria. Sin embargo, muchos equipos de trabajo fracasan tanto en sus proyectos como en el intento de implementar la metodología . En algunas ocasiones se culpa a la propia metodología.

Es usual mencionar a las metodologías ágiles como "la nueva" forma de desarrollo de software, de manera evolutiva, iterativa e incremental que llegaron para reemplazar a las viejas y deprecadas metodologías de desarrollo como el famoso modelo de desarrollo en cascada o Waterfall Investigando un poco me llamó la atención que el  modelo Waterfall  fue recién definido en 1970 por Wiston Royce  en su artículo " Administrando el desarrollo de sistemas de software grandes "  -todavía sin el nombre "Waterfall" y sin las etapas con las que finalmente se usó ampliamente- mientras que la ideas metodologías ágiles son anteriores. La idea de desarrollo en ciclos cortos iterativos e incrementales data de 1939 y el término Scrum como analogía del Rugby para el desarrollo de software data de 1986. Otro dato curioso, es que el paradigma de programación orientada objetos fue creado antes que el paradigma de programación estructurada  cuando en la práctica vemos ...

En el 2011 asistí a un workshop donde tuve oportunidad de conocer la técnica de Visual Story Mapping de su ideador,  Jeff Patton . User Story Map es una herramienta que permite generar una representación visual de la sistema completo. Ofrece una vista general de todas las funcionalidades que lo componen ( the big picture ) de punta a punta. Permite identificar User Stories faltantes en el Backlog , planificar Releases partiendo en rebanadas ( Slicing ), visualizar cómo se distribuyen las funcionalidades de acuerdo a las diferentes áreas del sistema. Es una forma de reorganizar el Product Backlog en dos dimensiones, una dimensión para el tiempo (medido en Releases ) y otra dimensión para las funcionalidades.

¿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.

En todo proyecto planificar es importante porque permite reducir riesgos así como también responder preguntas básicas como cuándo va a estar terminado el proyecto y qué va a estar listo para determinada fecha. De esta manera se puede decidir si vale la pena hacer el proyecto o no. Da información útil para tomar ciertas decisiones, como por ejemplo en qué momento realizar la campaña de marketing. Se provee confianza e información que puede ser necesaria para la aprobación del proyecto, etc. Pero ¿Qué tienen de particular la planificación en las metodologías ágiles?