Archivo de la etiqueta: Desarrolladores

13 Formas de Cómo Fallar al Implementar Scrum (Metodologías Agiles)

Una de las mejores formas de aprender es de los fallos. En éste resumen de cómo fallar al Implementar Scrum (Metodologías Agiles), tenemos algunas claves importantes.

Scrum proporciona un marco de procedimientos para ayudar a obtener beneficios de los principios ágiles. Scrum se ha demostrado eficaz muchas veces, en numerosos proyectos, a lo largo de multiples industrias. Es un conjunto bastante simple y directo de prácticas y directrices que (normalmente) dará como resultado una mayor adaptabilidad al cambio, mejora de la productividad, productos de mayor calidad y clientes más felices (a comparación de metodologías en cascada -Waterfall-). Son tan simples y sencillos estos métodos, que muchas organizaciones se esfuerzan por obtener los beneficios de “Agile”.

A través de mi experiencia desde 1999 de implementar proyectos ágiles, he sacado unas conclusiones de porqué fallan al adoptar Scrum algunas de las organizaciones que quieren implementarlo.

Veamos las 13 Formas de Cómo Fallar al Implementar Scrum (Metodologías Agiles).

1. Temor de compromiso

Cada día parece que más personas promocionan los beneficios de Agile. Sin duda, a menudo hay muchas cosas que pueden obtenerse mediante la adopción de prácticas ágiles, pero si usted solo se queda con las guindas de las prácticas que son más fáciles de adoptar, o aquéllas que mejor se adapten a su organización, usted probablemente perderá el tren del valor real que aportan las metodologías ágiles. Los principios ágiles se derivaron de décadas de observaciones de lo trabajado en proyectos exitosos y de lo que no funcionó en los que no. Y la práctica de aplicar estos principios al desarrollo de productos ha sido refinada  en los últimos diez años, las metodologías ágil toman lecciones de principios Lean, como Kanban (cuyo origen se remonta a mediados del siglo XX).

Si desea obtener todo el potencial que ofrece Agile, no puede coger a mitad de camino y llorar cuando no se cumplen con las expectativas. Y no debe de apoyarse       en las prácticas ágiles para resolver sus problemas. Ágil es una herramienta muy buena en resaltar ineficiencias en sus procesos de desarrollo de software, pero una vez que esas cuestiones se hacen visibles a través de métodos ágiles, corresponderá a las personas de su organización el resolverlos. Así que si vas hacia “ser ágil” , a continuación, hay que hacer el compromiso de adoptar todos los principios identificados en el manifiesto ágil.

2. La falta de disciplina

Proyectos ágiles exitosos requieren interacción y colaboración. No sólo entre el equipo de desarrollo y de los clientes (o área de negocio), sino también entre sí. Esto no es facilitado a través de equipos funcionales, que simplemente aceptan artefactos de un       equipo, agregan valor y luego va a otro equipo. Los equipos deben ser cruzados. Así que si su organización tiene equipos independiente en áreas, localización, gestión del producto o equipo de instalaciones, entonces prepárate a reorganizarlo si deseas tener éxito con el “Agile”. Todas las disciplinas de ingeniería de software (obligatorio) deben completarse dentro de una iteración. Una historia de usuario debe ser desarrollada íntegramente, desde principio a fin, desde los requisitos hasta la implementación, dentro de una iteración. Una vez una historia que se hace, se hace. Si no eres capaz de completar ese ámbito dentro de una iteración, entonces sus historias son demasiado grandes o tus iteraciones son demasiado cortas. También es importante desarrollarlo justo a tiempo. Sólo escribir tantos requisitos como pueden ser completamente diseñado (dentro de una iteración); desarrollo sólo lo que puede aplicarse completamente (dentro de una iteración); aplicar sólo lo que puede ser completamente probado y validado (dentro de una iteración); y así sucesivamente. Esto le permitirá adaptarse rápidamente a los cambios en el mercado, en los requisitos o las requerimientos de los interesados.

