¿Cuál es la diferencia entre conocimiento explícito y tácito?

Realmente lo que ocurrió es que un alumno me preguntó en un curso presencial: ¿Qué es el conocimiento tácito? Sonreí por dentro con cierta ironía porque el hombre acababa de realizar su certificación PMP, e imaginé que la certificación en Scrum estaba haciendo tambalear sus esquemas. He de admitir que este alumno se interesó mucho por Scrum, y que sus comparativas con PMBOK siempre resultaron en una síntesis que sumaba.

El conocimiento puede tener dos naturalezas:

• Explícito: contenido en los procesos y la tecnología
• Tácito: contenido en las personas

Reglas de Scrum como conocimiento explícito, cortesía de Juan Palacio

El conocimiento explícito es aquel conocimiento que se puede escribir, codificar y almacenar en algún tipo de medio y tiene la característica de poder ser transmitido inmediatamente a otros, tanto personas como sistemas. Los procesos y la tecnología empleada en un proyecto se basan en conocimiento explícito, la calidad de sus resultados se encuentra en ese conocimiento explícito. Un ejemplo de ello son las reglas del marco de trabajo de Scrum, el resultado de la implementación del Scrum reside en la correcta aplicación de sus reglas, en definitiva el conocimiento explicitado en la figura del post.

El conocimiento tácito consta comúnmente de hábitos y aspectos culturales que difícilmente reconocemos en nosotros mismos, o en palabras de los autores Nonaka & Takeuchi (1995) un conocimiento "informal, personal o social, difícil de expresar de forma sistematizada - poco visible y difícil de compartir por los medios tradicionales - que poseen los actores del contexto donde se desarrolla cualquier actividad humana, incluso dentro de las organizaciones".

Uno de los aforismos famosos de Polanyi respecto al conocimiento tácito es: "Conocemos más de lo que podemos decir". Por ejemplo, los que trabajamos en proyectos de TI en ocasiones nos hemos visto enfrentados a una incidencia que no sabemos por dónde cogerla. Entonces uno de los miembros experimentados del equipo utiliza expresiones como "esto es como aquello que...", "esto me suena a la función de...", "mirar allí..." y efectivamente, ese conocimiento difuso que procede de la experiencia con el proyecto nos lleva a la solución de la incidencia. Otro ejemplo de conocimiento tácito es cuando vemos por primera vez un piso candidato de compra o alquiler, entramos en el piso y gracias a nuestro conocimiento tácito e inteligencia emocional sabremos en 2-3 minutos si nos vale o no vale. Hacer este mismo análisis con un proceso explícito en base a nuestra inteligencia racional costaría entre ¡¡¡2 y 4 horas o más!!!

En Agilidad la producción se basa en personas donde el conocimiento o "know-how" responsable de la calidad del resultado se encuentra en mayor medida en el "saber hacer" tácito de las personas que lo construyen. Las personas adquirimos conocimiento tácito automáticamente al compartir experiencias, con la comunicación directa, con documentos, con manuales y con tradiciones, añadiendo así continuamente conocimiento novedoso a la base colectiva de la organización.

¿Cómo resuelve Scrum la frustración de un desarrollador cuando le viene una enésima modificación de su tarea?

Si preguntamos a los programadores qué es lo que más les fastidia y más malestar les produce, su contestación suele ser que cuando les hacen modificar una y otra vez el mismo código o transacción. 

Desesperado ante un cambio, gracias Pedro por la escenificación :-)

En equipos tradicionales, sin valores ágiles adquiridos, los desarrolladores suelen no ver más allá de la parte del desarrollo que les atañe directamente, y son varios los sentimientos de rechazo que puede producirles un enésimo cambio:

• Una asociación automática con que les viene "otro marrón que no es mío" que supondrá un esfuerzo por su parte y que asociará directamente a correr, a estrés y a hacer horas extra
• Un sentimiento de crítica hacia su trabajo, contrario al reconocimiento que todos necesitamos
• Enfado hacia el usuario, analista o jefe de proyecto que según su percepción no sabe lo que necesita, produciéndose exclamaciones como "Que hagan bien su trabajo, y antes de marearme que definan bien..."
• Desmotivación por sentirse anclado a la misma pierda y no ver avance

