archivo

Archivo de la etiqueta: Ken Schwaber

Comenta Ken Schwaber que (traducción libre): “Scrum es como comprar un espejo y crear un programa para mirarte en él muchas veces a la semana recibiendo una evaluación crítica de lo que se refleja en él”.

Schwaber lo centra en Scrum pero perfectamente podría ser válido para cualquier enfoque iterativo incremental en el que existe feedback, retrospección y un seguimiento de cada una de las iteraciones.

Es muy importante hacer esta evaluación continua de lo que estamos haciendo, cómo lo estamos haciendo y el resultado (el producto) de nuestras actuaciones (de todo el equipo incluido el Product Owner).

Generalmente se deja esta visión crítica para el final y normalmente suele ser demasiado tarde. Todos lo tenemos claro: si hay desviaciones o errores debemos corregirlos cuanto antes. Sí, puede llegar a ser pesado, puede romper el ritmo, pero siempre será mucho mejor eso que seguir un camino que sabemos que no lleva a ningún sitio, de nada sirve hacer un producto que puede funcionar pero que no se aproxima a lo que necesita, quiere o espera el usuario.

Hace un tiempo publiqué un artículo en el que comentaba la siguiente cita de Ken Schwaber: “El software que funciona es la principal medida de progreso”.

Cuando lo hice sabía que iba a crear una cierta controversia ya que se trata de una afirmación muy directa y contundente. Teniendo en cuenta que Schwaber es cocreador de Scrum y fue firmante del Manifiesto Ágil no es de extrañar que pudiera hacer esa reflexión.

Realmente la clave está en la palabra “funciona” porque por un lado habla de un software en ejecución que cumple con unas expectativas y especificaciones en un determinado nivel de avance de su desarrollo y por otro porque esa palabra no solo encierra eso ya que el “funciona” es mucho más: software mantenible (deuda técnica acorde a las características del producto), experiencia de usuario y con el nivel de testing y verificaciones necesario también acorde a las características del sistema.

Muchos proyectos de desarrollo de software han quedado en la fase de análisis o diseño tras un montón de documentación, yo he vivido en primera persona eso y he sido testigo también de esa circunstancia y el que esté libre de pecado que tire la primera piedra, por eso estoy de acuerdo con la cita de Schwaber con los matices indicados en el párrafo anterior.

Hace poco he leído otra cita de Ken Schwaber que es totalmente congruente con la anterior: “Las métricas se utilizan en el desarrollo en cascada porque no se tenía ni idea de lo que estaba pasando así que intentábamos medirlo todo”.

¿Son los entregables no software en un desarrollo en cascada hitos significativos para medir un avance real en el proyecto?

Avance es, pero ¿cuánto tiene de ficticio?, ¿cuánto de real?, ¿cuál es su riesgo?.

El pasado ya fue, de él nos queda la experiencia adquirida que será más o menos en función de ese pasado y de la actitud que hayamos tomado ante nuestros aciertos y, sobre todo, ante nuestros errores.

El futuro es lo que construimos con el esfuerzo de hoy a partir del conocimiento adquirido en el pasado.

Es necesario marcarnos objetivos porque de lo contrario caminamos sin rumbo pero manteniendo el enfoque en el presente y no distrayéndonos con lo que puede o no puede ser.

En el desarrollo de software perdemos mucha energía y mucha motivación pensando en lo que no es o en lo que no tenemos que en intentar solucionar el problema que tenemos ahora.

Solo podremos pasar al siguiente nivel si pasamos este y para ello tenemos que mantener nuestra atención en el presente, en nuestro contexto. Esto no quiere decir que debamos cerrar los ojos ante lo que puede pasar o ante lo que nos vamos a encontrar, sino en enfocar nuestros esfuerzo en lo que hay ahora y en lo que podemos hacer dentro de esta situación actual.

Tal vez nos gustaría que el proyecto hubiera evolucionado de otra manera, que las circunstancias nos permitieran trabajar como nos gustaría y tener el producto en el estado en que quisiéramos. Es humano pensar en lo que no se tiene pero se convierte en un inconveniente cuando eso provoca una situación de bloqueo.

Sobre este tema Ken Schwaber realiza la siguiente reflexión: “Céntrate en lo que se puede hacer en lugar de frustrarte por lo que no se puede hacer”.

¿Por qué la necesidad de la figura de un responsable funcional, de un Product Owner o de un Product Manager? Pues porque incluso teniendo la organización unos objetivos bien definidos, en diferentes departamentos se tendrán prioridades distintas en cada momento no necesariamente incompatibles con los objetivos de la organización.

Si la situación de partida es el de una organización sin objetivos definidos (entiéndase objetivos definidos si están por escrito y son conocidos por el conjunto de la organización) resulta más complicado todavía armonizar las tareas de los diferentes departamentos.

Ken Schwaber describe perfectamente esta situación en la siguiente reflexión: “Ventas y marketing quieren respuestas rápidas a cada oportunidad que llama a la puerta. Los desarrolladores necesitan centrarse en el desarrollo del producto. El caos en una empresa es a menudo causada por la incapacidad de resolver estos conflictos”.