3. Una persona cumple varias funciones

Scrum define tres funciones para facilitar las prácticas ágiles. El propietario del producto representa los intereses de todos los interesados del proyecto, asegura el equipo persigue una visión común, posee el product backlog y garantiza el buen rendimiento de la inversión. El ScrumMaster conduce la ejecución del proceso Scrum, enseña los valores de scrum y prácticas a todos los implicados en el proyecto, asegura que todo el mundo sigue sus normas y prácticas y elimina los obstáculos para el éxito del equipo scrum. El equipo de Scrum decide cuántos elementos sobre la historia de producto se comprometerá a completar en un sprint dado y cómo entregar esos elementos. El equipo de Scrum entonces debe cumplir esos compromisos.

Estas funciones funcionan muy bien en la puesta en práctica de los principios ágiles. Sin embargo, ninguno de estos roles son efectivos si se combinan con otro papel por la misma persona. Como ejemplo, el papel de propietario del producto nunca se cumplió por la misma persona cumpliendo el papel del ScrumMaster. Si el proceso funciona bien, debería haber algún conflicto (saludable) entre el propietario del producto y ScrumMaster. Mientras el propietario del producto está trabajando para garantizar que el equipo está trabajando lo más rápido posible, para ofrecer el mayor valor, con el menor costo, el papel de ScrumMaster es garantizar que el equipo está siguiendo el proceso definido, trabajando a un ritmo sostenible. Muchas veces, estos objetivos pueden estar en conflicto unos con otros. Pero es el consenso entre estas dos funciones que garantiza el mejor resultado. Otra responsabilidad del propietario del producto es aceptar o rechazar los productos de trabajo entregados al final del sprint. Si el propietario del producto es también un miembro del equipo, sería difícil ser objetivo para determinar si un producto es aceptable para el lanzamiento. Y si un ScrumMaster es un miembro del equipo, esa persona tendría dificil identificar defectos en un proceso en el cual es un participante activo. El ScrumMaster también tendría menos tiempo para       eliminar impedimentos como un miembro del equipo. Para obtener todo el potencial de Scrum, debe mantener estos roles separados.

4. No se puede cumplir con los compromisos de Sprint

Trabajar en Sprint ofrece ventajas en varios aspectos. Se permite a los equipos trabajo ininterrumpido en un pequeño trozo de la funcionalidad y el desarrollo que la funcionalidad completa. Cuando esta función se completa al final del sprint, el equipo presentará lo que fue construido para obtener retroalimentación de los participantes en el proyecto (que se incorporará en los Sprint sucesivos). Y, mostrar a los clientes software que funciona ,sobre una base predecible, es la mejor manera para construir confianza. Cuando el cliente puede ver la realización de lo que se prometió al comienzo del Sprint, es difícil no confiar en un equipo cuando se dice que puede ofrecer algo en un Sprint. Por supuesto, esta confianza se disipa rápidamente cuando el equipo falla en cumplir con su compromiso asumido en el comienzo del Sprint, especialmente para los experimentados equipos de Scrum.

Una vez que un equipo Scrum tiene cinco o más sprints en su haber, deben tener una idea bastante buena en cuanto a su velocidad, asumiendo que la composición del equipo y la capacidad de mantenerse (al menos) bastante consistente. Esta velocidad debería permitir al equipo mantener un ritmo de desarrollo sostenible en el largo plazo y siempre entregar un determinado número de puntos de cada sprint. Una cosa que interfiere con su capacidad de entregar constantemente un cierto grado de alcance es, por ejemplo, si el Scrum Master permite las interrupciones que se producen fuera del equipo.

