Buscar en Gazafatonario IT

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

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

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

viernes, septiembre 11, 2015

Gerencia de Proyectos Iterativos: de cómo el software se puede construir por incrementos

Divide et impera: ‘divide y vencerás’. Frase atribuida a Julio César.
FreeDigitalPhoto.Net
Los proyectos de construcción de software deben responder con prontitud a los cambios frecuentes e inesperados tanto en los requisitos del negocio como en la tecnología de implementación. Es habitual que en estos proyectos haya una gran incertidumbre en cuanto al alcance, a la fecha de entrega y al presupuesto requerido, lo que conlleva un alto número de riesgos que obstaculizan la consecución de los objetivos propuestos.
Por ejemplo, es un grave error con consecuencias atroces, asumir que los usuarios –generalmente personas de mandos medios y altos– son capaces de suministrar al equipo del proyecto información oportuna y precisa de todos los requisitos para un sistema de software. Además, uno de los problemas principales de la construcción de software tradicional recae en el hecho de que quienes han estado involucrados en ello hasta la fecha no están dispuestos a reconocer que esta actividad es, la mayoría de las veces, un asunto de planeación ocupacional y organizacional.
Corresponde precisamente al gerente del proyecto lidiar con todos estos factores que entorpecen la evolución normal de un proyecto de software. Es el gerente del proyecto quien sabe que los procedimientos tradicionales seguidos tienen un conjunto de riesgos tácitos “indetectables” dada la propia naturaleza del ciclo de vida de los proyectos. Los proyectos iterativos propician la detección temprana de los riesgos y facilitan su manejo anticipado por parte de los responsables. Pero ¿qué es realmente un proyecto iterativo? Para entenderlo, veamos lo fundamental.
¿Qué es una Iteración?
Una iteración es un mini-proyecto con una salida bien definida: una versión incrementada, estable, probada e integrada del producto de software, con su documentación asociada.
Esta definición lleva implícito un concepto muy importante: la versión o porción de software que se produce en una iteración tiene tales cualidades que se podría no solo mostrar al usuario sino poner en producción. De hecho, en fases avanzadas del proyecto, esto ocurre con regularidad; es decir, en un proyecto iterativo es posible tener versiones del software funcionando antes de terminar el proyecto.
Características de las Iteraciones
Ahora bien, como cualquier proyecto (de software), una iteración pasa por todas las etapas de un proyecto tradicional: inicio, planeación, ejecución y control, y cierre. En el caso particular de los proyectos de software, durante la etapa de ejecución y control de una iteración encontramos el ciclo tradicional del software: modelado de requisitos, análisis y diseño, implementación, pruebas, integración y, opcionalmente, despliegue, aunque una iteración no necesariamente cubre todas las etapas.
Pero la verdadera esencia de las iteraciones radica en otros aspectos que buscan disminuir la incertidumbre en los proyectos, aumentar el desempeño, mitigar los riesgos, sobre todo reducir los riesgos técnicos en las primeras iteraciones, y recibir retroalimentación continua y efectiva de los usuarios. El primero de estos aspectos es la duración de las iteraciones: de unos pocos días hasta unas pocas semanas es lo más eficaz, aunque también depende del tamaño del equipo y de la duración total estimada del proyecto.
Figura 1: esquema de una iteración típica. Cada iteración es un mini-proyecto con todo lo que ello implica.
Excepto quizás en proyectos grandes con más de 40 o 50 personas, la idea es no tener iteraciones de varios meses, ya que en ese tiempo puede ocurrir lo que sucede en los proyectos ejecutados en cascada: hay poca o ninguna mitigación de riesgos técnicos, puesto que no hay entregas “visibles” para los usuarios, recibimos poca retroalimentación de ellos y así no medimos eficientemente el progreso del proyecto, o no podemos reaccionar a tiempo ante una mala decisión técnica que conduzca a un retraso en el proyecto.
Duración de las iteraciones
Número de personas
Duración
2 a 15
2 a 4 semanas
15 a 30
4 a 6 semanas
30 a 50
6 a 8 semanas
Fuente: Bittner, K. Spence, I. Managing Iterative software Development Projects. Addison Wesley Professional. Junio 27, 2006.
Otro aspecto importante es que la duración de las iteraciones no tiene que ser la misma, pero la desviación debe ser pequeña. La idea es no tener iteraciones de dos semanas y otras de seis o más. Scrum, una metodología ágil ampliamente usada hoy día, por ejemplo, promulga iteraciones de 30 días, llamadas Sprint, con equipos de menos de 10 personas. Y ya que menciono Scrum, me parece importante aclarar que no todos los proyectos iterativos son ágiles, pero todos los proyectos ágiles son iterativos; la iteración es una propiedad intrínseca de las metodologías ágiles de construcción de software.
Gestión iterativa de proyectos
Otra de las características principales de este tipo de proyectos es que en las primeras iteraciones se construye la porción de producto que es significativa para la arquitectura del software. El gerente del proyecto se apoya en el arquitecto y en los ingenieros de requisitos para tomar la decisión de cuántas iteraciones “arquitectónicas” tendrá el proyecto, normalmente de 1 a 3, y qué funcionalidad será implementada, de tal manera que al final de esta fase (llamada de Elaboración, de Planeación o de Arquitectura, según la metodología que se use), no solo existe un documento de arquitectura o de diseño de alto nivel, sino que hay software funcionando cuyo propósito es demostrar que esa es la arquitectura correcta para el producto.
Figura 2: Perfil de los riesgos durante la gestión iterativa de proyectos. Los riesgos técnicos disminuyen en las primeras iteraciones. Contrario a lo que sucedía con el método en cascada, donde los riesgos disminuían al final del proyecto, durante las pruebas en el mejor de los casos.
La gestión iterativa de proyectos puede tomar muchas formas, dependiendo de las metas del proyecto: el desarrollo iterativo de prototipos puede ayudar a evolucionar una interfaz de usuario. El desarrollo ágil es una forma de involucrar muy de cerca un usuario en un proceso que podría repetirse diariamente. Entre tanto, el desarrollo incremental permite al equipo del proyecto a producir incrementos semanales o en cortos períodos de tiempo, mientras que un modelo en espiral puede ayudar al equipo a confrontar y a mitigar los riesgos de un producto en evolución.
En estos casos es el gerente del proyecto quien toma la decisión de la estrategia a seguir, teniendo en cuenta el valor de distintas variables: tamaño del proyecto, tamaño del equipo, experiencia del equipo y de los usuarios, criticidad y complejidad del proyecto, los riesgos técnicos y administrativos, el grado de volatilidad detectada de los requisitos y las herramientas de apoyo disponibles.
Foto de FreeDigitalPhoto.Net
La gestión iterativa ayuda a superar las barreras de especificación y de comunicación entre los usuarios y el equipo de trabajo con el único objetivo de alcanzar la más alta satisfacción de los primeros. El factor clave es precisamente que las personas del negocio entiendan los requisitos y retroalimenten a las personas de tecnología. En este apartado, el papel del gerente es de mediador, por lo que debería incluir elementos de comunicación efectiva, como la tolerancia –cuando no se confunde con la pasividad–, la imparcialidad y la empatía, para construir confianza y disciplina entre unos y otros.
Corresponde al Gerente del Proyecto integrar el equipo de trabajo con todos los involucrados tanto internos como externos y la gestión iterativa posibilita una integración paso a paso. Para lograrlo, el gerente del proyecto debe tener en cuenta algo que está fuera de su control: una infraestructura cambiante y un proceso de negocio inestable. También se debe vincular la estructura del proyecto (iterativo) con el éxito del proyecto, de esta forma, no habrá espacio para la ruina del proyecto.
Esto se logra mediante la motivación interna del equipo de trabajo, el desarrollo de competencias blandas (negociación, técnicas de comunicación –escrita, verbal y no verbal–, manejo eficaz del tiempo, creatividad, trabajo en equipo, entre otras) y la “implantación no invasiva de chips de alta efectividad”, como la proactividad y la sinergia.
Ahora bien, puede haber muchas desviaciones de un plan de proyecto de desarrollo de software. En estos casos, el gerente de proyecto decide cómo manejarlas, puesto que cada retraso requiere de una acción de su parte. Sin embargo, las opciones del gerente son muchas veces limitadas y una de las estrategias que puede seguir es esta de la agenda iterativa. Esto permite corregir o ajustar los planes de trabajo a medida que se desvían de las medidas iniciales.
Por ejemplo, si una iteración toma más tiempo del programado debido a un problema técnico que el equipo del proyecto tardó en responder o a la toma de una decisión por parte del usuario, el gerente puede reprogramar las iteraciones subsiguientes de tal forma que el plan original global del proyecto no se vea afectado.

