Entrevista a Henrik Kniberg (autor de Scrum y XP desde las trincheras)

HenrikKniberg2-446x550La primera vez que leí algo escrito por Henrik Kniberg podría remontarse a finales de 2007 o quizás a comienzos de 2008. En 2007, Henrik publicó el que es uno de los libros más famosos de agilidad, y uno de los libros más agradables de leer: Scrum and Xp from the Trenches (Enterprise Software Development).
Posteriormente, Henrik publicó otros libros bastante influyentes como “Kanban and Scrum – Making the Most of Both” y “Lean from the Trenches: Managing Large-Scale Projects with Kanban” (su último libro publicado).
Y es más: Henrik es también el autor del famoso paper “Escalando lo ágil @ Spotify” y del video “Agile Product Ownership in a nutshell” (video visto más de 77.000 veces). Excelente material de aprendizaje para los profesionales de software.
Por todo esto, actualmente Henrik es uno de los «personajes ágiles» más influyentes.
¡Qué más se puede decir de él!
Personalmente, es todo un honor entrevistar a Henrik. Desgraciadamente no pudimos coincidir en mi visita de hace unas semanas a Estocolmo, pero hemos podido cerrar la entrevista por mail.
Henrik, muchas gracias por la entrevista.

1 – La mayoría de la gente conoce tu trabajo en agilidad, lean, Scrum, pero…¿Quién es Henrik Kniberg? ¿De dónde eres? (creo que eres el único europeo en el top ágil) ¿Conocimientos? ¿Dónde trabajas?

Soy sueco y vivo a las afueras de Estocolmo. Aunque crecí en Japón y pasé los primeros 16 años de mi vida en Tokio, asistiendo a una escuela americana. Por ello, cuando me toca escribir, escribo más fluido en inglés que en sueco.
Cuando me trasladé a Suecia, mis padres todavía vivían en Japón, así que estuve en un internado. Me interesé mucho por la música, hasta tal punto que estuve pensando en convertirme en músico después de graduarme, pero finalmente decidí estudiar informática. Imagino que aunque la música es divertida, puede no serlo tanto si tienes que ganarte la vida con ello. Así que estuve pensando a qué otra cosa podría dedicarme, y me di cuenta de que era bueno en programación y que quizás podría ganarme la vida con ello y tocar música en mi tiempo libre, como diversión. ¡Estoy muy agradecido por haber tomado esa elección!
Así que estudié informática en el Real Instituto de Tecnología de Estocolmo, luego hice contratación de software y monté varias empresas de software junto con un amigo. Una de esas empresas creció hasta más de 70 personas, así que terminé como CTO y tuve que aprender cómo dirigir a la gente. ¡Descubrí que era muy interesante! Este fue el momento en el que también me metí en el mundo de XP y lo ágil (alrededor del año 2000) y me enganché porque, bueno, simplemente funciona.

2 – “Scrum y XP desde las trincheras” es una historia de “guerra”. Tu historia de “guerra” sobre cómo implementar Scrum. Tal como dijiste, las historias de guerra convierten principios y prácticas en cómo se aplican realmente estos principios. ¿Cuáles son los retos clave y más importantes para ganar la guerra de implementar Scrum? ¿Qué consejo nos darías para ganar y superar el escepticismo generado en torno a él?

Solo ayudar a la gente y a las organizaciones que QUIEREN ayuda. No imponer Scrum (o cualquier otra cosa) en gente que es feliz con su actual forma de trabajar.
Asegúrate que entiendes cual es tu verdadera meta de negocio, tanto a largo (por qué la compañía está aquí) como a corto plazo (qué es lo siguiente que queremos conseguir y por qué). Scrum es una herramienta, no un objetivo.
Experimenta mucho, tanto con tu producto como con tu proceso.
Independientemente de qué proceso uses, no temas “romper las reglas” una vez que has aprendido lo básico. Muchas empresas están atascadas en el nivel principiante de libro de Scrum. Eso puede ayudarte a salir del paso, pero no te hará volar.
Si encuentras resistencia escepticismo a lo que estás haciendo, hay una razón para ello. Trata a la gente con respeto. Encuentra la raíz de la resistencia. ¿Tenéis distintos objetivos? ¿Tenéis distintas ideas sobre cómo alcanzar las metas? Si tratas todo como experimento, la resistencia tenderá a ser menor (“Sé que no crees que esto funcionará, y puede que estés en lo cierto, pero ¿por qué no lo intentamos un par de semanas y luego lo evaluamos?”)
Cuando usamos un proceso como Scrum (u otro), asegúrate de que todo el mundo entiende la razón que hay detrás de cada práctica – ¿POR QUÉ celebramos una reunión diaria? ¿POR QUÉ tenemos reuniones de planificación del sprint? Una buena definición de burocracia es “cosas que la gente hace sin saber por qué”. Minimiza la burocracia.
[Nota mía: sería bueno aquí volver a leer aquello de que Si no tienes claro “por qué” estás implantando una práctica TI, probablemente metas la pata, y en pocos meses dejes de usarla ]
Si eres un coach o un manager, intenta que el equipo no sea dependiente de ti, enseña y entrena al equipo para dirigir contigo. Esta mentalidad te hará centrarte en las cosas correctas. Y si te conviertes en algo redundante para tu equipo (improbable), no te preocupes, es más probable que te asciendan a que te despidan. Así que primero dale a la gente pescado que comer. Luego enséñales cómo se usa una caña de pescar. Después enséñales cómo construir una caña de pescar. Luego enséñales cómo enseñar a pescar. Por último vete a buscar a alguien distinto que quiera ayuda.

