Mitos, Monstruos, Leyendas Urbanas y otros Desvaríos de Ágil y Scrum

La mitología es un conjunto de mitos relativamente cohesionados: relatos que forman parte de una determinada cultura. Los mitos son relatos basados en la tradición y en la leyenda, creados para explicar el universo, el origen del mundo, los fenómenos naturales y cualquier cosa para la que no haya una explicación simple [1]. En el bestiario mitológico de la humanidad encontramos seres fantásticos que nos hacen soñar o morir de miedo: el Dragón, el Fénix, el Grifo, el Kraken, el Cancerbero, la Hidra, el Minotauro, la Escila, el Pegaso y la Sirena, para citar algunos de los más arraigados en nuestros temores y pesadillas.

Se trata de esa necesidad inherente al ser humano de aferrarse a lo desconocido y a lo sobrehumano para entender mejor la realidad que lo rodea, o simplemente para escaparse de esta. En el caso de los métodos de software, por ejemplo, estas aprehensiones tienen su origen en la falta de conocimiento teórico-práctico sobre algo específico, en el miedo o rechazo al cambio o en la fobia a equivocarse de quienes practicamos el desarrollo de software. Lo que haré a continuación es mencionar brevemente algunos de estos arquetipos quiméricos que pululan en el universo de los métodos ágiles en general y de Scrum en particular.

Ágil no necesita documentación

¡Esta es la madre de todas las entelequias! Su origen está en ese valor expuesto en el Manifiesto Ágil que reza: “valoramos software funcionando sobre documentación extensiva” [2]. En ninguna parte del manifiesto dice que no se hace documentación, esta debe elaborarse justo cuando se necesita y solamente la suficiente y necesaria y en los formatos más adecuados, que llegue al público interesado, que entregue valor a la organización. Y siendo consecuentes con el primer valor del manifiesto, esta documentación no se requiere producir con herramientas sofisticadas.

Ágil significa “no hay un plan”

De hecho, ágil no soporta el desarrollo sin planeación. Los métodos ágiles usan planeación y estimación continua para maximizar el ROI. En realidad, ágil es sobre manejo de alcance. La planeación continua permite redireccionar el compás del proyecto de acuerdo con el entorno cambiante del mismo; también, asegura un foco consistente en las prioridades del negocio teniendo en cuenta las restricciones impuestas al proyecto. Además, la planeación constante posibilita tomar mejores decisiones y comunicarlas más efectivamente. Plan sí hay, solo que es dinámico y flexible.

Podemos rastrear el origen de este mito a otro  valor del Manifiesto Ágil que invoca: “valorar la respuesta ante el cambio sobre seguir un plan” [2]. Otra vez, se trata de un malentendido nocivo para la industria del software. Este artículo es un intento más por remediar esa situación.

Ágil es la solución tipo “bala de plata” a todos los problemas de la ingeniería de software (Existe una solución tipo bala de plata)

De todos los monstruos que llenan las pesadillas de nuestro folclor, ninguno más terrorífico que los llamados licántropos. Para ellos buscamos balas de plata que mágicamente los hacen desaparecer para siempre.

La industria del software tiene muchos problemas, aquellos que precisamente se quisieron arbitrar con el manifiesto ágil. Sin embargo, ningún método actual, por sí solo o combinado, es capaz de enfrentar la enorme cantidad de variables que se mezclan en el ambiente de los proyectos de software, dada la magnitud y complejidad de la mayoría de estos. Los métodos ágiles no son la excepción. Si bien su modelo iterativo y adaptativo de gestión posibilita en gran medida la resolución de muchos impedimentos, siempre habrá que poner de manifiesto nuestro sentido común para afrontar escenarios hostiles.

Es decir, además de recurrir a balas de plata, estacas de madera, ajos o apelaciones a la mediación divina (léase procesos y herramientas, documentación detallada, contratos y acuerdos de servicio, planes, etc.), necesitamos encontrar mecanismos que nos permitan interactuar mejor entre nosotros, construir productos de software por incrementos, colaborar íntimamente con los usuarios y reaccionar hábilmente ante los cambios que se presentan todo el tiempo durante un proyecto. Esto es lo que dice realmente el manifiesto ágil.

Ágil no necesita diseño previo