Tomando como base ese ejemplo, cada departamento se centra en sus objetivos: ventas y marketing quieren conseguir ventajas competitivas, desarrollo llevar a cabo de manera adecuada el producto. ¿Cuándo se produce el conflicto? Cuando son varias las personas de ventas y marketing la que llaman a la puerta de desarrollo, para cada una de las cuales lo suyo es lo más urgente y prioritario.

Por ese motivo cada producto debe tener un responsable que establezca las prioridades en la evolución del mismo (haciendo las consultas pertinentes dentro de su departamento) y si existen varias líneas de producto y la capacidad del departamento de desarrollo no puede satisfacer todas las necesidades que se plantean, se necesita un responsable que priorice las actuaciones a realizar sobre el conjunto de productos.

El día a día parece indicarnos que el objetivo es ejecutar trabajo y cuando la mentalidad de toda una organización es esa se entra en una espiral peligrosa en la que solo importa terminar tareas, bien, mal o regular y si no se consiguen finalizar dentro de unos parámetros presupuestarios adecuados darlas por terminadas estén como estén o con una terminación lejos de la expectativas planteadas.

En nuestro sector esa forma de actuar se encuentra muy extendida y como no podía ser de otra forma ha contribuido al desprestigio que tiene nuestra profesión.

La ejecución de un trabajo o de una tarea solo es significativa si cumple las expectativas que se tenía depositada en ella en detalles incluso que el propio cliente desconoce o no valora de manera adecuada en primera instancia como por ejemplo que el sistema además de cumplir las especificaciones del usuario y proporcionarle una buena experiencia de uso sea fácilmente mantenible (no todas las personas para las que se desarrolla software tienen en cuenta ese factor), pasa sin incidencias significativas a producción, se respeta la garantía con unos tiempos de respuesta adecuados, etc…

Estos detalles marcan la diferencia y crean relaciones duraderas con los clientes y crean una imagen positiva de la organización. Es cierto que es complicado mantener un determinado nivel pero no por ello debe dejar de ser un objetivo llegar a él y superarlo.

Todo lo anterior queda resumido en la siguiente cita de Ken Schwaber: “La calidad no es una variable basada en proyectos, sino un activo corporativo”.

Dentro del ámbito de un equipo de proyecto los rumores relacionados con aspectos profesionales, en las relaciones entre las personas del equipo, en las relaciones con el resto de stakeholders, en las relaciones con el resto de la organización, etc… debe ser el menor posible porque es un elemento de distracción evitable, genera malos entendidos e incluso según la naturaleza del rumor puede afectar a la motivación o a la estabilidad de miembros del equipo.

Dentro del ámbito del proyecto también debe cuidarse este aspecto entre todas las partes que intervienen, por los mismos motivos que los que acabo de exponer pero haciendo especial énfasis en los malos entendidos.

En el ámbito de un departamento o de una organización también debería minimizarse la existencia de rumores, si bien resulta mucho más complicado conforme el tamaño y complejidad de la misma y el número de empleados crece.

Ken Schwaber considera que “Donde hay rumores, no hay una buena comunicación” y yo creo que efectivamente así es ya que en este tipo de contextos la información solo fluye entre una serie de personas que después queriendo o sin querer la filtran completa o sesgada a otras personas dentro o fuera de la organización y a partir de ahí el mensaje queda distorsionado.

El desarrollo de software es algo muy complicado como para añadirle elementos de resistencia adicionales que pueden ser perfectamente evitados a través de una política o estrategia de comunicación adecuada dentro del equipo de proyecto y con los stakeholders.

El desarrollo de software no es solo son procesos, metodologías, arquitecturas, programación, etc… hay algo más, mucho más importante que es la relación entre las personas que intervienen en el proyecto.

Si falla esa relación, esa comunicación entre las personas, esa búsqueda de un objetivo común, esa necesidad de trabajar juntos para alcanzarlo difícilmente va a funcionar todo lo demás por muy bien que se trabaje.

También está el bagaje profesional y personal, ese background que te ayuda a intentar tomar las mejores decisiones (aunque no siempre se acierte) incluso en contextos complicados y/o que no son conocidos por nosotros.

Si se trabaja como un equipo se tendrá la capacidad de integrar el background de todos, si no es así no es ya que no se aproveche ese talento y esa experiencia sino que esas diferentes visiones tenderán a convertirse en fuerzas que empujan en distinto sentido y provoca situaciones de bloqueo en el proyecto, desgaste, etc…

Ken Schwaber considera que no todo son procesos y metodologías, sino que hay algo más: “Una metodología te dice lo que tienes que hacer, un proceso es un framework que establece algunas restricciones. Una metodología no puede decirle a la gente que hacer cuando nunca han estado allí”. Es decir, tras la metodología quedan los desarrolladores (las metodologías son generalizaciones y no pueden tener en cuenta cada situación concreta de un proyecto) que son los que al final tienen que tomar las decisiones.