Tag: teoria

Trabajando con el Product Backlog

Posted on by Juan in Scrum

Introducción

El Product Backlog es uno de los artefactos con los cuales trabaja el Product Owner pero no es de propiedad exclusivamente suya, de hecho cualquier miembro del Scrum Team debe tener acceso al Product Backlog pero el Product Owner es quien decide el orden de los items.

Si el backlog fuese secreto provocaría poca visibilidad por parte del Equipo de Desarrollo y lo que es peor no permitiría que todos los miembros del equipo contribuyan con ideas y opiniones recortando así la creatividad.

El Product Backlog, al igual que los demás artefactos, es propiedad del Scrum Team y para que éste lo pueda usar en su trabajo diario. Al ser un artefacto ligado con la táctica es necesario que todos en el equipo puedan verlo y sentirlo presente en el día a día.

Además de lo anterior el Product Backlog tiene otras características, tales como: ser finito, contener items que son diferentes entre sí en valor y nivel de especificación, ser dinámico, y ser alcanzable en un horizonte de tiempo corto.

Como tal el trabajo del Product Owner consiste en tener el Product Backlog ordenado incorporando el conocimiento más actual que viene del aprendizaje y la retroalimentación de los clientes. El trabajo del Scrum Mater será guiar al Product Owner y los desarrolladores para que el Product Backlog mantenga las características descritas en el párrafo anterior.

Producción versus Resultado

La producción es medible y observable, aun cuando el software es un elemento abstracto, pues esta ligada a la cantidad de algo que se produjo dentro de un Sprint. 

Por ejemplo podemos decir que en un Sprint cualquiera se implementaron X cantidad de items, se escribieron Y lineas de código, se escribieron Z pruebas automatizadas, o el porcentaje de cobertura de pruebas es del W%.

El resultado es más intangible y subjetivo pero aun así puede ser apreciado aunque no necesariamente se mida numéricamente. 

El mejor ejemplo de resultado es la percepción de si el equipo Scrum está construyendo el producto correcto que resolverá los problemas y necesidades de los clientes. Ligado a lo anterior está la percepción de los clientes que gustan del producto y lo compraran cuando este terminado.

Si bien es cierto que no se puede llegar al resultado sin la producción es económicamente mas conveniente tratar de alcanzar el mayor resultado con la menor cantidad de producción posible. La clave para esto es que el Product Owner pueda identificar que items del Product Backlog implementar primero. 

Existen varios atributos que pueden tener los items del Product Backlog que permiten ver si contribuyen mayor resultado, por ejemplo:

  • items que tienen un componente visual, es decir que los usuarios finales pueden ver en el producto e interactuar con el
  • items que al verlos en el producto los usuarios finales los conectan inmediatamente con una posible solución a un problema o necesidad que ellos tienen
  • items que un gran número de usuarios potencialmente utilizaran

Demás esta decir que cualquier item que se espere que produzca resultados positivos tiene que tener insertada la calidad. 

Definiendo Valor

El valor de los items puede definirse desde diferentes perspectivas pero es importante no perder de vista que siempre debe estar conectado a algo que los clientes puedan ver y pagar por él.

Muchas veces los desarrolladores tienden a pensar que primero deben hacer todo el trabajo de las capas más inferiores, que tiene valor solo técnico, para en varios Sprints posteriores recién empezar a implementar items que los clientes puedan ver. 

En este punto es frecuente que los clientes hayan cambiado de opinion o pidan cambios en los items pero estos cambios ahora son costosos pues hay que bajar varias capas y tocar mucho código. La consecuencia natural es que los desarrolladores se resistirán lo mas posible a hacer cambios restringiendo de esta manera la adaptabilidad del producto.

Por el contrario sí el abordaje arquitectónico permite desde el principio ver el producto y realizar cambios rápido se tiene dinamismo y adaptabilidad. Precisamente es en este escenario en el cual se puede tener items con mejor definición de valor, items como por ejemplo:

  • items que permitan realizar operaciones o flujos completos
  • items que permitan aprender como interactuaran los clientes con el producto
  • items que permitan descubrir nuevos clientes o descartar clientes que se consideraba que iban a utilizar el producto
  • items que ayuden a reducir el riesgo de que algún item no se vaya a usar una vez implementado completamente
  • items que permitan descubrir que tan frecuentemente serán utilizados

Un otro factor importante es considerar que en un producto están involucrados diferentes grupos y cada uno puede percibir el valor de manera diferente. Así por ejemplo:

  • Los stakeholders del negocio pueden pensar que el valor se conecta a vender el producto a la mayor cantidad de gente al mejor precio
  • Los usuarios y clientes perciben el valor de un producto que resuelve sus problemas y necesidades
  • El Equipo de Desarrollo ve el valor de implementar items que los desafíen técnicamente o por el contrario puedan implementar con su conocimiento actual

La labor del Product Owner consiste en balancear estos intereses para que los items acaben contribuyendo valor para todos los grupos involucrados.

El valor también puede conectarse con indicadores econométricos como por ejemplo estos:

  • costo total de propiedad es decir cuánto le constara al cliente adquirir y operar el producto a lo largo de su vida útil. Aquí es importante hacer notar que un producto con baja calidad sera muy costoso de operar y su horizonte de vida es mas corto.
  • costo de retraso que tiene que ver no solo con llegar tarde a un mercado con el riesgo de ser sustituidos por competidores, sino también con el costo interno de pagar salarios y otros gastos por un tiempo extendido.
  • margen entre cuento dinero esta costando desarrollar el producto y cuanto se espera recuperar y en cuanto tiempo

Ordenando Items

Ordenar los items del Product Backlog no es una tarea que debe considerarse tomando solamente una única perspectiva, por ejemplo ordenarlos tomando en cuenta el tiempo estimado de implementación de los items.

Pensando sistemicamente [Senge90] el Product Owner deberá identificar cuales son las variables relevantes y luego analizar si prioriza una por encima de las otras cual será el impacto. Por ejemplo, un item puede tomar poco tiempo para implementarse pero una vez implementado produce poco impacto en los usuarios.

Estos son algunos ejemplos de variables o criterios relevantes:

  • alineamiento estratégico con el objetivo que persigue el producto, es decir items que nos acerca mas a alcanzar la vision del producto
  • valor de negocio percibido a través de items que harán que por ejemplo el producto se vaya distinguiendo de la competencia y el negocio mejore su imagen 
  • valor para el usuario final determinado por el grado en que el item ayude a resolver un problema o mitigar un dolor
  • el tiempo de comercialización que se conecta a la noción de cuanto tiempo total pasa desde que se construye un item, se distribuye y se empieza recuperar la inversion  

Creando y Refinando Items

Los items como tal pueden provenir de fuentes diversas como por ejemplo estas:

  • Grupos de clientes que manifiestan sus necesidades y problemas que originan ideas de solución traducidas en items
  • Requerimiento regulatorios como leyes y políticas de gobierno que fuerzan a que el producto incluya ciertas características
  • Aprendizaje a través de validación de supuestos que derivan en items que si se deben incluir en el producto
  • Defectos que se acarrean de Sprints pasados o peor aun de una versión previa del producto que ya esta en producción 
  • Cuestiones técnicas como componentes, librerías, parches de seguridad, plataformas, etc. que si bien tienen un valor técnico presentan un riesgo de tiempo y desvío de enfoque importante

Una forma dinámica e iterativa de crear nuevos items es utilizar el concepto de un estudio de diseño en el cual se dibuja y se hablar acerca del item, como si se estuviese diseñando alguna parte de una casa en el estudio de un arquitecto. Bajo este enfoque se dibuja cómo debería lucir el item dentro del producto, se habla de porque y quién lo utilizara, se exploran alternativas, y se comentan riesgos y desafíos.

Las conversaciones pueden quedar registradas en videos y los dibujos en fotografías, todo este material puede ir a un wiki interno. El titulo de el item es el que se anota en una tarjeta que ira dentro del Product Backlog, si se una una herramienta en linea como Google Spreadsheet la lógica es la misma, el titulo del item ira en una celda de una hoja llamada Product Backlog [Larman17].

Para incrementar el envolvimiento y contribuciones de los clientes en el Product Backlog es posible, y de hecho recomendable, tener reuniones semanales o aun mejor tener a los clientes sentados cerca del equip para poder comunicación y retroalimentación fluida

Para refinar los items del Product Backlog resulta muy util realizar juegos colaborativos en los cuales intervendran clientes y el Scrum Team y cuyo objetivo es entender mejor no solo los items sino el porque son necesarios.

El refinamiento de los items debe realizarse como una actividad recurrente para ir incorporando descubrimientos y conocimiento a medida que se adquiere. Tratar de hacer un solo refinamiento para todo el Backlog consume demasiado tiempo y no necesariamente aportara valor pues los items no prioritarios cambiaran y necesitaran de todas maneras ser refinados posteriormente.

El propósito del Product Backlog a veces puede ser mejor comunicado a través de herramientas como: hojas de ruta del producto, wireframes y mapas de historias de usuario [Patton14].

Un producto enorme aun puede ser trabajado a través de un backlog pequeño pero que provea valor siempre y cuando este backlog corresponda al lanzamiento de un producto minimamente viable, un lanzamiento para aprender (globo de ensayo), o un producto con el mínimo de características que lo hagan comercializable. 

Conclusiones

El Product Backlog debe ser un elemento de uso cotidiano y que sirva para centralizar el trabajo y la discusiones del Scrum Team. Mas aun, debe reflejar el entendimiento actual del orden en el cual se quieren implementar los items para producir el mayor impacto posible.

Como tal este artefacto puede tomar formas diferentes pero en esencia no se debe perder de vista que es solamente una lista de cosas por hacer en un horizonte de tiempo finito.

Finalmente, el Product Backlog debe poderse ver, idealmente debe poderse tocar, para que cumpla mejor su función de elemento integrador y facilitador de la comunicación. 

Bibliografia 

Ohno13 Ohno T., 2013. Taiichi Ohno’s Workplace Management, McGraw Hill

Senge90 Senge P., 1990. The Fifth Discipline: The Art & Practice of The Learning Organization, Doubleday

Larman17 Larman C., Vodde B., 2017. Large-Scale Scrum More with LeSS, Addison-Wesley

Patton14 Patton J., 2014,  User Story Mapping: Discover the Whole Story, Build the Right Product, O’Reilly Media

Validando las Suposiciones del Producto

Posted on by Juan in Scrum

Introducción

Un producto, cualquiera que éste sea, mientras está en una etapa temprana de su ciclo se basa en muchas suposiciones. Por ejemplo se supone que tenemos el conocimiento, los recursos económicos, y disciplina para construir el producto correcto. 

Desde luego las suposiciones anteriores pueden o no ser ciertas, en el mejor caso si lo son nos llevaran a construir un producto pero ese no es el fin de la historia. También suponemos que conocemos el alcance del producto, quienes lo compraran, cuando dinero pagaran y en que mercado se venderá.

Ese segundo grupo de suposiciones son aun mas inciertas que las primeras pues están conectadas a factores externos variables como fluctuaciones del mercado, competidores y la economía misma de un país.

En esencia crear suposiciones y creer que se materializaran no es equivocado, pero la clave esta en validar si son verdaderas o no lo más pronto posible. Por tanto el gran servicio que un Product Owner presta no sólo al equipo sino a la organización, los clientes y el mercado mismo, es contribuir productivamente a la validación temprana de suposiciones.

Scrum Soporta la Validación de Suposiciones

Uno de los puntos centrales de Scrum es obtener retroalimentación sincera de clientes reales al final de cada Sprint, es precisamente a través de ésta dinámica que Scrum enfatiza la necesidad de validar suposiciones.

En muchos equipos he encontrado la tendencia a esperar un Sprint más para tener más cosas que mostrar a los clientes; desde luego esto no es recomendable y es generalmente un reflejo de que Scrum no se entendió bien o técnicamente el Equipo de Desarrollo esta abordando la construcción del producto usando un enfoque arquitectónico que no permite tener funcionalidad observable al final de cada Sprint.

Existen suposiciones técnicas que el Equipo de Desarrollo debe validar lo mas pronto posible, la mas común de ellas es que podemos poner código en producción fácilmente [Humble10].

Scrum a través del empoderamiento que concede al Equipo de Desarrollo para tomar decisiones técnicas favorece el que éste pueda invertir en aprender cómo poner código en producción desde los primeros dias del primer Sprint.

Una otra suposición técnica es que todo código que se construya luego se podrá probar a mano de forma rápida, eficaz y exhaustiva. Desde luego esta es una suposición muchas veces herrada pues el testo manual es lento, puede tener errores y omisiones. 

Una vez más Scrum fomenta que el Equipo de Desarrollo mejore sus prácticas de ingenieria para que inserte la calidad en el producto mismo a través de pruebas automatizadas [Jeffries00].  

Enfoques para la Validación de Suposiciones

Decidir qué suposiciones son las que se validaran primero tiene una influencia directa en el ordenamiento del Producto Backlog y por eso el Product Owner debe estar consciente de que existe varios enfoques. Estos son tres de los mas comúnmente empleados:

  • Validar primero las suposiciones que implican el mayor riesgo de negocio
  • Validar primero las suposiciones que implican el mayor riesgo técnico
  • Validar primero las suposiciones que ofrecen las mayores posibilidades de aprendizaje

Balancear la incertidumbre en estas tres esferas (negocio, técnica y conocimiento) es complicado pues el Product Owner tiende a priorizar el negocio por encima de las otras dos. Si esta acaba siendo la tendencia en todos los Sprints muy probablemente el Equipo de Desarrollo acabara construyendo un producto plagado de deuda técnica y acarreara hacia el futuro una deuda de conocimiento. 

Parte de la labor del Scrum Master es colaborar con el Product Owner para que el balance entre esas tres dimensiones se mantenga. La receptividad y pensamiento sistemico en el Product Owner son esenciales en este punto para poder entender y aceptar lo que el Scrum Master trate de exponer [Schwaber04].