Este quizás es un derivado del primer mito. En la realidad, la pieza funcional de software que se entrega en cada iteración requiere de diseño, el suficiente y necesario para construir un producto con calidad. Se trata de un diseño funcional, tan robusto pero tan flexible como se requiera para que todos los cortes del software se puedan integrar en uno solo. Si pensamos en “diseñar a medida que avanzamos”, seguramente fallaremos en el intento y nuestro producto nunca verá la luz del día. El ciclo convencional del software no desaparece porque lo hagamos ágil: análisis, diseño, implementación, pruebas y despliegue. ¡Algunas cosas no cambian!

Ágil siempre usa “Historias de Usuario"

Esta leyenda también desciende de la primera. Es que la “no documentación” es el más arraigado de todos los mitos alrededor de los métodos ágiles. Tanto las organizaciones como los individuos necesitamos de conocimiento explícito, o sea, de aquel que tenemos y del que somos plenamente conscientes cuando lo ejecutamos, que está estructurado y muchas veces esquematizado para facilitar su difusión. Esas son las claves: estructurado y esquematizado, es decir, documentado. Otra cosa es el formato que usamos para documentar, quizás ese es el que debe cambiar, pero ese es un problema diferente.

Y en cuanto a las historias de usuario, rutinarias en los métodos ágiles, hay que decir que ágil no siempre las usa. Hay que usarlas sí, y solo sí, son apropiadas. Existen otros instrumentos, unos más efectivos que otros, como los prototipos, los tableros de historias, los simuladores. ¿Alguien ha intentado “porciones de caso de uso”? Estas últimas son tan livianas como las historias de usuario y tienen el poder de los casos de uso. Y otro error muy común es creer que las historias de usuario siempre son elaboradas por el Dueño de Producto.

Scrum siempre Funciona

Ya tenemos claro que ágil no es una bala de plata y Scrum es ágil, conclusión…

Primero debemos saber cuándo implementar Scrum en la organización. Y luego debemos saber cuándo usar Scrum en un proyecto. ¿Está preparado nuestro cliente/usuario? ¿Habrá un dueño de producto? Más importante aún, ¿está dispuesto nuestro equipo para entregar software probado y funcionando que sea potencialmente distribuible cada periodo corto de tiempo – 2 semanas –? ¿Están claros los valores y principios del manifiesto ágil? Este artículo es un síntoma de que no lo están. ¿El equipo es autogestionado y experto? ¿Nuestro usuario está dispuesto a involucrarse al 100%?

Entre otras, estas son algunas de las cuestiones que debemos responder y establecer antes de intentar Scrum en nuestros proyectos. Se requiere de cierta capacidad y de cierta madurez para enfrentar el reto.

Scrum Master igual a Gerente de Proyecto

Scrum Master es un rol de gestión, sí, pero no es un gerente como lo conocemos en los proyectos tradicionales, mucho menos un gerente tipo PMI o algo parecido. “El Scrum Master es un líder servil, al servicio del Equipo Scrum.” [3] Un SM es un facilitador, es alguien que se sitúa en algún lugar entre el equipo de desarrollo y el cliente. También puede verse como un “guardián de Scrum”, un custodio, alguien que vigila que el proceso se esté llevando a cabo como lo indica la guía de Scrum.

El SM puede venir de una PMO, es cierto, pero también puede llegar desde el equipo de Analistas o de cualquier otro miembro de la organización que tenga las habilidades y la empatía requerida. El SM tampoco es un desarrollador líder o arquitecto, también hay que decirlo.

Podemos hacer Scrum sin un Dueño de Producto o con muchos dueños de producto

Cuando no tenemos un dueño de producto que está fuera del equipo o, mejor, fuera de la jerarquía del equipo, perdemos algo precioso e inherente a ágil: la noción del cliente. Perdemos a la persona que nos puede ayudar a entender lo que realmente quiere el cliente. “El dueño de producto es el responsable de maximizar el valor del producto y del trabajo del Equipo de Desarrollo.” [4] El dueño de producto es quien establece los criterios reales de aceptación del producto, esto no lo puede hacer otro rol en el equipo o en la organización. Es un hecho, sin este personaje, el equipo no sabrá que hacer.

