¿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.