En cualquier caso, todas las formas de gestión iterativa proporcionan una manera de:
  • Integrar y validar la evolución del producto continuamente
  • Demostrar progreso en cortos períodos de tiempo
  • Alertar pronto al equipo del proyecto de los problemas suscitados
  • Entregar funcionalidad de manera temprana
  • Incorporar sistemáticamente el re-trabajo inevitable que ocurre en el desarrollo de software

En resumen, la gestión Iterativa de proyectos facilita procedimientos para el desarrollo exitoso de aplicaciones y minimizan tanto los riesgos como los costos, combinando técnicas de administración bien estructuradas de métodos en cascada con técnicas de validación temprana del modelo evolutivo. Este proceso es más adaptable a situaciones diversas en proyectos de software y da al gerente la flexibilidad necesaria para acomodarse a un rango dinámico de alternativas técnicas.

Información
Este artículo fue publicado originalmente por la Revista de la Asociación Española de Profesionales en Dirección de Proyectos, en marzo de 2012. Para acceder al artículo original, pueden hacer clic aquí.

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:

martes, diciembre 16, 2014

Antipatrones Scrum: definición de la estructura


Sobre ScrumButs, seres humanos y otros menesteres terrenales de lo Ágil

El cambio es difícil, aceptar el cambio es aún más difícil, pero cambiar una cultura organizacional, arraigada en la estructura de las organizaciones y en el ADN de las personas, es quizás la tarea más compleja que un ser humano, o un grupo de personas, pueden emprender. Pero los cambios son necesarios y con estos vienen los sinsabores de la toma de decisiones erróneas, las que, en el caso de los métodos de desarrollo de software, son el equivalente de errores en la adopción de prácticas y métodos nuevos para la organización.

