La experiencia y el conocimiento suman, pero tu actitud multiplica

Hace poco escuché una frase a un coach que me gustó mucho: la experiencia y el conocimiento suman, pero la actitud multiplica. Fijaros en la fórmula: (E+C)*A. Toda nuestra experiencia que vamos acumulando en cuanto a desarrollo software es vital, así como el conocimiento que vamos adquiriendo a base de la lectura y formación. Sin embargo, todo esto no sirve absolutamente de nada sin una actitud correcta y profesional. Una actitud de esfuerzo y búsqueda de la excelencia. Aún si tenemos poco conocimiento y poca experiencia, nuestra actitud nos llevará a buscar la manera de desarrollar todos esos skills que nos faltan.

actitud

Pero, ¿Qué ocurre si llevamos muchísimos años trabajando sin plantearnos si hay maneras mejores de hacerlo o simplemente sin ser autocríticos con nuestra forma de proceder? Este relato, está orientado a llevarte a la reflexión. Hoy en día, en España, “Scrum está de moda” y muchos adoptan la metodología pensando que es una cuestión principal consistente en leer un libro básico como por ejemplo Scrum y XP desde las trincheras (el cual no dejo de recomendar como iniciación) y seguir el procedimiento sin plantearse realmente de forma crítica si realmente tiene sentido lo que están haciendo, convirtiendo su día a día en rituales y referencias a una documentación que siento decirlo y a muchos les dolerá, pero resume tanto las cosas que puede llevar a la confusión en algunos casos si esta lectura no se complementa con otras (y os dejo aquí algunas sugerencias).

Naturalidad-infancia-Suavinex

A continuación os dejo un relato que escribí hace años. Este relato aunque está lleno de humor negro, no deja de presentar una realidad, al menos en España, que es la falta de profesionalidad. Empresas deciden adoptar una metodología (sea cual fuere, en el caso del relato Scrum, pero como veremos…podría ser cualquier otra) y eligen a personas para liderar el cambio organizacional que no están preparadas. Quizá han acumulado años de experiencia, pero su actitud no es precisamente la adecuada. Normalmente esto se produce por el contexto y falta de motivación. Usaba el nombre de Patrick B. tratando de buscar una relación entre este tipo de persona y la película American psycho. Os dejo con el relato.

american

A Patrick B. le tocó ser Scrum Master: momento y lugar inadecuados él decía sonriendo. En su empresa las cosas iban mal y los proyectos no terminaban del todo bien. Se dieron cuenta de que el 49% de los proyectos terminaban con un sobrecoste, el 27% no terminaban y se cancelaban y el resto estaba al borde de o acabar mal o cancelarse. Aunque había un pequeño número terminaban con éxito, cosa que nunca llegaron a entender. Algunos decían que era por la involucración de cliente en esos proyectos, otros decían que era suerte. A Patrick B. simplemente, no le importaban demasiado estos números.

Chuck Norris - Scrum master

Pero como iba diciendo, Patrick B. era Team Leader. Sumar, quitar y poner horas ya no tenía ningún misterio para él. Con su Gantt en la mano se sentía bastante seguro y “sus chicos”, como él los llamaba, estaban “a tope”. Si eso de la Zona de confort existiera, creo que la de Patrick B. era de látex con doble capa, con un televisor y con un par de pufs para apoyar sus cansadas piernas. Su vida era maravillosa, siempre cumplían los hitos, de una manera u otra. Tenía trucos que nadie conocía, como mandar la entrega en un CD rayado a cliente para tener cinco días más de desarrollo. Infalible.

scrum norris - gantt

Su empresa, una gran multinacional que poseía grandes, pesados y seguros procesos para todo. Tenía en el plan de desarrollo software un modelo en V descrito. La primera vez que escuchó de él, se imaginó que era algo novedoso, pero al parecer llevaba aplicado bastante tiempo. Lo leyó una vez y casi obligado. El caso es que fuera lo que fuera, parece ser que no funcionaba del todo y no tenían claro por qué. Patrick B. sabía que alguien había escrito el documento y lo había subido a control de configuración un tiempo atrás. ¿Qué más había que hacer para que funcionara?

ni idea de lo que hablas

