Cultura ágil y cómo escalarla: #AgilEsAlgoQueEres

Vivimos en una era de ofertas pero también de riesgo. ¿Qué tipo de productos queremos que usen nuestros clientes? La filosofía ágil está modificando a pasos aumentados el statu quo del desarrollo del software, con nosotros a bordo o sin nuestra participación. El interrogante es cómo y hasta qué punto seremos capaces de dar el salto hacia lo que ya está aquí: la cultura ágil.

Para implementar una verdadera Cultura Ágil se requiere un nivel más alto de confianza de lo que es necesario en los enfoques tradicionales.  Responsabilidad y transparencia son dos de los beneficios clave de tener una Cultura Ágil.

Para alcanzarla, para establecer una verdadera Cultura Ágil, debemos revisar las ideas que tenemos de los enfoques tradicionalistas e iniciar un camino que quizás sea o se vea poco confortable para muchos en la organización, puesto que ese camino hacia la cultura ágil expone las debilidades existentes no solo en la estructura sino en el comportamiento organizacional, es como si el ojo del Gran Hermano se posara sobre todos los miembros de la organización y les permitiera observarse a sí mismos, como en un espejo virtual, y al resto del entorno: clientes, proveedores, socios de negocio y mercado potencial, a observarlos desde el exterior.

Esta es la versión actualizada de la presentación, como la vieron en Ágiles Colombia, en Cali, el pasado 4 de junio:

Cultura Ágil: #AgilEsAlgoQueEres por Luis Antonio Salazar Caraballo

De Scrum Master bueno a Scrum Master grandioso

Somos lo que hacemos repetidamente. La excelencia, por tanto, no es un acto, sino un hábito.

-Aristóteles

Así que ya eres o te consideras un(a) buen Scrum Master. Bien. Pero algo que aprendí en los últimos años es que siempre hay una acción de mejora, un camino que tomar que nos hará mejores. Qué tal si en vez de quedarnos allí, en ese claustro de “bueno”, damos un paso más allá, quizás más arriesgado, para convertirnos cada día no solo en mejores profesionales sino en personas sobresalientes, grandiosas. Trataré de explicar mi punto en los siguientes apartados:

Aprender del pasado

Quien olvida la historia, la suya y la de su entorno, está condenado a repetirla. Así que revisar una corta lista de cosas que han ido mal en el pasado y analizar con el equipo cómo podrían manejarse si se presentan nuevamente es una forma excelente de evitar esos mismos problemas. Las retrospectivas siempre son bienvenidas, no solo al final de cada iteración o hito del proyecto, sino siempre que se necesiten, como un instrumento de mejora continua.

Un buen Scrum Master hace esto, pero un gran Scrum Master proporciona además ejemplos vivos de lo que pasó, cuenta la historia completa. Recordemos que contando historias es como sobreviven las culturas y en ágil todo es acerca de la cultura. Mediante ejemplos, les decimos a las personas lo que esperamos de una manera diáfana. Si además los ejemplos son lo suficientemente buenos, estaremos proporcionando ideas valiosas sobre cómo los integrantes del equipo pueden lograr la meta final. No solo les estaríamos dando un contexto personal sino también profesional de algo que quizás no logren entender de otra forma.

Más allá de la ‘Definición de Terminado’

Un buen Scrum Master posibilita que el equipo en pleno tenga una Definición de Terminado (DoD); un gran Scrum Master se asegura de que la planificación conduzca a un plan claro y que el equipo en pleno tenga igualmente objetivos claros y alcanzables que vayan más allá de la DoD y que, si es necesario, existan objetivos intermedios que ayuden a lograr al objetivo final. Algunas metas pueden ser extensas en el alcance, pero deben describirse con simplicidad y de tal forma que comprometan al equipo y a la organización.

Los desafíos y el futuro

Un buen Scrum Master ayuda a preparar el entorno en el que su equipo creará productos con una excelente trama en su interior y que generen resonancia en los usuarios y soporta la implementación de Scrum en la organización. Un gran Scrum Master, además, prepara no solo al equipo sino a la organización para enfrentar los retos que llegarán: 

• dominar las tecnologías emergentes, pero también los enfoques y los cambios de paradigma que harán de los miembros del equipo personas más innovadoras, más proactivas y que entiendan mejor la filosofía ágil;
• compartir más para aumentar tanto la velocidad como la calidad de las decisiones -es  un asunto de mayor y mejor conocimiento;
• licenciar a todo el equipo y a todos en la organización para que se sientan empoderados y lideren el cambio y a crear valor continuamente; y
• anticiparse a las necesidades de los clientes, a identificar y resolver los problemas más rápido y a ir más adelante que la competencia.

Personas sobre Scrum Masters