3 – Escribiste en “Lean desde las trincheras” lo siguiente: “Uno de los retos clave de los proyectos software es cómo organizar a la gente en equipos de tamaño decente y cómo coordinar varios equipos”. En mis proyectos ágiles y en los cursos que imparto, muy a menudo veo que es muy complicado que las organizaciones grandes se adapten a trabajar en equipos ágiles. ¿Cuál es tu experiencia con este tema? ¿Es realista implementar la agilidad en organizaciones grandes con centenares de personas?

Solo si ellos quieren cambiar. Si están contentos con su actual forma de trabajar, déjales continuar así.
No hay ningún conflicto entre agilidad y escalabilidad. De hecho, la agilidad hace que la escalabilidad sea más sencilla, principalmente porque promueve la auto-organización. La naturaleza es básicamente un sistema auto-organizado a escala masiva. Una jungla es un gran y complejo sistema con billones de criaturas individuales, si haber managers, proyectos o especificaciones. En Spotify tenemos más de 50 equipos de desarrollo distribuidos a lo largo de 4 ciudades, y la agilidad es la salsa no tan secreta que nos permite escalar sin mucha coordinación por encima.
Lo único que como en la naturaleza, el cambio ocurre gradualmente. Cuanto más grande sea una compaía, más gradual tiene que ser el cambio. Spotify es una excepción, porque esa compañía nació ágil. Nunca han atravesado una transición, la agilidad es su ADN.
Puedes acelerar el proceso y hacer que los cambios ocurran más deprisa, pero en ese caso será más probable que el cambio se estanque.

4 – La agilidad ha pasado de ser algo extraño para las compañías a ser la forma en que todas las empresas quieren trabajar, descartando el hecho de que no todas las compañías lo consiguen. ¿Cómo ves el futuro de la agilidad? ¿Cuáles son los siguientes pasos que debe realizar la comunidad ágil?

La agilidad tiene 50 años de antiguedad, es tan antigua como la industria del software. Lo único que no fue llamada “agilidad” hasta hace 10 años atrás. Este arículo proporciona una buena perspectiva histórica:
http://www.craiglarman.com/wiki/downloads/misc/history-of-iterative-larman-and-basili-ieee-computer.pdf
[Nota mía, en relación a esto te recomiendo volver a leer aquel post del 2010 sobre el Veterano ciclo de vida iterativo e incremental]
En relación al futuro, creo que la agilidad es algo permanente. Es un enfoque natural y obvio hacia el desarrollo software. Sin embargo, la palabra agilidad pasará de moda, y como se dice en el artículo anterior, cada década, más o menos, se irán creando nuevas palabras para ella.
De forma más concreta, el manifiesto ágil y los métodos más famosos (Scrum/XP/Kanban) nos han enseñado básicamente cómo entregar software fiable. No hay ninguna excusa, cualquier compañía puede entregar software siguiendo cualquiera de estos métodos.
Ahora la cuestión, es QUÉ entregar. Ese es el motivo por el que hay mucho rumor acerca de UX, Lean Startup, Impact Mapping y cosas por el estilo. Así que en los próximos años continuaremos centrándonos en cómo asegurar que estamos construyendo lo correcto, con cosas como por ejemplo cómo involucrar a los diseñadores, cómo validar hipótesis cuanto antes etc. También veo que los principios ágiles se van a expandir a otras áreas como el desarrollo hardware, ventas, recursos humanos. Esta tendencia será probable que continúe.
La agilidad se está uniendo gradualmente con escuelas paralelas de pensamiento como Lean y Beyond Budgeting. Ideas parecidas, pero con orígenes diferentes. Nuevas palabras de moda surgirán para describir estas formas de pensamiento.

5 – Por otro lado, ¿cuáles son tus tres libros favoritos que cualquier professional software debe leer? (Por supuesto, aparte del tuyo 🙂 )

Alistair Cockburn «Agile Software Development»
Jerry Weinberg «Becoming a technical leader»
Don Reinertsen «Managing the Design Factory»
Hay muchos más, por supuesto, pero esos son los tres primeros que aparecen en mi memoria ahora mismo.

6 – ¿Alguna recomendación para ingenieros software jóvenes?

Ten un proyecto hobby. Algo que crees solo por diversión y deja que la gente lo use gratuitamente. Te enseñará más que un curso de universidad. Un desarrollador con notas mediocres y proyectos hobby chulos es MÁS probable que sea contratado por una buena compañía que un desarrollador con notas altas y sin proyectos hobby.

7 – Nos encanta el video de “Agile Product Ownership in a nutshell”.  Uso el video en mis cursos y clases de universidad. ¿Estás pensando hacer nuevos videos o un nuevo libro?

No planeo esas cosas, solo las hago. Ahora mismo estoy haciendo un video sobre la cultura de Spotify, siguiendo el mismo estilo que el de Agile Product Ownership in a nutshell. Es mucho trabajo, pero ¡disfruto cada momento de ello!

8 – ¿Has estado alguna vez en España? ¿Te veremos pronto en España?

Sí, he ido a Madrid, Barcelona (dos veces) y Sierra Nevada. ¡Es probable que vuelva alguna vez!
 
Gracias por la entrevista y con muchas ganas de verte pronto en España, Suecia o cualquier parte.
 
 

3 comentarios en “Entrevista a Henrik Kniberg (autor de Scrum y XP desde las trincheras)”

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Share This
Ir arriba