Comenzó la moda en la que las grandes multinacionales con sus pesados, completos y e inexpugnables modelos en V y en cascada querían pasar a eso de las metodologías ágiles. Querían cambiar su filosofía, adaptarse al cambio. En algunas empresas, se contrata a un agile coach o especialista en metodologías de desarrollo. Patrick B. tenía un amigo que se dedicaba a eso y decía que es una gran trampa.  Muchas empresas normalmente no quieren cambiar su forma de trabajar y lo que quieren es que las nuevas formas de trabajar se adapten a ellos dando resultados positivos a corto plazo. Decía que contrataban a un agile coach y pensaban que sin ningún tipo de apoyo por parte de la dirección y mediante extraños rituales conseguirían llevar a cabo esos cambios tan deseados.

dilbert_ideas

Otras empresas contratan a un consultor externo. Pero Patrick B. decía que solían ser gente muy teórica que querían hacer cambios radicales. “Si quisiéramos hacer cambios radicales llamaríamos a Longueras”,  decía Patrick. “Estos devoradores de libros, están media hora y te cobran un ojo de la cara”. Alguien le contestó una vez que no le cobraba los 10 minutos de tiempo por resolver el problema, si no todo el tiempo que había invertido en aprender cómo resolver su problema en 10 minutos.

longueras

El caso es que a Patrick B., le cayó el tema agile y le tocó empaparse de todo esto de los “agiles”. Como Patrick B. era un tipo con recursos, lo primero que hizo fue teclear www.google.com  y buscar “agile V Model” y Eureka! Encontró una página que se titulaba “¿por qué Agile es mejor que V-Model?“. Le pareció curioso que estuviera la séptima y que hubiera antes páginas extrañas que hablaban de manuscritos, comunidades y trincheras. Patrick B. pensó que es lo mismo que cuando buscas cracks que te sale porno por todos sitios.

agile vmodel perturbado

Patrick B. vio un poco los dibujos y sintió que ya sabía de qué iba. Tras un análisis de 30 segundos llegó a la conclusión de que estaba muy bien desde el punto de vista teórico, pero en proyectos de verdad, de los que acaban con sobre-coste o se cancelan, esto no era aplicable… y menos en el suyo. Nunca le llegó a gustar eso del burndown chart: “eso de que la línea vaya hacia abajo y no hacia arriba, le resultaba extrañamente inquietantemente”.

sherlock2

Se  creó un backlog con las cosas que había que hacer, “historias de usuario” las llaman los agilistas. Debían tener una prioridad y un criterio de aceptación. Esto del scrum, es un marco de trabajo así que el bueno de Patrick B. decidió hacer su propia implementación adaptándolo a las necesidades de su proyecto. Decidió que iba a ser product owner y scrum master ya que estos roles se adaptaban más a lo que él conocía de antes. Dicen que son roles que no son compatibles por tener objetivos distintos, pero Patrick B. suponía que esta advertencia era como la fecha de caducidad de los yogures, es decir, opcional.

1241915072NEURAS

Empezaron con las reuniones diarias. Al principio las hacían de pié, pero a partir de los 45 minutos ya les dolía la espalda y decidieron hacerlas sentados. Cada uno contaba lo que había hecho el día anterior y lo que iba a hacer ese día. Dejaron de usar la pizarra porque tener que actualizarla era agotador y la verdad es que nadie la utilizaba. Al poco tiempo tampoco le encontraron mucho sentido a la reunión diaria, salvo para tomar el café de la mañana. Conocieron a mucha gente durante estas dailies ya que la gente se paraba para ver que hacían y algunos acabaron quedándose por hábito. Patrick B. conoció a su mujer en una daily.

batman

Las historias de usuario se mantenían tanto tiempo en la pizarra en progreso que tuvieron que designar responsables de historia de usuario para “ver si eso se movía un poco”. Patrick B. decidió ahondar un poco, mirando el las retrospectivas de los equipos de desarrollo. No solía echarles un vistazo porque opinaba que la gente al final acaba quejándose y no siendo constructiva. Hizo una lista con los últimos sprints pero no obtuvo respuesta ninguna a su problema. Decididamente pensó que la gente se quejaba por vicio. He aquí algunas de sus incoherentes quejas:

  • Los test unitarios tardan 3 horas en ejecutar.
  • Baja cobertura.
  • Rama de desarrollo inestable.
  • Cambios en mitad del sprint.
  • Demasiadas reuniones.
  • Si no nos hacen caso, que no nos pregunten, por favor.

shutterstock_39087388-A

Para favorecer la comunicación, Patrick B. decidió implantar reuniones diarias donde participaran algunos miembros del proyecto de distintos equipos. Eran unos 20 diariamente y trataban temas tan variopintos como el problema que había habido con tal módulo de desarrollo, problemas en testing, en especificaciones o los problemas de Pepe el chico de mantenimiento, que todos los días pasaba por allí hasta que al ver tanta gente reunida decidió tomarse el café de por la mañana con ellos.