Un buen Scrum Master sabe y promueve que el trabajo es importante, siembra la semilla en el equipo para que lleve un ritmo sostenido durante todo el proyecto a lo largo y ancho de toda la organización; un gran Scrum Master sabe y promueve que la vida es más importante que cualquier otra cosa, reafirma en el equipo que lo más importante son las personas, los desafíos personales e inspira a todos a que mantengan esas prioridades por encima de cualquier otro reto profesional, sin que se pierda de vista el compromiso, la responsabilidad y el foco de los miembros del equipo en los objetivos definidos.

Otros 10 consejos extraordinarios para ser un mejor líder

En su artículo “10 Awesome Tips for Being a Better Leader” (10 consejos extraordinarios para ser un mejor líder), Carly Okyle, asistente editorial de Enterpreneur, enumera estas sugerencias para ser un gran líder. Pienso que todo Scrum Master debería celebrarlas como parte de su rutina diaria si quiere llegar a ser realmente grandioso. De hecho, ya he mencionado algunas de estas indicaciones de una u otra forma en los párrafos precedentes:

1. Lidera mediante el ejemplo
2. Algo de humildad siempre cae bien
3. Practica la comunicación efectivamente
4. Promulga y cerciórate de que las reuniones sean productivas
5. Conoce bien tus limitaciones
6. Encuentra un mentor, siempre hay alguien que puede enseñarte algo
7. Sé emocionalmente consciente
8. Ten cuidado con y evita los errores comunes en el liderazgo, por ejemplo, pensar que tienes que tomar todas las decisiones o no tener presente que lo más importante puede suceder cuando no estás presente
9. Aprender del pasado, sobre todo de los errores del pasado
10. Nunca dejes de mejorar, los grandes líderes y, de hecho, las grandes personas, están aprendiendo constantemente y tratando de superarse a sí mismas.

Adenda

Un  buen Scrum Master dispone de los instrumentos y recursos necesarios para remover impedimentos en el proyecto; un gran Scrum Master se prepara y prepara a su equipo para lidiar con la complejidad, la incertidumbre y los cambios inherentes no solo a los proyectos de TI, sino a la industria en general.

Finalmente, recuerda que un buen Scrum Master triunfa con el equipo, un gran Scrum Master hace que las personas en el equipo sean más exitosas que él/ella.

¿Y tú, qué estás haciendo por pasar de ser un buen Scrum Master a un Scrum Master absolutamente grandioso? Házmelo saber en el foro.

------------------------------------------------------------------------

Más sobre Scrum Master en:

De Jedi Master a Scrum Master

Vademescrum, Sección I: El Scrum Master 1

Planificación del Sprint: el primer paso para producir el máximo efecto

Cultura Ágil, ese oscuro objeto del deseo

“No puedes guiar el viento, pero puedes cambiar la dirección de tus velas”

Sobre el cambio a ágil, temores infundados y penas frívolas

“Las masas humanas más peligrosas son aquellas en cuyas venas ha sido inyectado el veneno del miedo... del miedo al cambio.”

[Octavio Paz (1914-1998) Poeta y ensayista mexicano]

Todavía me encuentro con muchas personas que creen que ‘saltar al ecosistema ágil’ es como en las películas donde después de un ataque al gobierno, a veces por parte de alienígenas, a veces por parte de un gobierno enemigo, se dan a la búsqueda de los jóvenes y niños ‘genios’ de las universidades para que les resuelvan el misterio o le decodifiquen el mensaje cósmico. Lo bueno de esas historias es que siempre hay alguien que lo logra, a veces solo, a veces en compañía de alguien que para lograrlo viola un sinnúmero de leyes y comete muchos delitos en simultáneo. Otros son más facilistas y quieren usar la máquina del tiempo para ir al momento justo antes de que los modelos y enfoques tradicionales salieran a la luz pública y borrarlos de la historia. ¡Eso ya no es posible! Al menos no con una máquina.

Lo bueno de Ágil es que no tenemos que ser súperdotados para practicarlo ni para ser exitosos. Es más una cuestión de disciplina, de ganas, un deseo inacabable de ser feliz (o de volver a serlo) en el trabajo y de juntarse con las personas adecuadas. También es cuestión de pensar un poco, de entender cuáles son los problemas mayores de las organizaciones y de las personas cuando intentan dar el salto a una nueva forma de ver e interpretar el mundo. Hay dolores superficiales, pero también hay enfermedades crónicas cuyos síntomas no son tan evidentes; para completar el cuadro clínico, hay penas que traspasan lo físico y se quedan en lo puramente espiritual, son difíciles de detectar y mucho más de erradicar, de sanar.

Conocer los miedos no solo de los interesados sino también de los patrocinadores, de quienes toman las decisiones, por ejemplo, es un buen comienzo. He encontrado que muchos de ellos/ellas temen no alcanzar el éxito en el proyecto de transformación y quienes no, imaginan o sospechan que pueden perder su lugar en la organización una vez se dé el cambio, asunto que está bastante alejado de la realidad a no ser que la persona no se adapte al nuevo entorno. En este último caso, tendríamos que preguntarnos si en realidad ya estamos en el punto que queremos.