Una de las consecuencias más caras de la desmotivación puede ser una degradación paulatina del código, la incurrencia en deuda técnica y por ende, de una calidad mediocre del producto.

Como expone el Manifiesto Ágil "valoramos la respuesta ante el cambio sobre seguir un plan", Scrum abraza el cambio y por tanto, situaciones de enésimos cambios sobre un mismo objeto forman parte de la naturaleza de los proyectos ágiles. Entendido esto, tanto por el equipo como por todos los demás interesados, la mentalidad con la que el desarrollador se enfrenta a estos cambios es muy distinta. El cambio no le rompe nada, el cambio forma parte de su día a día y tiene la vía de incorporación del cambio resuelta:

• La tarea al estar dentro de un sprint intocable, con un inicio y un final, hará que el programador haya cerrado mentalmente el cambio en curso antes de iniciar un posible cambio posterior en otro sprint
• No hay solapamientos. Nuevos cambios, nuevos sprints, un espacio propio y acotado para cada cambio. Al entrar en un sprint el nuevo cambio este es reconocido y aceptado por todos, tanto equipo como interesados
• Gracias a la comunicación y transparencia propia de Scrum, el programador tiene visión del producto y así está preparado para entender el porqué del cambio. Tiene empatía hacia el cliente y es capaz de ver y entender la necesidad del cambio, y de que se ha producido por un cambio sufrido en el negocio/mercado que se le ha contando y comprende
• No tiene sensación de hacer un esfuerzo extra, cada cambio viene a través la pila de producto y entra en la pila de sprint con el tiempo necesario para realizarlo
• No tiene sensación de trabajo mal hecho, si su tarea ha estado bien hecha ha sido reconocida en la reunión de revisión de sprint correspondiente
• El sentimiento es de avance continuo, si no es por su tarea inmediata percibe el avance en adaptación del producto a las variaciones del negocio

La motivación hace que el desarrollador se sienta parte del proyecto y viva el producto, y de esta forma busque automáticamente la mejora continua en el código.

La motivación intrínseca que propicia Scrum va mas allá de la satisfacción del trabajo técnico bien hecho, esta surge del trabajo en conjunto bien hecho, sentir el orgullo de como la herramienta en que se ha participado resuelve realmente el trabajo diario a usuarios y clientes.

¿Pueden tomar los miembros del equipo el rol de Scrum Master de forma rotativa?

En uno de mis cursos tuve una conversación muy interesante con una de mis alumnas en cuya empresa habían implantado Scrum. Al inicio de la implantación decidieron que cada uno de los miembros del equipo pasaría por el rol de Scrum Master con la idea de que se enfrentara como Scrum Master a todas situaciones que este vive, y así todo el equipo adquiriera mayor conocimiento práctico y experiencia en Scrum. La idea fue que todo el mundo estuviera durante un sprint en la piel de quién garantiza y vela por las reglas de Scrum, además de desarrollar la gestión que conlleva el rol.

Vivir las actividades de un Scrum Master

Recordemos que un Scrum Master es un rol que se encarga de facilitar la comprensión de Scrum, de acompañar a los equipos y velar que estas se apliquen, de garantizar que estas no se rompan, además de facilitar la resolución de impedimentos al equipo. Tiene un perfil de coach para poder acompañar al equipo y a cada miembro en su camino hacia la autonomía, la autoorganización y la adopción de los valores ágiles como son la transparencia y el compromiso.

La experiencia fue muy positiva para aquellos perfiles de personas abiertas e interesadas por lo que les rodea, para ellos fue motivante y les llenó de entusiasmo. Los perfiles más introvertidos se limitaron a ejecutar las acciones derivadas de las reglas de Scrum de forma mecánica, para ellos fue una experiencia menos enriquecedora y prácticamente nada motivante.

La respuesta a la pregunta del post es un "si" para aquellos que tengan un perfil afín, generalmente de tipo T, y un "no" para aquellos en que su área de intereses cae fuera de las tareas de un Scrum Master. Recordemos que en un equipo puede haber sitio para todo tipo de perfiles, puede haber un perfil poco entusiasta que resuelve echen lo que le que echen, y otro perfil exultante que siempre esté metido en todo lo novedoso y en todo lo que sea un reto. La combinación de esos dos perfiles tan diferentes puede hacer del equipo un equipo ganador.