tapon-reuters--644x362

Como Patrick B. siempre decía, “esto de las metodologías ágiles es sólo aplicable a entornos de laboratorio. En el mundo real, no funcionan.” No tenían ningún resultado positivo, el número de historias de usuario resueltas no bajaban. La motivación de los equipos estaba por los suelos y la calidad del código estaba deteriorándose cada día más. Patrick B. no paraba de repetir que no funcionaba en entornos reales porque se trataba de metodologías de plastilina.

El jefe de departamento contrató a un consultor Agile muy famoso que les dijo que tenían que partir las historias para reducir el cycle time, los sprints deberían ser del mismo tamaño para poder medir la velocidad del equipo y tenían que volver a hacer retrospectivas, dailies y planificaciones en los sprints. Patrick B. no entendía cómo podía todo eso arreglar su problema. No veía en que podía ayudarles nada de lo que ese famoso agile coach les decía. En las páginas web que había leído sobre agile no ponía absolutamente nada de “cycle time”, o de que los sprints tenían que tener el mismo tamaño. Patrick B. finalmente llegó a la conclusión de que este consultor al que él había admirado durante tanto tiempo se había vuelto tan teórico que ya no tenía los pies en la tierra: en alguna ocasión hasta le había visto intentar levitar.

Coach

En definitiva, Patrick B. se dio cuenta de que nada de esto funcionaba así que decidió volver a la metodología que tenía antes. Un maravilloso modelo en V, que aunque nunca les había dado buenos resultados, estaban acostumbrados a utilizar. Su modelo en V era algo particular y por eso Patrick B. había hecho algunos ajustes:

  • No hacían un análisis previo porque era una pérdida de tiempo ya que los requisitos cambian.
  • Preferían empezar el desarrollo antes de tener los requisitos. Ya que daban prioridad al software corriendo frente a documentación exhaustiva.
  • No creían en los test unitarios. O sólo en aquellas partes importantes…y si hubiera tiempo.
  • En cuanto a la verificación si tenían tiempo lo harían. Pero lo más seguro es que reservaran un mes de la planificación antes de la calificación con cliente para resolver bugs.

american ps

Así, Patrick B. volvió a la oscuridad de la que procedía sin haber aprendido absolutamente nada y con la extraña convicción de que ninguna metodología ágil podía aplicarse a proyectos de verdad y concretamente… al suyo propio.

autocritica

Como vemos en el relato, el problema no es la metodología, simplemente la actitud de las personas. Al final decide volver a lo mismo que tenían antes, pero deciden ajustarlo a su propia comodidad, rompiendo con todos los principios de V-Model, de forma que tampoco están haciendo un modelo en cascada, simplemente están haciendo otro tipo de rituales. Este relato aunque es inventado, las cosas que se cuentan son cosas que en algún momento, en algún equipo y en alguna empresa han ocurrido tal cual. Os invito a reflexionar, si realmente somos parte del ritual, o parte de la solución. La autocrítica, es el primer paso de la excelencia.

https://www.scrum.org/ScrumBut

PDFicono EXTENDIDO

Anuncios

Scrum I: Nadar a través del cambio más que tratar de andar sobre las aguas.

Llevar a cabo un proyecto software con Waterfall es similar a andar sobre el agua, la única manera de tener éxito es mediante congelación…de los requisitos claro. Por eso Scrum es más nadar a través del cambio que tratar de hacer equilibrio sobre los cambios andando sobre el agua, teniendo en cuenta claro, que la congelación de requisitos nunca es una opción aceptable.

andar_aguas

No hay nada infalible, todo depende del contexto, las balas de plata sólo funcionan en las películas.

Posiblemente en software embarcado, donde tienes que cumplir una serie de normas de safety y donde está impuesto algún tipo desarrollo en cascada (Waterfall) por contrato, seguramente tengas que aplicar un V-Model, pero siempre habría que estudiar el contexto, porque creo firmemente que, por norma general, las metodologías ágiles se adaptan  a cualquier tipo de desarrollo software muchísimo mejor que las metodologías tradicionales debido a que todo desarrollo basado en Waterfall requiere como premisa que los requisitos sean inamovibles, algo que yo no he visto nunca en ningún desarrollo software. Alguna vez alguien ha intentado convencerme de lo contrario, pero siempre, de una manera u otra, el cambio está presente: que no cambie el texto no quiere decir que no cambie la interpretación de los mismos por ejemplo.

