Buscar en Gazafatonario IT

Mostrando las entradas con la etiqueta Principio Ágil. Mostrar todas las entradas
Mostrando las entradas con la etiqueta Principio Ágil. Mostrar todas las entradas

miércoles, octubre 26, 2016

Ecce homo o el Ágil es algo que eres

Ecce Homo restaurado de Cecilia Giménez
En el mundo moderno, las personas profesionales tienen una preocupación, con visos de ansiedad, vinculada a su ADN, sobre todo quienes trabajan en o alrededor de compañías de TI: ser competitivas, exhibir un alto desempeño y lograr metas en plazos cortos. Las actividades que realizan y los resultados, productos o servicios generados, deben ostentar estándares elevados de calidad. Este escenario sube el nivel de estrés de quienes lo intentan día a día, aunque también acentúa el grado de satisfacción cuando se alcanzan esos objetivos.
Es precisamente bajo esta atmósfera donde el enfoque ágil presume de sus incontables beneficios. El movimiento Ágil, que no es una metodología, nos permite encontrar y poner en práctica alternativas a la gestión tradicional de personas, proyectos y organizaciones. Esta perspectiva Ágil ayuda a los equipos a responder de manera oportuna a la poca o incierta predictibilidad a través de cadencias de trabajo incremental e iterativo y de la retroalimentación empírica.
Este modelo de desarrollo repetitivo o de ciclos de trabajo abreviados, también nos habilita a las personas y a los equipos para ser cada vez más expertos en cada uno de los aspectos de la construcción de productos. En el caso de la Ingeniería de  Software, hablamos de los requisitos, diseño, programación, pruebas, integración, etcétera. Pero este enfoque puede aplicarse en muchos otros entornos de producción y operación, una oportunidad que no teníamos con el modelo tradicionalista en Cascada, donde solo había una única  ocurrencia para hacer las cosas.
Esta evolución de la eficacia en el trabajo relacionada con proyectos de desarrollo sistémico es notoria y nos permite, a su vez, ofrecer una mayor garantía de calidad y de cumplimiento con las fechas límite, aunque surgen algunos efectos colaterales de la aplicación del modelo: nos volvemos menos predictivos (¡bueno, tampoco es que antes fuéramos altamente predictivos!), se acaba eso de culpar a alguien más si las cosas no salen bien y el hecho de que Ágil requiere mucho más compromiso y esfuerzo (¡aun a ritmo sostenido!) de todos los involucrados.

Ágil es algo que eres, las prácticas y los frameworks son algo que usas

Dentro de esos innumerables beneficios de la estrategia Ágil encontramos que las características más importantes del producto reciben la más alta prioridad y que incrementos funcionales del producto se entregan desde temprano y frecuentemente; además, las prácticas y marcos de trabajo livianos que acompañan el enfoque simplifican en grande el flujo de trabajo a la vez que solo se produce la documentación necesaria y suficiente para facilitar el control del producto por parte del usuario o cliente; por último, mi beneficio favorito de este conjunto, todo esto conduce a esa eficiencia y eficacia que mencionaba al principio, lo que a su vez confluye en equipos con personas altamente motivadas y felices que exhiben un alto desempeño, sin la carga de estrés impuesta por los métodos antiguos.
Cómo se logra esto es otro asunto pero son esenciales para ello la comunicación y la colaboración no solo entre los miembros del equipo sino con las personas del entorno, los interesados. También es importante que apliquemos la filosofía Ágil donde y cuando genere valor, aunque no se me ocurre en este momento un escenario donde esto no sea posible. No se trata solo de usar Scrum, Kanban o Lean, SAFe o Nexus, o de hacer retrospectivas por hacerlas, que apenas son artefactos y comportamientos visibles, esa porción de la cultura que nos permite hacer Ágil.
Se trata es de entender y practicar las formas de racionalizar y las estructuras cognitivas de elementos como la comunicación cara a cara, la simplicidad, el compromiso, las entregas incrementales de producto funcionando con valor, la calidad y la satisfacción del cliente, entre muchos otros; pero más en el fondo o en la base, este enfoque es acerca de cultivar y experimentar continuamente valores y creencias relacionados con las personas y sus interacciones, el coraje, el respeto, la inspección y la adaptación  permanentes, la transparencia, la respuesta a los cambios constantes y tantos otros elementos que constituyen eso que conocemos como Manifiesto Ágil, es esa otra porción de fondo de la cultura que nos permite Ser Ágil.