Ahora bien, el dueño del producto es uno solo, no un equipo o comité de dueños de productos. El dueño de producto es una sola voz y representa los intereses del cliente, es decir, de todos los interesados en el producto. Más de un dueño de producto puede “adicionar ruido” al proyecto, es decir, sumar variables que pueden llevar el proyecto a la devastación. Finalmente, este mito tiene sus orígenes en que ninguna persona por sí sola tiene el conocimiento completo de lo que quiere la organización, pero ello no es necesario, solo es suficiente con que tenga contacto con las personas apropiadas.

Scrum no funciona con CMMI u otros modelos de procesos y viceversa

He visto anuncios en la Web sobre “la gran pelea” entre Scrum y CMMI, seminarios virtuales, tertulias presenciales, diplomados para expertos, como si se tratara del campeonato de combate definitivo, la última de las grandes contiendas entre dos “gigantes” del deporte. Esta leyenda urbana tiene sus raíces en la creencia de que CMMI es predictivo mientras que Scrum es adaptativo. Pero lo que hay que saber realmente es que CMMI es un modelo de mejoramiento de procesos, nos indica qué buenas prácticas dan ventaja a nuestra organización, en tanto que Scrum aporta precisamente el cómo implementar esas prácticas.

En la realidad es posible integrar estos dos mundos y ponerlos a funcionar en beneficio de nuestros clientes y de nosotros mismos: a la vez que CMMI permite describir todos los procesos de la organización y su interacción, Scrum regula el procedimiento a seguir en el mero proceso de desarrollo. Quizás el detalle más oscuro en este análisis es aquel de las estadísticas inherentes a toda organización de alta madurez, pero la cultura ágil de alguna manera impuesta por Scrum sirve de fundamento sistemático a los requisitos de un proceso de control estadístico impuesto por CMMI. Las cosas así, es totalmente viable convivir con Scrum y CMMI en un mismo plano.

Scrum produce equipos de súper héroes, tipo los Vengadores o la Liga de la Justicia

Necesitamos expertos, es cierto. Pero estos no se hacen solos. Scrum no es una caneca de desechos biológicos o químicos y donde podamos caer y levantarnos con poderes extrasensoriales que permitan leer la mente de los usuarios o con una memoria prodigiosa que nos faculte a escribir solo las líneas de código correctas o realizar diseños perfectos en cuestión de segundos.

Si seguimos Scrum, si asistimos a las ceremonias propuestas por el marco de trabajo, seremos capaces de entender los obstáculos que evitan mejorar nuestro desempeño. Y sin la habilidad o deseo de remover esos impedimentos, apenas si podremos tener mayor visibilidad de los problemas. Y esto simplemente redundará en el aumento de nuestra frustración, lo que a su vez dejará notar nuestro comportamiento negativo y menos productivo. Ya lo he repetido, Scrum no es la solución definitiva, pero ayuda a ser mejores cada vez. La transparencia y la predictibilidad son los beneficios inmediatos.

¡El plan de mejoramiento personal y profesional lo ejecutamos de nuestra cuenta!

Más Mitos y Leyendas

Otros mitos, no menos perjudiciales, son:

• Estamos haciendo Scrum, así que no necesitamos otras prácticas ágiles como TDD, Refactoring, Pair Programming, etcétera
• Ágil es menos disciplinado y más fácil
• Podemos lograr agilidad sin cambio organizacional e individual
• Ágil es igual a Scrum
• Con Scrum podemos hacer cambio en cualquier momento

La lista realmente podría ser interminable.

Conclusiones

Scrum es una idea sencillamente empaquetada y de esta manera podemos transferirla rápidamente de una persona a otra y de un equipo a otro. Con todo y ello, es innegable la gran cantidad de concepciones erróneas que tenemos al respecto. Para sacar estos monstruos y mitos de nuestras mentes es necesario tener acompañamiento, no basta con aprender por sí solo, necesitamos entrenamiento de personas que hayan usado exitosamente el método. Las organizaciones, por su parte, deben concebir un buen plan de implantación del método: configurar el proceso, hacer proyectos piloto, medir, analizar los resultados, ajustar, entrenar a los equipos e institucionalizar.

¡Así lo estamos haciendo!

Referencias Web/Bibliográficas

[1] Colaboradores de Wikipedia. Mitología [en línea]. Wikipedia, La enciclopedia libre, 2013 [fecha de consulta: 11 de junio del 2013]. Disponible en http://es.wikipedia.org/w/index.php?title=Mitolog%C3%ADa&oldid=67124850

