Deja que el responsable funcional o el product owner tenga visibilidad sobre el sprint

Transparencia absoluta y posibilidad de feedback dentro del sprint. Todo eso podemos conseguir si damos visibilidad al responsable funcional sobre el entorno de desarrollo.

Esto se puede hacer en dos niveles y dependerá del momento del proyecto si resulta conveniente hacerlo o no. En cualquier caso que el usuario elija. Un primer nivel es el entorno en el que se ve el día al día del desarrollo, en el que tendremos historias de usuario el sprint resueltas y otras que están en construcción. En un segundo nivel el entorno de integración en el que solo deberíamos tener historias de usuario resueltas.

Sobre esto puede haber opiniones para todos los gustos (y respeto todas), desde los que piensen que es contraproducente dar esta visibilidad, como los que crean que con que tengan acceso al entorno de integración es suficiente.

Solo con la posibilidad de obtener feedback que permita ajustar mejor determinados detalles ya estaría del todo justificado esta decisión. ¿Tiene sus riesgos? Claro que los hay, como puede ser el hecho de que el responsable funcional interfiera demasiado en el sprint, afecte al ritmo del equipo y por tanto al cumplimiento de los objetivos.

Esa interferencia puede ser provocada por su deseo de cambiar una historia de usuario en pleno sprint (una cosa es ajustar detalles y otra darle un enfoque sensiblemente diferente) o por sus nervios si no terminan de ver unos resultados de calidad (muchas veces esto es provocado por trabajar con un entorno inestable, por eso hay quienes defienden que visibilidad sí pero solo al entorno donde se muestren las historias de usuario completadas).

Ante esto, lo mejor es recordar al usuario cuáles son las reglas del juego y hacerlo cuantas veces sea preciso.

Si quiere cambiar una historia de usuario, mejor prepararla bien y que sea en el siguiente sprint, anulando por tanto esa tarea en el actual. Si piensa que no se van a cumplir con los compromisos del sprint se le dan las explicaciones que sean oportunas.

Feedback, cuanto antes mejor pero con intención

El desarrollo de un producto que satisfaga las expectativas del usuario requiere poner en contraste de manera sistemática las distintas versiones que se van obteniendo en cada iteración, pasen o no a producción, con las ideas que tiene el usuario, las cuales evolucionan de la mano del sistema.

Esto es así porque las ideas no se aclaran hasta que son tangibles, por muy buenas ideas que se tengan y/o muy claro se tenga cuál debería ser el resultado final. En otros contextos como son, por ejemplo, las obras de arte, los mismos artistas que son, además, sus propios usuarios (independientemente de que la creación la adquiera un tercero), necesitan trabajar sobre la solución y en muy contadas ocasiones, todo sale a la primera.

Pensar que la solución no se obtiene a la primera no es una actitud derrotista o una bajada de brazos sino de ver el proyecto desde una perspectiva más realista.

Las ideas son solo hipótesis que cobran forma cuando se materializan en producto. Cuanto más se tarde en corregir las desviaciones entre el producto y las expectativas del usuario más costoso resulta volver a encontrar el camino, por eso el feedback no solo es necesario sino que cuanto antes empiece a aplicarse mejores resultados se obtendrán a la par de un mejor aprovechamiento de los recursos disponibles.

No olvidemos, sin embargo, que se debe desarrollar con intención, el feedback no es un salvoconducto para la programación por permutación o para probar hipótesis que no han sido lo suficientemente reflexionadas. Si se actúa de esa manera se desvirtúan los beneficios del feedback, pasando de un enfoque evolutivo a otro basado en el prueba y error, que no niego que en alguna ocasión para funcionalidades que no se tienen claras pueda ser de utilidad, pero que no debe ser la práctica habitual en un desarrollo de software en el que se trata de adquirir el mayor valor posible con respecto al esfuerzo invertido.

Sincronización de los sprints en proyectos con más de un grupo de trabajo

Teniendo en cuenta que habría que estudiar cuál es la solución más adecuada en cada proyecto, soy de la opinión de que resulta más productivo a la vez de que simplifica la gestión, tener sincronizados los sprints de los diferentes grupos de trabajo que participan en el desarrollo de un producto.

Tal vez una primera cuestión, antes de analizar el tema de la sincronización, podría ser si tiene sentido tener varios equipos o no, la respuesta es que depende del número de personas que participan, de si se pueden independizar los desarrollos de manera que no exista gran acoplamiento en los trabajos, de si se tiene uno o más proveedores, de la localización geográfica…, y por supuesto del proyecto.

Si tenemos varios equipos de trabajo es porque de manera acertada o errónea se ha determinado qué es la mejor opción en estos momentos. Superada esa primera decisión, toca determinar si los equipos entregan a la vez o no.