Ágil significa reemplazar la predictibilidad falsa por la eficiencia

Las organizaciones que han incorporado estos paradigmas ágiles, por su parte, entienden que las personas experimentadas, con amplias habilidades en la resolución de problemas y en el mejoramiento de procesos, son extremadamente valiosas para hacer realidad la visión organizacional. Estas compañías reconocen que el costo de desarrollar personas con estas habilidades es grande, especialmente si quieren involucrarlas y comprometerlas en la mejora continua de procesos. Por eso no solo les proporcionan las herramientas y los recursos necesarios para entrenarse continuamente sino que también disponen de agentes de cambio que los ayudan a potenciar sus destrezas.
De esta manera es que hemos abierto nuestras mentes para enfocarnos en las personas y nuestras interacciones con ellas y cómo colaboramos con nuestros clientes y en cómo pensamos acerca de nuestro trabajo y en tácticas que nos descubran el camino hacia la superación perpetua. Nos concierne y nos motiva enfrentar los cambios, nos interesa ser la estrategia, no simplemente apoyarla, somos líderes por naturaleza, pero líderes con el poder de influenciar a otros, no de gobernarlos, nos gusta animar a los demás a que compartan nuestra visión y compartimos la de ellos, no miramos al pasado sino para aprender  y nos hacemos cargo del futuro.
Las reglas del juego cambiaron, ¿te diste cuenta? Déjamelo saber en el foro.
---
Más sobre Filosofía Ágil en:

miércoles, octubre 12, 2016

Dueño de Producto, usted ha sido invitado a la Retrospectiva


El Dueño de Producto, ¡ese ilustre olvidado!

Me preguntan por interno si este personaje debe asistir a la ceremonia de inspección y adaptación. Es una buena pregunta, teniendo en cuenta que hay quienes recomiendan que no sea así o que la participación del Dueño de Producto es opcional en la Retrospectiva.
No hay ninguna buena razón por la cual el Dueño de Producto no deba estar en la retrospectiva. Desde la misma guía de Scrum ya sus autores sugieren que debería participar:
"La Retrospectiva de Sprint es una oportunidad para el Equipo Scrum de inspeccionarse a sí mismo y de crear un plan de mejoras que sean abordadas durante el siguiente Sprint".
Y ya sabemos que el Equipo Scrum se compone de Scrum Master + Desarrolladores + Dueño de Producto.
Pero más allá de esto, no concibo cómo, sin la participación del Dueño de Producto en esta reunión, sea posible que el equipo en pleno se inspeccione a sí mismo para luego crear un plan de mejoras que nunca estará completo sin la intervención de este actor. Por ejemplo, ¿cómo mejorar la comunicación con el entorno del negocio? El resto del equipo no podría definir la mejor estrategia para lograrlo en ausencia del Dueño de Producto.
Algunos dirán que se define la estrategia en la reunión y luego se la comunican al Dueño de Producto, eso simplemente extendería la retrospectiva, con el riesgo de que él "tumbe" las acciones a realizar por cualquier motivo válido.

  • ¿Y qué pasa si hay problemas con la salud del backlog? 
  • Problemas con la definición de los criterios de aceptación de las historias de usuario.
  • ¿El equipo conoce cómo los usuarios realmente usan el producto?
  • Problemas con la aceptación del incremento sprint tras sprint.
  • ¿El equipo conoce la visión completa del producto, la estrategia de implementación y cómo lo quieren los usuarios?
  • ¿Y qué ocurre si el Dueño de Producto no está el tiempo suficiente con el equipo para responder sus preguntas y clarificar las características del producto? O para proporcionar retroalimentación efectiva.