Para decidir cual enfoque escoger muchas veces resulta util ver que tenemos disponible, es decir, si quiero validar riesgos de negocio tengo que tener disponible usuarios reales, si quiero validar riesgos técnicos tengo que tener la infraestructura o dispositivos, si quiero aprender tengo que tener disponibilidad de tiempo y recursos de aprendizaje.

En función de lo que haya disponible, sea más barato o sea mas accesible se podrá tomar una decision de que suposiciones validar primero. 

Conclusiones

El trabajo en ciclos, el empoderamiento, la retroalimentación, la comunicación constante, y el espíritu de colaboración son algunos de los elementos que ofrece Scrum para permitir validar suposiciones lo más pronto posible.

Un buen Product Owner debe conocer y utilizar estos elementos y estar siempre dispuesto a cambiar el rumbo del producto en función de lo que vaya aprendiendo.

Una suposición también importe a considerar es que el Product Owner es el adecuado para el producto, quizás esto no sea cierto y una vez más Scrum a través de la transparencia y el coraje ofrece la oportunidad de que el mismo Product Owner pueda darse cuenta de que alguien más puede tomar su lugar. 

Finalmente y reiterando lo antes mencionado, suponer no es malo pues es parte del ciclo de desarrollo de un producto, lo que es malo es no validar esas suposiciones a tiempo y generar gran desperdicio con un producto construido que no sirve a las necesidades de los clientes o simplemente es el producto equivocado.

Bibliografia 

Humble10 Humble J., Farley D., 2010. Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation, Addison-Wesley

Jeffries00 Jeffries R., Anderson A., Hendrickson C., 2000. Extreme Programming Installed, Addison-Wesley Professional

Schwaber04 Schaber K., 2004. Agile Project Management with Scrum

Entendiendo a Clientes y Usuarios

Posted on by Juan in Scrum

Introducción

El trabajo del Product Owner tiene mucho que ver con el descubrimiento y la validación. Para ambos tipos de trabajo la comunicación cercana y efectiva con los clientes y usuarios es esencial.

El descubrimiento parte del dialogo acerca de cuál es el problema, dolor o limitación del estado actual de las cosas. Frecuentemente ese descubrimiento detona la necesidad de construir una solución al problema traducida en un producto de software.

En otras oportunidades el descubrimiento puede tener que ver con la detección de un producto que puede prestar un servicio que el mercado todavía no descubrió qué necesita, o por lo menos no existe como producto de software. 

Cualquiera que sea la fuente del descubrimiento el Product Owner si se decide a iniciar el desarrollo de un producto, lo estará haciendo basándose en un sinnúmero de hipótesis.

La forma más efectiva de validar las hipótesis de un producto siempre sea la validación con clientes y usuarios reales que puedan interactuar con el producto mientras se construye y no cuando ya esté totalmente construido.

Investigación de Clientes

Al construir un producto se produce un fenómeno similar a la paradoja del huevo o la gallina; es decir, primero se define el producto y luego el cliente o al revés.  

Concebir un producto, construirlo y luego salir en búsqueda de clientes no es un trabajo fácil y de hecho el mundo esta lleno de productos que se fabricaron y luego no se vendieron.

Encontrar clientes con un problemas y a partir de ahi derivar un solución/producto implica menos riesgo pero a su vez trae el gran desafío de identificar el segmento del mercado global que contiene potenciales clientes [Watts17].

Si el producto es para el consumo dentro de una organización el fenómeno se repetirá, en lugar de construir el producto y luego imponerlo a los usuarios funcionara mejor determinar quienes son ellos y qué características de un producto necesitaran.

Una forma simple de segmentar un mercado es considerar variables como ubicación geográfica, es decir no hacer un producto para el mundo entero sino para un mercado más pequeño y definido [Pichler16]. Esta simple distinción geografía reduce grandemente la complejidad sistémica del producto que se intentara desarrollar. 

Cuando un segmento esta bien definido, o por lo menos más reducido, será mas sencillo tratar de interpretar el problema o necesidades de los clientes del segmento. Sin embargo esto llevara muchas veces a la existencia de prioridades en conflicto.

Existen varios técnicas que un Product Owner puede utilizar para tratar de dilucidar con un grupo de clientes que podría ser prioritario, la base de estas técnicas siempre es la comunicación efectiva que permite que alguna de las partes en contraposición acabe descubriendo que puede mover su opinión sin ver sus interés seriamente lastimados.

De esas técnicas “Buy a Feature” que es parte de Juegos de Innovación [Hohmann06] es una de las que mejor funciona a la hora de dilucidar con un grupo de clientes con opiniones en conflicto que vale la pena o no incluir en un producto.

Una vez definidos los segmentos resulta muy util emplear técnicas como Personas   [Cooper04] para poder identificar y entender que objetivos y expectativas tendrá un grupo de usuarios con el producto.

Las personas pueden tomar diferentes formatos que van desde los más sencillos a los más complejos y crearlas puede tomar mucho o poco tiempo, pero lo que yo recomendaría es mantener la simplicidad tanto en el formato y el la inversion de tiempo en su creación. Después de todo siempre debe ser posible cambiar la descripción de estas personas a medida que se va entendiendo mejor el producto y sus potenciales usuarios. 

Personas es una excelente técnica para conceptualizar usuarios potenciales pero tiene la limitación de que no permite recolectar retroalimentación real acerca de cómo los usuarios utilizarían la aplicación [Adzic09].

En la practica si se tiene un esqueleto que camina este debe presentarse a los usuarios reales para ver cómo interactúan manos en el teclado con el producto que se esta desarrollando.

En este punto enfatizó que es vital que los usuarios “toquen” el producto, es decir que puedan verlo e interactuar con él, solamente así se puede saber cómo se comportarían y si el producto resolvería alguna de sus necesidades o no. 

Antes de construir un esqueleto que camina se podrían utilizar técnicas para tratar de entender qué quieren los clientes, como por ejemplo observar sentados junto a ellos como hacen realmente su trabajo y cuales son los problemas o limitaciones que experimentan. Entrevistas y grupos focales también pueden servir para el mismo objetivo. 

Lo anterior siempre trae el riesgo de caer en una larga fase de análisis en papel y con discusiones pero sin construcción del producto de software en sí. Por esta razón recomiendo hacer las cosas en paralelo, es decir, tener a los usuarios cerca, ver qué quieren hacer con el producto, implementar rápidamente y mostrárselos para ver si es lo que querían.  

Descubrimiento de Productos

Durante la fase de descubrimiento del producto existen varios aspectos que luego contribuirán positivamente con los resultados que el producto puede alcanzar. Estos aspectos se basan en poder entender que harán los usuarios con el producto, es decir cómo interactuaran con él. 

Para poder apreciar las interacciones de los usuarios con el producto es necesario que estos puedan verlo y es ahi donde intervienen instrumentos como diseño de la experiencia de usuario, diseño de la interacción y diseño visual.

Este tipo de diseño puede realizarse con herramientas de software o mejor aun todavía solamente con papel y marcadores, la idea siempre es mantener la simplicidad y permitir que cualquier cambio sea tan rápido como borrar o dibujar de nuevo.

Técnicas que vienen en formato de Juegos de Innovación [Hohmann06] son especialmente útiles para permitir “ver” con mayor claridad que características podría tener un producto.

Sin embargo descubrir un producto en papel no es lo mismo que verlo funcionando en una computadora o dispositivo móvil por lo cual urge validar la hipótesis de cómo podrá lucir realmente en esos dispositivos.

Abordar el desarrollo del producto de software usando un concepto de arquitectura como el Esqueleto que Camina [Hunt99] permite ver en pantalla el producto desde el primer Sprint y así descubrirlo con los usuarios de manera efectiva.  

Conclusiones

Partimos de la observación de que la correcta definición de un producto no existe como tal antes de construirlo; por tanto se necesita un proceso de descubrimiento y aprendizaje continuo en el cual interviene todo el Equipo Scrum junto con los stakeholders, clientes y/o usuarios finales.

Este proceso de aprendizaje requiere ser dinámico y para esto herramientas ligeras y comunicación efectiva son fundamentales. Al abordaje de la arquitectura del producto también debe estar acorde con la adaptabilidad que se requiere para un aprendizaje dinámico. 

Finalmente el Product Owner será el actor que articulara al producto y sus clientes, en esta función sus habilidades interpersonales, comunicativas y de negociación serán vitales.

Bibliografia 

Watts17 Watts G., 2017. Product Mastery: From Good To Great Product Ownership, CreateSpace Independent Publishing Platform

Pichler16 Pichler R., 2016. Strategize: Product Strategy and Product Roadmap Practices for the Digital Age, Pichler Consulting

Hohmann06 Hohmann L., 2006. Innovation Games: Creating Breakthrough Products Through Collaborative Play, Addison-Wesley Professional

Cooper04 Cooper A., 2004. The Inmates Are Running the Asylum: Why High Tech Products Drive Us Crazy and How to Restore the Sanity, Sams – Pearson Education

Adzic09 Adzic G., 2009. Bridging the Communication Gap: Specification by Example and Agile Acceptance Testing, Neuri Limited

Hunt99 Hunt A., Thomas D., 1999. The Pragmatic Programmer: From Journeyman to Master, Addison-Wesley Professional

Describiendo el Propósito y la Estrategia

Posted on by Juan in Scrum

Introducción

Un producto tiene muchas formas de ser concebido, a veces proviene de la idea de un soñador y otras de una concepción colectiva, pero sin importar su origen necesita de alguien que se encargue de llevar la idea a través de un viaje para que se torne en un producto viable en el mercado. 

Haciendo una analogía, un producto es como un barco que navega pero precisa de alguien que pueda ver la costa en el horizonte y diga hacia allá vamos. Continuando la analogía, la linea recta hacia el objetivo no siempre es el mejor camino o el más seguro, por lo cual a medida que se navega se van haciendo adaptaciones sin perder de vista el objetivo.

Un Product Owner tiene dentro de su rol trazar la vision del producto, descubrir un propósito inspirador, y concebir una estrategia que sea lo suficientemente flexible y adaptable que permita evolucionar el producto escuchando al mercado.

Como cualquier otro de los roles que Scrum propone, el rol del Product Owner no es para cualquier persona pues ciertas características, experiencias, y rasgos de personalidad preparan mejor a un individuo para triunfar en este rol.

Estrategia del Producto

La visión de un producto es la que permite tener un propósito articulador, algo que ayuda a que la gente que trabaja en el producto entienda que están construyendo algo que tendrá un gran impacto y no simplemente perdiendo el tiempo construyendo algo que nadie vaya a utilizar. 

Descubrir la visión de un producto es el primer paso para poder entender porque haremos lo que haremos, a quienes servirá el producto, qué causa defenderemos, y que problema queremos resolver o cambiar.

Existen varias formas de descubrir la vision, una de las más sencillas pero a la vez eficientes que he encontrado es utilizar la metáfora del Circulo Dorado [Sinek11] que permite encontrar el porque antes que el cómo y el que. 

He utilizado el Circulo Dorado en múltiples contextos, países y organizaciones, y estos son algunos consejos que puedo proveer:

  • Tener un grupo diverso y multidisclinario fisicamente presente en el mismo lugar
  • Utilizar un papelógrafo, post-its y marcadores
  • Poner un timebox de no mas de 15 minutos
  • Incluir en la articulación del porque frases incluyentes como “nosotros creemos” o “nosotros queremos”
  • Incluir en la articulación del porque palabras que toquen sentimientos como por ejemplo “familia”, “madre tierra”, “vida”, “salud” o “comunidad”

El poder del Circulo Dorado está en que él porque descubierto con esta técnica debe resonar con quienes los escuchen; dicho de otra forma ésta será la causa inspiradora que motivará al grupo de personas a perseguir una vision de un futuro mejor. 

Según Pichler [Pichler16] una vision efectiva tienen cuatro características principales:

  1. Es amplia lo cual permite al producto tener grados de maniobrabilidad y hacer adaptaciones para de todas maneras alcanzar el objetivo
  2. Es compartida por toda la gente que trabaja en el desarrollo del producto y quienes lo consumirán
  3. Es inspiradora pues busca hacer una diferencia en el mundo a través de un producto o servicio
  4. Es concisa y fácil de comunicar con palabras simples y consecuente todos la entienden 

Una vision clara es la que permite derivar una estrategia más concisa y realista. La estrategia trazará el camino para alcanzar la vision, es decir del cómo la vision se hará realidad. 

Para que la estrategia cobre vida ésta necesita de pasos más concretos y es ahi donde interviene la táctica. A nivel táctico también se incluyen los detalles necesarios para desarrollar el producto, muchas veces al hacer el desglozamiento en lo táctico detona un descubrimiento que acaba haciendo que la estrategia cambie.  

Por tanto, de la vision se deriva la estrategia y de la estrategia la táctica. Lo anterior es de vital importancia para un Product Owner que no debe perderse solamente en la escritura de historias de usuario. 

Planificación y Pronóstico de Productos

La planificación de cuando se entregará un producto tiene mucho que ver con el ciclo de lanzamientos que este tendrá. Si el producto es software no buscamos una sola entrega del producto cuando esté completamente terminado, por el contrario, buscamos hacer lanzamientos parciales en ambientes de producción reales para que los usuarios puedan proveen retroalimentación realista.

Como parte de la planificación el Product Owner deberá decidir con el resto del equipo y los stakeholders la frecuencia con la cual se pondrá en producción. La periodicidad de estos lanzamientos dependerá de varios factores y en muchos casos puede verse una correlación directa entre la capacidad técnica del Equipo de Desarrollo y la frecuencia con la cual este puede llevar código a producción. 

Algunos ejemplos típicos de periodicidad puestas en producción incluyen:

  • Una vez al año 
  • Una vez por semestre
  • Una vez por cada trimestre del año
  • Una vez al final de cada mes
  • Al final de cada Sprint de dos semanas (dos veces al mes)
  • Una vez cada semana
  • Una vez cada día
  • Varias veces al día