charles-darwin

Para explicar que es Scrum, empecemos por decir que ante todo no es una metodología: Scrum es un marco de trabajo (framework). Un marco de trabajo es una caja de herramientas más un libro de instrucciones y recomendaciones. Si fuéramos a cortar un tronco de madera con una sierra eléctrica, podríamos coger la sierra de nuestra caja de herramientas, leer las recomendaciones de uso y seguridad, y empezar a usar la sierra como nos convenga. El marco de trabajo, hace hincapié en que si utilizas indebidamente algún principio que describa no se hace cargo del resultado obtenido. Debido a esto, si cogemos nuestra sierra eléctrica, la ponemos en marcha y nos ponemos a cortar una viga de hierro, posiblemente no obtengamos el resultado esperado. Pues con Scrum ocurre exactamente lo mismo.

sierra electrica

LOS EVENTOS

Una de las herramientas que proporciona Scrum son los eventos. Existen varios tipos de eventos pero quizá el más relevante a la hora de explicar Scrum es el Sprint. Denominamos Sprint a una ventana de tiempo que suele ser entre 1-4 semanas durante las cuales vamos a desarrollar una parte del producto a la que se le denomina un incremento de producto. Obviamente un proyecto estará lleno de Sprints consecutivos que van generando incrementos de producto de forma iterativa. Cada incremento de producto es un entregable potencial que sustituye al incremento de producto del anterior sprint. No hay que sacar una release por cada sprint, pero potencialmente deberíamos poder hacerlo si fuera necesario. La idea es que cada sprint es un “miniproyecto” con su producto correspondiente. Al fin y al cabo, utilizar iteraciones y obtener feedback temprano es una manera de reducir el riesgo de scope creep y comprender mucho mejor que es lo que realmente nos está pidiendo el cliente: Individuos e interacciones sobre procesos y herramientas.

scopecreep

Un sprint contiene otros eventos como el sprint planning, la daily scrum, el sprint review y la retrospectiva del sprint. No los explicaré en profundidad en este primer artículo, pero son tremendamente importantes y posiblemente requieran un artículo independiente cada uno de ellos.

scrum sprint

La idea principal dentro de un sprint es que sea una ventana de tiempo donde se permita trabajar al equipo en el incremento de producto sin interrupciones. ¿Cuántas veces nos ha pasado que durante un desarrollo software nos aparecen tareas inesperadas? Algunas implementaciones de Scrum tienen artefactos como “la zona de trabajo no planeado o pozo”, “el carril de emergencia por donde vienen tareas…pues eso, de emergencia” y bueno innumerables implementaciones de trabajo “inesperado”. Uno de los factores más importantes de Scrum es que buscarnos maximizar el foco del equipo en el incremento de producto y para conseguirlo es necesario no interrumpirles en el sprint  (¿básico no?). Si realmente en tu contexto, aparecen tareas inesperadas constantemente puedes tener dos opciones: o asumes que parte del tiempo tu  equipo trabajan al 40%  o 50% (o lo que estimeis) y calculas la velocidad estimada en función a esto, o bien cambias el método a uno que se adapte más a tus necesidades, quizá Kanban, XP… o te inventas uno nuevo, pero no la llamas Scrum…llamaló “Joaquín” o “Mariano 2.0”…pero no deberías llamarlo Scrum.

mi propia metodologia

Un sprint está dividido a su vez en una serie de eventos que siempre se producen en el mismo orden y que su duración es proporcional a la duración del sprint que hayamos elegido. Primero viene la planificación del sprint, la ejecución del trabajo, la revisión del sprint donde una de las partes de esta reunión es realizar una demostración de lo realizado en el sprint (importantísima la retroalimentación o feedback) y la retrospectiva en donde el equipo analiza la ejecución y toma acciones de mejora. Y esto se hace una y otra vez, una y otra vez, una y otra vez…una y otra vez…. lo más importante de todo esto es que en cada iteración debemos mejorar a través de las retrospectivas y del feedback proporcionado a través del sprint review. Estas son las bases del Ciclo de Deming que es algo que es inherente a Scrum: respuesta al cambio sobre seguir un plan.

ciclo-pdca

Hemos reconocido que Scrum no es una metodología, y ahora toca romper otro mito: Scrum no es una metodología para gestionar proyectos, es una metodología para gestionar el ciclo de vida de un producto que puede formar parte de un proyecto o no. ¿Gestionas riesgos con scrum? ¿Gestionas costes con scrum?¿Gestionas stakeholders con scrum?. No, porque Scrum es una metodología de desarrollo de productos complejos no de gestión de proyectos, ni siquiera es solo para desarrollo software (definición que encontraremos en muchos sitios). Os dejo aquí la definición oficial de los creadores de Scrum.