Quizás entonces el entrenamiento y el soporte no ha sido el adecuado. A veces nos quedamos en las áreas de tecnología, cuando ‘Ágil’ es un asunto de toda la organización. El papel del Scrum Master es fundamental en este aspecto y no nos digamos mentiras (al menos no entre nosotros), los buenos Scrum Masters, los verdaderamente buenos, son difíciles de encontrar: ellas o ellos necesitan tener lo que llamamos comúnmente ‘don de gentes’ y también habilidades en lo ágil y también conocimiento técnico y todo esto junto es muy difícil de encontrar en una sola persona.

Algunas otras dificultades ya son ‘clásicas’: cambiar de un enfoque de ‘comando y control’ tradicional a un enfoque de autoorganización, al mejor estilo Scrum, es una tarea espinosa por no decir algo indecible. Este es un aspecto que impacta a los mandos medios de una compañía, por ejemplo, a la habitual oficina de proyectos o PMO que llaman en algunos entornos. Es precisamente en esta oficina donde comienza el cuestionamiento de lo que puede ser y no es: ¿entonces qué hago con todos los gerentes de proyecto que tengo? He escuchado decir. Encontrar una justificación válida para esto es arduo, imposible dirán algunos. Pero en general, todas las personas tienden a sentir miedo, por aquello de los equipos multifuncionales, donde el poder de la especialización de una persona se pierde. En este mismo orden de ideas, abandonar la falsa seguridad que dan los planes a mediano y, sobre todo, a largo plazo, que nunca han funcionado, en pro de planes a corto plazo, es algo que enciende las alarmas de más personas en la organización de las que quisiéramos contar. Miedo al cambio, natural por demás, es el tema de fondo.

Algunos otros obstáculos que he encontrado:

• Conseguir que las áreas del negocio y la alta dirección se involucren efectivamente
• Lograr la confianza y la autonomía que requieren los equipos ágiles y, sobre todo, el equipo de transformación
• Qué hacer con la jerarquía existente en las organizaciones donde el escalafón de las personas es algo ‘valioso’, es una pregunta que deberíamos responder al iniciar el cambio
• Crear, preparar y promover un equipo ‘colonizador’ o mejor aún, un equipo ‘conquistador’, punta de lanza, que se atreva a hacer las cosas, a ir más allá de donde nadie en la compañía ha llegado. Este es un asunto vital.
• Desaprender los hábitos del desarrollo en cascada, del comando y control, del esperar a que me digan qué hacer, del llenar documentos por llenar y todos esos aspectos que aborda el manifiesto ágil en toda su extensión. Sobre este asunto, los invito a leer: ‘Respuesta al cambio sobre seguir al plan: no planearás’, aquí mismo en este Gazafatonario.
• No intentar cambiar a las personas que no quieren cambiar. La naturaleza humana evade el cambio o se resiste a este cuando alguien intenta cambiarla. Cuando la dejan en paz, cambia por sí misma… ¡si quiere!
• Finalmente, pero no menos importante, cambiar la cultura de la compañía, en ágil todo es acerca de la cultura. Pero sobre esto pueden leer mi artículo: ‘Cultura ágil: ese oscuro objeto del deseo’, aquí mismo en mi Gazafatonario.
• Más allá de todo, recordar que ser ágil significa reemplazar la predictibilidad falsa por la eficiencia.

Cambia... Hay un gran chance de que el nuevo día sea radiante.

Antipatrones Scrum: primer acercamiento

“Scrum es como el ajedrez. O lo juegas como lo dictan sus reglas, o no lo juegas. Scrum y el ajedrez no fallan ni aciertan. O los juegas, o no.” Ken Schwaber [1]

Presentación, o de la relación que tiene Bruce Lee con un arquitecto de apellido Alexander, una banda de los cuatro, Chuck Norris y Kent Beck

Las llaman ‘malas prácticas’, a mí me gusta llamarlas ‘prácticas fuera de contexto’; en el entorno ágil, algunos incluso hablan con humor de ‘Scrum Norris’, refiriéndose a aquel actor de Hollywood, Chuck Norris, quien apareciera por primera vez en 1972 en una película del legendario Bruce Lee, La Furia del Dragón, y que se hiciera popular por allá en los años 80 con películas de acción como Ojo por Ojo, Perdidos en Acción y Fuerza Delta y donde, a pesar de la incesante acción, no sufría ni un rasguño, ni siquiera se espelucaba. Los más técnicos y aventajados penetran la barrera científica y las llaman ‘Antipatrones’. Pero para usar este último término, primero definamos qué es un patrón, en nuestro contexto.

