Buscar en Gazafatonario IT

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 (que 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 la sección de comentarios más abajo.

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)



sábado, julio 30, 2016

Un vistazo a la guía de Scrum

¿Hace cuánto leíste por última vez la guía de Scrum? Es bien sabido que a medida que tu experiencia y conocimientos crecen, tu forma de ver (leer) algo cambia respecto a la vez anterior. Quizás aprendas algo más, quizás seas capaz de visualizar o entender algo que antes no habías percibido o entendido.

Aprovechando la revisión de la que fue objeto la guía por parte de sus autores y de que había que traducir esa actualización, realicé una revisión exhaustiva tanto de la versión en inglés como de la versión en español en la que tuve la oportunidad de trabajar por primera vez en 2013. (Para conocer los cambios introducidos a la guía, ve a: http://www.gazafatonarioit.com/2016/07/revision-la-guia-de-scrum.html)

Con tres años más de experiencia y conocimiento en Scrum y temas relacionados, me tomé la libertad de actualizar la Gramática y redacción del documento y también algunos asuntos de fondo que me hacían ruido desde hacía mucho tiempo respecto a la versión original de la guía en inglés.

Con todo esto, aproveché también para “repasar” lo que dice la guía, para mirarla más a fondo y decidí traer aquí una lista, arbitraria por demás, pero de todo mi gusto, de algunos puntos que quiero resaltar. Son los siguientes:
“Scrum no es un proceso o una técnica para construir productos; en lugar de eso, es un marco de trabajo dentro del cual se pueden emplear varios procesos y técnicas”.
Es impresionante la cantidad de personas, equipos y organizaciones que solo “aprenden” o quieren aprender Scrum, como si con eso fuera suficiente para hacer todo el trabajado que se les viene por delante. La lista de proceso, técnicas, marcos de trabajo y prácticas que podemos y deberíamos usar con Scrum es extensísima, no voy a elaborarla aquí, pero lo que sí es cierto, lamentándolo mucho por quienes no lo han visto, es que Scrum solo no es suficiente.
“Scrum muestra la eficacia relativa de las prácticas de gestión de producto y las prácticas de desarrollo de modo que podamos mejorar”.
Scrum se basa en la teoría empírica  de control de procesos. Esto quiere decir básicamente que aprendemos de la experiencia. Scrum nos permite visualizar la eficacia las prácticas que usamos las personas, los equipos y las organizaciones y nos permite inspeccionarlas continuamente y adaptarlas y adaptarnos de acuerdo con los distintos escenarios circundantes.
“El Dueño de Producto es la única persona responsable de gestionar la Lista del Producto”.
Todavía me encuentro con muchos equipos y organizaciones que no terminan de integrar al negocio, vía el Dueño de Producto, en sus equipos. Y muchos menos son los Dueños de Producto que realmente actúan como tal. El muy comentado pero pocas veces entendido “backlog” de producto sigue siendo gestionado por el equipo y muchas veces solo por el Scrum Master o por alguien más que no es ninguno de los roles propuestos en la guía.
“El Scrum Master es el responsable de asegurar que Scrum se entienda y se adopte. Los Scrum Masters hacen esto asegurándose de que el Equipo Scrum trabaja ajustándose a la teoría, prácticas y reglas de Scrum”.
Usar Scrum no nos hace ágiles, eso lo tenemos claro muchos. Pero muchos no tienen claro que si vamos a usar Scrum como marco de trabajo ágil, debemos ajustarnos a las reglas enumeradas en la guía. Estas reglas condensan la experiencia de muchos años de trabajo, sobre todo en proyectos de software, de los autores y de muchos otros en la industria. Conjuguemos esta observación con la del primer punto más arriba.
“La Planificación de Sprint tiene un máximo de duración de ocho horas para un Sprint de un mes. Para Sprints más cortos el evento es usualmente más corto”.
En las versiones anteriores es español aquí decía que el tiempo de las reuniones era proporcional a estas ocho horas para sprints más cortos. En ninguna parte de la guía original en inglés dice así, de tal forma que la actualicé en este sentido.
“Al finalizar la Planificación del Sprint, el Equipo de Desarrollo debería ser capaz de explicar al Dueño de Producto y al Scrum Master cómo pretende trabajar como un equipo autoorganizado para lograr el Objetivo del Sprint y crear el Incremento esperado”.
¿Cuántos de los equipos en los que has trabajado, en los que eres Scrum Master, miembro del Equipo o Dueño de Producto, hacen esto? De hecho, muchos quieren terminar lo más rápido posible la planificación para ponerse a trabajar pero nadie es capaz de explicar cómo van a trabajar para lograr la meta trazada del Sprint.
“El objetivo del Sprint puede representar otro nexo de unión que haga que el Equipo de Desarrollo trabaje en conjunto y no en iniciativas separadas”.
Es más, muchas veces los equipos no establecen un objetivo más allá de aquel que indica el número de historias de usuario a construir en el sprint. La meta del Sprint debería ser algo más de Valor para el Dueño de Producto y, por ende, para el negocio. Dejaré este asunto de la meta del sprint para otro artículo pero además de pensar en las características o funcionalidades a implementar siempre es bueno pensar en las razones para llevar a cabo la iteración. Bien sabemos que metas efectivas nos sirven para probar o demostrar que nuestras ideas funcionan, para fomentar el trabajo en equipo, para reducir o eliminar un riesgo específico o para proporcionar mayor valor entregado al negocio.
 “El Equipo de Desarrollo o los miembros del equipo a menudo se vuelven a reunir inmediatamente después del Scrum Diario, para tener discusiones detalladas, o para adaptar, o replanificar el resto del trabajo del Sprint”.
La expresión clave aquí es “a menudo”. Hacer otras cosas después de la reunión diaria puede hacernos perder foco y, por consiguiente, productividad y puede alejarnos de la consecución del objetivo del sprint. Por ejemplo, en la reunión diaria no hablamos de las soluciones a los impedimentos, entonces es buena idea tener reuniones específicas sobre estos asuntos justo después de aquella.
“El Scrum Master se asegura de que se cumpla la regla de que solo los miembros del Equipo de Desarrollo participan en el Scrum Diario”.
Sigo viendo mucho de comando y control en la reunión diaria. ¡El seguimiento diario, dicen algunos! Esta es una reunión de coordinación, de planificación, es precisamente “una reunión clave de inspección y adaptación”. Cualquier otra cosa que se requiera hacer con el equipo, debe ser en otra reunión especial, no en esta.
“Durante la Revisión de Sprint, el Equipo Scrum y los interesados colaboran acerca de lo que se hizo durante el Sprint. Basándose en esto y en cualquier cambio a la Lista de Producto durante el Sprint, los asistentes colaboran para determinar las siguientes cosas que podrían hacerse para optimizar el valor”.
La Revisión de Sprint no es solo para hacer la demostración del incremento de producto terminado. Y puesto que a esta reunión asisten o pueden asistir interesados clave en el producto, es una oportunidad única para discutir lo que viene a continuación en el proyecto.
“Una Lista de Producto nunca está completa. Mientras el producto exista, su Lista de Producto también existe”.
“Aceptamos que los requisitos cambien, incluso en etapas tardías del desarrollo. Los procesos Ágiles aprovechan el cambio para proporcionar ventaja competitiva al cliente”. ¿Hace falta decir algo más?
“Los elementos de la Lista de Producto tienen como atributos la descripción, el orden, la estimación y el valor”.
El valor para el negocio. Noten además que hablamos de “los elementos de la lista”, no son solo historias de usuario, como muchos erróneamente creen y manifiestan.
“Scrum no reconoce subequipos en los equipos de desarrollo, no importan los dominios particulares que requieran tenerse en cuenta, como pruebas o análisis de negocio; no hay excepciones a esta regla”.
No existe tal cosa como “ellos y nosotros”, somos un único equipo indivisible, somos una unidad morfológica (orgánica) y funcional y actuamos como tal. Valoramos las habilidades y fortalezas de cada uno de los miembros de esta unidad, pero hacia el mundo exterior somos El Equipo.


Y bueno, como dice mi amigo y colega Jorge Abad, hasta aquí estas reflexiones, viscerales por demás, sobre la guía de Scrum. Los invito a que la descarguen y vuelvan a leerla y a que nos cuenten en el foro cuáles son sus puntos favoritos de la guía, con cuál no están de acuerdo, cuál cambiarían, etcétera.

También pueden descargar la guía de:

Guía de Scrum en español

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 grandiosos. 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).

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