Desde luego la periodicidad que se escoja puede estar desasociada de las lanzamientos formales [Forsgren18]. Así por ejemplo el equipo puede tener la capacidad de poner código varias veces al día en producción pero el Product Owner puede decidir lanzar el producto formalmente en un ciclo de cuatro meses.

El punto anterior es especialmente importe porque muchas veces he encontrado la confusion entre el concepto de lanzamiento (release) y puesta en producción. Un lanzamiento puede implicar cosas como marketing, aspectos legales, difusión en redes sociales, etc. y una puesta en producción es una práctica ingenieríl que permite validar las hipótesis de que el producto que construye el Equipo de Desarrollo es el correcto y funciona en un ambiente real.

Ejemplos típicos de ciclos de lanzamiento incluyen:

  • Oportunista, es decir cuando una condición externa o de mercado disparan la necesidad de lanzar inmediatamente el producto
  • Tiempo fijo, que implica que se lanzará el producto en una fecha especifica
    • Multi-Sprints, es una variación de Tiempo Fijo pues implica que después de X Sprints que equivalen a N meses se lanzará el producto
  • Alcance fijo, que solamente permitirá lanzar públicamente un producto cuando todas sus características se hayan implementado. Desde luego esto es no solo costoso y riesgoso, sino que también desvirtúa el principio de porque usar un enfoque ágil de alcance adaptativo y tiempo finito

Un Product Owner tiene a su disposición varias técnicas y herramientas para planificar el desarrollo y entrega de un producto a través de un horizonte de tiempo definido.

La herramienta más básica es un Product Backlog que se ordena constantemente en base al descubrimiento de nuevas prioridades/items, retroalimentación de los stakeholders y capacidad técnica del equipo. 

Los mapas de impacto [Adzic12] son otra valiosa herramienta que permite ir analizando que items del producto están causando que impacto en que stakeholder y hacer adaptaciones en el producto en función de ese análisis.

Priorizar y repriorizar con los stakeholders una hoja de ruta del producto es una otra herramienta muy valiosa a la hora de tratar de definir que es importante y que no, que debe incluirse en el lanzamiento actual y que podría esperar para futuro.

Las tres técnicas anteriormente mencionadas en su esencia buscan adaptar el alcance en función de que tiene sentido, desde la perspectiva de los usuarios finales, incluir o no en el producto. 

Este tipo de pronóstico se distancia de la forma tradicional de tratar de predecir sí vamos a llegar a la fecha X con todo el alcance completado que se descubrió inicialmente. 

La gran labor del Product Owner es precisamente convencer a los stakeholders de que para construir un producto que tenga alguna chance en un mercado cambiante y evolutivo, es necesario adaptar el alcance multiples veces dentro de un tiempo finito, descubriendo en cada ciclo como el producto puede aportar mas valor.

Conclusiones

Un Product Owner es en esencia un estratega y un visionario; como estratega su mente debe estar abierta a cambiar la estrategia con tal de llegar al objetivo del producto, como visionario descubre cual es la visión del producto y los traza los objetivos que ayudaran a materializarla.

Si bien el trabajo del Product Owner no lo distancia de lo táctico pues hay un artefacto con el cual debe trabajar, el Product Backlog, su trabajo con el no debe se al nivel de detalle minucioso sino más bien orientado al ordenamiento que busca major impacto con menos funcionalidad implementada.

Finalmente, la efectividad de alguien en rol del Product Owner no debe medirse por que tan bien hizo ejecutar un alcance descubierto pues eso seria un indicador de que su rol ha sido completamente mal entendido.

Bibliografia 

Sinek11 Sinek S., 2011. Start with Why: How Great Leaders Inspire Everyone to Take Action, Portfolio

Pichler16 Pichler R., 2016. Strategize: Product Strategy and Product Roadmap Practices for the Digital Age, Pichler Consulting

Forsgren18 Forsgren N., Humble J, Kim G., 2018. Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations, IT Revolution Press

Adzic12 Adzic G., 2012. Impact Mapping: Making a Big Impact with Software Products and Projects, Provoking Thoughts

Competencias Clave del Product Owner

Posted on by Juan in Scrum

Introducción

El rol de Product Owner completa la triada de roles en los cuales se basa el enfoque colaborativo del marco de trabajo Scrum. Esta triada, independientemente de la nomenclatura, buscar tener representación y participación del negocio, la parte humana, y la parte técnica. 

El rol del Product Owner es especialmente importante pues es quién definirá el producto que construirá el Equipo de Desarrollo, los tiempos en los cuales será liberado, las características esenciales del producto, y a quienes serán sus principales consumidores.

Yendo un paso mas atrás, el Rol del Product Owner se hace necesario cuando vamos a construir nuevos productos o cuando queremos llevar productos existentes a nuevas alturas. Si lo anterior no ocurre habría que partir por el primer cuestionamiento de si vale la pena usar Scrum o no.

La carrera de un Product Owner estará marcada por varios lanzamientos de productos −algunos exitosos con suerte− y la constante lectura del mercado y sus tendencias. 

Es vital también entender que la organización donde trabaja el Product Owner le concede total poder de decisión acerca del producto; para esto desde luego la organización deberá repensarse a si misma como una organización que crea productos y no solo ejecuta proyectos.

Fundamentos del Rol de Product Owner

El rol de Product Owner muchas veces es confundido con el de un Project Manager que se encarga de hacer que todo funcione bien, es decir lo mismo de antes pero sólo con un cambio de nomenclatura. Desde luego ésta es una disfunción de Scrum y no conduce a resultados positivos y duraderos.

En la práctica he observado que algunos Product Managers transicionan al rol de Product Owner y eso produce mejores resultados por dos razones:

  1. La existencia de Product Managers indica que la organización ya trabaja en función de productos y no sólo proyectos
  2. Los Product Managers ya tienen poder de decision suficiente para decidir el curso de acción sobre un producto

Lo anterior no es mencionado como una receta para maquillar el esquema actual y ahora llamarlo Scrum, lejos de eso sólo lo menciono con el afán de enfatizar que el Product Owner necesita tener poder de decisión y que el enfoque organizacional debe estar ahora en productos. 

Existen varias responsabilidades para el rol de Product Owner, algunas de las más importante son:

  • ayudar a la organización a crear productos comercialmente y técnicamente viables que acaben deleitando a los clientes finales
  • trabajar de la mano con los clientes para descubrir como solucionar sus problemas y atender sus necesidades a través de un producto
  • descubrir a través del ordenamiento del Product Backlog que características no se incluirán (o por lo menos no todavía) en el producto
  • promover dentro del equipo, la organización y con los clientes el enfoque minimalista y de retroalimentación rápida (basado en Lean Startup [Reis11]) para construcción de productos
  • fomentar el crecimiento técnico dentro del Equipo de Desarrollo a través de la inversion de tiempo para aprendizaje
  • educar a los clientes y la organización acerca de la realidad en la variabilidad del alcance 

Cuando el Product Owner llega a dominar las competencias de su rol se podrían esperar beneficios como estos:

  • Haber desarrollado una vision estratégica para colocar el esfuerzo del equipo en la implementación de características con gran futuro
  • Tener un pensamiento sistémico que le permitirá ver el producto y su ciclo de vida considerando múltiples variables [Senge90]
  • Concebir el producto como un ente viviente que se extiende a lo largo del tiempo, las tecnologías, los mercados y los clientes
  • Dominar el vocabulario del cliente y entender a cabalidad su giro de negocio
  • Desarrollar una intuición de hacia donde debe ir el producto a futuro

El rol del Product Owner mal interpretado puede degenerar en anti-patrones que afectan grandemente al equipo Scrum y a la organización. Algunos de estos anti-patrones son:

  • El Product Owner es solamente un tomador de ordenes y escritor de historias de usuario sin poder de decisión sobre el producto
  • El Product Owner es incapaz de ordenar el Product Backlog y sostiene que todos los items son igualmente importantes y se deben implementar
  • El Product Owner trabaja a tiempo parcial en otra función y no dispone de tiempo para cumplir a cabalidad con las responsabilidades de su rol
  • La organización pone a alguien técnico que no conoce del nada del mercado y los clientes en el rol de Product Owner
  • El Product Owner solamente aparece en el Sprint Planning y el Sprint Review dejando al equipo a la deriva durante el Sprint

Estos anti-patrones son desde luego lo opuesto a lo que se debería esperar de un Product Owner que entiende y cumple a cabalidad con las responsabilidades que su rol implica.

El contexto organizacional dentro del cual opera el Product Owner también tiene un efecto sobre el rol, los siguientes son algunos ejemplos de estos contextos:

  • La organización le confiere poder absoluto sobre el producto al Product Owner, es decir, esta en sus manos conocer y decidir acerca del problema, la solución, el producto y el mercado
  • El Product Owner recibe el mandato de construir un producto que a alguien más se le ocurrió y para un mercado que el no conoce a cabalidad
  • El Product Owner en realidad no trabaja en un producto sino en varios proyectos de corta duración
  • El Product Owner no construye un producto para un mercado interno sino que más bien provee soluciones para otros equipos o departamentos 

Si bien Scrum se podría llegar a aplicar en los cuatro contextos anteriores he observado que el primero explota a cabalidad el potencial del rol del Product Owner. Cabe aquí puntualizar que en esencia Scrum se pensó para creación de productos, no para ejecución de proyectos o prestación de servicios. 

Trabajando con los Stakeholders

Gran parte del trabajo del Product Owner consiste en mantener el respaldo de los stakeholders; para esto mostrar el progreso en la construcción del producto es esencial [Pichler16]. La lógica detrás de esto es mostrar a los stakeholders que se esta avanzando hacia un objetivo. 

Para mostrar avance existen varias maneras, dos de las más comunes son:

  1. Con indicadores y métricas como el product roadmap y el release burn-up chart
  2. Con software funcionando con el cual los stakeholders pueden interactuar en el Sprint Review o en cualquier otro momento durante el Sprint

La segunda manera es la que a la larga provee mejores chances de conseguir retroalimentación real y una apreciación más realista del grado de progreso del producto. 

Los stakeholders necesitan permanecer interesados en el producto para que su participación sea activa y voluntaria en lugar de pasiva y forzada [Watts17]. Hacer preguntas directas es siempre la forma preferida pero hay situaciones en las cuales las respuestas pueden ser muy largas o el grupo de stakeholders es muy grande.

En situaciones como las mencionadas en el párrafo anterior se pueden aplicar técnicas como estas para tener a los stakeholders participando e involucrados con el producto:

  • Grupos de afinidad que se forman con stakeholders que comparten la misma opinion, interés o punto de vista
  • Votación con puntos en un papelógrafo para decidir acerca de que item, idea o alternativa tiene mas futuro
  • Votación con los dedos de la mano que permite decidir incorporando el voto de la mayoría 

El Product Owner podría llegar a actuar como un facilitador neutral con los stakeholders en situaciones como estas:

  • Cuándo un stakeholder presenta una idea que le parece descabellada al resto e interrumpe a quien la propone sin dejar que termine de proponerla
  • Cuando los stakeholders tienen opiniones contrapuestas acerca de un item o característica del producto

En ambas situaciones el Product Owner podría proponer la escucha como mecanismo para la información, el entendimiento y el posterior debate. 

La no-neutralidad podría generar una fractura en la relación con un stakeholder o un grupo de ellos; o lo que es aun peor, perderse de la creatividad que viene de la diversidad de opiniones que solo ocurre cuando el grupo es funcional [Lencioni02]. 

Sin embargo existirán situaciones en las cuales el Product Owner deberá tomar un abordaje diferente, por ejemplo cuando se ha perdido demasiado tiempo debatiendo y se necesita una decisión rápida.

En situaciones como estas el Product Owner puede usar su prerrogativa y decidir por ejemplo en qué orden se implementaran los items del Product Backlog, o si un item merece la pena o no ser incluido en el Product Backlog.

Cabe sin embargo recalcar que el Producto Owner no construye un producto que le sirva a él sino que contribuya valor para los stakeholders. La lógica aquí es no imponer la voluntad o preferencia del consultor por encima de la necesidad del cliente [Lencioni10]. 

Trabajando con el Equipo de Desarrollo

El Product Owner colaborar con el equipo en varias instancias, una de las más importantes es en la Definición de Terminado. Esta definición es un acuerdo de trabajo creado y mantenido por el Scrum Team y la intención es tener claridad acerca de cuándo algún item se considerara realmente terminado.

Cabe enfatizar que “terminado” para que tenga valor debe ser algo que los stakeholders puedan ver y de lo cual puedan dar retroalimentación. Como corolario, items que cumplen con condiciones solamente técnicas, como por ejemplo que no rompan el build, no presentan valor de negocio y por tanto no accionan el feedback de parte de los stakeholders. 

Otra instancia cuando el Product Owner debe colaborar con el equipo de desarrollo, y principalmente con los stakeholders, es descubriendo el Product Backlog con las cosas que tendrá el producto. 

Descubrir el Product Backlog es una tarea central y funciona mejor bajo un enfoque colaborativo y dinámico en el cual en grupo de personas exploran juntas las características, mercados, usuarios y problemas que potencialmente resolverá el producto [Patton14]. 

En eventos como el Refinamiento el Product Owner tendrá la oportunidad la oportunidad de trabajar lado al lado con el Equipo de Desarrollo ordenando los items que vendrán en el siguiente Sprint; cabe hacer notar que es el Equipo de Desarrollo el que se encarga de descomponer y estimar los items para el siguiente Sprint.

También es factible que el Equipo de Desarrollo planifique solamente suficientes items para uno o dos dias y que en la reunion de Refinamiento se planifiquen los siguientes items; este tipo de planificación en base a items terminados y capacidad liberada se basa en un sistema pull [Ohno13].

Es importante recalcar que él Product Owner no conoce en detalle cada uno de los items del Product Backlog pues esta labor seria demasiado exhaustiva y lo desviaría de la verdadera función de su rol que es tener la vision y estrategia del producto.