Quiero resaltar que un Scrum Master externo al equipo generalmente es una mejor solución, cuando el proyecto tiene problemas el Scrum Master y a la vez miembro de equipo puede tener un conflicto al tener que decidir si ir en favor del proyecto o de Scrum.

Este post lo dedico a Antonio y a Jordi, dos personas tan distintas y tan complementarias que formaron parte de un Dream Team en el que pensé mientras escribía estas líneas.

¿Qué es el sprint 0?

Actualmente hay muchas empresas que implementan Scrum sobre proyectos que han arrancado con metodología tradicional, y debido a que no funciona en escenarios cambiantes, han decidido probar a "salvar" el proyecto con Scrum. Después, cuando Scrum ha funcionado, es cuando las empresas experimentan con la introducción de Scrum desde la propia preparación y planificación del proyecto, y es entonces, en la fase de construcción, cuando suelen introducir el sprint 0. Resaltar que el sprint 0 no es un artefacto de Scrum, es un práctica que en alguna empresas ha funcionado.

El sprint 0 es un primer sprint que no aporta valor de negocio, cuyo objetivo no es producir una parte del producto "tangible" y funcional, sino construir una parte de la arquitectura ágil básica para que los incrementos de futuros sprints puedan añadir valor de forma eficiente al producto. Puede incluir tareas de análisis y/o diseño previos, así como algún trabajo de investigación y selección de herramientas, identificación de políticas de calidad y seguridad y necesidades de formación.

El sprint 0 es un sprint especial diferente a los demás

Se inician los flujos de forma solapada, como son el análisis y el diseño, para refinar y preparar las primeras historias de usuario. Hay que ir con cuidado para no preparar demasiadas historias como si de un análisis tradicional se tratara. Esta tarea inicia la pila de producto, pero el mantenimiento de esta y su refinamiento continuo deben de ser vivos a lo largo de todo el proyecto.

Walking Skeleton, cortesía de i<3vector

El diseño y la arquitectura que se creen en este sprint 0 deben de ser minimalistas para que haya cabida de diseño y arquitectura emergentes en futuros sprints. Es interesante incluir una prueba de concepto, un "walking skeleton", que conecta todas las tecnologías involucradas en el proyecto para garantizar su integración. Con esta práctica traemos todos los riesgos tecnológicos a principio del proyecto y nos evitamos sorpresas a mitad del mismo. No debe de confundirse una prueba de concepto con una maqueta, las maquetas dan idea del aspecto de como será un producto y de como estará interconectado, el walking skeleton no muestra el producto, sólo garantiza la interconexión y funcionamiento de las tecnologías implicadas.

La duración del sprint 0 suele ser más larga y su velocidad más baja que la de los sprints posteriores, y el sprint está vigente mientras no se finalicen todas sus tareas.

En su post "Sprint cero: ¿que necesitamos?", José Vázquez Sánchez, hace el siguiente inventario de las cuestiones que se consideran pueden ser necesarias para el llamado sprint 0:

• Visión del producto: coincidimos todos en ello como una de las cosas más importantes. Visión de lo que hay que hacer y además que esté compartida (y todos los involucrados sepan cual es su lugar y como aportan al proyecto). Saber qué es y que no es el producto.
• Equipo: formado, motivado y con actitud.
• Lista de funcionalidades a alto nivel: epics.
• Plan de trabajo inicial: plan de releases y Road Map. Tiempo aproximado para que el producto tenga sentido.
• Definida la release 1.
• Prioridades del cliente.
• Intervinientes y contactos: quien tiene algo que hacer y qué.
• Fases de aceptación: proceso para conseguirlo, acuerdos de trabajo. Definición de hecho (Done).
• Expectativas de Calidad.
• Detección de dependencias.
• Restricciones o limitaciones: de seguridad, de rendimiento, de disponibilidad, de escalabilidad, de entorno, …
• Tamaño objetivo de la base de clientes esperada.
• Primera versión de la pila de producto priorizada: según valor de negocio.
• Pila de riesgos del proyecto: se pueden intercalar con la pila de producto, para dar respuesta temprana a cualquier riesgo.
• Métricas que se seguirán en el proyecto: Ojo con lo que se mide. Que no cueste mucho esfuerzo. Seguir tendencias, no datos.
• Entorno tecnológico disponible.
• Spike de arquitectura.