En fin, muchas son las razones para que el Dueño de Producto sí esté en la reunión. Estas que mencioné son solo algunas. En breve, el Dueño de Producto es protagonista principal en esta ceremonia.
Ahora bien, se me ocurren algunas malas razones por las cuales no debería asistir. Las mencionaré brevemente y estableceré alguna razón sólida para no tenerlas en cuenta:
Lo aburrimos con minucias técnicas. Una retrospectiva no es para profundizar en los detalles de lo puramente técnico.
El equipo de desarrollo y el Scrum Master son de un proveedor y el Dueño de Producto es del Cliente. Entonces dónde queda la confianza y, por consiguiente, la transparencia. Si estamos pensando así, todavía nos hace falta mucho de la Cultura Ágil y de liderazgo. En cualquier caso, esta práctica reduciría mucho la transparencia, necesaria a todas luces en un entorno ágil.
No tiene tiempo. ¡Este es, precisamente, un tema a abordar con él en la retrospectiva!
Así lo hemos hecho aquí y nos funciona. Esta es interesante. ¿Y qué tal si lo hacemos de la otra forma (qué si asista) y vemos la diferencia? ¿Mejoramos o empeoramos? Seguramente será lo primero.
Esta última es la típica cuestión que se enmarca en el empirismo, es decir, aprendemos de la experiencia, como todo en Scrum. Algo que se resume también en eso de "usar o hacer lo que te funciona". Sin embargo, las razones que expuse al principio y muchas otras precisamente nos han enseñado los beneficios de la presencia del Dueño de Producto en la ceremonia.
Entre otras, pero todas absolutamente son "malas" razones.
En definitiva, el Dueño de Producto debería (sí debe) asistir a las retrospectivas, así que adelante. Si como Scrum Master te sugieren que el Dueño de Producto no debe estar en la reunión, te enfrentas a una sintomatología que te indica que falta algo de la base, los valores y principios ágiles, la forma cómo racionalizamos, el fondo de la cultura ágil, más que del mismo Scrum y otras prácticas. --- ¿Y tú invitas al Dueño de Producto a tus retrospectivas? Déjamelo saber en el foro.


martes, enero 19, 2016

Agilidad: algunas características intrínsecas

Infografía: Agilidad 101. Clic en la imagen para ampliar.

AGILIDAD

La habilidad de las personas, equipos y organizaciones de crear Valor a la vez que promover y responder al cambio para tener éxito en un entorno incierto.

Algunas características intrínsecas a la Agilidad son:
RETORNO DE LA INVERSIÓN

Ágil proporciona ROI en forma de beneficios cualitativos como el mejoramiento de la moral del equipo y principalmente ROI en la forma de beneficios cuantitativos, expresado en términos económicos, mediante la entrega continua y frecuente de soluciones con Valor.
MARCOS DE TRABAJO

Estamos descubriendo formas mejores de desarrollar software. Los marcos de trabajo ágiles son iterativos e incrementales y de Valor. Scrum y otros métodos y prácticas ágiles se basan en la teoría empírica, es decir, aprendemos de la experiencia. El propósito final de las prácticas ágiles no es tanto el hacer como el encontrar formas mejores del hacer.
TIEMPO

Entregamos productos frecuentemente, incluso todos los días. Las iteraciones son períodos muy cortos de tiempo que finalizan con la entrega de productos que generan Valor del negocio.
DOCUMENTACIÓN

Valoramos más las soluciones en uso que la documentación exhaustiva. La meta de ágil es encontrar el balance adecuado entre la documentación y la comunicación cara a cara. La documentación es una parte importante de todo producto, pero la documentación exhaustiva como tal no asegura el éxito de un proyecto. De hecho, aumenta la probabilidad de fracaso.
INNOVACIÓN

En la forma de mejoramiento continuo.  Las prácticas ágiles nos permiten encontrar formas innovadoras para crear productos y servicios mejores, más baratos, más livianos, más rápidamente y de una forma más conveniente y personalizada para nuestros clientes.
PERSONAS

Valoramos más las personas y la comunicación cara a cara entre las personas. Lo más importante en el ecosistema ágil somos las personas. Los equipos son autoorganizados y nuestra mayor prioridad es satisfacer al cliente.
MEDICIÓN


Las mediciones se hacen mediante observación directa en el lugar de trabajo, el Gemba, y medimos la realidad de la organización y de los proyectos con el ánimo de encontrar continuamente opciones de mejoramiento. Fomentamos la retroalimentación continua en todas las direcciones. 