[2] El Manifiesto Ágil de Software: http://www.agilemanifesto.org/iso/es/

[3] La Guía de Scrum: http://www.scrum.org/Scrum-Guides

[4] La Guía de Scrum: http://www.scrum.org/Scrum-Guides

Actualización 20200220

Puedes ver y descargar la presentación asociada a este artículo aquí.

Scrum Orgánico para Iniciantes

Advertencia: al final de este artículo podrás empezar a usar Scrum en tus proyectos.

Marco de Trabajo Scrum

Presentación

Cuando publiqué la lista de chequeo de Scrum, asumí que mis lectores ya conocían este marco de trabajo (para software o productos y servicios de otro tipo) o que estarían familiarizados con el concepto de prácticas y técnicas ágiles y que conocían el suficientemente expuesto manifiesto ágil. Pensé que  no hacía falta abordar los aspectos más básicos del asunto. Me equivoqué. Acaso para algunos de nosotros esta sea la primera vez con Scrum, el primer contacto con un marco de trabajo ágil, la primera incursión en esta forma de construir productos de software. Así es que decidí volver a lo fundamental. Aquí vamos otra vez.

Scrum es un marco de trabajo liviano e iterativo de gestión de proyectos que ayuda a los equipos a ejecutar y a entregar exitosamente el valor de negocio más alto en el tiempo más corto posible. Este método es particularmente bien apropiado para entornos donde los requisitos están sujetos a cambios continuos o donde los requisitos no se entienden correctamente. “Scrum es un marco de trabajo con el cual podemos afrontar problemas complejos y adaptativos y con el cual podemos emplear distintos procesos y técnicas, así como también podemos optimizar nuestra predictibilidad y tener un mejor control de los riesgos”[i].

Métodos Ágiles

Pero Scrum no es el único método ágil que podemos encontrar. Algunos otros marcos de trabajo ágil son:

·         Adaptive Software Development (ASD)

·         Crystal Clear

·         Kanban
·         Extreme Programming (XP)
·         Dynamic System Development Method (DSDM)

·         Feature Driven Development (FDD)

·         Lean Software Development (LSD)

·         Open Unified Process (OpenUP)

·         Essential unified process (ESSUP)

·         Agile Unified Process (AUP)

·         Use Case 2.0

La Filosofía Ágil

Todos estos métodos tienen sus cimientos en lo que se conoce como Filosofía Ágil:

·         Usted no puede predecir o planear con absoluta certeza lo que va a entregar, cuándo lo entregará y cuánto será su costo.

·         Empiece con planes iniciales alrededor de las estimaciones, fechas y alcance, pero enfóquese en la revisión continua de estas restricciones a medida que avanza.

·         La meta es entregar el mejor software posible, dadas estas restricciones, pero ningún método con el enfoque de receta de cocina mejorará lo que es “mejor”.

Scrum

Scrum define explícitamente tres roles, cuatro ceremonias y cuatro artefactos principales. El Dueño del Producto, el Equipo de Desarrollo y el Scrum Master son quienes tienen bajo su responsabilidad entregar software probado y funcionando cada cuatro semanas o menos. Todos ellos forman el Equipo Scrum que, además de las actividades regulares de desarrollo de software, realiza cuatro ritos durante cada iteración que en Scrum se llama Sprint: Planificación del Sprint, Reunión Diaria, Revisión del Sprint y Retrospectiva. Durante estas ceremonias, el equipo actualiza la Lista (Backlog) del Producto, la Lista de Pendientes (Backlog) del Sprint y la Lista de Impedimentos; y al final entrega un incremento del producto potencialmente distribuible.

Actores en Scrum

El Dueño del Producto es la persona encargada de maximizar el valor del producto elaborado por el equipo de desarrollo. Es quien define y prioriza los ítems de la bitácora de producto y quien proporciona al equipo todo el conocimiento del negocio necesario para que este sea transformado en software. Entre tanto, el Equipo de Desarrollo es el responsable de construir el producto, teniendo en cuenta las necesidades y prioridades del dueño del producto. En Scrum no existen roles especializados, es simplemente el equipo, comprometido todo con el éxito del proyecto.