Cuando se ejecuta un proyecto ágil, tiene que haber un acuerdo entre el equipo de desarrollo y otras partes interesadas del proyecto para que el equipo se pueda comprometer a cumplir sus promesas, así que cualquier cambio en el alcance o los requisitos (o cualquier otra cosa) debe esperar hasta el sprint siguiente. Esto permitirá al equipo ir codo con codo en el desarrollo sin tener que preocuparse por distracciones externas o interrupciones. Esto no sólo le permitirá al equipo cumplir con su compromiso, sino que también ayudará a mejorar la productividad y la calidad del producto.

5. Grupos de individuos

Agilidad viene en muchas formas. Ser capaz de adaptarse rápidamente sus procesos es un método de ser ágil. Esto requiere trabajo en equipo. No sólo un grupo de ingenieros individuales o especialistas inflexibles, trabajando en su propia pieza, si no un grupo de profesionales trabajando juntos y hacer sacrificios para alcanzar la meta del equipo. A menudo, los equipos de desarrollo tienen personas que trabajan sólo en ciertos tipos de tareas. Es sin duda importante tener personas con conocimientos especializados; de hecho, a menudo es necesario a lo largo del desarrollo de productos. Pero eso no significa que los especialistas sólo deben trabajar en su especialidad. La capacidad de responder rápidamente a los cambios requiere que los miembros del equipo que están dispuestos a trabajar en las tareas que se necesitan en ese momento. Es muy común en equipos de Scrum inmaduros que los miembros del equipo sólo hacen desarrollo, validación o administración de la configuración. Para ser verdaderamente ágil, todos los miembros del equipo deben estar dispuestos a llenar los vacíos que se produzcan. Lecciones de desarrollo Lean nos han enseñado que, si queremos lograr el flujo de trabajo alto, debemos desplazar recursos para aliviar los cuellos de botella cada vez que ocurren. Esto significa que los miembros que tradicionalmente sólo hacen arquitectura, diseño o desarrollo debe estar dispuesto a trabajar en las tareas de diseño, validación o implementación en cualquier momento que sea necesario. Necesitan salir de la costumbre de elegir sólo las tareas de su especialidad. Si bien es importante contar con miembros con conocimiento de dominio específico, es igualmente importante que los miembros del equipo sean cruzados.

6. Falta de auto organización

El valor de la inteligencia de grupo se ha documentado muchas veces y en una amplia variedad de circunstancias. Dos cabezas piensan mejor que uno… y mejor si son siete. Numerosos estudios han demostrado también que la auto-gestión de equipos son más productivos y son mejores en la solución de problemas que los equipos dirigidos por un individuo. Si se les dejan auto-organizarse y tomar decisiones en cuanto a cómo resolver mejor los problemas, los equipos auto gestionados tienden a basarse en la inteligencia colectiva y la experiencia del grupo, en comparación con la de un jefe de equipo. Este enfoque cooperativo no sólo hace al equipo más productivo, sino que además les hace mejores para identificar las oportunidades y el empleo de métodos de mejora. Con el tiempo, el equipo comenzará a funcionar como una unidad, en lugar de un conjunto de personas tras un individuo.

7. Revisiones de Sprint ineficaz

Las Sprint Reviews son algo más que reuniones para revisar lo que se logró durante un sprint. Son oportunidades de oro para poner su proceso empírico en juego. La mayoría de las organizaciones adoptar prácticas ágiles para mejorar su agilidad – su capacidad de adaptarse eficazmente al cambio. Las Revisiones de Sprint facilitan esa capacidad dándole la oportunidad de ver de primera mano lo que fue el desarrollo y la oportunidad de ofrecer comentarios, críticas o sugerencias de todos los interesados del proyecto. Esta información no sólo es bienvenida, se debe alentar. Ayuda a orientar el desarrollo de productos haciendo pequeños cambios en el plan de liberación entre cada sprint. También ayuda a mitigar los riesgos de forma temprana. Los ojos más centrados en la evolución del producto y cuanto antes esto se hace, más eficaz será detectar y corregir problemas.