viernes, junio 12, 2015

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:


domingo, mayo 31, 2015

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? Déjamelo saber en el foro.

------------------------------------------------------------------------
Más sobre Scrum Master en:

miércoles, mayo 13, 2015

Ágil es algo que eres

Foto de http://pixshark.com
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. Más sobre Cultura Ágil en “Cultura Ágil: ese oscuro objeto del deseo
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.
Por ejemplo, respuesta ante el cambio sobre seguir un plan, uno de los valores del Manifiesto Ágil, es apenas una de las divergencias filosóficas cardinales entre los enfoques enraizados desde siempre en el desarrollo de software y esta visión emergente que significa ser ágil. Sobre este valor en particular, pueden leer mi artículo relacionado aquí. Más sobre el Manifiesto ágil en este enlace.
La Cultura Ágil es un continuum:
  • Empieza con la persona, se irradia primero hacia los equipos y luego a toda la organización, y termina en la persona.
Cuando hablamos de los productos, además de los atributos de excelencia que deben tener, es relevante interiorizar que:
  • El responsable de la calidad de un producto es Todo el Equipo Ágil. Además, una vez que el equipo entregue el producto, que este deje la sala de desarrollo, es porque está preparado para salir a producción.
  • Un error, una falla, no se ve como un evento crítico sino como una oportunidad de aprender acerca de los componentes del producto (el código, por ejemplo), del proceso y de cada uno de los miembros del equipo.
En su libro, “Being Agile”, Mario Moreira nos dice que “crear o adoptar una cultura ágil no se hace por accidente” y yo agrego: tampoco se hace por decreto. Moreira enumera algunas actividades que te ayudarán a moverte a una cultura ágil:
  • Reconocer que moverse a Ágil es un cambio cultural
  • Compartir los Valores y Principios Ágiles (continuamente)
  • Establecer y compartir objetivos y motivaciones
  • Obtener retroalimentación continua de los empleados. (Podemos extrapolar esto a conseguir retroalimentación de los socios de negocio, de los clientes, de los proveedores, es decir de todo el ecosistema organizacional)
  • Adaptar el sistema de recompensas para alinearlo con la nueva cultura
  • Identificar técnicas para ayudar a mitigar la resistencia de manera agradable
  • Evaluar a la administración y ver si los empleados tienen una personalidad que les permita alinearse con la nueva cultura
  • Comenzar a vivir los valores y principios que te ayuden a alcanzar la cultura que estás buscando
  • Proporcionar mecanismos de comunicación que se alineen con la cultura que quieres
  • Identificar y aplicar los procesos, métodos, prácticas y herramientas ágiles que estén alineados con tus objetivos
  • Aplicar un enfoque de inspeccionar y adaptar para medir el progreso