Finalmente, el Scrum Master es un servidor, es quien vela porque se ejecute el proceso como está definido y que se lleven a cabo cada una de las ceremonias Scrum como está consignado en la Guía de Scrum. También es el encargado de introducir nuevas prácticas al proceso y al proyecto, acompañando de cerca su implantación y monitoreando los resultados. Es importante aclarar que el Scrum Master no es un gerente, aunque bien podríamos decir que hace parte de y reporta al área de manejo de la organización, por ejemplo, a la oficina de proyectos. Contando el SM, el equipo Scrum no debe superar las 9 personas.

Ceremonias y Artefactos Scrum

En un proyecto gestionado bajo el manto de Scrum, todo ocurre en el marco de un Sprint: este es una iteración de un tiempo máximo de 4 semanas. La industria del software está gritando a cielo abierto que este tiempo sea de solo 2 semanas o de menor duración. Al principio del Sprint se realiza la Planificación del Sprint. En esta reunión, el dueño del producto asiste con la Lista del Producto actualizada y priorizada, de acuerdo con las necesidades del negocio. Junto con el equipo de trabajo, se seleccionan algunos de los elementos de la lista, usualmente los de mayor valor para el negocio, para ser desarrollados durante la iteración.

Con estos elementos seleccionados se conforma lo que se llama la Lista de Pendientes del Sprint, el trabajo del sprint. A continuación, el equipo de desarrollo define cómo hará el desarrollo y estima el esfuerzo necesario para cada uno de los elementos seleccionados, teniendo en cuenta que el esfuerzo máximo es el definido para el sprint, ni un minuto más. Con estas premisas, el Equipo en pleno elabora la Definición de Terminado y se asegura que todo el mundo la entienda y la comparta. Esta “definición de Terminado” se convierte en una especie de “contrato” del sprint, define las cláusulas sine qua non el incremento del producto no satisface a su dueño ni a la organización.

Con la definición de Terminado en la mente de los miembros del equipo Scrum, este inicia el ciclo de vida del software. Todos los días, a la misma hora y en el mismo lugar, de pie y durante 15 minutos máximo, el equipo se congrega en la Reunión Diaria. En esta sesión, cada integrante del equipo responde tres preguntas: ¿qué hice ayer? ¿Qué haré hoy? Y ¿Qué problemas tengo? Solo tres y nada más que tres. Esta reunión no es para saludarse ni para hablar de asuntos que no estén relacionados con el proyecto o con las personas que lo ejecutan. Tampoco es para resolver los problemas expuestos.

De la reunión diaria sale actualizada la Lista de Impedimentos, la cual es tratada fuera de la reunión, por cada uno de los responsables de solucionarlos. En Scrum, el equipo es autogestionado, multidisciplinario y debería tener la capacidad de resolver sus propios problemas sin la ayuda de alguien externo. Hacia el final de la iteración, se realiza la Revisión del Sprint. En esta sesión, el equipo Scrum y los interesados realizan un escrutinio de lo que se hizo en el sprint y ajustan la lista del producto si fuese necesario. En definitiva, el dueño del Producto verifica que se haya cumplido la Definición de Terminado.

Justo a continuación de la revisión, se hace una Retrospectiva del Sprint: ¿Qué hicimos mal que no repetiremos? ¿Por qué no se alcanzó la Definición de Terminado? ¿Qué hicimos bien que podemos mejorar? ¿Qué hicimos bien que seguiremos haciendo tal cual? Estas son algunas de las cuestiones que, con ayuda del Scrum Master, se responden en esta reunión. En esta sesión también deberíamos separar unos instantes para realizar una introspectiva: ¿Cómo está nuestro estado de ánimo? ¿Seguimos? ¿Paramos? Si seguimos, ¿qué acciones de mejoramiento podemos introducir a partir del siguiente Sprint?

Conclusión

Estos son, grosso modo, los elementos que subyacen el método Scrum. Todas las ceremonias tardan un tiempo fijo definido en el libro de reglas de Scrum o Guía de Scrum. No hay que saber nada más para comenzar a usar el marco de trabajo. Y para usarlo hay que ser ágil, porque Ágil es algo que eres, no algo que haces. Una vez que puedes diferenciar esto, entonces convertirse en ágil será algo fácil. Extrapolando, una organización no puede forzar la filosofía ágil en su cultura, sino que debe permitir que su cultura evolucione hacia un estado ágil. Ágil es un estado de la mente, es una forma de pensar y de ver las cosas.