También muchos equipos utilizan los Sprint Review como una reunión para revisar historias completas, tareas y defectos y hacer cambios en sus herramientas de gestión de procesos. Este tipo de agenda es garantía de que no se pierda en una de las prácticas más valiosas que ofrece Agile.

Por lo tanto, es fundamental que los exámenes de Sprint sea exhibir programas funcionales Y asegúrese de dar a conocer estos Sprint Review a todos los interesados ​​en el proyecto y sean conscientes de ellos. Todos deben ser invitados a asistir y participar. Todos y cada uno debería sentirse lo suficientemente cómodos para dar información, sin temor de ser ellos mismos criticados. Esto es lo que hace un producto de éxito: la incorporación de ideas de un grupo diverso de personas que tienen un interés en el éxito del producto.

 

8. Integración de cascada de hitos

Los métodos de desarrollo ágil están diseñados para maximizar el valor para el cliente. Continuamente centrándose en las necesidades del cliente, se mejora enormemente el éxito del proyecto. Esto no es el caso de ciclos de vida de cascada (Waterfall). Los métodos de cascada son orientados a tareas, mientras que ágiles están orientados al valor. Debido a estos principios contradictorios, es contraproducente intentar alinear un ciclo de vida de desarrollo ágil con hitos en cascada. El plan de Agile es entregar valor al cliente temprano y a menudo, mientras se adaptan fácilmente y eficazmente para cambiar. El plan de en cascada es completar un conjunto predefinido de tareas a tiempo y dentro del presupuesto y se utilizan para entregar un producto que se ajusta a un conjunto de requisitos definidos cerca del inicio del proyecto. Hitos, como alfa y Beta, se utilizan en los ciclos de vida en cascada para ayudar a medir el progreso. Pero utilizando métodos ágiles, el progreso se mide desde el trabajo acabado: software funcional. Si un proyecto en cascada está al 30% hecho, no tendrás absolutamente ningún software funcional. Si un proyecto ágil está al 30% hecho, tendrá un 30% de las características del producto totalmente terminados y entregado a su cliente. Intentar integrar estos dos ciclos de vida no le permite obtener los beneficios de desarrollo iterativo de (Agile), por no hablar de que no tiene sentido. Y si su organización intenta medir el progreso de un proyecto ágil mediante el uso de hitos de la cascada, falla completamente. Este comportamiento nos ocurre cuando se adopta de forma superficial métodos ágiles. No interrumpir prácticas Agile por intentar integrar los principios de la cascada.

9. Definición de procesos alrededor de herramientas

Scrum ha sido cuidadosamente planificada para ayudar a los equipos de desarrollo de producto a poner en práctica los principios ágiles. Un marco de proceso Scrum proporciona métodos, directrices y mejores prácticas para ayudar a obtener los beneficios de apoyo de principios y valores ágiles. Definiendo sus procesos basados en este marco, se adapta mejor para facilitar la adopción de Agile. Sin embargo, si define sus procesos alrededor de una herramienta específica, como para la administración del ciclo de vida, estará limitado a la visión de quienes desarrollaron esa herramienta. Incluso si tuvieron su industria específica y su dominio en mente, es muy improbable que abordaran todas las cuestiones que su organización se enfrenta al desarrollar y ofrecer sus productos. Los procesos deben ser diseñados por la organización, para servir a sus metas y objetivos. Nadie más puede hacerlo, sobre todo no un equipo de desarrollo que nunca ha interactuado con su organización. A menos que la herramienta se desarrolla en casa, ninguna herramienta cumplirá con todos los aspectos de su proceso.

10. La falta de formación