sorpresa

Si tu empresa está desarrollando exclusivamente un producto, seguramente tendrá una serie de funcionalidades previstas (features), ¿Cuándo finaliza el desarrollo de ese producto? Pues cuando no hay más necesidades, normalmente cuando ya no se utiliza más, no hay más demanda del producto, es sustituido por otro mejor, etc. La lista de features (backlog) está viva y sólo  muere con el propio producto.

juez

¿Qué pasa si estamos en un proyecto? Un proyecto tiene un inicio, un final y unos hitos de entrega (definición de proyecto). Scrum se adapta bien a proyectos de desarrollo software porque realmente lo que haces es adaptarte al cambio que suele ser inherente a cualquier proyecto de estas características.  Además permite maximizar el valor del producto proporcionado a cliente, y esto al final se convierte en satisfacción del mismo. Al final el cliente no quiere que se hagamos malabares e interpretaciones para cubrir los requisitos que redactó años atrás a cualquier precio, lo que quiere es que le solucionen su problema, y para eso lo que hay que hacer es colaborar con el cliente: colaboración con cliente frente a negociación contractual.

Crossing out Plan A and writing Plan B on a blackboard.

En lo relativo a proyectos, he visto que suelen empezar de formas diferentes y estas suelen marcar, ya desde el principio, el fracaso o éxito del mismo con un alta probabilidad. Algo de lo que no solemos ser del todo conscientes la mayoría de las veces. Estas son las tres formas que recuerdo ahora mismo y seguro que hay alguna más.

  • La primera es obtenemos requisitos, muchos requisitos, los redactamos, esperamos conformidad, cambiamos la redacción de los mismos, lo trazamos a la RCP (Request for Proposal), volvemos a aclarar dudas, hacemos casos de uso (¿lo trazamos?…venga si…que nunca se sabe) y volvemos a tener más dudas que aclaramos con cliente, volvemos a tener dudas y bueno por fin, pasamos a diseño en el que sufrimos un ciclo parecido y luego lo implementamos muy rápido y con unos desarrolladores muy baratos porque hemos gastado mucho tiempo y dinero, y tras 10 años tenemos un maravilloso sistema hecho con tecnología y conceptos de 10 años atrás que entregamos a un usuario final, el cual está contentísimo…porque es el día de su jubilación y firmaría la aceptación hasta de un burro disfrazado de sistema contable. Obviamente es una exageración, pero no tan lejana de la realidad como creemos.

22sepBurroRELAX

  • La segunda es que somos conscientes de que no vamos a poder analizar todo, así que, decidimos ir codificando: “Yo sé cómo va esto, seguidme”…manta a la cabeza y para delante. Normalmente acabamos haciendo tantos cambios a la arquitectura (que podría estar bien orientada desde el principio o quizá no), que al final sólo nos queda decir: “esto lo que tenemos que hacer es volver a hacerlo desde cero”. Incluso usando buenas prácticas de desarrollo, tendremos algo que no cubra las necesidades del cliente: “Es imposible trabajar de otra manera” o “Los proyectos siempre son así” son comentarios típicos en este tipo de proyectos. La realidad es que una metodología que no se adapta al cambio siempre va a traer problemas en un mundo con tanta variabilidad como es el desarrollo software. Además, por otro lado, enfocar el desarrollo mediante una arquitectura software poco o nada adaptable a cambios hace que a lo largo del proyecto vayamos acumulando una serie de problemas (deuda técnica) cuyo coste de afrontar será elevadísimo (Os recomiendo ver este video de Tio Bob sobre Clean Architecture).

Seguidme

  • La tercera opción es “vamos a ir poco a poco y tratando de involucrar al usuario desde el principio y tratando de adaptarnos a los cambios de la mejor manera posible”. No tiene que ser Scrum, de hecho he visto gente que funcionaba así que no conocía nada acerca de Scrum, pero su metodología, a veces inventada, coincidía tanto con los principios ágiles que causaba asombro, aunque no tendría por qué, ya que las metodologías ágiles, surgieron de esta manera. De hecho diría más, XP nació justo de un problema que no resolvían las metodologías tradicionales (requisitos cambiantes), ahora tiene nombre, pero en su momento era una metodología inventada con unos principios muy sólidos: Software funcionando sobre documentación extensiva.

