Buscar en Gazafatonario IT

Mostrando las entradas con la etiqueta Agile. Mostrar todas las entradas
Mostrando las entradas con la etiqueta Agile. Mostrar todas las entradas

martes, diciembre 13, 2016

El Scrum Master extraordinario


En esta presentación hablo sobre que ser Scrum Master es principalmente acerca de liderazgo y coaching. No es un rol de gestión. No eres un gerente de proyectos ni de personas. Además, ser Scrum Master o Coach ágil definitivamente no es acerca de reforzar los procesos. 
Un Scrum Master extraordinario quiere o querrá que su equipo sea parte de esta carrera evolutiva – por ejemplo, haciéndolos partícipes de entrevistas con los usuarios o haciendo experimentos.
Si quieres llegar a ser un Scrum Master extraordinario enfoca tu energía en construir un entorno grandioso para tu equipo, probablemente así no tendrás que pasarte la vida, tu fantástica vida como Scrum Master, removiendo impedimentos. 
Además del trabajo de referencia, esta presentación está basada en mis artículos:
Puedes ver o descargar la presentación en el siguiente enlace:


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:

martes, agosto 23, 2016

Inceptions, con Jorge Abad



¿Cómo nacen los productos grandiosos? De esos cuyos componentes hacen resonancia entre sí e impactan el 'modus vivendi' de quienes los usan o consumen.

¿Cómo defines su alcance?

¿Cómo estableces el Producto Mínimo Viable - MVP?

¿Cuáles son las distintas técnicas y prácticas ágiles para hacer Inceptions de gran calidad y que motiven al equipo a empezar un trabajo fabuloso?

¿Qué es eso del Elevator Pitch?

¿Y el Product Box?

Además:

El User Story Mapping

+ El plan de entregas

+ El plan de iteraciones

+ Otras técnicas y herramientas que nos ayudan no solo a entender lo que queremos construir (lo que quieren nuestros usuarios o clientes), sino también a lograr consenso entre los miembros del equipo y los interesados en el proyecto y producto o servicio que queremos diseñar y construir.

Estas y algunas otras cuestiones son las que compartí con mi gran amigo Jorge Abad, con ejemplos concretos y prácticos, durante el Webinar del mismo nombre. El video lo pueden encontrar en:



Pueden descargar la presentación de:



Nota:
Este post lo podrás encontrar también en el blog de mi estimado amigo Jorge Abad @Jorge_Abad (Inceptions, con Lucho Salazar)



miércoles, julio 13, 2016

SCRUM CARD GAME – Un juego para experimentar Scrum


SCRUM CARD GAME es un juego simple que permite a los jugadores experimentar el trabajo en sprints de Scrum discutir muchas cuestiones y temas que suceden en la vida real mientras trabajan en un equipo Scrum. La discusión sobre la mesa  de juego será muy cercana a la experiencia real del trabajo en un equipo Scrum. Este juego usualmente se juega durante un entrenamiento o taller. Los participantes ya deben conocer y entender el marco de trabajo Scrum o pueden aprenderlo mientras participan del juego. También puede servir como método para hacer que un equipo experimentado reflexione sobre sus rituales y reglas establecidas de Scrum.

El eje del juego es que cada equipo (de 4 a 6 personas) es un centro de desarrollo competitivo contratado para llevar una nueva aplicación al mercado. El equipo más productivo gana.

Los materiales para el juego incluyen:
  • Un juego de cartas de Historias, Eventos, Problemas y Soluciones. Estas son las cartas de Oportunidad. Estas se encuentran en el manual oficial del juego del que comento más abajo.
  • Dos dados de seis lados (para cada equipo)
  • Rotafolio
  • Marcadores

Podrán imaginar ustedes que los sucesos del juego ocurren durante los sprints, se pueden jugar hasta tres sprints aunque es posible jugar 4 o más. Los sprints son de tres días de duración y durante cada día cada uno de los miembros del equipo trabaja en el sprint. En cada Sprint los equipos realizar Planificación, Revisión y Retrospectiva y durante la ejecución del sprint se experimentan conceptos como impedimentos o bloqueos, definición de Terminado, trabajo, Tablero de tareas, Backlog, entre muchos otros.