Se me olvidaba decirles, la retrospectiva siempre debe hacerse al final de cada sprint, a menos que el equipo esté bien ocupado. En cuyo caso, se deberían hacer dos.

Lecturas Adicionales

Mi artículo de Scrum Fundamental lo encuentran en este mismo Gazafatonario, en: http://www.gazafatonarioit.com/2013/05/scrum-lo-fundamental.html.

El libro de reglas de Scrum, la guía de Scrum, lo encuentran en:

http://www.scrum.org/Portals/0/Documents/Scrum%20Guides/Scrum_Guide%202011%20-%20ES.pdf#zoom=100.

La lista de verificación de Scrum que desató esta serie de artículos  la encuentran en: http://www.gazafatonarioit.com/2013/05/lista-de-chequeo-scrum.html.

Otros sitios que pueden visitar para aprender más de Scrum y libros que pueden leer son:

http://www.scrum.org/scrumguides

http://www.scrumalliance.org

http://www.mountaingoatsoftware.com/

http://scrum.jeffsutherland.com/

http://www.controlchaos.com/

http://americalatina.pmi.org/latam/CertificationsAndCredentials/PMI-ACP/PMI-ACPExamPreparation/MaterialsAndResourcesInAgile.aspx

Essential Scrum: A Practical Guide to the Most Popular Agile Process. Mike Cohn.

Succeeding with Agile: Software Development Using Scrum. Mike Cohn.

Agile Project Management with Scrum (Microsoft Professional). Ken Schwaber.

Agile Product Management with Scrum: Creating Products that Customers Love. Roman Pichler.

Professional Scrum Development with Microsoft® Visual Studio® 2012. Richard Hundhausen.

User Stories Applied: For Agile Software Development. Mike Cohn.

---

[i] La Guía de Scrum. © 1991-2011 Ken Schwaber y Jeff Sutherland, Todos los Derechos Reservados.

Scrum – Lo Fundamental

Lista de Chequeo de Scrum

Si logra esto puede ignorar el resto de la lista. Su proceso está bien.

• Entregar software funcionando y probado cada 4 semanas o menos

• Entregar lo que el negocio necesita más

• El proceso está mejorándose continuamente

Hablemos un poco de cada uno de estos criterios.

Entregar software funcionando y probado cada 4 semanas o menos

Scrum es un método iterativo e incremental. Pero “iterativo” e “incremental” son dos adjetivos ampliamente usados y pocas veces entendidos correctamente. Ya sabemos que una iteración es un proyecto, con todo lo que eso significa: es decir, si nos atenemos a la definición del PMI^®, un proyecto tiene un inicio, una planeación, una ejecución, un seguimiento y control, y un cierre, donde se formaliza la aceptación del producto o resultado, un producto que, en nuestro caso, es precisamente software, desplegado en un ambiente del usuario, no necesariamente ambiente de producción, pero del usuario al fin y al cabo, un entorno distinto al del desarrollador.

Este “incremento” de software funcionando es potencialmente distribuible, o sea, puede ponerse en producción con muy pocas o ninguna modificación, preferiblemente esto último. Y si este proyecto tarda cuatro semanas (como lo prescribe la guía orgánica de Scrum) o menos, mucho mejor. La industria del software, la nuestra, está diciendo a gritos que este lapso de tiempo sea de dos semanas. Así, podemos conseguir retroalimentación más efectiva y al día de los usuarios, mucho más de lo que hemos logrado en el pasado cuando solo entregábamos “papelware”, documentos llenos de texto (requisitos), diagramas de UML (arquitectura, análisis y diseño), casos de prueba, etcétera.

Entregar lo que el negocio necesita más

¿Quién mejor que el usuario conoce el verdadero valor de lo que necesita? Es el usuario, que en Scrum se llama Dueño del Producto, el que define y prioriza sus necesidades y las de los demás interesados, asegurándose así que los intereses de la organización queden incluidos en el producto; también es quien sabe cómo alcanzar las metas organizacionales y es el responsable de maximizar el valor del producto y del trabajo del Equipo de Desarrollo, y es el encargado de no perder el foco en el valor de negocio. Bien sabemos que, a más involucramiento del cliente en el proyecto, este saldrá mejor y se obtendrá una mayor satisfacción al final, tanto el usuario como el equipo que lo atiende.