Como-emplear-la-comercialización-con-comentarios-de-clientes

LOS ROLES

Una de las cosas que dan más problemas en los proyectos es la indefinición de las responsabilidades ligadas a roles:

  • Jefe: “vas a ser…product senior support manager”…mmm… “adjunto”
  • Empleado: (contento) Y cuáles son mis responsabilidades.
  • Jefe:(confuso) Tu estate por aquí por las mañana temprano unas horas, unas 8, y estate atento en busca de señales.

O este otro ejemplo:

  • Jefe: “vas a ser…el Manuel Pérez del proyecto X”
  • Empleado: (contento) Y cuáles son mis responsabilidades.
  • Jefe:(confuso)  Pues lo que hace Manuel Pérez en su proyecto, lo vas a hacer tú en el proyecto X. Ale venga Manuel, nos vemos.
  • Empleado: (confuso) Pero si me llamo Jacinto…

Scrum lo que hace es definir estas responsabilidades. No habla de jerarquías, habla de responsabilidades, roles y colaboración. El scrum master es el encargado de que se siga scrum correctamente así como de ayudar al equipo a crecer y que logre sus metas (es un lider de servicio). El product owner es el encargado del producto y su misión es conseguir que las features que incluya cada incremento de producto den el mayor valor posible al cliente, y el equipo de desarrollo  es el encargado de desarrollar ese producto con la mayor calidad posible. Todos ellos pertenecen al equipo de scrum y no existen jerarquías, ni nadie posee más importancia que otro, todos son importantes para lograr un objetivo común, son un equipo.

teamwork (2)

Creo que uno de los grandes problemas a la hora de implementar Scrum es justo no entender los roles y un error común es tratar de hacer una correlación entre los roles tradicionales y roles Scrum. Curiosamente esta tendencia a intentar mapear lo que conocemos con lo que no conocemos, es algo que hacemos habitualmente de forma natural. Vamos a ver algunos ejemplos de tendencias,  he descrito cuatro pero hay muchos más:

  • La misma persona como scrum master y product owner. Este es un clásico, a veces porque no nos permiten tener product owner, otras veces porque no nos permiten tener un scrum master, y otras, porque no le damos importancia a la separación de responsabilidades. El problema es que ambas responsabilidades son incompatibles porque, en primer lugar,  ambos tienen que focalizar sus esfuerzos en cosas distintas que poseen competencias distintas y los cambios de contexto son complicados (por ejemplo en una retrospectiva tienes que actuar como facilitador neutral entre el equipo desarrollo y el product owner…el cual eres tú mismo…). En segundo lugar ambos roles necesitan atención plena, hacer dos cosas al mismo tiempo lleva a que hagamos ambas a medias y por último existe una tensión natural entre ambos roles necesaria para que se produzca negociación y colaboración que dé lugar a un equilibrio. Si es la misma persona esto no va a producirse o va a ser tremendamente difícil de afrontar. Efectivamente, en muchos sitios ambos roles son realizados por la misma persona y si son conscientes de que debería haber una separación y hacen el esfuerzo por separar ambos roles en su cabeza, todos me dicen lo mismo: se sienten como Jeckill y Mr Hyde.

Dr_JekyllMr_Hyde

  • El scrum master es el arquitecto del equipo, es un desarrollador avanzado que además les dice que hacer al resto del equipo, normalmente más junior. Si es cierto que existe “una modalidad” de scrum master que es uno de los desarrolladores que pueda actuar como tal, pero no es un jefe de equipo, es un desarrollador que además tiene como responsabilidad que se cumplan las reglas establecidas y ser vigía de la correcta implementación de scrum. El problema radica en que pensemos que este scrum master “va a asignar tareas al equipo” o que ejercer de alguna manera parecida a un team leader en metodologías tradicionales. El equipo es un todo, una entidad y tratar de poner a una persona de que reparta tareas o “vigile” al equipo no es algo que tenga que hacer un scrum master. Por el contrario, servir de mentor, cuidar al equipo, hacer de coach y ejercer como líder de servicio si sería algo aceptable. No obstante, la recomendación es que el scrum master no esté involucrado en el desarrollo, recordemos que debe ser neutral por el bien del equipo.

Orginal_John_Hannibal_Smith

  • En el equipo de desarrollo, tenemos figuras de más peso que otras que toman decisiones de forma unilateral. En un equipo todos tienen la misma importancia independientemente de si tienen más  o menos experiencia o, más o menos simpatía. La idea es buscar la sinergia y el trabajo en equipo, así como la responsabilidad compartida. Introducir este tipo de conceptos y jerarquías funciona en contra de esta premisa.