Lo anterior nos lleva a que el Product Owner debe saber quien originó el requerimiento para que así pueda direccionar al desarrollador que trabajará en ese requerimiento para que hable directamente con el usuario. 

Si las conversaciones deben ser registradas para la posteridad por razones pragmáticas como poder recordar lo dicho entonces grabar un video resulta la forma mas eficiente. Aun mejor es cuando se graba un video de la conversación que va ilustrada con dibujos en un papelógrafo.

Product Ownership con Multiples Equipos

Ser el Product Owner de multiples equipos implican desafios como por ejemplo:

  • El principal y mas grande desafío siempre es la comunicación, empeora cuando los equipos se hallan en zonas horarias diferentes y hablan idiomas distintos
  • Un segundo gran desafío es hacer que todos lo equipos tomen items del Product Backlog que sea de alta prioridad y que contribuyan valor perceptible para los stakeholders
  • Finalmente esta el desafío de mantener un producto congruente creado por un único equipo aunque este este globalmente distribuido

Los desafíos anteriores son solamente algunos ejemplos de los que encontrara un Product Owner que trabaje con múltiples equipos. Desde una perspectiva sistémica mientras mas equipos se tiene mayor es la complejidad y por tanto habría que tender a la simplificación.

Como se sugiere en LeSS [Larman17] para lograr simplicidad sistémica a la hora de trabajar con multiples equipos abría que mantener la simplicidad y elegancia de Scrum a través de condiciones como: trabajar con equipos locales, mantener un solo Product Backlog y tener un único Product Owner.

El escalamiento solamente debería intentarse cuando no hay otra alternativa, mas aun, en lugar de escalar con mas gente habría que de-escalar reduciendo la complejidad sistémica para rescatar así la esencia de Scrum que se basa en equipo autónomos y auto-manejados.

Conclusiones

El rol del Product Owner bien entendido puede llevar a las organizaciones a construir productos que realmente produzcan un impacto positivo en el mercado beneficiando a los usuarios o clientes finales. 

Para que lo anterior acabe ocurriendo se necesitara no solamente de Scrum dentro del equipo sino también del cabal entendimiento por parte de la alta gerencia de la organización que implica el cambio hacia Scrum.

Un punto esencial de ese cambio es entender que el Product Owner tiene total poder de decisión acerca del rumbo del producto, decidiendo qué características tendrá el producto y en qué orden se implementaran.

Finalmente, quien asuma este rol deberá poseer entre otras cualidades una mentalidad estratégica y un espíritu emprendedor que le permita fallar rápido de ser necesario o perseverar hasta alcanzar los objetivos del producto. 

Bibliografia 

Reis11 Reis E., 2011. The Lean Startup, Crown Business 

Senge90 Senge P., 1990. The Fifth Discipline: The Art & Practice of The Learning Organization, Doubleday

Watts17 Watts G, 2017. Product Mastery: From Good To Great Product Ownership, CreateSpace Independent Publishing Platform

Pichler16 Pichler R., 2016. Strategize: Product Strategy and Product Roadmap Practices for the Digital Age, Pichler Consulting

Lencioni02 Lencioni P., 2002. The Five Dysfunctions of a Team: A Leadership Fable, Jossey-Bass; 1st edition

Lencioni10 Lencioni P., 2010. Getting Naked: A Business Fable About Shedding The Three Fears That Sabotage Client Loyalty, Jossey-Bass; 1st edition

Patton14 Patton J., 2014,  User Story Mapping: Discover the Whole Story, Build the Right Product, O’Reilly Media

Larman17 Larman C., Vodde B., 2017. Large-Scale Scrum More with LeSS, Addison-Wesley

Competencias Básicas de un ScrumMaster

Posted on by Juan in Scrum

Introducción

Un ScrumMaster no es solamente una persona que toma un curso de dos días y con esto siente que ya concluyó su aprendizaje de Scrum. Por el contrario es alguien que aborda Scrum con humildad intelectual y curiosidad infinita.

La humildad intelectual consiste en primero aceptar que no se conoce todo, que hay mucho mas que aprender y que incluso lo que se conoce puede estar equivocado, desactualizado o simplemente puede no ser aplicable al contexto actual.

La curiosidad infinita hace que un ScrumMaster esté siempre en constante aprendizaje, que busque nuevas ideas, técnicas y conocimiento de diferentes disciplinas para ampliar su repertorio.

En el extremo opuesto a la humildad intelectual esta la noción de que ya no hay nada que nadie puede enseñarle a un “experimentado” ScrumMaster. Un indicador clarísimo de que la curiosidad infinita dejó de existir para un ScrumMaster es hecharle un vistazo a su biblioteca personal y ver que esta leyendo.

Las competencias básicas de un ScrumMaster cambiaran con el tiempo y se irán enriqueciendo con diferentes experiencia, además de ser altamente contextuales. Pero lo que no debería cambiar es la actitud de abordar Scrum con humildad intelectual y curiosidad infinita.

Facilitación

El ScrumMaster puede facilitar el trabajo del equipo a través de varias formas que incluyen:

  • Ayudarlos a comunicarse más efectivamente descubriendo/redescubriendo la herramienta más efectiva de comunicación: el habla
  • Ayudarlos a que reconozcan cuando es mejor permanecer en silencio escuchando y aprendiendo de lo que otros tienen que decir
  • Ayudarlos a darse cuenta que la adopción de Scrum requerirá de un profundo cambio en el sistema organizacional 

El tercer punto es especialmente importante pues el sistema organizacional es él que propicia el comportamiento de los individuos y si éste no es cambiado no habrá una adopción duradera de Scrum. 

Ejemplificando lo anteriormente dicho, si el sistema organizacional está diseñado para premiar y motivar la participación individual mas no el trabajo en equipo entonces Scrum tiene pocas chances. Similarmente si el sistema esta diseñado para basarse en controles, supervision y jerarquías entonces tampoco Scrum podrá florecer. 

Técnicas de modelamiento sistémico y en general pensar sistémicamente ayudaran a que el equipo y sobre todo la alta gerencia de la organización se den cuenta de la necesidad del cambio y los impactos que este tendrá [Senge90].

En el tema de la facilitación de decisiones de grupo existen varias técnicas que un ScrumMaster puede considerar utilizar [Schwarz16], algunas de las más comunes son estas:

  • Voto con los cinco dedos de la mano
  • Voto de aprobación/reprobación con el pulgar arriba/abajo
  • Voto con puntos en un papelógrafo 
  • Pararse en algún lugar de un salon
  • Protocolo para la toma de decisiones

Independientemente de las técnicas que un ScrumMaster decida utilizar es importante recordar que en su papel de facilitador no le corresponde imponer o forzar una decision en el equipo [Schein13]. 

Coaching

Muchas veces la facilitación es confundida con el coaching siendo ésta una disciplina mucho más amplia y estudiada [Adkins10] que incluye facetas como:

  • facilitación que implica el ayudar a que grupos de personas se puedan comunicar más efectivamente para llegar a acuerdos que satisfagan a la mayoría
  • enseñanza de una habilidad o capacidad con la expectativa de que los demás puedan aprenderla y también utilizarla
  • tutoría que consiste en informal o formalmente guiar el paso de conocimiento y experiencia hacia un aprendiz

El coaching abarca también algo más amplio y poderoso que las facetas anteriores pues implica la habilidad del coach de guiar a las personas en su propio descubrimiento.

El coaching implica que las personas que lo reciben sean capaces de formularse a sí mismo preguntas poderosas que los hagan pensar y descubrir sus propias respuestas.

Cabe hacer notar que el valor del coaching no esta necesariamente en encontrar respuestas sino en la exploración misma, en el proceso mental que implica el cuestionamiento interno que a la vez es el disparador del verdadero aprendizaje.

Si hablamos de equipos que tratan de ser autoorganizados a menudo ellos encuentran desafíos como:

  • estar tan acostumbrados a la mentalidad de recibir ordenes y ser controlados que simplemente no pueden cambiar su mentalidad
  • están acostumbrados a operar en un sistema organizacional cargado de títulos jerárquicos, planes de carrera, ascensos, etc. que en esencia provoca la competencia interna y la envidia
  • tener miembros del equipo que eran managers y estaban acostumbrados a dar ordenes y preparar reportes pero que carecen de conocimiento actualizado que les permita hacer trabajo técnico

Uno de las contribuciones más significativas que podría hacer un ScrumMaster desde la disciplina del coaching es precisamente ayudar a que un equipo descubra  como autoorganizarse para vencer los desafíos anteriores [Hackman02].

Debido a que no hay una formula garantizada o algo así como “mejores prácticas” la labor del coach es siempre dependiente del factor humano, y de la creatividad, colaboración y entendimiento de quienes reciben sus servicios. 

Parte de hacer coaching con un equipo tiene que ver con hacerle notar a la gente que el estado actual de conocimiento, creencia y valores deberá cambiar y esto implicará dejar ir algo. 

El que dejar ir muchas veces implica renunciar a la zona de confort o la ilusión del conocimiento o control; precisamente es porque éste dejar ir es tan difícil que el coach no puede ni debe obligar al equipo a adoptar Scrum.

Un punto central en el coaching es la diferencia entre ideas propias y prestadas [Kimsey11]. Las primeras son las que la gente misma descubre, abraza, cree en ellas y las defiende; las segundas en el mejor de los casos pueden ser inspiradoras pero al no ser propias no se quedan y no provocan el cambio verdadero.

Como coach el objetivo siempre debe ser posibilitar que el equipo mismo genere sus propias ideas para cambiar el status quo y verdaderamente adoptar Scrum [Hackman02].

Sirviendo al Equipo de Desarrollo

El ScrumMaster sirve al Equipo de Desarrollo a través de diferentes maneras. Sin embargo una constante es la aplicación del Liderazgo Servicial.

El Liderazgo Servicial es un estilo de liderazgo que básicamente invierte la pirámide jerárquica tradicional en la cual los empleados sirven a los jefes, en su lugar los líderes serviciales buscan ayudar a los empleados −que ahora son colegas al mismo nivel− para que desarrollen todo su potencial y enriquezcan sus vidas.

El ScrumMaster actúa como Líder Servicial en situaciones como las siguientes:

  • Escucha a los demás cuando necesitan ser escuchados
  • Ayuda a los demás para que ellos mismos remuevan sus impedimentos
  • Con humildad intelectual reconoce que no lo sabe todo pero que está dispuesto a aprender
  • Hace preguntas ingenuas que nadie más se anima a preguntar
  • Se ofrece de voluntario para tareas que nadie más gusta de realizar 

Cada enfatizar a manera de advertencia que ser un Líder Servicial no quiere decir hacer cosas cómo actualizar el tablero para el equipo o ser la única persona que habla en los eventos. De hecho lo anterior puede considerarse como anti-patrones del accionar de un ScrumMaster.

El ScrumMaster como Líder Servicial puede cultivar la actitud de voluntariado del equipo, un escenario típico es ofrecerse como voluntario para tareas que nadie quiere tomar durante el Sprint Planning Two. 

Desde luego el ofrecerse como voluntario no quiere decir que el ScrumMaster sea la persona con el mayor conocimiento sino solamente que es la persona con la actitud de servir a los demás.

Esta actitud de voluntariado de parte de ScrumMaster si se repite constantemente eventualmente acaba contagiando a otros miembros del equipo que poco a poco van descubriendo que es gratificante tomar tareas que no conocen.

Otro escenario clásico es cuando el Product Owner o algún cliente o stakeholder quiere presionar al equipo con el afán de incrementar la velocidad de desarrollo pidiendo incluso que el equipo trabaje horas extra.

En su rol de Líder Servicial el ScrumMaster puede invitar a quien quiera presionar al equipo a realizar un ejercicio de modelaje sistémico en un papelógrafo. 

En este ejercicio se listará la variable “velocidad” y las demás variables como calidad, motivación, colaboración y otras que se verán impactadas cuándo el equipo trate de acelerar el desarrollo.

Normalmente con este tipo de modelaje es claro que la velocidad no viene sin consecuencias y esto hace abandonar la idea de exigir que el equipo se mueva más rápido.

Implementaciones que se hacen a la rápida generan Deuda Técnica que es una analogía inventada por Ward Cunningham. Al igual que un préstamo bancario existen intereses que si no se pagan acaban incrementando la deuda y eventualmente llevan al colapso del acreedor.

Algo muy similar ocurre con el código que al escribirse rápida y desprolijamente va acumulando Deuda Técnica que eventualmente hace el código inmantenible o simplemente demasiado costoso de cambiar y mantener estable. 

No tener tiempo para refactorizar o construir el código sin pruebas es el primer paso a la introducción de la Deuda Técnica. Los postulados de Código Limpio, con las prácticas que recomienda basadas en su vez en Extreme Programming, son la mejor forma conocida hasta ahora de poder evitar la acumulación de Deuda Técnica [Martin08].  

Una parte crucial del servicio que el ScrumMaster presta al Equipo de Desarrollo es precisamente ayudar a que descubra cómo crear código limpio [Martin11]. Para ayudar en este descubrimiento el ScrumMaster tiene a su disposición las disciplinas del coaching, la tutoría, la facilitación y la enseñanza.

Organizaciones que están cómodas tolerando que sus desolladores generen cualquier tipo de código con tal que funcione presentan un tipo de deuda al cual llamó Deuda Organizacional.  

He observado que las prácticas de Extreme Programming propuestas hace veinte años  [Beck99] usadas con disciplina y constancia conducen a la creación de código limpio y un consiguiente Incremento del Producto de mayor calidad.

Si bien todas la prácticas de Extreme Programming tienen sentido existen algunas de ellas que desde mi experiencia son imprescindibles, estas son:

  • Test Driven Development
  • Integración continua 
  • Refactorización 
  • Cliente sentado con el equipo
  • Liberaciones frecuentes