Con esta premisa en mente, en esas iteraciones o sprints de corta duración que mencionaba en el apartado anterior, siempre estaremos entregando el producto que todos quieren ver. Un beneficio directo de esto es la posibilidad que tiene la organización de responder a la competencia aun durante el propio proceso de desarrollo y no después de este, como ocurre en los proyectos ejecutados con métodos más tradicionales. Además, este enfoque hace que el producto vaya madurando en la medida de su exposición a los usuarios. A medida que el producto se expone y más cambios resulten de allí, más maduro llega a ser el producto. Y cuando esto ocurre, la probabilidad de obtener ROI a corto o mediano plazo es mucho mayor.

El proceso está mejorándose continuamente

Empiece con Scrum “al natural” o Scrum orgánico, o sea, el que está definido en la guía de Ken Schwaber y Jeff Sutherland: consiga un dueño de producto (un cliente), nombre un Scrum Master y establezca un equipo de desarrollo pequeño. Y ya está listo para iniciar. Haga la reunión de planeación, asegúrese vía el Scrum Master de que el equipo completo esté realizando la reunión diaria y que al final de cada sprint de 4 semanas o menos se haga una reunión de revisión y una de retrospectiva para conocer no solo el estado del proyecto sino del equipo en general y para crear un plan de mejoramiento que sea ejecutado a partir del siguiente sprint y en los demás proyectos con Scrum.

Asegúrese de que todo lo mencionado se haga como dice la guía, por ejemplo, que las reuniones diarias tarden 15 minutos flash. De lo contrario, mejore primero esos aspectos que no se están haciendo bien. El Scrum Master debería ser capaz de lograrlo. A partir de allí, vaya introduciendo nuevas prácticas, no sin antes entrenar al equipo: refactoring, desarrollo dirigido por pruebas o TDD por sus siglas en inglés, kanban, lean, historias de usuario, programación en pares, casos de uso 2.0, entre otras. Adiciónelas una a una al proyecto, haga acompañar a su equipo de expertos en cada técnica, monitoree su ejecución, mida los resultados y haga los ajustes necesarios. Repita para cada práctica.

Conclusión

La entrega constante de software probado y funcionando cada pocos días o semanas, que sea de valor para los usuarios, y el mejoramiento continuo del proceso, contribuyen trascendentalmente al éxito en los proyectos. Scrum es un marco de trabajo que hace posible todo lo anterior. Y esta lista de verificación, la cual iremos atomizando poco a poco en este Gazafatonario, es un instrumento productivo que se puede usar como suplemento de primer orden a la guía de Scrum.

Lecturas adicionales:

La lista de verificación completa de Scrum la encuentran en mi artículo:

http://www.gazafatonarioit.com/2013/05/lista-de-chequeo-scrum.html

Sobre Iteraciones pueden leer mi artículo "Gerencia de Proyectos Iterativos" en la revista de la Asociación Española de Profesionales en Dirección de Proyectos.

El libro de reglas de Scrum, la guía de Scrum, lo encuentran en:

http://www.scrum.org/Portals/0/Documents/Scrum%20Guides/Scrum_Guide%202011%20-%20ES.pdf#zoom=100

Sobre casos de uso 2.0 y métodos ágiles pueden leer mi serie de artículos en este Gazafatonario:

Casos de Uso 2.0 y Métodos Ágiles:

http://www.gazafatonarioit.com/2012/04/casos-de-uso-20-y-metodos-agiles.html

Casos de Uso 2.0:

http://www.gazafatonarioit.com/2012/04/casos-de-uso-20.html

¡Quiero una Porción de Caso de Uso!

http://www.gazafatonarioit.com/2012/04/quiero-una-porcion-de-caso-de-uso.html

Casos de Uso 2.0 – Aplicable a todos los tipos de sistemas y organizaciones:

http://www.gazafatonarioit.com/2012/04/casos-de-uso-20-aplicable-todos-los.html

Todavía Otra Lección Más Sobre Porciones de Casos de Uso:

http://www.gazafatonarioit.com/2013/02/todavia-otra-leccion-mas-sobre.html