Podría dar igual si cada equipo va desarrollando partes totalmente independientes del producto, es más, podría resultar hasta más productivo de cara a un cliente (aunque no es más que un efecto óptico) ver cómo de manera continua se están añadiendo nuevas funcionalidades al sistema, en lugar de esperar todo un sprint para ver un nuevo incremento. Sin embargo, resulta complicado encontrarnos con situaciones en la que los desarrollos se encuentren totalmente desacoplados, ya que llegará un momento donde será necesario integrar las piezas del puzzle que unen unos desarrollos con otros y esto sucederá tarde o temprano y más de una vez.

Este tipo de desarrollo es demasiado vertiginoso tanto para los propios gestores técnicos del proyecto que tienen que tratar de sincronizar e integrar trabajos de equipos que trabajan en tiempos distintos, como para los propios usuarios que no terminan de trabajar sobre un producto asentado lo que afecta a la calidad de su feedback, a la par de someterles a una gran presión ya que además de eso, deben seguir colaborando en el refinamiento de la pila de producto, proporcionando toda la información y material necesario para que los equipos de proyecto puedan cumplir con sus compromisos.

Además, resulta más fácil alinear los objetivos de varios equipos, así como fomentar su colaboración, ya que tienen un horizonte común que no es otro que la fecha de finalización del sprint, independientemente de las tareas que tengan que realizar cada uno.

A todo lo anterior hay que sumarle el overhead que supone la gestión de más procesos de pasos a producción, que se multiplicarían con aquellos casos en los que sea necesario realizar subidas fuera de sprint para resolver incidencias críticas.

Desarrollo de software. Se dan por supuestas demasiadas cosas

Uno de los motivos que dan lugar a deficiencias funcionales, problemas de integración, numerosos bugs, etc… es que los desarrolladores damos demasiadas cosas por supuestas.

También es un mal de los responsables funcionales pero debemos tener en cuenta que somos nosotros los que mandamos sobre nuestra cocina y por tanto, decidimos si tenemos suficientes ingredientes o no para poder elaborar nuestros platos. Otra cosa bien distinta es que nos “obliguen” a cocinar sin la materia prima necesaria, quienes toman esa responsabilidad deben saber que difícilmente de esta forma saldrá el plato esperado.

¿Por qué se dan por supuestas tantas cosas?

- Falta de comunicación. Es el principal motivo. Nos da pereza y/o pudor tener que estar consultando cosas, incluso en determinados momentos de manera continua. Tenemos que intentar evitar esas sensaciones, nuestro objetivo debe ser contar con toda la información necesaria para poder realizar nuestro trabajo con intención y de manera efectiva. No debemos cubrir los huecos que dejen los usuarios o nuestros compañeros salvo que sean cosas evidentes.

En el ámbito del equipo de desarrollo, las reuniones de tipo Daily Scrum ayudan mucho, si no lo has puesto en marcha, prueba y verás como mejora la comunicación del equipo; si ya la has puesto en práctica y piensas que no te funcionó, ¿realmente has llegado a obtener mejores resultados no aplicándola?.

En el desarrollo iterativo incremental la comunicación entre desarrolladores y responsables funcionales es intensa y es uno de los beneficios más importantes que aporta este enfoque. No solo obtenemos feedback en las demos o en las retrospectivas, no solo se revisan las prioridades en la preparación de la pila de sprint, sino que la comunicación debe ser frecuente para ir preparando el siguiente sprint mientras se desarrolla el actual (lo que se suele denominar refinamiento de la pila de producto).

No pongas muros, tíralos. La comunicación es esencial en el desarrollo de software.

- No rematar. Este es otro de los grandes problemas que tenemos los desarrolladores y uno de los aspectos que marca la diferencia entre un buen desarrollador y un gran desarrollador. ¿En qué consiste? Tendemos a relajarnos cuando estamos a punto de conseguir el objetivo, en ese intervalo entre el casi y el completo no se termina de hacer el esfuerzo final y se terminan dando por supuestas demasiadas cosas.

William Grosso. La atención y los errores

Comenta William Grosso que: “El código que aburre al programador es probable que contenga errores”. Esta reflexión es extensible a cualquier trabajo que no nos parezca lo suficientemente motivante como para centrar nuestro enfoque en él.

Cuando desviamos la atención de la tarea que estamos realizando se incrementan drásticamente las probabilidades de que cometamos errores.

La atención se desvía cuando encontramos una situación u otra tarea que nos parece más interesante y/o porque hay algo que nos preocupa o inquieta.

Cuanto más interesante (por el motivo que sea) nos parece una tarea más capacidad tenemos de mantener nuestro enfoque en la misma y menos errores tendremos como consecuencia de despistes, además de manera inconsciente le daremos más vueltas (productivas) a nuestro trabajo con el objeto de eliminar (o por lo menos reducir) posibles incidencias porque estaremos más implicados en que el resultado final sea lo más óptimo posible.

No siempre vamos a tener la oportunidad de que nos llegue trabajo interesante o motivante. En este caso si las tareas no lo son implícitamente tendremos que ser nosotros los que pongamos ese interés o esa motivación y si nos ponemos a buscar encontraremos motivos para ello y si aún así no lo conseguimos tendremos que tirar de profesionalidad para intentar que el trabajo salga de la mejor forma posible y mantener el enfoque en el mismo todo lo que se pueda.