La habilidad de tener un Incremento del producto potencialmente liberable al final de cada Sprint puede ser influenciada por las prácticas ingenieriles del un Equipo de Desarrollo de las siguiente maneras:

  • Teniendo un conjunto de pruebas automatizadas que puedan correrse exitosamente incontables veces al día garantiza que el Incremento esta probado e integrado
  • Incorporando a través de la refactorización constante el conocimiento más actualizado que tienen los desarrolladores acerca del domino del problema, la tecnología y el vocabulario del cliente
  • Teniendo liberaciones a producción cada vez más cortos y frecuentes que clientes sentados con el equipo puedan evaluar rápidamente

Sirviendo al Product Owner

Un Product Owner puede utilizar varias técnicas para colaborar y comunicarse con el Equipo de Desarrollo y con el cliente, técnicas tales como:

  • Ayudar al equipo a ver el panorama completo del producto que están construyendo a través de la creación de un Product Roadmap [Pichler16]
  • Descubrir con los clientes y otros interesados que características tendrá el producto a través de User Story Mapping [Patton14]
  • Trabajar con los clientes y otros interesados en el planeamiento estratégico del producto empleando Impact Mapping [Adzic12]

A su vez el ScrumMaster puede apoyar al Product Owner haciendo cosas como estas:

  • Asesorando a la gerencia para realizar los cambios necesarios como por ejemplo concederle total autoridad sobre el producto al Product Owner
  • Animando al Equipo de Desarrollo a colaborar con el Product Owner para juntos refinar constante y consistentemente el Product Backlog
  • Ayudándole a seleccionar las herramientas más simples, baratas y eficientes para su trabajo
  • Aconsejando a los clientes colaborar directamente en los desarrolladores en el día a día 
  • Educando a los clientes y el Equipo de Desarrollo acerca de que las determinaciones que tome el Product Owner respecto al orden del Product Backlog deben ser respetadas

Sirviendo a la Organización 

El ScrumMaster puede apoyar al equipo a responder ante los impedimentos de varias maneras, entre ellas:

  • Constantemente preguntando si existen impedimentos, por ejemplo en el Daily Scrum
  • Manteniendo los impedimentos visibles, por ejemplo en un papelógrafo en el área de trabajo del equipo
  • Ayudando a que el equipo hable acerca de los impedimentos y piensen en posibles mitigaciones

Sin embargo hay impedimentos organizacionales mucho más grandes que pueden afectar el accionar de cualquier equipo, impedimentos como por ejemplo:

  • Demasiada burocracia
  • Una mentalidad de comandar y controlar que demanda demasiados reportes del equipo
  • Fechas impuestas por un agente externo al equipo
  • Presión para llegar a una fecha establecida sacrificando la calidad del producto y afectando las vidas personales de los desarrolladores
  • Tendencia a que el trabajo se especialice y se vayan creando silos de conocimiento

Para erradicar los impedimentos anteriormente nombrados Scrum eventualmente requerirá de un rediseñó organizacional que implicará cambios radicales como estos:

  • No más Project Managers ni Oficina de Gestión de Proyectos
  • No más departamento de Quality Assurance con pruebas manuales
  • No más banca de recursos sin proyecto
  • No más pensamiento inmediatista enfocado en proyectos
  • No más outsourcing
  • No más distribución de los miembros del equipo en lugares geográficamente separados

Cabe enfatizar que en Scrum no tenemos una figura central de poder que reportar el progreso del equipo a la gerencia. 

Algunas prácticas de Project Management como disciplina puede que sean necesarias pero el equipo mismo será quien las realice sin tener una única figura de Project Manager.

En general buscamos distanciarnos completamente del enfoque Taylorista bajo el cual se tiene una figura central de poder que le dice a los demás que hacer. 

Existen algunos comportamientos de los clientes que pueden contribuir grandemente al éxito del Equipo Scrum, comportamientos tales como:

  • Estar disponible, involucrado y colaborar de cerca con el equipo
  • Entender que la calidad no viene gratis
  • No exigir que toda característica imaginable sea incluida en el producto
  • Reconocer y adoptar la adaptabilidad en el ciclo de desarrollo del producto 

Opuestamente hay otros comportamientos de los clientes que no contribuyen al éxito del equipo, comportamientos como por ejemplo:

  • Pedir un requerimiento, olvidarse de él y esperar a que sea entregado para recién opinar
  • Crear capas y capas de intermediaros que los separen cada vez más de los desarrolladores
  • Insistir en que se cumpla en su totalidad un alcance inicialmente definido
  • Pedir exactitud y precision en las estimaciones
  • Exigir velocidad en el desarrollo 

Finalmente, si la organización adopta Scrum sólo parcialmente acabará perdiendo beneficios tales como:

  • El rediseñar la organización completamente para incorporar prácticas de management modernas
  • La oportunidad de pagar Deuda Técnica, Organizacional y de Conocimiento
  • El desarrollo del verdadero potencial de las personas
  • La pérdida de ventajas competitivas frente a organizaciones más pequeñas pero más ágiles

Conclusiones

Muy comúnmente he visto la confusion de pensar que el rol del ScrumMaster es simplemente terminología nueva para reciclar la clásica idea de una figura de poder y autoridad, lejos de eso el ScrumMaster es alguien que sirve a los demás y no se sirve de ellos para crecer el mismo.

Para que ese rol de Lider Servicial sea realmente efectivo para el equipo y la organización se requieren cambios profundos que parten desde el rediseño del sistema organizacional hasta tener a bordo a la gente correcta.

Desde luego los cambios anteriores no podrán materializarse sin el total respaldo de la alta gerencia que debe estar convencida de que el cambio es necesario (a veces inevitable) y ve en Scrum el vehículo adecuado.

Finalmente, cambios profundos requieren tiempo y perseverancia y en este sentido el ScrumMaster debe ser paciente con el equipo, con la organización y desde luego consigo mismo. 

Bibliografia 

Senge90 Senge P., 1990. The Fifth Discipline: The Art & Practice of The Learning Organization, Doubleday

Schwarz16 Schwarz R., 2016. The Skilled Facilitator: A Comprehensive Resource for Consultants, Facilitators, Coaches, and Trainers, Jossey-Bass; 3rd edition

Schein13 Schein E., 2013. Humble Inquiry: The Gentle Art of Asking Instead of Telling, Berrett-Koehler Publishers; 1 edition

Adkins10 Adkins L., Coaching Agile Teams: A Companion for ScrumMasters, Agile Coaches, and Project Managers in Transition, Addison-Wesley Professional

Hackman02 Hackman R., 2002. Leading Teams – Setting the Stage for Great Performances, Harvard Business Review Press

Kimsey11 Kinsey-House H., Kinsey-House K., Sandahl P., Whitworth L., 2011. Co-Active Coaching: Changing Business, Transforming Lives, Nicholas Brealey; 3rd edition

Hackman02 Hackman R., 2002. Leading Teams – Setting the Stage for Great Performances, Harvard Business Review Press

Martin08 Martin C. R., 2008. Clean Code: A Handbook of Agile Software Craftsmanship, Prentice Hall

Martin11 Martin C. R., 2011. The Clean Coder: A Code of Conduct for Professional Programmers, Prentice Hall

Beck99 Beck K., 1999. Extreme Programming Explained: Embrace Change, Addison-Wesley

Fowler18 Fowler M., 2018. Refactoring: Improving the Design of Existing Code, 2nd Edition, Addison-Wesley Professional

Pichler16 Pichler R., 2016. Strategize: Product Strategy and Product Roadmap Practices for the Digital Age, Pichler Consulting

Patton14 Patton J., 2014. User Story Mapping: Discover the Whole Story, Build the Right Product, O’Reilly Media

Adzic12 Adzic G., 2012. Impact Mapping: Making a Big Impact with Software Products and Projects, Provoking Thoughts

Eventos de Scrum, Artefactos y Transparencia

Posted on by Juan in Scrum

Introducción

Los pilares de Scrum (inspección, adaptación y transparencia) inspeccionan grandemente el comportamiento de las personas en los eventos y desde luego trazan la linea matriz a la hora de emplear los artefactos.

Cabe señalar que más importante que un evento ocurriendo a tiempo es importante que durante el evento realmente ocurra la inspección y la adaptación posibilitada por la transparencia.

La adaptación, inspección y transparencia son mecanismos poderosos que con el tiempo pueden (y deben) alterar para mejor la forma de los eventos y artefactos. 

Inspección, Adaptación y Transparencia en los Eventos de Scrum

En el Daily Scrum el equipo tendrá la oportunidad de verse las caras y sincronizar para el día. Más aún, los miembros del equipo tendrán la oportunidad de escuchar que acerca de que están haciendo los demás miembros, como esta progresando el Sprint para todos y observar como se siente la gente en ese día.

Lo anterior sólo será posible si la gente que participa en este evento esta realmente presente en el momento (física y mentalmente). Al estar presentes en el momento se incrementan las chances de inspeccionar el trabajo y proponer adaptaciones pero desde luego lo anterior no seria posible si no existe un alto grado de transparencia y confianza para decir las cosas [Rubin12].

En el Sprint Planning la transparencia en necesaria para cosas tan vitales como que  todo el equip manifieste que realmente ha entendido del Objetivo del Sprint. La inspección permitirá al equipo hacer preguntas que clarifiquen su entendimiento de que hay que hacer y la adaptación permitirá crear un plan que parezca realista en ese momento del tiempo con el conocimiento que se tiene disponible.

Inspeccionar cualquier plan creado durante el Sprint Planning ya durante el Sprint es vital hacer adaptaciones pues de esta forma se añadirá realismo. Añadir realismo a un plan creado, en lugar de defenderlo a capa y espada, se alinea mejor con la agilidad [Auer02].  

En el Sprint Review los clientes tendrán la oportunidad de ver y principalmente utilizar el Incremente en el cual trabajó el equipo durante el Sprint.

Cabe hacer notar que la única forma de realmente ver como el cliente usuaria el producto es hacer que éste lo utilice, escuchar sus comentarios, dialogar y observar sus reacciones y expectativas.

De hecho lo anterior ofrece la oportunidad perfecta para tener transparencia, inspeccionar el grado de satisfacción (o no satisfacción) del cliente y realizar las adaptaciones necesarias en el Product Backlog.

Existen varios mitos acerca de este evento que vale la pena nombrar con el afán de desmitificarlos:

  • Primer mito, sólo el equipo muestra software funcionando pero el cliente no puede tocar el teclado
  • Segundo mito, en esta evento el equipo muestra software funcionando para el Product Owner que luego en otra reunión posterior le mostrará el producto al cliente y luego volverá al equipo con la retroalimentación que recoja
  • Tercer mito, el cliente sólo ve software funcionando en estos eventos y no debe ser molestado durante el Sprint 

En la Retrospectiva del Sprint una vez más la transparencia será vital para que cada miembro del equipo pueda manifestar su opinión sincera e inspeccionar todos juntos como equipo factores tales como:

  • el Sprint en general
  • el equipo
  • las relaciones e interacciones entre miembros del equipo
  • las relaciones e interacciones con personas externas al equipo
  • las relaciones e interacciones con el cliente
  • su forma de trabajo
  • los resultados que se alcanzaron
  • los puntos a mejorar

Si bien es cierto que la lista anterior podría seguir creciendo y nunca está completamente definida el objetivo es cultivar el espíritu de mejora continua [Ohno13]. 

Será precisamente ese espíritu de mejora continua el que hará que el equipo busque sin descanso eliminar desperdicios, construir un producto de calidad y mejorar en la práctica de su oficio. 

Las retrospectivas tendrán como uno de sus resultados principales el proveer ideas para realizar adaptaciones para el siguiente Sprint. Otro de los resultados de una retrospectiva es la celebración, aprecio y reconocimiento por las cosas que salieron bien en el Sprint.

Las retrospectivas no son sin embargo eventos en los cuales la gente del equipo deba quedarse callada mientras haya uno o dos que dominen la discusión. Tampoco es un evento en el cual se deba tener violencia en la comunicación, ataque o criticas hacia las personas o su trabajo [Lencioni02].

El ciclo de transparencia, inspección y adaptación debe también aplicarse a las retrospectivas para que así el equipo las vaya mejoran con el pasar del tiempo.

El Sprint y el Incremento 

Comencemos recordando que en Scrum un Sprint es un periodo de tiempo, generalmente menor a cuatro semanas, durante el cual el equipo trabaja de manera alineada para construir un Incremento del producto.

Durante el Sprint el Objetivo del Sprint no debería cambiar porque sino el equipo podría acabar construyendo varias piezas desconectadas del mismo producto. 

Tener un objetivo que sea lo suficientemente amplio pero que no cambie en su esencia permite mantener el alineamiento del equipo y contribuye a la consistencia del mismo.

Un objetivo que no cambia también puede contribuir a que el cliente tenga claridad respecto a que esperar al final del Sprint. Nótese en este punto que el alcance no es lo mismo que el objetivo, la idea siempre es pensar Lean y lograr el mismo objetivo pero con menos alcance.

La salida del Sprint es una pieza de software bien construida cuyos componentes cumplen con la Definición de Terminado y esta en condiciones de ser utilizada, más aún puede ser instalada y ejecutarse establemente en un ambiente de producción.

Lo anterior es de vital importancia porque:

  • permitirá recolectar retroalimentación real de los clientes y usuarios
  • hará evidente la capacidad y conocimiento del equipo
  • llevará al equipo un paso más cerca de la visión del producto 

Liberar públicamente un Incremento del Producto tienen repercusiones en otras áreas del negocio como: mercadeo, legal, finanzas, infraestructura, y otras; por tanto ésta es una decisión que debe ser tomada por el Product Owner.

De hecho es el Product Owner que en función del mercado, la infraestructura, los clientes y otros interés, dede trazar la estrategia de liberaciones públicas. Cualquiera que sea la frecuencia de liberaciones públicas definidas en esa estrategia no excusa al equipo de construir un Incremento del Producto potencialmente liberable al final de cada Sprint.

Sprint Planning