¿Por qué existe Casos de Uso 2.0?

http://www.gazafatonarioit.com/2013/01/por-que-existe-casos-de-uso-20.html

Todavía Otra Lección Más Sobre Porciones de Casos de Uso:

http://www.gazafatonarioit.com/2013/02/todavia-otra-leccion-mas-sobre.html

Lista de Chequeo Scrum

Clic sobre la imagen para ampliar. Clic para [Descargar] la Lista de Chequeo Scrum

De las muchas listas de verificación que encontré, esta llenó mis expectativas. La lista original es de Henrik kniberg. La pueden encontrar en sueco y en otros idiomas en: www.crisp.se/scrum/checklist.

Esta es la traducción al español.

¿Qué es esto? ¿Para quién es?

La lista de chequeo Scrum es una herramienta simple para ayudarte a empezar con Scrum, o para evaluar tu actual implementación de Scrum.

Nota que estas no nos reglas. Son guías. Un equipo de dos podría decidir saltar el Scrum diario, puesto que ellos están haciendo programación par todo el día y podrían no necesitar una reunión para sincronizarse. Bien. Luego, intencionalmente ellos se han saltado una práctica Scrum, pero se aseguraron de que el propósito de la práctica Scrum se cumplió de otra forma. ¡Esto es lo que cuenta!

Si estás haciendo Scrum, podría ser interesante hacer que tu equipo tenga esta lista en la Retrospectiva como una herramienta de discusión, no como una herramienta de evaluación.

¿Cómo la uso?

•        Joe: “Para esta retrospectiva, les he traído una pequeña y útil lista de chequeo. ¿Hay algo de esto que no estamos haciendo?”.

•        Lisa: "Hmmm, veamos. Bueno, ciertamente nos hace falta la Definición de Terminado y no estamos midiendo la Velocidad”.

•        Joe: “Bueno, la 'Definición de Terminado' está listada bajo 'Scrum Esencial' ¡así que parece muy importante! La Velocidad está listada bajo 'Recomendado, pero no siempre necesario' así que eso puede esperar y empecemos con lo esencial.

•        Lisa: “Mira, también nos hace falta ‘Entregar producto funcionando y probado cada 4 semanas o menos'. ¡Eso está listado bajo 'Lo Fundamental'! Tiene sentido, ¡porque Mercadeo siempre se está quejando de eso!”

•        Joe: “Quizás un concepto como la 'Definición de Terminado' podría ayudarnos a tomar porciones más pequeñas por sprint y liberar funcionalidades más seguido.”

•        Lisa: “Buena idea, intentémoslo.”

¿Cómo NO la uso?

•        Gran Jefe: “Bien, equipo, hora de ver qué tanto cumplimos con Scrum. Llenemos esta lista de chequeo, por favor.”

•        Joe: “Jefe, estoy feliz de reportar que estamos haciéndolo todo. Bueno, todo excepto los gráficos de trabajo pendiente del Sprint.”

•        Gran Jefe: “¡Mal, mal equipo! Aquí dice que ustedes deberían estar haciendo estas... eh...  ¡cosas pendientes del sprint! ¡Las quiero ver!”

•        Lisa: “Pero nosotros hacemos sprints de 2 semanas y casi siempre entregamos lo que nos comprometemos a hacer, y los usuarios están felices. Las gráficas de trabajo pendiente del sprint no agregarían valor en este escenario”.

•        Gran Jefe: “Bueno, aquí dice que deberían hacerlo, así que no dejen que los encuentre haciendo trampa otra vez, ¡o llamaré a la policía Scrum!”

¿Es esta una lista de chequeo oficial?

No. La lista de chequeo refleja mi opinión personal y subjetiva acerca de lo que realmente importa en Scrum. He pasado años ayudando a compañías a empezar con Scrum y he conocido a cientos de otros practicantes, instructores y entrenadores; y he encontrado que listas de chequeo como esta pueden ser útiles si se usan correctamente.

Descargar la lista de chequeo Scrum

Puedes descargar la lista en formato PDF aquí.

Más sobre esta lista de chequeo de Scrum

Para profundizar más en los conceptos de la lista, puedes leer este artículo:

"Scrum: lo fundamental" en:

http://www.gazafatonarioit.com/2013/05/scrum-lo-fundamental.html