Una vez que su organización adopta Agile, la formación es fundamental para que los interesados comprendan sus funciones y responsabilidades y cómo ejecutar métodos ágiles de manera que obtendrá el máximo valor. También es importante que entiendan los principios ágiles y cómo su práctica puede mejorar sus productos, junto con la satisfacción del cliente. Incluso si todo el mundo tiene experiencia “desarrollando ágil”, no puede asumir tengan la necesaria, capacidad para ser exitosos con proyectos ágiles. Para garantizar que todo el mundo está en el mismo campo de juego y tiene expectativas similares (al menos) de qué es Agile, deberá ofrecer formación de alguien que tiene la experiencia (preferiblemente dentro de la industria) y quien tiene un historial comprobado de dominio de éxito dentro de un similar (si no el mismo). Esta formación debe adaptarse a su organización por un experimentado entrenador ágil o entrenador que ha invertido tiempo en la comprensión de su organización. Establecer una base con los conceptos básicos, y después de que sus equipos apliquen de forma efectiva de esas prácticas, pasar a una formación más avanzada. Puede ser prudente seguir con la formación de base tras el primer año para asegurar que nuevos actores (stakeholders) entienden el fundamento y las expectativas de la organización como un todo.

11. Scrum no es Kanban

Otro error tipico es el de intentar meter procesos que pertenecen al área de mantenimiento en un ciclo Scrum. Hay que diseccionar adecuadamente cada fase o ¿Historia – Tarea? para decidir si es Scrum o es Kanban. No todo es Scrum. Nos encontramos en muchos casos equipos alargando Sprints a los Product Owners para poder encajar acciones de resolucion de Bugs, Versionado, Refactoring, Fly Updates (actualizaciones al vuelo)… etc. Cada historia, proyecto, dominio es diferente y no siempre todo se puede encajar en un Sprint de Scrum. La experiencia de un Scrum Master es esencial para ahorrar tiempo y productivizar. .

12. Si haces Scrum haz KISS (Keep It Simple Stupid)

Los técnicos informáticos tienen la tendencia a complicar el código “buscando la simplicidad” en el número de líneas de código. Un código “elegante” no significa encapsular hasta la locura funciones, procesos o código de testeo. Un código elegante es aquel que es entendido por cualquiera y no solo por el que lo ha escrito. Se debe limitar en lo posible Interfaces, Polimorfismos, TDDs… etc. De esa manera, entre otras cosas, el cambio de un técnico por otro (ver punto 5, “Grupos de individuos”) está más alineado con la “agilidad” de poder hacerlo. Cuanto menos KISS menos SCRUM. Estamos haciendo “verdadero” Scrum directamente proporcionalmente a lo que nos acerquemos a codificar lo más KISS posible. .

13 Hacerlo uno mismo, ser ágiles

Sobre el papel, Scrum es un marco bastante simple. ¿Leer un par libros, asistir a una reunión de grupos de usuarios aquí y allá, seguir algún blog … ? Bien, mientras que Scrum puede ser simple, no es necesariamente fácil. La puesta de Scrum en práctica y obtener buenos resultados, realmente puede ser bastante desafiante. Si es sólo una cuestión de aplicar métodos documentados en un libro, probablemente sería bastante fácil. Pero es el factor humano el que dificulta el Scrum. Se puede aprender mucho por estudiar casos en Scrum, pero dos proyectos no son iguales. Y menos que se tenga la experiencia de luchar para resolver los problemas, entrenamiento y motivación de los individuos, frente a las críticas y la defensa de los principios de Agile, encontrar el éxito es bastante difícil. Para tener éxito con el Agile, especialmente al inicio, realmente necesita tener un entrenador experimentado ágil. Esta persona puede ayudar a definir un plan de producto, asegúrese de que las funciones y responsabilidades se entienden bien, ayudar a evitar obstáculos comunes y asegurar que está entregando valor poniendo en práctica los principios ágiles. Su entrenador debe provenir fuera de su organización. Aunque es de ayuda tener conocimiento del dominio de su producto, facilita aún más el trabajo tener un entrenador con una perspectiva discriminativa de su organización. Si está comprometido a ser ágil, DEBE COMPROMETERSE A HACERLO BIEN.