miércoles, julio 06, 2016

Revisión a la Guía de Scrum

Actualización 2016/07/23. Ya está disponible la versión en español de la guía actualizada de Scrum. La encuentran en la página oficial de la Guía (http://www.scrumguides.org/download.html), en la sección correspondiente a "Spanish (July 2016)" o buscan en la página la secuencia de caracteres "Lucho Salazar".

Recuerden, si tienen alguna observación sobre la traducción, comenten en el foro (más abajo) o escríbanme a lucho.salazar@gmail.com.

¿Qué te parece la inclusión de los valores Scrum a la guía? ¿Por qué crees que Refinamiento sigue sin ser una ceremonia formal en Scrum? Comenta sobre estos y otros aspectos en el foro.

******************************************************************************

Estos son los cambios presentados a la Guía Scrum por Ken Schwaber y Jeff Sutherland este 6 de julio de 2016.

******************************************************************************
Los Valores de Scrum

Cuando el Equipo Scrum incorpora y vivencia los valores de compromiso, coraje, foco, apertura y respeto, los pilares Scrum de transparencia, inspección y adaptación se materializan y fomentan la confianza en todo el mundo. Los miembros del Equipo Scrum aprenden y exploran estos valores a medida que trabajan en los eventos, roles y artefactos de Scrum.

El uso exitoso de Scrum depende de que las personas lleguen a ser más virtuosas en la convivencia con estos cinco valores. Las personas se comprometen de manera individual a alcanzar las metas del Equipo Scrum. Los miembros del Equipo Scrum tienen coraje para hacer bien las cosas y para trabajar en los problemas difíciles. Todos se enfocan en el trabajo del Sprint y en las metas del Equipo Scrum. El Equipo Scrum y sus interesados acuerdan estar abiertos a todo el trabajo y a los desafíos que se les presenten al realizar su trabajo. Los miembros del Equipo Scrum se respetan entre sí para ser personas capaces e independientes.

******************************************************************************

La guía ya está disponible en ingles en http://www.scrumguides.org. Muy pronto estará en español (¡hace varios días envié la actualización!) y en otros idiomas.

domingo, junio 26, 2016

¡El tamaño sí importa!


Vamos al grano. Si la mayoría de tus historias de usuario llegan a “Terminado” apenas unas pocas horas antes de la Revisión del Sprint, todavía pueden ser más pequeñas. Tu equipo debería tener historias tan pequeñas que las puedas finalizar durante las primeras horas o días del Sprint, dependiendo de la duración de este. Así te aseguras desde las primeras de cambio que el equipo está siendo productivo, está enfocado y que van a entregar valor al final de la iteración. ¡Después de todo, finalizar una tarea aumenta la moral del equipo!
Aunque el objetivo de un Sprint no debe medirse en número de historias de usuario a terminar (implementar), sino al cumplimiento de un objetivo específico, siempre es mejor “prometer” o planear terminar varias historias pequeñas o muy pequeñas que muy pocas historias medianas o grandes.
Es evidente: si tienes 10 historias en tu lista de pendientes del sprint (alias el backlog del sprint), y no terminas 2, es mucho mejor que si solo tienes 4 y terminas 2. En ambos casos fallaste en el mismo número de historias, pero en el primer escenario tuviste un acierto del 80% mientras que en el segundo apenas llegaste a la mitad de la promesa del sprint. El resultado es menos alentador si las historias terminadas son dos de 3 puntos y dejaste sin terminar o aun a punto de terminar dos historias de 13. Solo cumpliste con 6 de los treinta puntos que prometiste.
Hablando de puntos, una buena medida, algo que me ha funcionado casi siempre, es implementar historias cuyo puntaje no sobrepase entre una décima parte y una sexta parte de la velocidad del equipo. Es decir, si la velocidad del equipo de desarrollo es 30 puntos por Sprint, las historias a implementar no deberían ser más grandes de 3 a 5 puntos. Historias de ½, 1 y 2 puntos siempre son bienvenidas en este escenario.
Ahora bien, el tamaño de las historias es un concepto relativo. Un equipo de 7 o 9 personas no ve igual una historia de usuario en un sprint de 3 o 4 semanas que un equipo de 3 o 5 personas en un sprint de 1 o 2 semanas. Pero algo en lo que todos estamos de acuerdo es que, una vez terminadas, las historias deben proporcionar valor al negocio. Las cosas así, otro indicador de “pequeño” es Pareto.
El objetivo siempre es encontrar ese 20% de la historia (de funcionalidades que se van implementar vía esa historia) que genere o entregue el 80% del valor total de la misma. A partir de allí, la división se hace de manera orgánica, adicionando historias al backlog de producto que complementen la historia de “más valor”.
También ayuda el nivel de entendimiento de toda la historia y qué tan rápido llegamos a entenderla por completo. Un índice de que quizás la historia no es pequeña es que no la hemos terminado de entender, quizás no están claros algunos de los criterios de aceptación o hay nubes en la conversación (la c de conversación de la historia) relacionadas con los requisitos funcionales o no funcionales a implementar.
El Principio de Sweepnoise, de mi amigo Leonardo Agudelo, ilustra muy bien este punto:


Finalmente, no solo la S de INVEST indica que la historia es pequeña (Sucinta). Un indicativo de que quizás no lo es tanto, es que  algunas partes de la misma (o toda la historia) no sean negociables o que no haya consenso en su estimación o que tengamos dudas acerca de si es posible conducirla a través de un proceso que nos asegure la calidad del producto terminado o de que incluso tenga dependencias con otra(s) historia(s).

Comparte conmigo y con los demás lectores del blog lo que piensas sobre este asunto del tamaño, ¿importa? ¿No importa? ¿Qué haces habitualmente para dividir tus historias de usuario? Cuéntanos tus heurísticas.
---------------------------------------------------------------------------------------------------------------
Para saber más sobre historias de usuario, puedes leer mi artículo introductorio:
Historias de Usuario: un nuevo orden en los requisitos del software:
http://www.gazafatonarioit.com/2013/07/historias-de-usuario-un-nuevo-orden-en.html

Para saber más de los criterios INVEST de las historias de usuario puedes leer mi serie de artículos sobre el asunto.
La serie de artículos "Escribiendo Historias de Usuario Altamente Efectivas":
Escribiendo Historias de Usuario Altamente Efectivas, 1 - Introducción
Escribiendo Historias de Usuario Altamente Efectivas, 2 - Independiente
Escribiendo Historias de Usuario Altamente Efectivas, 3 - Negociable
Escribiendo Historias de Usuario Altamente Efectivas, 4 - Valiosa (y Valuada)

Y este otro:

De historias de usuario, culturas y del arte de narrar historias


También puedes visitar el blog Lecciones Aprendidas de mi amigo Jorge Abad:
Video de explicación: Cómo se construyen historias de usuario
Ejemplo: Una historia de usuario - Listado de Morosos
Ejemplo de historia de usuario : Ingreso al sistema
http://www.lecciones-aprendidas.info/2015/03/ejemplo-de-historias-de-usuario-ingreso.html

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:

miércoles, junio 01, 2016

Los Pilares de Scrum

Los Pilares de Scrum. Clic en la imagen para ampliar.

Sin ninguna duda, para que Scrum sea eficiente y efectivo, cada uno de estos pilares debe estar en pie, deben promoverse desde las personas y los equipos hasta toda la organización y deben apoyarse sin restricciones. Sin uno o más de estos pilares, cualquier implementación de Scrum está condenada a un cataclismo anunciado.

Déjame saber en el foro como te ha ido con la puesta en macha de estos pilares mientras implementas Scrum en tu organización.

Puedes descargar el PDF de la imagen en alta resolución haciendo clic aquí.

O me la solicitas a mi correo: lucho.salazar@gmail.com.



martes, abril 26, 2016

Del triángulo de hierro al triángulo ágil extendido


Las empresas en período de transformación organizacional se enfrentan a la dicotomía de seguir paradas sobre el triángulo de hierro en lo que se refiere a planificación y gestión de proyectos de software o moverse a una zona que en principio se les parece más al Triángulo de las Bermudas que al área de confort por donde han transitado durante las últimas décadas.

De lo más valioso que hemos aprendido en el desarrollo de software es que muchas de las prácticas y técnicas usadas desde aquella histórica reunión del Comité Científico de la OTAN en 1968 en la ciudad de Garmisch, Alemania y que diera inicio a la Ingeniería de Software como profesión, fueron tomadas a manera de préstamo de otras áreas de la ingeniería y de otras ciencias aplicadas.

Algunas de esas prácticas influyeron directamente en la forma de realizar estimaciones y de planificar proyectos de software. Específicamente, hemos aprendido que no podemos estimar ni planificar proyectos de software como lo hacen en proyectos de la industria de la construcción… ¡a no ser que vayamos  a usar piezas de Lego® para construir ciudades!


Afortunadamente ya sabemos con certeza que la ingeniería de software tiene su propia personalidad. Se trata de un sello que la hace única y que hace que sus practicantes se distingan del resto de profesionales de la ingeniería y de otros cuerpos de conocimiento. Por ejemplo, en su libro Agile Project Management, Jim Highsmith[1] sugirió que si aplicamos el enfoque Ágil al Triángulo de hierro encontraríamos los siguientes vértices:
  • Valor, para el usuario en términos de un producto que se pueda distribuir y cuyo uso genere beneficios para la organización.
  • Calidad, para entregar continuamente valor al usuario en términos de un producto confiable y adaptativo.
  • Restricciones, los ya tradicionales alcance, tiempo y costo, en donde, si movemos uno, usualmente el primero, se mueven los otros dos.
Como dice el mismo Highsmith [2], las restricciones siguen siendo parámetros importantes de un proyecto pero no constituyen el objetivo del mismo. En cambio, el Valor y la Calidad establecen la meta del proyecto y las restricciones mencionadas se ajustan a medida que el proyecto incrementa el valor para el usuario. En particular, El tiempo podría seguir siendo una restricción fija pero entonces el alcance debería ajustarse para entregar el valor más alto posible dadas las restricciones impuestas.


Como nos gusta lo visual, esta otra versión del triángulo ágil de Highsmith nos llega más:


Más allá de este enfoque de planificación y de gestión de proyectos (ágiles), quienes ya hemos trasegado algunos años por los vericuetos, subido a los riscos y caminado por los valles complejos del desarrollo ágil de software, sabemos que todo momento es una oportunidad de mejorar: de mejorar como personas y como profesionales, de mejorar los procesos y las técnicas, de mejorar la calidad de los productos y de incrementar el valor que estos entregan a nuestros usuarios. ¡Es la mejora continua!

Ahora bien, la mejora continua junto al valor y a la calidad forma otro vértice del triángulo, el del resultado. A los agilistas no nos interesa simplemente crear un producto, por más disruptivo o benéfico que este sea. Nos interesa pensar en lo que viene, en lo que llevará al cliente al próximo nivel de optimización, satisfacción y felicidad.

Pero lo más importante en todo proyecto, en todo proceso de innovación o mejoramiento, en todo plan que tenga como propósito el diseño y la construcción de productos (de software), son las personas: la comunicación cara a cara entre ellas, la motivación de todos los individuos que intervienen en el proyecto, la atención continua a la excelencia técnica, la autogestión del equipo y la confianza que la organización deposite en ellas se constituyen en las bases del éxito de cualquier iniciativa que requiera generar nuevos productos o servicios.

Las cosas así, podríamos entonces encontrarnos con esta nueva versión del triángulo ágil:



Referencias:

[1] Highsmith es uno de los 17 firmantes del Manifiesto Ágil