¿Puede una misma persona tener los roles de Propietario del Producto y Scrum Master a la vez?

Aunque no sea recomendable, si no hubiera posibilidad de un Scrum Master dedicado, yo recomendaría buscar primero un rol en el equipo, luego advertir que la Scrum Guide lo desaconseja firmemente y no es buena idea que una sola persona haga de Product Owner y Scrum Master a la vez. Es un arte nada desdeñable, hay que asegurarse en todo momento de aislar los dos modos de pensar y actuar en uno y otro modo según el rol desempeñado.

Las diferencias de foco principales son:

• Mentalidad: externos (interesados) versus internos (equipo)
• Enfoque: qué/cuándo versus cómo
• Principales excepciones: los cambios de alcance versus impedimentos generales

Ambos roles a la vez bajo un mismo gorro

Los dos roles son contrapuestos por definición, el Scrum Master vela para que Scrum se aplique según el modelo, se asegura de que el equipo esté motivado y focalizado en sus tareas y de que nadie interfiera en el sprint. El Propietario del Producto tiende a hacer exactamente lo contrario, dado que su labor consiste en absorber el cambio que se produce en el negocio y mantener una pila de producto cambiante, este está tentado por naturaleza a interrumpir e interferir en el equipo. Desempeñado ambos roles es crucial resistir firmemente esta tentación.

Desempeñar dos roles conlleva cierta jerarquía implícita y no es fácil encontrar un equilibrio entre ambos roles, si prepondera el Scrum Master y no hay nadie estirando hacia el negocio, el resultado puede ser un enfoque más tecnológico de lo debido o marcado por el ritmo del equipo. Si prepondera el Propietario del Producto puede ocurrir que este vaya demasiado lejos y vea en ello una oportunidad para tomar el control directo de su propio equipo de desarrollo.

Para entender los diferentes objetivos de ambos roles, Rafael, uno de mis profesores una vez dijo:

• El Scrum Master quiere el mejor equipo
• El Product Owner quiere el mejor producto

La actividad crítica para quién desempeña ambos roles es la reunión de planificación de sprint, ya que estará a caballo entre negocio y equipo frente a un equipo unilateral. Mi consejo sería hacerse acompañar por un tercero, una persona de negocio que represente de forma unilateral al negocio y de esta forma apoye y permita al Propietario del Producto/Scrum Master estar en ambos lados. Como en la reunión de scrum diario el rol es exclusivamente de Scrum Master no hay conflicto entre los dos roles, lo que si aconsejaría, funciones de Scrum Master aparte, es apartarse lo máximo del equipo durante el sprint. En la reunión de revisión de sprint no hay conflicto, ya que, aunque pudiera haber imparcialidad, no puede haber influencia retroactiva.

Uno de los beneficios al pasar por esta experiencia es que de esta manera el Propietario del Producto se acerca al equipo, obtiene una visión desde dentro del equipo técnico y eso redunda en aprendizaje por ambas partes y una integración más fuerte.

Añadir que si depositamos el rol del Scrum Master en un miembro del equipo también puede haber conflictos, pero de un menor grado. El reto está en no perder el foco, al estar involucrado en el proyecto puede verse condicionado en sus decisiones como Scrum Master. Ha velar por la forma en que se trabaja y que el equipo sea sano y productivo a la vez que formar parte del equipo e intervenir directamente en decisiones sobre el producto. 

En caso de varios miembros interesados en el rol puede hacerse un sistema de rotación, es una buena práctica ya que así los interesados viven Scrum de una forma más profunda, lo que por ende revierte en mejora continua. También pudiera ser interesante cruzar el rol con otros equipos, ser Scrum Master de otro equipo permite focalizarse mejor en los dos roles al no interferirse.

¿Cuánta muda transaccional puede ahorrarse en un proyecto desarrollado bajo Scrum?