El evento de Sprint Planning se divide en dos mitades, la primera de ellas a la cual llamamos simplemente Sprint Planning One se enfoca en entender y discutir el quese hará durante el Sprint.

El que del Sprint esta alineado con el Objetivo del Sprint y normalmente es el Product Owner quien puede explicarlo mejor al equipo.

Nótese que la explicación del que esta conectada más al porque el cliente necesita las funcionalidades que se implementarán en el Sprint y como éstas potencialmente contribuirán valor al producto. 

La explicación se debe mantener en un nivel de abstracción lo suficientemente alto como para no entrar en la minucia y extender ésta parte de la reunión demasiado. Hablar de la minucia es precisamente el trabajo de comunicación que deberán hacer ya dentro del Sprint los desarrolladores con los clientes a mediada que avancen con la implementación.

La segunda parte del Sprint Planning, que es llamada de Sprint Planning Two, el Equipo de Desarrollo se concentra en discutir como se organizaran para realizar el trabajo y cuanto de este es factible terminar en el Sprint. 

Lo anterior implica que el Equipo de Desarrollo deberá descomponer items grandes, incorporar realismo estimándolos, y postergar para después items menos importantes [Beck00].

Las estimaciones no deben buscar la precisión y menos aún ser utilizadas por los jefes como un compromiso al cual estarán sujetos los miembros del equipo. Si esto acaba ocurriendo la tendencia lógica será que los desarrolladores inflen sus estimaciones como mecanismo de defensa.

En lugar de lo anterior la idea con las estimaciones es que se utilizaran como un indicador interno del equipo para tener una percepción de que podría o no caber dentro del Sprint.

Más importante todavía que las estimaciones es tener presente en este evento y durante todo el Sprint el concepto de flujo que se apoya grandemente en tener piezas pequeñas de trabajo moviéndose constantemente [Goldratt14]. 

Las estimaciones pueden realizarse usando diferentes técnicas y unidades pero el principio básico es mantenerlas simples y ligeras para que estimar y reestimar no sea un proceso penoso y conflictivo.

En mi experiencia las estimaciones con unidades de tiempo medidas en semanas, días, y horas es la que mejor funciona puesto que el tiempo es una unidad universalmente entendida y no conlleva ambigüedad [Jeffries00]. 

Al final del Sprint Planning Two el equipo debería acabar teniendo un plan no extremadamente detallado y con estimaciones precisas, sino más bien un plan lo suficientemente bueno como para hacer sentir a los miembros del equipo confiados en que podrán implementar los items más valiosos de su Sprint Backlog durante el Sprint [Patton14]. 

Daily Scrum

El Daily Scrum es diferente de una reunión tradicional de reportes de status debido a que:

  • No tiene la aspiración de reportar sólo con palabras el estado, impacto y calidad del trabajo que se esta realizando
  • No es para hablar acerca de un plan estático creado hace tiempo y como se está avanzando en función de ese plan
  • Debe ocurrir con la gente parada en un circulo, cara a cara, sin laptops ni celulares, y distantes del lugar donde ocurre el trabajo (gemba) 

El simple hecho de que este evento se realizará lejos del gamba ya conlleva de por si un grado de subjetividad pues el equipo no estará mirando el trabajo. Para que la inspección se vuelva realmente efectiva después de esta reunión habrá que “ir y ver” el trabajo [Ohno13].

Quizás uno de los grandes aportes de este evento es que hace que todo el equipo reconozca que para estar realmente empapados del trabajo necesitan ir y ver donde realmente ocurre, pero para permanecer comunicándose efectivamente y sintiendo el lado humano del trabajo necesitar pararse en un circulo para hablar, reír y compartir.

Por otro lado este evento tiene algunas restricciones introducidas con el fin de hacer que fluya mejor para el Equipo de Desarrollo, éstas restricciones son:

  • No jefes o gerentes presentes
  • Sin dispositivos electrónicos de ningún tipo
  • Debe terminar dentro de un timebox de sólo 15 minutos
  • No esta permitido culpar o juzgar a otros miembros del equipo en el círculo 
  • Sin “superiores”, todos somos iguales en el círculo

Para mantener este evento dentro del tiempo límite existen ciertas técnicas que pueden ayudar:

  • Hablar solamente acerca de los logros de ayer, los objetives para hoy y los impedimentos sólo si existiesen
  • Todos hablando cara a cara en un círculo
  • Posponer para después conversaciones largas 

Sprint Review

El Sprint Review es el evento formal en el cual el equipo presentará el Incremento a los clientes o usuarios finales para validar hipótesis y ver si el producto está avanzando en la dirección correcta. 

La definición anterior ha causado muchos problemas y confusiones pues muchas veces se ha entendido como el único momento en el cual los clientes pueden ver el producto en construcción. 

Volviendo a los pilares fundamentales de Scrum (inspección, adaptación y transparencia) nos daremos cuenta que la idea es tener retroalimentación constante y ésta se logra mostrando el producto lo más frecuentemente que se pueda (idealmente cada día y varias veces dentro de cada día).

El otro gran componente esta en el verdadero significado de “mostrar”, la retroalimentación más realista viene de clientes que tocan el teclado y el mouse e interactuan con el producto. 

Sin embargo, tener el Sprint Review al final de un Sprint es un excelente punto de inicio para equipos que están empezando con Scrum ya que ayuda grandemente a acercarse al cliente y crear el hábito de que debe ver el producto mientras se esta construyendo.

Existen algunas actividades clave antes y durante de este evento: 

  • Preparar un salón y tener toda la logística preparada para que el clientes pueda interactuar con el producto
  • El Equipo Scrum observara detenidamente como el cliente interactuará con el producto
  • El Producto Owner deberá explicar, generar y responder preguntas acerca de como el Incremento se conecta con los objetivos del negocio
  • El ScrumMaster facilitará el evento para hacer que fluya de forma dinámica, entretenida y productiva para todos

A su vez este evento producirá algunos resultados clave:

  • La validación de que el producto está avanzando en la dirección correcta y se necesita perseverar por algunos Sprints más
  • La indicación de que el producto no esta cumpliendo las expectativas del cliente o no va en camino de resolver sus problemas por lo cual el producto deberá pivotar 
  • La apreciación de las capacidades técnicas reales del Equipo de Desarrollo que les permite construir software cumpliendo con la Definición de Terminado

Continuando con la anterior, el trabajo del Product Owner y del equipo en general se basa en un conjunto de hipótesis que mientras más tiempo tarden en validarse más riesgo implicarán, de ahí la importancia del Sprint Review como mecanismo a través del cual los clientes usarán el producto para dar retroalimentación oportuna. 

Sprint Retrospective

Este evento de retrospectiva persigue que el equipo en su conjunto reflexionen acerca de sus prácticas, métodos, interacciones y disciplina para ver como podrían mejorar para el siguiente Sprint.

Al ser un evento de autocrítica y a la vez de valoración de lo que salió bien, require de valores cruciales como transparencia, sinceridad y empatía.

Precisamente será labor del ScrumMaster facilitar este evento para fluya dentro del respeto a los valores nombrados. 

Responsabilidades adicionales del ScrumMaster como facilitador de este evento incluyen:

  • Ayudar al equipo a mantenerse enfocado al rededor del tema central que es la inspección del equipo mismo, sus procesos y dinámicas internas
  • Mantener la discusión balanceada entre lo positivo del Sprint pasado y los puntos a mejorar
  • Ayudar a que el equipo mantenga la discusión alrededor de los problemas sin culpabilizar a nadie y más bien hablando de como se podrían mejorar las cosas
  • Mantener las retrospectivas vivas, dinámicas y entretenidas usando técnicas de facilitación efectivas y continuamente innovarlas [Roden15]

Existen acuerdos que ayudan a que el ScrumMaster pueda contribuir con los puntos anteriores, dos de los más importantes en mi experiencia son: hacer que esta sea un evento privado de sólo el equipo y mantenerlo corto (menos de 45 minutos). 

No tener retrospectivas o simplemente tenerlas pero mal facilitadas acaba degradando el poder creativo y la cohesion del equipo, pues problemas subyacentes se vuelven cada vez más agudos hasta el punto de fracturar las relaciones interpersonales y consecuentemente el trabajo mismo.

Las retrospectivas podrían también llegar a realizarse en función de los sucesos que las disparen, es decir en lugar de solamente tenerlas en un evento formalmente programado para el final del Sprint el equipo podría tener reuniones cortas y puntuales cada vez que identifiquen un punto de mejora tal como lo hacen en Toyota [Womack07].

Product Backlog

Para el Product Backlog el Product Owner tiene las siguientes responsabilidades:

  • Liderar su descubrimiento inicial con la participación de clientes y patrocinadores clave
  • Mantener el Product Backlog vivo y siempre reflejando su entendimiento más actualizado del producto, el mercado y el cliente
  • Ordenar el Product Backlog de manera de centrar el tiempo y capacidad del Equipo de Desarrollo en los items que vayan a retornar más valor una vez implementados

A su vez para el Product Backlog el ScrumMaster es responsable de:

  • Hacer coaching a los dos otros dos roles para que vean el Product Backlog como una herramienta valiosa de comunicación y ordenamiento de trabajo que va contribuir valor
  • Hacer coaching a los dos otros roles para que juntos mantengan el Product Backlog pequeño y con solamente el mínimo necesario de detalle

Finalmente los Desarrolladores para el Product Backlog serán responsables de lo siguiente:

  • Proveer estimaciones y principalmente reestimaciones que contribuyan realismo
  • Refinarlo semanalmente en el evento de Backlog Refinement Meeting
  • Clarificar sus items con los creadores originales del requerimiento

Las responsabilidades anteriormente nombradas para cada rol sirven también para hacer énfasis en que el Product Backlog, al igual que los demás artefactos de Scrum, son elementos articuladores entre los roles.

El Product Backlog como tal debe tener las siguientes características:

  • Es dinámico y cambiará constantemente en función del aprendizaje del equipo y el descubrimiento del cliente
  • Esta ordenado y se reordenará constantemente con el afán de poner la energía del equipo en la implementación de primero los items más importante para el negocio 
  • Es finito y alcanzable en un horizonte cercano de tiempo
  • Es público y cualquier miembro del equipo puede verlo y editarlo pero solo el Product Owner puede cambiar el orden 

Muchas veces las metáforas son útiles para que un equipo acabe entendiendo un artefacto y lo aplique adecuadamente en el día a día [Auer02]. En tal sentido he encontrado útil asociar el Product Backlog con la metáfora de una lista de supermercado que lógicamente es dinámica, se ordena por prioridades dictadas por tiempo, dinero y preferencias, es finita, y es visible para toda la familia. 

Dentro del Product Backlog existen componentes a los cuales prefiero llamar simplemente items que deben cumplir con ciertas características:

Están orientados al cliente

  • Contribuirá valor al producto una vez implementado
  • No se detallan usando documentos sino que se conversa acerca de ellos
  • Se deben descomponer en items más pequeños que puedan ser implementados manteniendo un flujo constante

De manera general podemos considerar que los items en el Product Backlog son marcadores de posición para tener conversaciones acerca de ellos y su potencial valor en el producto. El punto es que esos items son promesas de conversaciones en lugar de documentos estáticos escritos a detalle [Larman17]. 

Sprint Backlog

El Sprint Backlog tiene las siguientes características esenciales:

  • Es creado por el Equipo de Desarrollo que lo utilizará activamente durante el Sprint
  • Contiene solamente información primaria para no sobrecargarlo demasiado
  • Puede contener estimaciones que son indicativas pero no compromisos inamovibles 

Es más que seguro que el Sprint Backlog ira cambiando a medida que los desarrolladores empiecen a trabajar en los items para el Sprint. 

Por lo anterior los desarrolladores son totalmente responsables de reestimar las tareas −en las cuales se descompusieron los items− cuando lo crean necesario, seguir descomponiendo, o cambiar el orden de las tareas. 

Sin embargo el Product Owner debe ser necesariamente consultado si tales cambios implicaran un impacto en la profundidad o anchura del alcance de la implementación del item. 

Definición de Terminado

Tener una Definición de Terminado común a varios Equipos Scrum se hace necesaria por las siguientes razones:

  • Brindará claridad para todo el mundo acerca de qué se considera realmente terminado lo cual eliminará posibles malos entendidos y desconexiones
  • Ayudará a que los equipos se comuniquen mejor a través del código ya que todos llamarán terminado a lo mismo

Aún cuando todos los equipo parten de una Definición de Terminado común es posible que algún equipo decida modificarla para hacerla más estricta o para llevarla cada vez más cerca a un ambiente de producción [Humble10].

No se puede decir que una Definición de Terminado sea buena o mala, pero si es cierto que ers más valiosa cuanto más cercana está de poner código en producción en tiempos cada vez más cortos [Forsgren18].

De manera más general, un equipo Scrum puede decidir modificar su Definición de Terminado por los siguientes motivos:

  • Un equipo encontró una Definición de Terminado aún más poderosa y ahora desea contagiar a otros equipos
  • Durante su retrospectiva un equipo observó que su Definición de Terminado no es lo suficientemente estricta o todo lo contrario
  • En el Sprint Review se están presentando items con deuda técnica o funcional 

Conclusiones

Inspección, adaptación y transparencia son mecanismos poderosos que Scrum emplea dentro de su forma de trabajo adaptativa que busca acomodarse bien al cambio del alcance. 

Cambio que a su vez ocurre por la naturaleza dinámica del mercado y/o por la incertidumbre respecto a que esperan realmente los clientes que haga el producto para ellos.

Estos tres pilares están presentes en los eventos y artefactos de Scrum y deben ser empleados por el Equipo Scrum como parte de su diario accionar.

La carencia de estos pilares no sólo limitara Scrum sino que trae consigo el riesgo de creer −inocente o mal intencionadamente− que se esta haciendo Scrum cuando en realidad es Scrum sólo de nombre.

Finalmente, Scrum no se basa en herramientas pesadas ni caras sino que tiene como eje motor al equipo y su sistema de principios, creencias y valores.