Durante la transición al enfoque ágil de construcción de software, muchas veces las organizaciones y las personas encargadas del cambio en las organizaciones deciden no seguir la línea descrita por las guías, los expertos o las prácticas documentadas por la industria, y se apartan de ello simplemente para adecuar su “nueva” forma de trabajo a las antiguas costumbres, a lo que es conocido y que costó tanto (tiempo, dinero, personas, recursos) implementar y que de alguna manera ha funcionado en la organización.

El término ScrumBut (ScrumPero) se usa para referirnos a los cambios a Scrum que se hacen para ocultar disfunciones y problemas que un Scrum no modificado revela a la luz del contexto donde suceden los hechos. Un ejemplo típico, de algunos presentados en [1], es: “Usamos Scrum, pero no podemos construir una pieza de funcionalidad en un mes, así que nuestros Sprints tardan 6 semanas” (o más). En este ejemplo, El ScrumBut es el uso de sprints de 6 semanas debido a la inhabilidad de la organización para dividir los requisitos en historias de usuario (o cualquier otra pieza que se use para representar funcionalidad del software) lo suficientemente pequeñas y simples.

El término (ScrumBut) implica que el cambio al método Scrum se debió a problemas en la organización, en vez de a problemas con el propio método Scrum. Pero ojo, no todos los cambios al método Scrum se consideran ScrumButs. Se considera aceptable cambiar las prácticas de Scrum si los cambios se basan en una necesidad real y en un entendimiento profundo de los mecanismos que hacen que Scrum funcione. Este último asunto es lo que constituirá la parte de “Excepción” del antipatrón.

Personas y sus interacciones sobre el mismísimo proceso Scrum y las herramientas que proporciona

Estamos de acuerdo en que Ágil es más acerca de las personas y sus interacciones, la comunicación cara a cara y la cultura, que acerca de los procesos, las prácticas y las herramientas, aunque nunca debemos cansarnos de repetir esto. Sí, las prácticas de Scrum son importantes y nos proporcionan guías inteligentes que nos ayudan a mejorar nuestra productividad y la calidad de lo que hacemos, pero son los principios – la parte difícil – los que hacen que Ágil sea sostenible en el largo plazo y los que nos permiten maximizar los beneficios que el método nos ofrece.

Así que cuando decimos que una mala práctica, un ScrumBut, es este de los sprints demasiado extensos, no vamos a arremeter contra la práctica en sí, lo que nos interesa es ir a los principios ágiles, esos del mismísimo Manifiesto Ágil y mirar que podemos hacer. ¡Eureka! Hay un principio que dice: “Entregamos software funcional frecuentemente…” [2], esto es lo que nos interesa. La entrega de productos, de alto valor para el cliente/usuario, priorizado por este, es lo que nos va a permitir obtener una mejor y más objetiva retroalimentación del estado de las cosas, nos hablará del grado de satisfacción del usuario, de su felicidad y de la calidad de ese producto.

Y esta entrega de software debemos hacerla desde el inicio del proyecto y manera frecuente, ¿cómo nos suena ‘cada 2 semanas’? De esta forma, si nos equivocamos, lo hacemos rápido, en 2 semanas, y barato, mucho más económico que si hubiésemos invertido meses de trabajo y muchas personas en esa porción del producto y del proyecto. Si nos equivocamos, todavía hay tiempo para reaccionar, decidir sobre acciones que nos hagan volver al “camino correcto”, que mejoren el estado de salud del producto/proyecto y de todos los interesados en el mismo.

Estudio a fondo de un Antipatrón: la estructura y el contenido