Quizás todos recordamos los súperarchipopulares ‘patrones de diseño’ [2] de los también súperarchifamosos ‘banda de los cuatro’ (Gang of Four), compuesta por Erich Gamma, Richard Helm, Ralph Johnson y John Vlissides, quienes a su vez basaron su investigación en el trabajo de un Arquitecto (no de software), Christopher Alexander, quien por allá a finales de los 70, dio origen al tema como un concepto arquitectónico. Lo curioso de este asunto es que no fueron Gamma y su banda quienes primero tomaron ese concepto de Alexander: fueron los mismísimos Kent Beck y Ward Cunningham quienes en 1987 comenzaron a experimentar con la idea de aplicar patrones a la programación de computadores y presentaron sus resultados en el OOPSLA de ese año.

Toda esta historia, que siempre me ha parecido fascinante, porque es en la que se basarán los antropólogos de la TI en el futuro para descubrir al resto del universo de donde proviene la inteligencia artificial: las máquinas que piensan, los robots que hablan mejor que los humanos y los computadores ópticos, toda esta historia, simplemente para entender que un ‘patrón’ es una solución reusable a un problema común y recurrente dentro de un contexto. Pero ojo, un patrón no es una solución terminada, en cambio, es una descripción de cómo solucionar un problema.

Finalmente, hay patrones de Análisis (Fowler), patrones de diseño (Gamma et all), patrones de programación (Beck), patrones de pruebas (Binder), etcétera. Por supuesto, están los patrones en los métodos y en las prácticas y en los procesos. Pero de todo esto hablaremos en otra oportunidad. Lo que me ocupa esta vez son precisamente los Antipatrones Ágiles, en general, y los de Scrum, en particular.

Antipatrones Scrum: una primerísima aproximación pragmática

Un Antipatrón es, entonces, la antítesis de una solución a un problema recurrente. En el caso de los métodos y prácticas (ágiles), son actividades, procedimientos o rutinas, usos o hábitos, que personas dentro de una organización o entorno adquieren o ejecutan, con la idea de que son la forma ‘correcta’ de hacer las cosas. Estas malas prácticas se dan por múltiples razones. Aquí algunas de las respuestas más frecuentes que escucho en mi trasegar ágil:

• Siempre lo hemos hecho así
• Nuestras condiciones son únicas, entonces debemos hacerlo de esta manera (¡la madre de todas las entelequias!)
• Hay temor al cambio (la más natural de todas estas especulaciones, el miedo es algo inherente al ser humano. Es quizás este miedo el que infunde los demás motivos expuestos aquí. No en vano León Felipe dice: “el miedo del hombre…ha inventado todos los cuentos.” [3])
• La teoría, lo que dicen los libros y los manuales (léase Guías) no nos aplica
• Tenemos regulaciones que nos impiden hacerlo de otra forma
• No hemos tenido entrenamiento ni acompañamiento (de expertos en la materia)

Quizás esta última sea la razón cardinal de que las organizaciones se desvíen de las prácticas propuestas en Scrum por distintos motivos y de que las implementaciones prácticas de Scrum rara vez sigan los ideales de los libros de texto y mucho menos de sus autores. Es probable que algunos de esos porqués estén bien respaldados y sean sensatos, como lo hemos abordado en algunos ambientes, sin embargo, la gran mayoría de las veces las organizaciones no alcanzan a distinguir netamente las secuelas que se derivan de tomar esas desviaciones y se sienten tentadas a ajustar, a ‘acomodar’ Scrum y otras prácticas ágiles para ellas.

He estado allí: muy tarde se dan cuenta estas organizaciones que han caído en un sinfín de malas prácticas o en unos hábitos inadecuados para las personas, para los equipos y para la organización misma. Los resultados infaustos empiezan a aparecer cuando tratamos de ir un poco más allá: ‘bueno, ya que hacemos Scrum, agreguemos TDD y refactoring’ o ‘ya que hemos gestionado dos o tres proyectos con Scrum, llevemos esto a nivel corporativo’. Personas quemadas, clientes/usuarios que no ven la diferencia con métodos anteriores (léase Cascada, WaterRUP, etc.) o modelos de calidad como CMMI, COBIT, PMI y familiares.

Ahora bien, es cierto que en un lapso de tiempo relativamente breve, desde el ascenso de los arquetipos, poéticos por demás, del Manifiesto Ágil, muchas organizaciones se han afiliado a alguna forma de trabajo ágil. Pero lo que realmente está sucediendo cuando alguien dice “somos ágiles”, es “estamos usando algunas prácticas o ideas de Scrum y de otros métodos o prácticas ágiles”, algo que se conoce ordinariamente como ScrumBut (en español, ScrumPero –algo así como: ‘sí, usamos Scrum pero…’, donde este ‘pero’, quiere decir muchas veces: no tenemos Dueño de Producto, o no hacemos reuniones diarias, o el Scrum Master es el mismo Arquitecto de software o el gerente del proyecto, o no tenemos ‘definición de terminado’, entre muchas otras cosas y, con frecuencia, un compuesto de varias de estas).