Bibliografia 

Rubin02 Rubin K., 2012. Essential Scrum: A Practical Guide to the Most Popular Agile Process, Addison-Wesley

Auer02 Auer K., Miller R., 2002. Extreme Programming Applied, Addison-Wesley

Ohno13 Ohno T., 2013. Taiichi Ohno’s Workplace Management, McGraw Hill

Lencioni02 Lencioni P., 2002. The Five Dysfunctions of a Team: A Leadership Fable, Jossey-Bass; 1st edition

Beck00 Beck K., Fowler M., 2000. Planning Extreme Programming, Addison-Wesley Professional

Goldratt14 Goldratt E. M., 2014. The Goal: A Process of Ongoing Improvement, The North River Press

Jeffries00 Jeffries R., Anderson A., Hendrickson C., 2000. Extreme Programming Installed, Addison-Wesley Professional

Patton14 Patton J., 2014,  User Story Mapping: Discover the Whole Story, Build the Right Product, O’Reilly Media

Roden15 Rosen 15., 2015, Fifty Quick Ideas to Improve Your Retrospectives, Neuri Consulting LLP

Womack07 Womack J., Jones D., Ross D., 2007. The Machine That Changed the World: The Story of Lean Production– Toyota’s Secret Weapon in the Global Car Wars That Is Now Revolutionizing World Industry, Free Press; Reprint edition

Larman17 Larman C., Vodde B., 2017. Large-Scale Scrum More with LeSS, Addison-Wesley

Fowler02 Fowler M., 2002. Patterns of Enterprise Application Architecture, Addison-Wesley Professional

Humble10 Humble J., Farley D., 2010. Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation, Addison-Wesley

Forsgren18 Forsgren N., Humble J, Kim G., 2018. Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations, IT Revolution Press

Roles en Scrum

Posted on by Juan in Scrum

Introducción

Una de las principales contribuciones de Scrum es que definió más claramente tres roles que son los que se encuentran dentro de un equipo, enfatizando que tres y sólo tres roles son necesarios.

Sin embargo con el paso de los años estos tres soles han sido mal entendidos principalmente porque las organizaciones tratar de hacer una equivalencia directa con cargos jerárquicos existentes. 

El primer punto de cambio proviene de que precisamente las organizaciones deben darse cuenta de que tienen que cambiar su estructura jerárquica formal hacia algo más ligero y simple. 

Los roles tampoco fueron creados para hacer un plan de carrera ya que ellos coexisten con el mismo nivel de jerarquía y autoridad dentro del equipo. Dicho de otra manera, cada rol esta en relación de pares con los otros dos roles. 

El equipo

En principio hay que hacer notar que en terminología Scrum existen dos equipos:

  • El Equipo Scrum que aglutina a todos los roles
  • El Equipo de Desarrollo que aglutina a los Desarrolladores

Personalmente creo que esta separación conceptual contribuye muchas veces confusión ya que la gente empieza a preguntarse cosas como ¿si soy Desarrollador a que equipo pertenezco?

Considero entonces que es mucho más sencillo utilizar el termino Equipo para referirse a las personas que trabajan juntos en el desarrollo de un producto [Larman17].

Tamaño del equipo

La preferencia siempre es tener equipos pequeños puesto que esto facilita la colaboración e interacción efectiva. Esta demás decir que un equipo pequeño se comunicara efectivamente si todos sus integrantes trabajan desde la oficina y comparten la misma mesa.

Sin embargo cuando un equipo es demasiado pequeño, digamos dos personas, no existe suficiente diversidad de opinion ni tampoco suficiente gente para cada rol. Un equipo demasiado pequeño también tiene menos posibilidades de avanzar rápido pues simplemente no hay suficientes desarrolladores que escriban código.

En el otro extremo, un equipo que se acerca o pasa la decena de integrantes se vuelve ineficiente debido a: problemas de comunicación y coordinación, malos entendidos, desocupación, y  especialización excesiva.

Por tanto llegamos a que un tamaño recomendable de equipo debería ser de más o menos siete integrantes incluyendo todos los roles. Sin bien la teoría dice que podemos aumentar o reducir dos personas mi recomendación es que tengamos siete como el número máximo de integrantes para un equipo.

Los Tres Roles

Los tres roles de Scrum son los siguientes:

  • ScrumMaster
  • Product Owner
  • Desarrollador

Cada uno de estos roles tiene un enfoque diferente:

  • ScrumMaster enfocado en Scrum, la gente, los procesos adaptativos, el cambio organizacional, la motivación, el trabajo en equipo
  • Producto Owner enfocado en el producto, el cliente, el mercado, la estrategia, el mediano y largo plazo
  • Desarrolladores enfocados en en la calidad del código, en las prácticas técnicas, la táctica, en aprender el lenguaje especifico del cliente, y el aprendizaje constante

No existen roles adicionales ni deberían existir; no existe por ejemplo el rol de Manager o Project Manager pues el equipo se maneja a si mismo y no hay una figura central de autoridad.

Tampoco existe roles de Lideres Técnicos o Arquitectos porque las decisiones técnicas se toman en base al consenso y conocimiento de los desarrolladores. 

El liderazgo como tal existe pero es primero rotativo dependiendo del tema o coyuntura y segundo voluntario pues la gente decide a quien seguir. 

Derechos y Responsabilidades del Product Owner 

El Product Owner tiene los siguientes derechos:

  • Abortar el Sprint si identifica que el Incremento del Producto perdió todo  valor de negocio para el cliente
  • Tener la palabra final acerca del orden del Product Backlog
  • Pedirle a los desarrolladores que en cualquier día del Sprint le muestren software funcionando, bien construido y corriendo en un ambiente integrado preferentemente de producción

El que un Product Owner no pueda ejercer sus derechos es un indicador claro de que algo no esta funcionando bien y es labor suya y del resto del equipo (e incluso la organización en su conjunto) trabajar para que pueda ejercerlos.

Si bien el Producto Owner tiene derechos también tiene obligaciones, alguna de ellas son:

  • Maximizar el potencial retorno de la inversión identificando características del producto y ordenando esas características en una lista (Product Backlog)
  • Trabajar dedicadamente para que el Product Backlog sea visible, pequeño, adaptativo y claro para todo el equipo y clientes
  • Conectar a los desarrolladores con los clientes que originaron los requerimientos para que puedan hablar directamente y facilitar la comunicación de primera mano
  • Ser el guardian de la vision del producto, es decir, ser quien tenga claro que está construyendo el equipo, para quien, en cuanto tiempo y con que impacto esperado
  • Mantener el Product Backlog ordenado y alineado con los objetivos de negocio que se persiguen con la construcción del producto

Nótese que no menciono como una de las responsabilidades del Product Owner el escribir historias de usuario ya que éste es uno de los malos entendidos más grandes acerca de este rol.

Las historias de usuario no se deben escribir por las siguientes razones [Larman10]:

  • El lenguaje escrito no es la forma más eficiente y económica de comunicación
  • Historias de usuario detalladas con lenguaje escrito eliminan la necesidad de comunicación oral, debate y creatividad colectiva
  • Mucha escritura hace que el equipo invierta tiempo excesivo analizando y redactando documentos convirtiendo Scrum en una cascada dividida en fases
  • Al escribirse las historias se disminuye significativamente la necesidad de que el cliente hable con los desarrolladores y viceversa, en Scrum queremos exactamente lo opuesto “colaboración con el cliente”

Las historias, porque el nombre correcto es “historias” y no “historias de usuario”, se crearon para tener presente un patrón de comportamiento en el cual los desarrolladores interactúan con los clientes de manera frecuente [Beck99]. 

Derechos y Responsabilidades del ScrumMaster

El ScrumMaster tiene derechos tales como:

  • Llamar la atención del equipo cuando hacen algo completamente desviado de la esencia de Scrum pero lo llaman Scrum
  • Tener el respaldo del nivel más alto de gerencia para tratar de cambiar el sistema organizacional dentro del cual opera el equipo
  • Tratar de extender Scrum muchos más allá del equipo para contagiar a toda la organización y provocar su transformación 

Es importante hacer notar que el simple hecho de empezar con Scrum es de por si disruptivo para muchas organizaciones todavía ancladas en prácticas Tayloristas. Como corolario de lo anterior no se puede esperar que al adoptar Scrum todo siga como antes, por el contrario Scrum −si su adopción es exitosa− acabará transformando una organización que comenzará a emplear prácticas de administración modernas [Hamel07]. 

Las obligaciones del ScrumMaster incluyen por ejemplo:

  • Crear, cultivar y expandir un ambiente de aprendizaje continuo donde el equipo se sienta cómodo experimentando, fallando y aprendiendo
  • Cambiar al equipo y las dinámicas de la organización
  • Ayudar a que el equipo se comunique efectivamente entre sus miembros pero también externamente con los clientes y el resto de la organización
  • Colaborar con el equipo para despejar obstáculos
  • Contribuir para el equipo se mantenga enfocado y cercano al lugar donde realmente ocurre el trabajo (gemba) 
  • Insertar en el equipo la mentalidad de siempre andar buscando y eliminando formas de desperdicio [Ballé14] 

Derechos y Responsabilidades del Desarrollador

Los desarrolladores tiene derechos como por ejemplo:

  • Sentirse cómodos y respaldados para decir “no se” 
  • Ser capaces de autoorganizarse y decidir por si mismos como hacer el trabajo
  • Invertir tiempo, esfuerzo y energía para crear un producto de software bien construido que los haga sentir orgullos de su trabajo y dominio de su artesanía

Que los desarrolladores entiendan sus derechos y tengan el respaldo de la organización para hacerlos valer es vital. De nada serviría que los desarrolladores crean tener estos derechos y la gerencia se los quite o simplemente les diga como hacer la cosas y los presione al punto de no dejarlos invertir tiempo y esfuerzo para crear software con calidad.

El conocimiento de la artesanía de software es vital pues sólo a través de él los desarrolladores aprenden los fundamentos de su oficio, fundamentos que deberían pasarse de generación en generación y no redescubrirse para cada producto. Artesanos de software con conocimiento del oficio muchas veces son necesarios para capacitar al equipo [Mancuso15].

Si hablamos de las responsabilidades de los desarrolladores, estas incluyen entre otras:

  • Aprender una segunda, una tercera y de ser posible hasta una cuarta especialidad técnica para así poder construir más efectivamente al equipo
  • Aprender el lenguaje y terminología del dominio de conocimiento con el que se esta trabajando para comunicarse eficientemente con el cliente
  • Construir software utilizando prácticas modernas para el desarrollo de software [Beck99]
  • Evitar desperdicios en el trabajo y procesos que retrasen la retroalimentación y comunicación efectiva con el cliente
  • Manifestar su opinión cuando se sienten sobrecargados o cuando sienten que el producto esta yendo en la dirección equivocada 

Características del Equipo de Desarrollo

El Equipo de Desarrollo debe reunir ciertas características para realmente funcionar bien [Larman08], características tales como:

  • De larga vida, que quiere decir que los miembros del equipo se conocen de hace mucho y viene trabajando años juntos
  • Co-ubicado, que literalmente implica que todos los miembros del equipo trabajan desde la misma oficina y se están sentados compartiendo la misma mesa de trabajo
  • Sin jefes formalmente asignados, esto implica que no hay una jerarquía impuesta sino lideres naturales que el resto del equipo decide seguir dependiendo de las circunstancias
  • Autoorganizados, que pone el poder (y la responsabilidad) en los miembros del equipo para decir como se organizaran para llevar a cabo el trabajo
  • Empoderados, que quiere decir que los miembros del equipo toman decisiones técnicas por si mismo sin tener que consultar o ser aprobados por alguna otra persona

Las características anteriores parecen ser muy caras y contradicen la tendencia de tener outsourcing y equipo geográficamente distribuidos, pero si lo pensamos bien, hacemos las cuentas, y le preguntamos a la gente de los equipos que hacen el trabajo encontraremos que tienen sentido.

Desde una perspectiva sistema, si tenemos un equipo visto como un sistema que tiene miembros pasajeros, que esta globalmente distribuido, que tiene jefes, que recibe ordenes, y que require aprobaciones entonces acabamos con un sistema más complejo, jerárquico, lento y burocrático. 

Scrum desde luego no quiere lo anterior sino más bien persigue la noción de simplicidad sistémica donde un equipo opera de la manera más efectiva posible con la menor complejidad.

El Product Owner es una Sola Persona

Existen varias razones para concentrar la responsabilidad de Product Ownership en una sola persona, una de las más importantes es que una persona en lugar de un comité acorta el proceso de toma de decisiones y ayuda a mantener la integridad del producto.

El concepto de tener una persona con capacidad total de decisión sobre el producto no es nuevo, de hecho se inspira en el Chief Engineer de Toyota que tiene todo la responsabilidad sobre el desarrollo y puesta en producción de un vehículo.  

Aún cuando pensamos o necesitamos escalar Scrum para múltiples equipos lo más recomendable es mantener un solo Product Owner y un sólo Product Backlog para un producto que será desarrollado por centenares de desarrolladores [Larman17].

Un Product Owner para ser efectivo en su rol debe realmente estar inmerso en el mercado y entender a cabalidad sus necesidades, más importante todavía debe ser capaz de anticipar los movimientos del mercado. 

El Product Owner Tiene la Palabra Final Acerca del Producto

Aún cuando los usuarios, los clientes, y los ejecutivos pueden tener opiniones respecto al rumbo del producto, es la prerrogativa del Product Owner decidir que va o no en el Product Backlog y en que orden. 

Como el Product Owner tiene la palabra final sobre el producto él debe buscar tener ciclos cortos de retroalimentación para validar sus ideas e hipótesis acerca del producto.

Los ciclos cortos de retroalimentación a su vez tienen dos precondiciones:

  1. Tener software funcionando en todo momento
  2. Tener acceso a clientes o usuarios reales en todo momento

