Estimados lectores, la actividad de este blog ha bajado en los últimos meses por que estamos migrando el servicio a nuevo concepto de comunicación Kiodomo.
En breve esperamos poder comenzar la nueva etapa de comunicación de contenidos sobre Scrum y las Metodologías Ágiles.
Perdonad el retraso de la puesta en marcha del nuevo proyecto.
Un cordial saludo.
Algo tan sencillo como comunicar es uno de ingredientes principales de Scrum.
No hay confundir comunicar con hablar, es mucho mas que hablar, hay que comunicar aparte de palabras, sentimientos, estados de emoción y otras circunstancias personales.
Un equipo es un ente orgánico, vivo, compuesto de varias personas y conectadas entre sí, si una de ellas no comunica se convierte en un miembro aislado, que lo único que consigue es disminuir la velocidad del equipo y distorsionar las comunicaciones existen,tes dado que no aparecen las suyas.
Comunicar significa permitir la libertad de expresión de todos los miembros, libertad que no se debe entender por un “todo vale”, hay que ejercer el diálogo con el resto del equipo dentro de un trato respetuoso y normal.
Todos los miembros del equipo cuando comienzan a trabajar como tal, deben entender que la comunicación no es algo que sale de forma espontánea, que se necesita un rodaje, unos inicios que vayan desarrollando su propia dinámica de grupo. Se necesita tiempo para reconocer los símbolos y gestos que muchas veces comunican igual que las palabras.
Es por esto que en los equipos de Scrum deben comenzar con una aceptación del bien el equipo sin querer imponer opiniones individuales, o forzar a miembros a hablar excesivamente sin estar preparados.
El Scrum Master cumple una función fundamental para que la comunicación fluya, debe conseguir sacar de todos sus compañeros que comuniquen todo lo que crean necesario, que no se guarden nada, es importante no dejar nada en el tintero, esto puede hacer que uno de los miembros del equipo no se encuentre todo lo satisfecho que debería con su trabajo realizado.
Además el Scrum Master debe intervenir en cualquier conflicto que surja, debe retomar la senda de esa comunicación, encauzarla hacia un lado constructivo y erradicar cualquier sentimiento negativo que se pudiera producir. Su labor debe ser de rescatar lo positivo, auspiciar que los propios miembros del equipo encuentren la solución, y que cualquier conflicto se acabe convirtiendo en una solución satisfactoria.
Por último es muy importante que las comunicaciones se produzcan entre personas, si es imposible tener una conversación cara a cara, si tiene que recurrir al email o otro sistema de mensajes, es mejor que no sean comunicaciones extensas, dado que cuanto mas se escriba mas interpretaciones se pueden dar, lo mejor es comunicar de una forma neutra y sin imposiciones. Las comunicaciones escritas se pueden interpretar de muchas formas, y si ha habido un conflicto lo normal es interpretarlas en su lado negativo.
En resumen, trabajar en equipo supone supone tener que comunicar no solo palabras, si no también sentimientos y estados de ánimos, y todos los miembros tienen que hacerlo, por que así la velocidad del equipo se acerca a la realidad y la dinámica de equipo es muy enriquecedora, tanto para cada persona como para la empresa.
Existe un problema latente en la relación con un futuro cliente: La presentación de un presupuesto que no corrompa la filosofía ágil.
Normalmente los clientes están habituados a tomar unos valores numéricos para tomar decisiones sobre los presupuestos que le presentan las empresas candidatas a realizar un servicio. Estos valores numéricos conllevan una rigidez que oculta parcialmente los valores emocionales y racionales.
Los clientes normalmente solicitan en los presupuestos una cantidad exacta en unidades de producción y plazos de entrega, no quieren asumir los principios de Agilidad en esta cuestión. Suelen estar encantados con la gestión de entregas por iteraciones, la disponibilidad de variar las prioridades a lo largo del proceso de creación, en definitiva, admiten y entienden todos los valores positivos de la Agilidad, pero el caso concreto de concertar un precio y nos plazos, quieren tener una rigidez que no concuerda mucho con los principios ágiles.
Si se cae en la idea de cerrar un presupuesto por “X” puntos de esfuerzo, ya se está encorsetando todas las actuaciones futuras, igualmente si se traducen estos puntos de esfuerzos en horas. Esta no debe ser la solución.
Para intentar corregir el planteamiento base que tiene el cliente se pueden intentar varias soluciones:
.- Exponer al cliente la velocidad del equipo que contratará.
.- Explicar el coste de las historias de forma general.
.- Hacerle ordenar por prioridad las historias necesarias para sacar la primera versión del producto.
Si el cliente tiene claro estos tres puntos se puede ordenar que es lo necesario para sacar el producto en su primera versión, como conoce la velocidad aproximada del equipo y el coste general de las historias el mismo tiene conciencia de los plazos previstos para la finalización del trabajo inicial. Con esto se consigue que sea el cliente, y no la empresa que realiza la oferta, la que vea el coste y los plazos de la finalización del trabajo encargado.
Trasladar al cliente la gestión de estos datos hace además que entienda que es difícil reflejar en un documento la Agilidad, y que todo lo que pone siempre es relativo y no absoluto.
Y a la hora de facturar siempre es mejor imponer un pago al final de cada iteración, dejando así también abierta la propuesta económica. Este punto es importante también de cara al cliente, dado que puede incluso dar por finalizado el trabajo sin tener que abonar la cantidad máxima prevista, permitiendo al cliente dar por finalizado el trabajo cuando considere oportuno.
En resumen, una buena práctica para que un presupuesto recoja la esencia de la Agilidad, es dar al cliente los parámetros y que sea el mismo el que configure su “Mapa de ruta”, dejando abierto el camino sin tener que poner unos valores numéricos.
La tendencia natural cuanto se esta realizando Scrum durante un largo tiempo es querer adaptarlo mejor a las necesidades de la empresa. Unos de los aspectos que se trata es valorar el número de reuniones, el obejto de las mismas y si es necesario modificarlas.
Algunos apoyan la creación de nuevos tipos de reuniones durante el Sprint, otros por mantener o disminuir las que actualmente existen:
-Planificación tareas
- Reunión Diaria
-Presentación de producto
-Retrospectiva
La reuniones básicamente son una herramienta mas de Scrum que mejora la comunicación interna del equipo y también con los clientes. LAs reuniones como están estructuradas dentro de Scrum actualmente consiguen que exista una comunicación fluida, directa y suficiente, no hay necesidad a priori de aumentar el número de las mismas.
Si hiciera necesidad de celebrar una reunión de urgencia esta debe realizarse, pero siempre avisando por adelantado de su contenido y duración. El problema viene por la tendencia que tienen muchos Product Owner de convocar reuniones alegando una urgencia que de verdad no tal.
Lo normal es que mientras se desarrolla el Sprint las reuniones se adapten de forma natural a las necesidades de comunicación de los equipos.
Hay una corriente de opinión Scrum que cree necesaria la introducción de una reunión llamada Backlog Grooming. Existe una corriente general que apuesta por este tipo de reuniones. En resumen podemos decir que son reuniones de mantenimiento de los proyectos, se deben celebrar tres días antes de la reunión de estimación.
Scrum duplica la productividad en las mismas horas de trabajo