Primera lista no exhaustiva, incompleta, de antipatrones Scrum

Hasta aquí la perorata, a manera de introducción. Lo que sigue es una lista de esas prácticas fuera de contexto, o antipatrones.

1. “Nuestro Scrum Diario tarda 30 minutos o más, hablamos mucho de todo”, emparentado con “no hacemos Reunión Diaria porque no le vemos sentido”. Ya sé, tus tareas tardan 20, 30 o más horas y cada día que se reúnen, tus actividades siguen “en progreso”. Por eso no tiene sentido reunirse cada día.
2. “Hablamos con el Dueño de Producto cada 2 o 3 semanas, durante la reunión de planificación”
3. “Nuestro Sprint 0 es de nunca acabar, estamos detallando todos los requisitos”, también conocido como el ‘contraataque de la Cascada’
4. “No sabemos donde está el Backlog del Producto”, o del ‘extraño caso del backlog de producto misterioso’
5. “No tenemos definición de terminado”, familiar de “nuestro ‘trabajo en progreso’ es ilimitado”
6. “No hacemos retrospectiva porque todo funciona muy bien con Scrum” o “nuestras retrospectivas son una oda a la autolaceración”. Me sé muchas otras con nuestra reunión favorita de regresión y análisis. Una, a propósito de Scrum Norris: ‘Cuck Norris no necesita Revisiones ni Retrospectivas. No hay espacio para el mejoramiento en los procesos de Chuck Norris’.
7. “Nuestros Scrum Masters están en piloto automático”. A estos los ascendieron en esta década a zombis. ¡Estamos llenos de Scrum Masters zombis! Necesitamos un proyecto ‘Alice’ que acabe con esa disfunción.
8. “Sí, hacemos sprints de 2 semanas, pero no entregamos valor al negocio”. Estos son los del enfoque iterativo e insustancial. El producto resultante es una colcha de retazos
9. “Nuestros equipos son elásticos: sus miembros entran a y salen del equipo en cualquier momento del sprint y en cualquier sprint”
10. “En la organización cambiamos el modelo de gestión del PMI por Scrum, pero el resto del proceso lo dejamos tal cual estamos certificados CMMI”

Suplemento

1. “Nuestros Scrum Masters están asignados a 4, 9 y hasta 17 proyectos simultáneamente”, mejor conocido el Pulpo Ágil
2. Nuestros clientes aceptan que usemos Scrum pero los proyectos son tiempo fijo-costo fijo-alcance fijo y el cronograma lo debemos entregar el primer día”

Por ahora solo la lista, pero mi análisis irá mucho más allá. Cuál es el contexto donde típicamente ocurre la mala práctica, cuál es la recomendación de Scrum/Ágil para cada eliminar el antipatrón de la faz de la tierra (bueno, al menos, del entorno donde se presenta), cuáles son las consecuencias de insistir en el mal-uso de la práctica, cuál es la solución (al menos, parcial) y, quién sabe, quizás alguna que otra excepción en la que el uso del antipatrón se justifique. ¿Es esto último posible? Yo no lo sé de cierto, lo supongo.

Colofón

Finalmente, quiero referirme a la frase inicial que usé para abrir este primer incremento sobre el tema: tiene razón Schwaber al hacer la analogía de Scrum con el Ajedrez. Las reglas de este juego son pocas y bastante simples, sin embargo, las estrategias existentes para jugarlo son diversas. Y hay un momento en el juego de la ‘Torre’ y el ‘Alfil’, llamado el ‘juego medio’ por los estudiosos, que se parece mucho a cuando los equipos de construcción de software juegan al diseño y a la programación usando las maniobras de Scrum: es cuando se requiere de creatividad, innovación, anticipación; es cuando precisamente nos damos cuenta que el desarrollo de software, como el Ajedrez, es jugado por personas, no por procesos ni herramientas.

Volveré con más antipatrones… ¡pronto! Mientras tanto, cuéntame cuáles malas prácticas o antítesis de excelencia, te has encontrado al ingresar a este apasionante pero complejo universo del desarrollo de software con métodos y prácticas ágiles.

Referencias

[1] Blog de Ken Schwaber: abril 7 de 2011:

https://kenschwaber.wordpress.com/2011/04/07/scrum-fails/

[2] Gamma, Erich; Richard Helm, Ralph Johnson, and John Vlissides (1995). Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley. ISBN 0-201-63361-2.

[3] Felipe Camino Galicia de la Rosa, conocido como León Felipe (Tábara, Zamora, 11 de abril de 1884 - Ciudad de México, 18 de septiembre de 1968), fue un poeta español. Este es su poema “Sé todos los cuentos”:

Yo no sé muchas cosas, es verdad.

Digo tan sólo lo que he visto.

Y he visto:

que la cuna del hombre la mecen con cuentos…

Que los gritos de angustia del hombre los ahogan con cuentos…

Que el llanto del hombre lo taponan con cuentos…

Que los huesos del hombre los entierran con cuentos…

Y que el miedo del hombre…

ha inventado todos los cuentos.

Yo sé muy pocas cosas, es verdad.

Pero me han dormido con todos los cuentos…

Y sé todos los cuentos.

Mañana empiezo un nuevo proyecto: ¿qué metodología ágil me pongo?

Ecosistema de Métodos y Prácticas Ágiles (Parcial)

El ecosistema ágil está formado por un conjunto de organismos “vivos” llamados “métodos y prácticas ágiles” (biocenosis) y el medio físico donde se relacionan, llamados Organizaciones (biotopo). Estas últimas están conformadas por personas y estas personas usan distintas clases de biocenosis, es decir, de métodos y prácticas ágiles, según sus necesidades.

Como todo ecosistema, el ágil tiene barreras que a veces impiden su normal evolución. Barreras físicas, como la falta de entornos adecuados dentro de las Organizaciones para albergar equipos que respiren “agilidad”. Barreras culturales y hasta emocionales, arraigos y miedos que se dan entre las personas, quienes experimentan temores muchas veces infundados debido a la falta de información o de acompañamiento efectivo por parte de expertos, de conocedores de ese ecosistema ágil en formación.

Pero, ¿cuáles son esos métodos y prácticas ágiles? ¿Para qué sirve cada uno de ellos? En esta sesión exploraremos, a manera de introducción, las metodologías más usadas, como Scrum, eXtreme Programming (XP), Kanban, Lean; y algunas de las técnicas necesarias en un primer esfuerzo por implementar la Cultura Ágil en una Organización: User Story Mapping, Product Vision Board, User Persona, User Stories, TDD, BDD, para mencionar solo algunas.

Y lo más importante, ¿para qué sirve cada uno de estos especímenes ágiles? ¿Alguno de ellos es adecuado para el proyecto que inicio mañana? ¿Varios de estos? ¿Son complementarios? ¿Qué problemas puedo encontrar si elijo mal? Y en el fondo, ¿cuáles son las razones por las que debo permitir el nacimiento y expansión de un nuevo ecosistema aun si el actual me está rindiendo beneficios? Y hablando de utilidades, ¿cuáles puedo obtener al implementar la “agilidad” en mi Organización?

Finalmente, sabemos que los ecosistemas están gobernados principalmente por eventos estocásticos (azar), por las reacciones que estos eventos ocasionan en sus componentes y por las respuestas de los organismos a las condiciones que los rodean. ¿Cómo controlar estos eventos y sobrevivir en el intento? Una mirada Darwiniana nos ayudará a entender cómo, mediante la inspección y la adaptación, nos iremos adecuando a los cambios que ocurren en todo proceso de evolución y entenderemos que la cultura ágil es el siguiente paso en la evolución de la inteligencia.

Nota:

Esta fue la presentación que hice durante el marco de las VII Jornadas Latinoamericanas de Metodologías Ágiles - Ágiles 2014, en Medellín, Colombia. Del 23 al 25 de octubre de 2014.

Nivel: Principiante

Título: Mañana empiezo un nuevo proyecto: ¿qué metodología ágil me pongo?

Resumen:

Uno de los impedimentos más grandes a la hora de implementar Ágil se origina en el desconocimiento que tienen las personas sobre lo que harán a continuación. ¿Por cuál de los métodos empiezo? ¿Uno solo es suficiente? La respuesta corta a esta última pregunta es “no”. Entonces, ¿qué debo saber para dar el salto de aquí hasta ágil? ¿De qué me “agarro” para no caer en el abismo? Estos son los asuntos que abordaré en esta sesión introductoria.

Con definiciones simples y ejemplificadas, basado en hechos históricos de los cuales he sido protagonista, le contaré a la audiencia de qué se trata toda esta jerigonza ágil, a manera de Gazafatonario.

La presentación completa la pueden descargar aquí:

Mañana empiezo un nuevo proyecto: ¿qué metodología ágil me pongo? de Luis Antonio Salazar Caraballo

#Agiles2014: Ágil es algo que eres, CMMI es algo que usas

ser ágil significa reemplazar la predictibilidad falsa por la eficiencia