Debo insistir en que la vía hacia una transformación ágil, más que adopción, es un salto en la evolución, en el sentido de los saltos que ha dado la naturaleza durante millones de años, solo que aquí no tenemos tanto tiempo, pero un cambio de este nivel puede llevar un quinquenio, quizás una década, sobre todo para organizaciones que llevan 30 o 40 años usando enfoques y técnicas tradicionales.
Es decir, no se trata simplemente de cambiar un proceso por otro e institucionalizarlo, no se trata estrictamente de pasar de “manual” a “automatizado”, o de ir de integración bajo demanda a integración continua. Estas apenas son señales de que “lo estás haciendo ágil” y, en últimas, ágil no es solo algo que haces, ágil también es algo que eres.
-----------------------------------------------------------------------------
*La imagen interior es de [http://kidskidskids.tumblr.com/]

viernes, abril 17, 2015

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

#RSGECU2015: Ágil es algo que eres, CMMI es algo que usas
Este viernes 17 de abril, presenté en el Regional Scrum Gathering 2015, en Quito, mi disertación sobre Ágil y enfoques tradicionales. Mi asunto principal es 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, como erróneamente pregonan muchos. Los líderes de los procesos actuales pueden y 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 tipo 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 está hablando en el  #RSGECU2015.

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.

¿Quieres saber más?

Pueden descargar la nueva versión de la presentación haciendo clic aquí o en esta dirección: http://goo.gl/leJ5N8.


No olviden escribirme con sus inquietudes o sugerencias a lucho.salazar@gmail.com o en el foro del blog.

lunes, abril 13, 2015

Los trinomios cuadrados perfectos no son ágiles… o del principio de la simplicidad

“La perfección no se logra cuando no hay nada más que añadir, sino cuando no hay nada  más que quitar” [Antoine de Saint Exupéry]
En el último conversatorio sobre Scrum que facilitamos en la Comunidad de Ágiles Colombia en Medellín, hablamos de lo que significa ser ágil y llegamos necesariamente a los valores y principios del Manifiesto ágil.  Uno de los principios llamó especialmente la atención: “La simplicidad, o el arte de maximizar la cantidad de trabajo no realizado, es esencial.

Luego me encontré un artículo* de alguien que decía que había vivido gran parte de o toda su vida sin usar el trinomio cuadrado perfecto y muchas otras cosas complejas que le enseñaron en la escuela. A pesas de mi fascinación por el Álgebra, tuve que ceder un espacio en mi mente para estar de acuerdo con este pensamiento.

La tarea que me quedó fue entonces definir qué significaba #simplicidad y qué era eso de ‘maximizar’ el trabajo no realizado. Aquí algunas pistas:

Simplicidad es:

  • Tener un equipo totalmente horizontal, sin títulos ni especialidades adheridas a la frente de  cada miembro, sin protocolos que seguir para comunicarse unos con otros, incluyendo al usuario, donde cada uno sea responsable de sincronizarse con los demás y que nadie le rinda cuentas a nadie. Son equipos altamente productivos.
  • Usar un framework que te permita adaptarte a los continuos cambios del entorno, que te permita inspeccionar tu situación y la de tu equipo y con el que puedas modificar tu comportamiento basado en la experiencia que vas adquiriendo. Un framework que no sea una fuente de artes adivinatorias, sino más bien que evolucione contigo.
  • Priorizar las características del producto y construir solo aquellas que entreguen valor al usuario y al negocio. Según algunos estudios más del 65% del software que se construye se deja de usar muy pronto o nunca llega a instalarse, así que ¿por qué no construir solo lo que el usuario verdaderamente necesita y que genere un alto valor para la organización? Construye solo necesario para obtener rápida retroalimentación.
  • No realizar estimaciones a mediano/largo plazo ni prometer una fecha fija de entrega. No componer planes súper elaborados sino planificar continuamente: planificar las entregas/salidas a producción, planificar las iteraciones o sprints, planificar cada día de trabajo. A la larga, los planes no son nada, pero la planificación lo es todo.
  • Usar herramientas simples, como tableros de tareas simples que estén a la vista de todos, tarjetas simples con lo que quiere el usuario (las historias de usuario: como <<usuario>> quiero <<hacer algo>> para <<obtener algún valor>>): no hagas nada a menos que su valor esté plenamente establecido. Elaborar la documentación suficiente para cubrir las necesidades de la organización.
    "Pero no más simples"
  • No usar trinomios cuadrados perfectos todo el tiempo. Einstein lo dijo, las cosas deberían hacerse lo más simple posible… para construir algo, una funcionalidad por ejemplo, usa la técnica de reusar-comprar-hacer. Consulta primero si ya la tienes o la tiene alguien cercano a ti. ¿No? Búscala entonces en el mercado. ¿No la encontraste? Fabrícala, pero hazlo de manera simple, sin artificios exagerados, no vuelvas el software más complejo de lo que es por naturaleza.
  • Aprender continuamente. Si conoces muchas cosas, encontrarás respuestas cada vez más simples a problemas cada vez más complejos, como los que surgen en la construcción de productos de software. Así que nunca pares de aprender. Y conviértete en maestro, pero recuerda, no se trata solo de decir las cosas, porque tu aprendiz las olvida; tampoco se trata solo de enseñar, porque quizás solo logres que él/ella las recuerde; involúcralo y verás que también aprende.

¿Qué más se les ocurre que es #simplicidad? Háganmelo saber por este medio o por cualquiera de los medios habituales de comunicación.


*El artículo al que me refiero lo encuentran haciendo clic aquí.