paraquesirven

  • En el equipo de desarrollo tenemos gente especializada (lo cual no es malo) pero sólo ellos saben y tocan ciertas partes del sistema y nos parece óptimo. No hay nada malo en tener especialistas pero lo que no es bueno es crear silos. Tener responsables de una parte del código, grupo de funcionalidades o lo que sea va en contra del principio de propiedad colectiva del código y en consecuencia nos trae silos.

every-software-developer-after-1am

LOS ARTEFACTOS

Los artefactos en scrum son el sprint backlog, el product backlog y el incremento de producto. El product backlog es una lista ordenada de cada cosa que requiere el producto y la única fuente de requisitos para cualquier cambio en el producto. El product owner es el responsable de este artefacto incluyendo su contenido, disponibilidad y ordenación. Es cierto que el scrum master, entre sus responsabilidades tiene la de ayudar al product owner a encontrar técnicas para optimizar su gestión y el equipo por otro lado ayuda a refinar los items, pero el máximo responsable del Product Backlog es el Product owner.

TeamProductOwner

Un product backlog nunca está completo, lo hemos dicho antes, muere cuando muere el producto. Normalmente al principio de proyecto los ítems del backlog están poco definidos y poco a poco van aclarándose más (rolling wave planning), partiéndose en otros más simples, creándose nuevos y desapareciendo otros. Esto es lo que se denomina proceso de refinamiento del backlog de producto. Como os habréis dado cuenta no hablo en ningún momento ni de user story, ni de épicas, ni de criterios de aceptación, ni de puntos de historia. Esto es debido a que scrum nunca habla del uso de estas técnicas, pero si queda abierto para que pueda utilizarse cualquier técnica que sea útil para su implementación. Obviamente, las user story son muy utilizadas y para su definición así como el uso de los criterios de aceptación. Del mismo modo para estimarlas es común el uso de puntos de historia, pero todo esto no es scrum, son técnicas que se han demostrado su efectividad y se han ido incorporando a las distintas implementaciones de scrum.

product backlog

Otro de los artefactos de scrum es el sprint backlog, se trata del conjunto de ítems del product backlog escogidos para que sean implementados durante el sprint. El sprint backlog surge tras el sprint planning y es fruto de la colaboración entre el equipo y el product owner para la planificación del sprint con el objetivo de lograr el Sprint Goal. Aunque el sprint backlog es normalmente la pizarra o tablero utilizado, como veis scrum no dice que utilicemos ni tableros ni pizarras. El uso de pizarras y post-its es una implementación del sprint backlog que proviene del visual management, técnica utilizada y que favorece tremendamente la colaboración en el equipo debido al poder tocar y visualizar las tareas (que de otra manera serían objetos intangibles). Al poder utilizar todos nuestros sentidos en una reunión face-to-face, esto mejora la comunicación y colaboración: se trata de una herramienta colaborativa.

daily

Scrum si que dice que esta información debe ser radiada y debe ser visible, por ese motivo el uso de visual management es tan habitual en cualquier implementación de Scrum. Actualmente con la aparición de herramientas como Jira, con plugins que permiten servir de apoyo al uso de scrum para realizar mediciones, gráficas, etc., se intenta sustituir en muchos casos estos tableros visuales por tableros electrónicos. Realmente, y esto es una opinión propia que seguro que encuentra muchos detractores, ambos tienen objetivos distintos (en un caso es colaboración y comunicación face-to-face, y en el otro lado es gestión y disponibilidad de las user story). Como he dicho antes, la información debe ser radiada, visible y disponible. Si tengo todos los miembros del equipo deslocalizados, el uso de un tablero de Jira puede ser muy útil, pero si no es el caso, sigue siendo igual de útil pero es bueno tener un tablero presencial para las reuniones diarias cara a cara.

facetoface