Con una actualización debido al cambio de audiencia, presenté en #Agiles2014 mi disertación sobre Ágil y CMMI. Como en la versión 1.0, durante la SEPG LA 2014 en Manizales, mi asunto principal era que los métodos ágiles no tienen por qué entrar en conflicto con otros modelos o enfoques de construcción de software, no es la idea de ser ágil o, al menos, no está en el flujo de un proceso de transformación a ágil echar tierra a las prácticas existentes en una organización. Los líderes de los procesos actuales deben trabajar en conjunto con los nuevos líderes para que estos últimos obtengan los beneficios de ambos universos y aprovechar esa sinergia para mejorar dramáticamente el rendimiento del negocio.

Para apoyar este concepto, expliqué que los modelos como CMMI, PMI e ISO nos dan una idea de cuales procesos son necesarios para mantener una organización madura y disciplinada, capaz de predecir y mejorar el desempeño de la organización misma y de los proyectos. Entre tanto, las técnicas ágiles proporcionan guías para un manejo eficiente de los proyectos de una manera que permite alta flexibilidad y adaptabilidad. Al mezclar los dos enfoques, la filosofía ágil asegura que los procesos se implementen eficientemente a la vez que aceptan los cambios; y los modelos tradicionales aseguran que se consideren todos los procesos relevantes.

Pero de inmediato fui al centro de mi exposición: una de las grandes diferencias, radicales por demás, entre los métodos tradicionales y los ágiles es que estos últimos son generativos, no prescriptivos. Los procesos necesitan evolucionar según las necesidades, no prescritos con anticipación. Un enfoque prescriptivo genera procesos complejos y complicados, mientras que un enfoque generativo comienza con un conjunto de procesos simples y adiciona otros a medida que se requieren.

La filosofía ágil reconoce que los procesos de software más efectivos no pueden definirse por adelantado; es un proceso continuo. Los métodos tradicionales se enfocan en definir y reforzar procesos y gastan muy poco tiempo en identificar y entregar lo que los usuarios necesitan. Aunque su propósito es mejorar la consistencia y la calidad, esto muchas veces se consigue a expensas de la productividad y la entrega. El enfoque tradicional de procesos tipo CMMI también usa herramientas monolíticas y pesadas que causan construcciones frágiles y traspasos inefectivos entre desarrollo, pruebas, despliegue y operaciones.

Lo que siguió fue enfatizar en lo que significa ser ágil: específicamente, la interiorización y la práctica de los Valores y Principios del Manifiesto Ágil, nada alejado de lo que se habló en el resto de #Agiles2014.

Hacia el final quise poner mi propio manifiesto, el ‘Ágil es algo que eres…’, se trata de la persona, no de las cosas ni de los procesos. Ya lo he dicho en otras oportunidades, ser ágil significa reemplazar la predictibilidad falsa por la eficiencia.

Para descargar la presentación

Puedes descargar las memorias de esta conferencia de: http://goo.gl/rhNMcf

Por qué usar métodos + prácticas ágiles

Anualmente, la consultora VersionOne.com publica un estudio sobre el uso de metodologías y prácticas ágiles. Este año, el estudio llegó a su octava edición. El estudio dice, por ejemplo, que Scrum es el método más ampliamente usado en el ecosistema ágil y así ha sido en los últimos 8 años, mismos en los cuales se ha incrementado su uso desde un 40% hasta el 55% de este año. Además, otros sabores de Scrum, combinados con métodos o prácticas como XP y Kanban también son bastante usados. Es un hecho, Scrum está aquí para quedarse.

Fuente: VersionOne.com. 8th Annual State of Agile Survey

Pero quiero referirme es a las principales razones por las cuales se usa Ágil. El estudio dice en esta sección que los 3 motivos primordiales que dieron los participantes de la encuesta son:

• Acelera la salida del producto al mercado: 23%
• Maneja más fácilmente los cambios en las prioridades: 16% y
• Mejora la alineación del negocio y de la IT: 15%

Fuente: VersionOne.com. 8th Annual State of Agile Survey

El 75% de los encuestados considera que es muy importante o de la más alta importancia el que los métodos ágiles aceleren la salida del producto al mercado. Este es el principal beneficio de usar prácticas y metodologías ágiles. Las salidas “tempranas” se logran construyendo el producto de manera orgánica, en iteraciones cortas de 4 semanas o menos, con preferencia al tiempo más corto posible. Y si bien es cierto que es posible no salir a producción al final de cada iteración, siempre debemos planear para que haya entregas a Operación cada muy pocas iteraciones.

Los equipos ágiles no congelan las prioridades ni las firman con sangre. Es el usuario (por ejemplo, el Dueño de Producto en Scrum), quien establece qué quiere ver primero y qué quiere ver más adelante. En consistencia con el aspecto anterior, es el usuario quien tiene la última palabra en el orden de prioridad conque el mercado llega al mercado o a los usuarios finales. Se trata además, de software con valor, recordemos que en Ágil todo es acerca de entrega de valor al negocio.