Al final del juego es posible hacer un análisis de temas tan importantes para los equipos ágiles como:
  • Esfuerzo planeado versus Real
  • Variaciones en la velocidad
  • Horas Estimadas versus Tamaño (Estimado Original)
  • Riesgos mayores que sucedieron (Técnicos, Personas, Eventos No Planeados)
  • ¿Cuáles son los tipos de riesgos más difíciles de tomar?
  • ¿Podemos proyectar eventos malos?
  • Entre otros

El autor del juego es Timofey Yevgrashyn, un agilista de Europa del Este, Gerente Ágil con experiencia en consultoría, coaching y entrenamiento. Timofey  tiene experiencia en el lanzamiento y liderazgo de transformaciones Ágiles/Lean que conducen a alinear las entregas con los objetivos del negocio. Hasta este año (2016) ha ayudado a más de 50 equipos de más de 10 países y ha completado cerca de 3000 horas de entrenamiento Ágil a más de 4000 personas. ¡Eso es estar en el campo de batalla!

Timofey se basó en su trabajo pragmático y en sus entrenamientos para diseñar este fabuloso juego, además de otros que pueden encontrar en su blog que escribe desde 2009 en lengua Rusa “The Improved Methods” (http://tim.com.ua). Conocí el juego y lo he jugado con algunos equipos mixtos de personas con mediana, poca o ninguna experiencia en Scrum y los resultados han sido grandioso. Por eso hablé con Tomofey para que trabajáramos juntos en la versión del juego en español y el resultado ya está aquí.

Mientras él termina de implementar un sitio exclusivo para el juego, pueden encontrar la versión en español su sitio actual:

En la sección Переводы. No se preocupen, si no saben ruso, se trata de la sección Translations (Traducciones).

O directamente en: http://bit.ly/ScrumCardGameES

Descarguen el juego con las tarjetas coloridas imprimibles y no dejen de contarme en el foro, más abajo, sus experiencias con el mismo.

jueves, junio 16, 2016

Purga ágil de producto

Nuestro backlog del producto puede no tener una “buena salud”. Es decir, puede contener elementos que lo oscurezcan o que disminuyan su transparencia. Por lo general estos elementos tienden a ir hasta el fondo del backlog y muchas veces no son detectados hasta que es muy tarde en el proyecto, trayendo como consecuencia la extensión innecesaria del esfuerzo de desarrollo y la desmotivación del equipo debido a la gran capacidad energética que sus miembros invierten en estos elementos de poco o ningún valor para el producto y para el negocio.
Una de las técnicas que podemos aplicar al backlog y, por consiguiente, al producto, es esta de la purga del producto. Los detalles de cómo hacerlo lo encuentran en mi artículo en Pulse de LinkedIn:

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. 

jueves, enero 14, 2016

Nexus, el exoesqueleto de desarrollo a escala con Scrum


Scrum es un marco de trabajo para desarrollar sistemas complejos. Como dice la Guía Oficial, es liviano, fácil de entender, pero quizás, después de un tiempo, con el acompañamiento adecuado, hayas sido capaz de llegar a dominarlo y tú y tu organización se encuentren en el camino de las entregas frecuentes de software con valor, del mejoramiento continuo vía retrospectivas, con equipos autoorganizados, donde las decisiones frecuentes de adaptación se basan en el conocimiento ganado vía la inspección y la experiencia. Después de todo, la autoorganización y el empirismo constituyen la doble hélice del DNA de Scrum.
Pero ¿cómo ha sido tu experiencia al querer dar el siguiente paso: escalar Scrum? Quizás has intentado SAFe, LeSS o el soberbio modelo de Spotify, para mencionar solo algunos de los ejemplares que prometen llevar con éxito la agilidad a toda la organización. ¿Cómo ha sido tu experiencia al intentar que múltiples equipos trabajen en un producto? O Quizás múltiples equipos trabajando en productos individuales o en una suite de productos integrados. ¿Qué tal toda la organización tratando de adoptar Scrum y otras prácticas ágiles? ¿Acaso has intentado una transformación organizacional de 180º hacia Ágil? Una que sea sostenible, es decir, un cambio que sea capaz de conservarse y reproducirse sin necesidad de apoyo o intervención externa.
Nexus™ – Un Exoesqueleto para 3-9 Equipos Scrum.
De eso se trata Nexus, “un marco de trabajo que consiste en roles, eventos, artefactos y técnicas que vinculan y entrelazan el trabajo de aproximadamente tres a nueve equipos de Scrum que trabajan en una sola Lista de Producto para construir un Incremento Integrado que cumpla un objetivo”.
Para entender Nexus, primero debemos entender de qué se trata el desarrollo de software a escala con Scrum: cualquier implementación de Scrum donde múltiples Equipos Scrum construyen un producto o un conjunto de características de un producto en uno o más Sprints o, también, cualquier implementación de Scrum donde múltiples Equipos Scrum construyen múltiples productos relacionados o conjuntos de características de productos en uno o más Sprints.
En el caso de múltiples equipos construyendo un producto, este tiene una Lista de Producto manejada por un Dueño de Producto y los equipos en conjunto crean un Incremento Integrado en cada Sprint por lo menos. Este Incremento se convierte en el foco y objetivo de todos los equipos dejando de lado el énfasis en el incremento individual que produce cada equipo en un Sprint.
Es precisamente la integración del trabajo (o la ausencia de esta), uno de los mayores obstáculos que encuentran las organizaciones al escalar Scrum o al tratar de implementar Scrum a gran escala. Para sobrepasar este impedimento, Nexus aumenta Scrum de manera orgánica, es el siguiente paso natural. Si has entendido y estás practicando Scrum, Nexus te parecerá más que familiar. Este nuevo marco de trabajo adiciona un nuevo rol, el Equipo de Integración Nexus, responsable de asegurar que se produzca el Incremento Integrado, es decir,  el trabajo combinado de un Nexus que adhiere a la definición de “Terminado”.
Además, Nexus adiciona un conjunto de eventos que, en general, extienden los eventos de Scrum o los reemplazan, lo mismo que un artefacto adicional:
Construido sobre los principios, valores y fundamentos de Scrum, el marco de trabajo Nexus:
  • Crea rutas de comunicación
  • Extiende y profundiza los mecanismos de inspección y adaptación
  • Fomenta la transparencia continuada
  • Depende de la inteligencia hacia arriba, en este caso, del Equipo de Integración Nexus hacia los equipos individuales que forman el Nexus.
Con mis grandes amigos Leonardo Agudelo y Jorge Abad tuve la oportunidad de traducir al español la Guía de Nexus, la misma que ya está publicada y disponible para descarga inmediata en:
Nota: este artículo se publicó por primera vez en diciembre de 2015 en Pulse de LinkedIn:
https://www.linkedin.com/pulse/nexus-el-exoesqueleto-de-desarrollo-escala-con-scrum-luis-antonio
------------------------------
Actualización 20150406:
Esta noche estuve hablando de Nexus con amigos de la Comunidad Ágiles Colombia en Medellín. Aquí está la presentación:

------------------------------
Actualización 20151007 (Ágiles 2016):
Hoy estuve hablando de Nexus con amigos de la Comunidad Ágiles Latinoamérica en Quito, durante las Jornadas Ágiles Latinoaméricanas - Ágiles 2016, una experiencia gratificante. 
Aquí está la presentación actualizada:



miércoles, octubre 28, 2015

El enfoque Iterativo e Incremental, ¡una vez más!


El enfoque Iterativo e Incremental, ¡una vez más!
Mucho se habla de esto, de hecho iba a titular este artículo: “Todavía otra lección más sobre el enfoque iterativo e incremental para construir productos (de software)” pero entonces pensé en cambiar ligeramente la dirección del tema… Pero no tanto.
Iterativo e incremental son de esos principios que pueden resultar artificiosos para quienes intentan aplicarlos por primera vez. Su interpretación se  presta a confusiones y a desacuerdos y finalmente los productos que surgen de los así llamados ‘proyectos iterativos e incrementales’ terminan siendo una colcha de retazos, pedazos de funcionalidades que no se integran bien entre sí y que terminan ocasionando más problemas al usuario de los que intentan resolver.
En breve, ‘iterativo’ quiere decir ‘en períodos cortos de tiempo’. El término clave es ‘cortos’. ¡De menos de un mes, gritamos a los cuatro vientos los agilistas! Durante este período se diseña y se construye, en el sentido extenso de la expresión ‘diseñar y construir’, una parte del producto que llamamos ‘incremento’. Pero no es cualquier parte del producto la que se construye. Sin embargo no voy a detenerme mucho en ello. Pueden consultar más sobre ‘Iterativo e Incremental’ aquí, gracias a Javier Garzás, o en cualquiera de estos lugares:
O algunos de los míos:
Entre muchos otros. Y no puedo terminar esta breve presentación del tema sin referirme a esa imagen que ya se está convirtiendo en icónica y que ilustra muy bien este par de conceptos: se trata de la imagen de Henrik Kniberg, actualizada:

Pero a dónde verdaderamente quiero llegar esta vez es a este asunto del ‘Incremento de Valor’, ¿qué quiere decir eso realmente? Así que empecemos de nuevo:

El Nuevo Nuevo Enfoque Iterativo e Incremental y de Valor

Resuelta la trama de ‘Iterativo e Incremental’, lo que queda es entender qué significa ‘producto de Valor para el cliente o usuario’, qué significa ‘Desarrollo de producto dirigido por el Valor’. Vamos a ver si lo logramos entender:
En este enfoque, conocido también como ‘desarrollo guiado por el valor’ o VDD, por sus siglas en inglés, el cliente o usuario juega un papel primordial:
  • Es el cliente o usuario del producto quien determina o establece su valor, no el equipo de desarrollo
  • Es el usuario o cliente quien solicita el producto, o esa porción del producto, es decir, fue ese usuario o cliente quien priorizó el desarrollo de ese incremento en ese momento del tiempo (del proyecto)
  • El incremento resuelve un problema pequeño o parte de un problema grande al usuario
  • Le permite obtener retorno de la inversión que está haciendo (ROI): reduce los costos para el negocio o aumenta las ganancias… ¡o ambas cosas a la vez! En últimas, al entregar el producto hay o se genera una compensación para el usuario, además de la satisfacción aumentada y de la felicidad recargada, no solo de él como receptor de un objeto de valor, sino de todo el equipo de desarrollo y, por qué no, de todos los demás interesados, dado el logro de objetivos.

Foto de FreeDigitalPhoto.Net
  • Varias o muchas personas se benefician de inmediato con el producto (con su uso), ya sea porque lo están usando directamente (usuarios, clientes) o porque otros lo usan (patrocinadores, otros interesados, alta gerencia, etcétera)
  • El producto está diseñado para humanos, sus componentes hacen resonancia unos con otros e impactan el modus vivendi de las personas, aunque solo para mejorarlo
Human-driven development o HDD –Desarrollo de Software Para Personas. Foto de FreeDigitalPhoto.Net 
  • El riesgo del proyecto, inherente a cualquier tentativa de construcción de software, se reduce dramáticamente luego de las primeras entregas. Si hemos de fallar, que sea rápido, en porciones pequeñas y muy barato. A partir de allí, el ascenso hacia el logro de los objetivos es vertiginoso y siempre positivo.
  • El crecimiento del producto es orgánico, se parte de un mínimo producto viable o ‘mercadeable’ (MVP por sus siglas en inglés) y el producto completo va creciendo alrededor de este MVP, en entregas sucesivas y constantes. Y ya que llegamos a este apartado, olvidémonos del “viable” en el MVP, la V ahora es por Valor, como en Mínimo Producto de Valor. Recordemos que este MVP es el primer objeto con el que el cliente o usuario podrá interactuar, así que el impacto a conseguir debe ser máximo, debemos hacer que se convierta en un objeto de deseo. A propósito de deseo, entonces en vez de llamarlo MVP, nombrémoslo MDP, por las siglas en inglés de Mínimo Producto Deseable. Es un juego de palabras, apenas para mi Gazafatonario, pero ayudan a entender lo que queremos realmente con esta generación de valor desde las primeras de cambio.
  • Se disminuye considerablemente la incertidumbre, tanto la del proyecto como un todo, como la del producto que se empieza a usar. Esto ocurre porque con cada entrega el equipo conoce mejor a su usuario y aprende mucho más rápido de sus necesidades y ambiciones. A la postre, el equipo construye el software para aprender y medir el impacto del uso real del producto. Después de todo, el proceso de creación de conocimiento se acelera si ellos entregan rápido un conjunto mínimo de elementos del producto priorizados por los objetivos que el cliente quiere alcanzar.
No son las únicas condiciones, si acaso algunas de las más importantes. En cualquier caso, la próxima vez que te soliciten un plan de trabajo para un proyecto, ya sea a mediano o a largo plazo, ten el coraje de responder: ¿quieres un plan a mediano/largo plazo o Valor en términos cortos?
Nota: este artículo se publicó originalmente en Pulse de LinkedIn en el siguiente enlace: https://www.linkedin.com/pulse/iterativo-e-incremental-luis-antonio-salazar-caraballo