Otra cosa importante en Scrum es que el trabajo debe ser monitorizado diariamente mediante el tracking de trabajo que queda por hacer. En ocasiones se puede utilizar diagramas de burndown o burnup, pero como siempre, esto son herramientas que nos ayudan a la implementación y no imposiciones de scrum. Algo curioso, que ocurre muchas veces, es que las mediciones del trabajo realizado se proporciona no en “lo que queda por hacer” si no que  “hemos hecho hasta hoy”. Por ejemplo, esta tarea está al 80%, o al 50%. Este tipo de medidas las denomino “medidas tranquilizantes”, píldoras que ayudan a dormir mejor, pero realmente de poca utilidad a nivel de métrica. Lo importante es la estimación de lo que nos queda y no de lo que hemos hecho ya que lo que pretendemos es tomar decisiones en base a lo que nos queda por afrontar (lo hecho hecho está). Utilizar el argumento de que lo que queda es la resta de 100%-80%, por ejemplo, no es válido, ya que la estimación es engañosa, sobre todo si la cantidad de trabajo ha disminuido o aumentado a medida que ha avanzado la tarea (fijando el máximo a un valor y restando de la cantidad de trabajo que hemos hecho esconde este tipo de hechos que son muy importantes para tomar decisiones). Lo importante, al fin y al cabo es: cuanto me queda por hacer, lo demás es irrelevante.

7tDkrt8v8Gwp3L3X-F6948

Otro artefacto es el incremento de producto, del cual ya hemos hablado. Se trata de la suma de todos los ítems del backlog que están completos que es el resultado de cada sprint. Recordemos que es siempre potencialmente entregable al usuario.

Sprint-Planning-Meeting-outcome-es

DEFINITION OF DONE

Una de las cosas más interesantes cuando trabajas en proyectos tradicionales es el ruido que crea la falta de definición de cosas que se dan por hechas debido a que son de “sentido común”. Como dice el dicho: el sentido común es el menos común de los sentidos y es que cada uno interpreta las cosas según “sus propios estándares”.

Recuerdo hace años trabajando en desarrollo software tradicional que una de las cosas que más quebradero de cabeza nos daba a los team leaders era conseguir que las cosas estuvieran acabadas tal y como espera nuestro sentido común (el nuestro, el de cada uno, ese que difiere tanto del de los demás). De esta manera encontrábamos a desarrolladores que, terminada una funcionalidad, no habían explorado todas las posibles casuísticas y el software reventaba una vez habían dicho que “estaba terminado”, en otras ocasiones esperábamos que hubiera test unitarios con una cobertura mínima concreta y siempre había olvidos, y así podría enumerar miles de problemas que nos encontrábamos para sacar una release que se pudiera probar por el equipo de verificación y validación.

7e67fc67bcfd578da574731d43df9dd5.png

Esto que comento es algo muy habitual y no solo es cuestión de funcionalidades que no hacen lo que deberían tener que hacer. Otro ejemplo con el mismo problema de raíz es la definición de bug y su criticidad, que es algo que también suele quedar en manos del “sentido común”. Al final es un problema de falta de definición, ni más ni menos. Algo que algunos no dan la suficiente importancia y que puede generar una cantidad tremenda de desperdicio de horas de trabajo en discusiones. Lo importante es que todo el mundo esté alineado y todo el mundo sepa que significa que algo esté hecho o no hecho (o que es un bug y que significa que sea de prioridad crítica). La definición de Done (DoD) es algo que depende del equipo y ayuda al equipo a saber si un ítem del backlog puede ser acometido o no en un sprint durante la reunión de planificación.

claridad2

La definición de Done puede formar parte de los estándares de la organización. Esto, que se define a nivel organizativo, es lo mínimo que deben incluir los equipos en su DoD, sin embargo, la DoD va más allá y se espera que evolucione a medida que evolucionan los equipos, suponiendo que a mayor madurez mayor calidad en el incremento de producto.

Cosas que pueden formar parte del DoD: los criterios de aceptación que son proporcionados por el product owner, quality gates en cuanto a análisis estático de código y cobertura, haber cumplido ciertas reglas establecidas por el equipo, pruebas de rendimiento,  de aceptación y cualquier otra cosa que haya sido elegida por el equipo por mutuo acuerdo para mejorar la calidad del producto.

IMG_7460

Citando directamente a la nota final de la guía de scrum de Ken Schwaber y Jeff Sutherland: Los roles, artefactos, eventos y reglas de Scrum son inmutables y aunque implementar partes de scrum es posible, el resultado no es Scrum. Si es cierto que pueden añadirse otras técnicas o prácticas al framework como por ejemplo las 12 prácticas XP o cualquier otra cosa que mejore la implementación de la metodología. Sin embargo jamás hay que olvidar los principios, ya que son la base de todo. En el momento que tengas dudas, una recomendación: volver a los principios para volver a encontrar el camino.

PDFicono

 

REFERENCIAS:

[1] www.scrum.org – Guías de Scrum
[2]  Agile Estimating and Planning – Mike Cohn
[3] Clean Code – Robert C. Martin
[4] Extreme Programing Explanined: Embrace change – Kent Beck