En ese mismo orden de ideas, la alineación de la IT con los objetivos del negocio siempre ha sido uno de los pilares de los métodos ágiles, de hecho, tiene sus cimientos en aquel valor del Manifiesto Ágil de Colaboración con el cliente sobre la negociación contractual. Recordemos también que los desarrolladores y el negocio trabajamos juntos cotidianamente durante todo el proyecto, o así reza uno de los principios del Manifiesto. El 65% de los encuestados respondió que esta razón es muy importante o de la más alta importancia para ellos a la hora de hace uso de las metodologías ágiles.

El estudio completo lo encuentran en versionone.com.

Certificar un proveedor como Ágil o de la 'Agile Certified Provider Alliance'

“Generalmente ganamos la confianza de aquéllos en quienes ponemos la nuestra.” [Tito Livio]

Hace algunos días, nuestro amigo y colega Jorge Abad decía en un mensaje a la Comunidad de Ágiles Latinoamérica:

“Me hacen esta pregunta desde una empresa del estado que realiza grandes contrataciones de proveedores: ¿Existe una lista de chequeo estándar para validar si una empresa es ágil y usa las prácticas de ingeniería adecuadas para ágil?”

Al margen de que sea o no una empresa del estado, la pregunta tiene su truco. En cualquier caso, esta fue mi respuesta a Jorge:

Watts Humphrey, el padre de CMMI, decía que certificarse CMMI 5 significaba que tu siguiente proyecto iba a ser exitoso. Él no decía nada de los demás proyectos. Es natural, la organización recién certificada “respiraba” CMMI, calidad, procesos, productividad y motivación, algunos de los elementos clave para el éxito de los proyectos.

¿Pero y los demás proyectos, los que siguen a continuación de ese?

Igual sucede con Ágil. Aun si el cliente visita al proveedor potencial, este último le puede demostrar a aquel (¡a no ser que sea una visita sorpresa!), que es Ágil.

¿Pero y los demás proyectos? [Acá entre nos, no existe ninguna posibilidad de que una lista de chequeo sirva para probar que un proveedor es ágil. Existen listas como esta de Henrik Kniberg (http://goo.gl/QnQUN), una herramienta para evaluar una implementación de Scrum, tratar de encontrar algo más allá es una utopía.]

Quienes hemos navegado por los vericuetos, a veces inescrutables, de las certificaciones de todo tipo, que nos proclaman como los poseedores del vasto poder del conocimiento y la experiencia, sabemos que eso no es suficiente y que, en muchos casos, eso no garantiza el éxito. Sobre todo, en nuestras economías tercermundistas, con nuestra idiosincrasia, con nuestra forma de ver el universo.

¿Qué vale entonces?

¡La confianza!

Aun una entidad del gobierno, debe dar el salto y modificar su “modus vivendi” (Sí, lo sé, no es fácil –pero igual, aun una entidad del gobierno debe saber que “ser ágil no es solo cosa de sus proveedores”, la organización también debe transformarse), para que pueda ser capaz de hacer pilotos, evaluar los resultados y luego sí, ajustar con el probable proveedor o desecharlo de una vez por todas y para siempre, condenarlo a 100 años de soledad, esa fatídica maldición de los que no tienen una segunda oportunidad sobre la tierra.

Incluso quizás unos cuantos sprints no serán suficientes. Más aun, ¿cómo comprobar al final de varios proyectos si tu proveedor es ágil? ¿Acaso es posible probar que parte del equipo no es ágil (el equipo de desarrollo –del Proveedor) y parte sí (acaso el Dueño de Producto y quizás el Scrum Master –del Cliente)?

Estaba reflexionando con toda esta perorata y mi conclusión es que no es posible, al menos no tiene mucho sentido que este cliente del estado, o cualquier otra empresa privada o de gobierno, evalúe si un proveedor es ágil.

Quizás el proveedor sí es ágil, pero cuando se junte con el cliente deje de serlo.

Quizás no lo es, pero cuando se junte con el cliente aprenda a serlo.

Quizás sí lo es y cuando se junte con el cliente, siga siéndolo.

En fin, las posibilidades son variadas.

¡Estamos de vuelta en la Confianza! Martín Alaimo, dice en su libro “Equipos #MásProductivos”, citando a su vez a Gorerg Simmel, que “La confianza es una hipótesis sobre la conducta futura del otro” y más adelante él mismo dice: “La confianza que inspiro en otros sobre mí, la construyo y la sostengo a través de mis acciones.”

Algunos miembros de la Comunidad le respondieron a Abad que era una cuestión de “feeling”. Yo, por ejemplo, tuve varias novias (2 al menos) antes de quedarme con quien es mi esposa, no era la más bonita pero sí la que más confianza me generó. Y eso, mi estimado Jorge, no se consigue con una lista de chequeo ni con una visita a casa de los padres de la novia. ¿Quién sabe? Quizás mañana me divorcie.