Todo este preámbulo, necesario por demás, para llegar al meollo del asunto. Vamos a intentar definir una primera versión de Antipatrón con el ejemplo que hemos venido mencionando a lo largo de este estudio. Es precisamente lo que me interesa porque en todo este recorrido de consulta sobre el tema he encontrado que la gran mayoría de los autores sobre mencionan el antipatrón, el scrumbut o la práctica dañina, algunos dan un paso más y mencionan una o dos recomendaciones de como curar la enfermedad. Pero en general, todos se quedan en el camino, no van más allá de mencionar una lista de prácticas incorrectas. Ahora que recuerdo, eso mismo hice yo en el primer artículo (acercamiento) de esta serie sobre antipatrones Scrum [3].

Pero muchas veces ayuda conocer el porqué del por qué, el problema detrás del problema, la causa raíz y con ello en la superficie, es un poco más liviano encontrar el camino de salida. Así que vamos al fondo de las cosas. Hagamos un acercamiento más detallado a un antipatrón, mejor dicho, entremos al núcleo de una mala práctica común.

Nombre del Antipatrón: ‘Sprint demasiado extenso’

Recomendación de Scrum: Realizar sprints de 2 semanas (o menos). Más específicamente, para equipos de menos de 5 personas, sprints de 2 semanas están bien: si el equipo es de 5 personas o más, es posible hacer sprints de menos de 2 semanas. En definitiva, los sprints no deberían tardar más de 3 a 4 semanas. Este último lapso, quizás solo para equipos pequeños de 3 personas.

Contexto: Experimentación temprana con Scrum, legado Cascada de ciclos de producción extensos, clientes/usuarios reacios a participar en intervalos cortos.
Esta situación es bastante común cuando el equipo venía trabajando con Cascada o con RUP o WaterRUP o similares. También, cuando el equipo intenta hacer/entregar muchas funcionalidades o funcionalidades muy grandes o complejas, o cuando el equipo es muy pequeño (1 o 2 personas) y para entregar Valor extienden los sprints

Solución (este es el antipatrón): Establecer sprints de 4 semanas o aún más largos.

Consecuencias: en vez de un trabajo más extensos para los sprints, las tareas planeadas tienden a no finalizarse al final del sprint, posiblemente porque las primeras semanas no son usadas los suficientemente eficientes y se establecen tareas muy largas en los sprints. Disminuyendo consecuentemente el compromiso del equipo a entregar elementos al final del sprint. El ciclo de retroalimentación llega a ser tan extenso que parte del trabajo podría no llegar a necesitarse más.

La productividad no es la misma al inicio del sprint (normalmente más baja), que al final del mismo. Algo similar ocurre con el “paso sostenido” que debería mantener el equipo durante todo el proyecto: en este caso, al principio del sprint, los miembros del equipo inician con el ritmo que quisieran tener durante todo el sprint y, por extensión, durante todo el proyecto; sin embargo, hacia la segunda parte del sprint y sobre todo hacia el final del mismo, el equipo regularmente trabaja más de la cuenta, tratando de alcanzar el objetivo del sprint. Lamentablemente, muchas veces es demasiado tarde.

Excepciones: Si el equipo de desarrollo debe sincronizarse con trabajo externo que tiene un ritmo más lento (por ejemplo, desarrollo de hardware), sprints más prolongados podrían justificarse. En este caso, se debe prestar especial atención a la Definición de Preparado”. [4]

Hasta allí esta versión. ¡Funciona para mí!

Terminemos con una sugerencia

Ya he dicho en otras ocasiones que debemos empezar con “Scrum al Natural”, Scrum orgánico si se quiere. Cuando sea hora de hacer alguna adaptación, motivada por el hábitat organizacional, debemos evaluar estos cambios a las prácticas Scrum en su contexto, con el fin de separar los cambios dañinos de los necesarios o benéficos requeridos por ese hábitat organizacional y evitar así una crisis mayúscula en el mediano o en el largo plazo.
Ágiles, nos vemos en la Red.

Referencias

[1] Un breve artículo: ‘ScrumButs and Modifying Scrum’, lo encuentran en

[2] http://www.agilemanifesto.org/iso/es/principles.html.
El principio completo dice:
“Entregamos software funcional frecuentemente, entre dos semanas y dos meses, con preferencia al periodo de tiempo más corto posible.”
¡Nunca está de más darse una pasadita por el Manifiesto Ágil!

El primer artículo de esta serie sobre Antipatrones Ágiles/Scrum, donde hago una introducción al asunto que nos ocupa. La dirección completa es:

[4] Un artículo sobre este asunto de la Definición de Preparado fue publicado hace poco por el amigo y colega Johnny Ordoñez, se los recomiendo ampliamente:
‘La Definición de “Ready” es tan importante como la Definición de “Done”’