Si lo anterior no es posible todavía mi sincera recomendación es trabajar hasta conseguir que si lo sea porque no hay sustituto para la retroalimentación real. 

La retroalimentación real que recolecta el Product Owner de los usuarios finales, el mercado e inclusive el equipo, le permite redireccionar el curso del producto o validar que se está avanzando en la dirección correcta, pivotear o perseverar en terminología de Lean Startup [Reis11].

Sólo Product Owner Aprueba Trabajo para el Equipo de Desarrollo

El Equipo de Desarrollo esta compuesto por desarrolladores a tiempo completo que trabajan en un sólo producto a la vez y es el Product Owner quien decide que se trabajara en cada Sprint, romper esta regla trae consecuencias como:

  • Pérdida de enfoque del equipo con el consiguiente costo de reenfoque
  • Demasiadas distracciones porque el trabajo viene desde multiples fuentes causando retrasos, peleas internas, retrabajo, y confusión de prioridades

Cabe hacer énfasis en que si bien el Product Owner es quien aprueba que trabajo se hará, ya a la hora de hacer el trabajo los desarrolladores deben comunicarse directamente con los clientes para así entender que se debe hacer e ir recolectando retroalimentación a medida que avanzan con el trabajo.

De hecho una de las grandes confusiones con el rol del Product Owner es pensar que él es el único que puede y debe hablar con los clientes, si esto acaba ocurriendo el Producto Owner se convertirá en el recurso critico que provocará un cuello de botella y consecuentemente retrasará el flujo de trabajo [Goldratt90].

Desde la teoría de la comunicación se sabe que mientras más nodos se añadan en un canal de comunicación más tarde y distorsionado llegará el mensaje. Es por esta razón que tampoco conviene tener un Product Owner que este de hombre en el medio entre el equipo y el cliente. 

Conclusiones

Los roles de Scrum son solo tres y deben mantenerse así pues no se necesitan más. Cuando se observan problemas en la adopción de Scrum buscar en el número de roles o añadir más personas normalmente no es la solución, el problema muchas veces está en otro lugar.

Tres roles implican simplicidad y es que en esencia Scrum es minimalista y Lean, es importante siempre recordar lo anterior para no complejizar el Equipo Scrum con nuevos roles o figuras de poder innecesarias.

Los roles son solamente eso roles pero no cargos jerárquicos que limitan responsabilidad y derechos de manera estricta. Al final el trabajo en equipo y la colaboración debe sobreponerse por el encima del dogma que puede llevar a que alguien diga “yo no hago ese trabajo porque no esta definido dentro de mi rol”.

Bibliografia 

Larman17 Larman C., Vodde B., 2017. Large-Scale Scrum More with LeSS, Addison-Wesley

Larman10 Larman C., Vodde B., 2010. Practices for Scaling Lean & Agile Development: Large, Multisite, and Offshore Product Development with Large-Scale Scrum, Addison-Wesley Professional 

Beck99 Beck K., 1999. Extreme Programming Explained: Embrace Change, Addison-Wesley

Hamel07 Hamel G., 2007. The Future of Management, Harvard Business Review Press

Ballé14 Ballé M., Ballé F., 2014. Lead With Respect A Novel of Lean Practice, Lean Enterprise Institute

Mancuso15 Mancuso S., 2015. The Software Craftsman: Professionalism, Pragmatism, Pride, Prentice Hall

Larman08 Larman C., Vodde B., 2008. Scaling Lean & Agile Development: Thinking and Organizational Tools for Large-Scale Scrum, Addison-Wesley Professional

Reis11 Reis E., 2011. The Lean Startup, Crown Business

Goldratt90 Goldratt E. M., 1990. Theory of Constrains, The North River Press

Teoría de Scrum

Posted on by Juan in Scrum

Introducción

Scrum no es un marco de trabajo novedoso ni que se haya inventado siquiera en la década presente, por el contrario ya fue teorizado por Schwaber y Beedle el 2001 [Schwaber01]. Sin embargo pese a su antigüedad su popularización se ha dado recién en los últimos años. 

La tardía entrada de Scrum en varios países y contextos no es necesariamente un síntoma de atraso tecnológico o cognitivo, por el contrario trae la ventaja de que Scrum llega ahora más pulido y cargado de experiencias de cosas que se intentaron pero no acabaron funcionando bien y que por eso mutaron hacia otros conceptos.

También es oportuno mencionar que Scrum no se creo de la nada sino que más bien viene fuertemente influenciado por Toyota, Lean y Extreme Programming. Considero necesario hacer esta puntualización para no pensar que Scrum es solamente unas pocas páginas de teoría ligera. 

Scrum: Una definición corta

Scrum es un marco de trabajo ligero con el cual un equipo de funcionalidad cruzada desarrolla productos de manera iterativa e incremental.

Scrum: Una definición más larga

Scrum esta basado en el poder sinérgico y creativo de un equipo, no es un marco de trabajo de aplicación individual ni tampoco se adapta bien para grupos de personas aleatoriamente reunidas que no son un equipo.

Debido al fuerte componente humanista que implica el trabajo en equipo, las interacciones y resultados que se logran dentro de un equipo Scrum difícilmente son directamente extrapolables hacia otros equipos de incluso la misma empresa y peor aún de otras empresas.

En este sentido podríamos decir que Scrum es altamente situacional y dependiente del contexto temporal. Lo anterior podría hacer parecer que Scrum es sui generis pero en realidad es como cualquier deporte de equipo en el cual cada partido es diferente.

Al igual que con los deportes en equipo ocurre con Scrum que las reglas de juego son simples y conceptualmente sencillas de entender pero luego requieren práctica, pasión, constancia, adaptabilidad y disciplina para poder jugar bien en el contexto del desarrollo de un producto. 

Elementos clave de Scrum

Scrum tiene tres elementos clave, a saber:

  1. Entregar software funcionando al final de cada Sprint
  2. Inspeccionar y hacer adaptaciones diariamente
  3. Confiar en el equipo

Imaginemos ahora que ocurriría si estos tres elementos claves no estarían presentes:

  1. Al no tener software funcionando al final de cade Sprint no se estaría respetando la Definición de Terminado y se estaría creando la falsa impresión de que estamos avanzando cuando en realidad existe gran acumulación de deuda técnica.
  2. Cada día se trataría de trabajar de acuerdo al plan inicialmente creado sin tomar en cuenta variaciones producidas por el cliente, el mercado, la tecnología o la misma gente del equipo; consecuentemente el equipo no sería adaptativo y por el contrario caería en la mentalidad rígida de ejecutar un plan sin importar lo demás. 
  3. Al no haber confianza la gerencia cae en el síndrome de pedir reportes detallados para tratar de entender con métricas y palabras escritas el código. La desconfianza también puede existir dentro del equipo donde sus integrantes no se apoyan ni piden ayuda debido a disfuncionalidades subyacentes.

Valores de Scrum

Un equip Scrum es de por si diverso en términos de género, conocimiento, experiencias de vida, edad cronológica, etc. Tanta diversidad es beneficiosa pues ofrece oportunidades de aprendizaje, variedad de opiniones y puntos de vista.

Sin embargo, la diversidad pueden hacer que un grupo de personas nunca llegue a cuajar como equipo si las personas no tienen un sistema de creencias común; es precisamente a este sistema de creencias que los creadores de Scrum llaman Valores de Scrum [Schwaber04].

Los Valores de Scrum son:

  • Enfoque
  • Coraje
  • Compromiso
  • Apertura
  • Respecto

Aunque estos valores son creencias y no algo tangible, son imprescindibles para un equipo que quiere realmente adoptar Scrum. Más aún, estos valores deben también estar presentes dentro de la empresa en la cual opera el equipo Scrum. 

Las personas dentro de cada rol deben realmente vivir en su día a día estos valores para que estos estén presentes en cada evento y artefacto de Scrum. 

Así por ejemplo durante el Sprint el equipo necesita mantenerse enfocado, tener el coraje de innovar, comprometerse con el objetivo del Sprint, estar abierto a aprender nuevas cosas y mantener una relación de respecto con las demás personas. 

Proceso de Control Empirico

Scrum implementa un proceso de control empírico basado en observaciones de la realidad en lugar de basarse en planes ficticios quedados en el tiempo. 

Es de esta manera que llegamos a que empirismo en Scrum significa trabajar basados en experiencias, hechos y observaciones y no confiar ciegamente en una planificación detallada realiza antes de empezar a trabajar.

El empirismo se basa en tres pilares fundamentales:

  • Inspección
  • Adaptación
  • Transparencia

Aplicando inspección posibilitada a la vez por transparencia el equipo Scrum hace adaptaciones (diariamente o al menos en ciclos cortos) en su forma de trabajo, sus interacciones, sus prioridades y en el alcance realizable dentro del Sprint.

Aunque tenemos empirismo ciertas cosas como: la duración del Sprint, los miembros del equipo, o el stack tecnológico; son definidas al principio de un Sprint y deberían mantenerse constantes (salvo excepciones) para no introducir demasiada disrupción.

De manera general en Scrum buscamos mantener un delicado balance entre lo empírico y lo definido. Constantemente tratamos de mejorar el lado definido de las cosas a través de ideas que salen del aprendizaje y experimentación constante.

Scrum es un Marco de Trabajo

Como fue definido por sus creadores [Schawaber07] y [Schawaber12]  Scrum es un marco de trabajo con el cual la gente puede trabajar de manera adaptativa para tratar de resolver problemas complejos, la resolución de estos problemas de forma productiva y creativa esta orientada a la creación de productos que aporten el mayor valor posible a sus consumidores finales.

Yendo un paso más atrás un marco de trabajo es una estructura básica que sirve de soporte a un sistema, un concepto, una idea o un texto. Por tanto un marco de trabajo se utiliza porque encima de él se quiere construir algo más. 

Scrum al ser definido como un marco de trabajo puede ser extendido y complementado con otros conceptos y herramientas. En este sentido Scrum es en realidad un meta-marco de trabajo que incorpora elementos empíricos de control.

Los elementos empíricos de control son los que precisamente nos indicarán si las extensiones que hacemos con el marco de trabajo son beneficiosas o por el contrario distorsiona el marco de trabajo y lo alejan de su esencia.

Scrum no es una metodología y menos una metodología ágil como comúnmente se cree. Es más, los creadores de Scrum nunca pretendieron crear una metodología pues una metodología es un conjunto de pasos científicamente estudiados que al ser aplicados siguiendo un orden metódico garantizan un resultado. 

Un marco de trabajo, en oposición a una metodología, esta minimalistamente definido e invita a la creatividad y complementación con herramientas, ideas, y prácticas importadas de otras disciplinas.

En términos simples: 

  • un marco de trabajo invita a la creatividad y require trabajo efectivo en equipo
  • una metodología invita al cumplimiento y requiere supervision y control efectivo.

Otra distinción fundamental es que en una metodología métricas duras y precisas son piezas fundamentales mientras que en un marco de trabajo toman relevancia la colaboración, el trabajo en equipo y la comunicación. 

Scrum requiere práctica dedicada

Debido a que Scrum es un marco de trabajo ligero conceptualmente fácil de entender  mucha gente y organizaciones tienden a subestimarlo y realizar solamente adaptaciones cosméticas.

Desde luego los cambios cosméticos son los más simples y en teoría baratos de hacer, el gran problema con ellos es que no acaban cambiando sistemicamente el diseño organizacional que es imprescindible para que Scrum florezca. Un problema secundario pero no menos importante es que los cambios cosméticos acaban creando desilusión después de un tiempo y la consecuentemente la falsa impresión de que Scrum no funciona.

La simplicidad conceptual de Scrum también provoca la falsa impresión de que es solamente un tema de leerse quince páginas, asistir a un curso de dos días y pasar un examen a libro abierto. Muy por el contrario Scrum tiene muchas pero muchas disciplinas aliadas y conocimiento complementario que solamente puede ser adquirido a través de la lectura, investigación y práctica constante.

Haciendo una analogía con la practica del yoga, una persona no puede esperar todos los beneficios que provee esta disciplina ancestral sin practicarla diariamente y un practicante devoto de yoga es además un lector e investigador que entiende a cabalidad los principios y fundamentos de su disciplina. 

Conclusiones

Scrum todavía tiene un camino muy largo por recorrer en su evolución teórica que se enriquece con la practica constante traducida en producción intelectual de contenido, basta ver nada más la cantidad de libros y otros materiales que llevan como tema central Scrum y han sido producidos en la última década. 

Sin embargo uno de los riesgos latentes es que Scrum sea mal entendido y consecuentemente mal aplicado, por eso el énfasis de este texto en los principios, valores, esencia e influencias que recoge Scrum.

Mucha gente afirma que para adoptar Scrum se requiere un cambio de paradigma mental, yo pienso que hay en realidad habría que empezar por un cambio de paradigma organizacional sistemático para de ahi recién derivar el cambio de comportamiento que consecuentemente acabará cambiando el paradigma mental.

Finalmente, adoptar Scrum es similar a adoptar cualquier otra disciplina, deportes o arte que apasiona a sus seguidores y que requiere tiempo, esfuerzo, dedicación y práctica constante para obtener sus verdaderos beneficios. 

Bibliografia 

Schwaber01 Schaber K., 2001. Agile Software Development with Scrum

Schwaber04 Schaber K., 2004. Agile Project Management with Scrum

Schwaber07 Schaber K., 2007. The Enterprise and Scrum

Schwaber12 Schaber K., 2012. Software in 30 Days: How Agile Managers Beat the  Odds, Delight Their Customers, and Leave Competitors in the Dust


Explicando Scrum con analogias

Posted on by Juan in Scrum, webinar

Recientemente tuve la oportunidad de colaborar con el Scrum Alliance para grabar un webinar en el cual explico, o al menos trato de hacerlo de la forma más simple posible, los roles de Scrum y el marco de trabajo usando analogías de deportes, música y otros ambitos.

El webinar esta disponible en el sito del Scrum Alliance y ojala sirva para aportar algo más de claridad sobre este tema.