Uno de las mudas o desperdicios que nos hacen ser menos productivos en nuestro trabajo y que mencionan Tom y Mary Poppendieck en su libro Lean Software Development, es el código o funcionalidad innecesarias o no solicitadas por el cliente.

Situando el foco del desarrollo en aquello que da valor al cliente se aplica un primer filtro al no incluir en la pila de producto funcionalidades que este no solicita, y un segundo filtro al poner funcionalidades con escaso o nulo valor al final de pila de producto. La pila de producto se reconstruye constantemente en función del mercado, y esto provoca que funcionalidades innecesarias siempre permanezcan al final de la pila. Una manera de decidir si vale la pena desarrollar elementos de la pila de producto es aplicar el ROI (Return Of Investment), cuando lleguemos cerca del final de la pila y si el ROI fuera negativo deberíamos de plantearnos si seguimos desarrollando las siguientes funcionalidades.

Para ilustrar la cantidad de desperdicio en funcionalidades he analizado el uso de una aplicación de gestión en cuyo desarrollo participé. El análisis abarca el uso de más de mil quinientas transacciones (páginas) en las que se han producido durante cinco años casi tres millones de clicks de acceso a las mismas.

Si nos fijamos en el siguiente gráfico, en concreto en las páginas que han tenido menos de 50 clicks, podemos ver en el gráfico de tarta de la derecha que ¡casi la mitad de las páginas son puro desperdicio! En el gráfico de tarta de la izquierda vemos que ¡el área que representa su uso casi no se puede distinguir! Tenemos casi un 50% de transacciones innecesarias. Resaltar que estamos hablando de número de transacciones, no de costes, posiblemente el coste represente entre un 10% y un 20% del producto.

Análisis desperdicio en transacciones (páginas)

Entre todo este desperdicio hay todo un sistema gestión de incidencias que nunca se ha llegado a utilizar. La mayoría son páginas de mantenimientos maestros de tablas paramétricas, lo que nos lleva a la conclusión de para tablas que se modifican raramente vale la pena mantenerlas directamente desde SQL/Server u Oracle.

Resaltar que no hay negocio, excepto TI, que acepte un 50% de desperdicio...

¿Cómo gestionar las historias técnicas?

Recientemente estuve hablando en un curso con un "Technical Product Owner". Me chirriaron los oídos, ese rol no existe en Scrum, pero me interesé más y le pedí que me contara. Me explicó en qué consistía su trabajo y cómo interactuaba con el resto del equipo.

¿Technical Product Owner?

La idea es tener dos pilas de producto, una para los requisitos funcionales, en forma de historias de usuario, y otra para los requisitos técnicos, la construcción de infraestructura que soporta las funcionalidades y la deuda técnica, en forma de historias técnicas. Cada pila tiene un responsable que colabora estrechamente con el otro; la primera el Product Owner o Propietario del Producto, y la segunda el Technical Product Owner. Ambos tipos de "product owners" se ponen de acuerdo a principios de cada sprint, especialmente en el inicio de las fases o releases, en donde deciden conjuntamente qué elementos técnicos van a incluir en los sprints.

Desde la perspectiva de Scrum la pila de producto ha de ser única e incluir historias de usuario e historias técnicas, y todas ellas ser responsabilidad sea el Propietario del Producto. Puede ser muy positivo que las responsabilidades recaigan en dos individuos con dos pilas, ya que eso propicia la negociación entre dos personas realmente interesadas en las historias de su rol.

Es importante focalizar los sprints en nuevas funcionalidades para que se produzca la entrega de valor al cliente, ya que las historias técnicas no aportan valor intrínseco, ahora sí, aseguran la capacidad de entrega funcionalidades y por tanto de valor. Alrededor de un 10% de estas historias técnicas son necesarias, a veces imprescindibles, según la fase en la que se encuentre proyecto.

Añadir que historias derivadas de deuda técnica pueden impactar fuertemente en la capacidad del equipo, mientras estas no se resuelvan, y a la vez puede ser positivo tenerla, porque nos hacen ágiles, ser mediocres a veces nos permite alcanzar un objetivo. Por supuesto hay que gestionar la deuda técnica y resolverla en cuanto sea posible.