Desarrollo de software. Las expectativas importan

Gestionar las expectativas es fundamental en nuestra profesión y es algo que no solemos hacer bien y que es causa de pérdidas de confianza, desgaste y de minusvaloración del trabajo realizado (nosotros mismos lo hacemos pequeño cuando intentamos “vender” algo más grande de lo que realmente es).

¿Por qué fallamos en esto? Los motivos pueden ser muy diferentes: no terminamos de ver (o no queremos ver) el problema y por lo tanto no lo transmitimos o lo hacemos demasiado tarde, tenemos miedo de la reacción de la otra parte o simplemente no le damos importancia a las expectativas que pueda tener el usuario (algo muy peligroso porque un proyecto surge de unas necesidades y de la expectativa de darles una solución).

No es sencillo transmitir al área usuaria que no se va a poder cumplir lo que se tenía pensado inicialmente y lo que hasta este momento parecía que se iba a poder conseguir, ¿por qué no es sencillo? pues porque se pedirán explicaciones (y es natural que así sea porque le estamos cambiando la imagen mental que tenían del proyecto) y las mismas no siempre se van a entender, seas sincero o no (mejor sincero).

¿Qué hacer? Lo importante es explicar qué ha llevado a esta modificación en las expectativas y qué ventajas supone hacer un ajuste a las mismas, ¿ventajas? perseguir quimeras en el proyecto no solo supone engañarnos a nosotros mismos sino que además supone inflingirnos un castigo en forma de esfuerzo desbocado que se traducirá probablemente en unos resultados deficientes.

Esto no es un alegato al incumplimiento de las planificaciones sino de intentar exponer mi punto de vista sobre una realidad: es muy complicado acertar en los plazos y presupuestos del proyecto para el alcance que se defina, es posible que ese alcance cambie o que funcionalidades que se esperan más simples sean más complejas y, además, a lo largo del proyecto pueden ocurrir infinidad de circunstancias que impidan un desarrollo lineal del mismo.

Teniendo en cuenta esa realidad gestionar las expectativas de manera adecuada resulta fundamental para alcanzar los objetivos marcados en el proyecto. ¿Cómo cumplir objetivos si se ajustan las expectativas? Generalmente las expectativas incluyen funcionalidades no imprescindibles o con mayor complejidad de la necesaria, ahí es donde podemos trabajar para seguir manteniendo el pulso al cumplimiento de objetivos.

A veces el ajuste no será suficiente y se requiere un mayor aporte presupuestario y/o un mayor plazo para la ejecución del proyecto. ¿Qué pasa cuándo no se puede o cuándo no se llega a un acuerdo? Problemas para todos (cliente y proveedor), mi recomendación es que lo mejor es intentar llegar a un acuerdo satisfactorio y eso pasará también porque las partes asuman su responsabilidad en que se haya llegado a esa situación (que no necesariamente tiene que deberse a un mal desempeño en el proyecto sino que puede darse el caso de que el problema partiera con la estimación inicial de presupuesto (principalmente) y plazos).

Bertrand Meyer. Madurar las soluciones

El producto resultante de un proyecto de desarrollo de software requiere de un período de maduración que comienza con el inicio del mismo a través de los ajustes que se realizan en las diferentes iteraciones y a través del conocimiento adquirido dentro y al final de las mismas (no solo se trata de aprender del feedback, se puede aprender también mientras se analiza una historia de usuario y nos apoyamos en estrategias tales como prototipado, pantallazos, etc…).

La solución no se tiene clara desde el principio, nadie la tiene ni usuarios ni desarrolladores (cada uno dentro de su ámbito de actuación) y lo más probable es que la visión que ambas partes tengan del producto en ese momento difieran sensiblemente.

El conocimiento inicial es limitado y esto eleva la probabilidad de que cometamos errores.

Es cierto que por algo tendremos que empezar y eso ya supone una apuesta pero eso es diferente a jugar todas tus cartas a una solución y tirar con ella hasta el final que es lo que sucede en los ciclos de vida clásicos. En estos casos también se madura la solución pero más a nivel técnico que funcional lo que da lugar a los problemas habituales en la aceptación del producto o tras su puesta en producción y es el desajuste entre lo que el usuario recibe y las expectativas que tenía puestas en el mismo.

En el proceso de maduración tendremos probablemente que desechar decisiones que tomamos en etapas anteriores precisamente por el hecho de no haber acertado o por existir otras soluciones más efectivas y válidas. Tirar y volver a hacer tiene un coste pero más caro resulta ir hasta el final con una solución no satisfactoria.

Lo importante es hacer un producto cada vez mejor aunque no consigamos un avance lineal en el proyecto.

Bertrand Meyer realizó la siguiente cita: “Las malas ideas y las más complicadas (que a menudo son las mismas) a menudo aparecen las primeras, se necesita tiempo para que aparezcan las simples y elegantes”.