Ya deberíais etar al corriente, pero por si las moscas: los días 10 y 11 de Junio se celebra la primera conferencia sobre metodologías Ágiles en España, organizada por la Asociación Agile Spain. Tengo el placer y el privilegio de que me hayan seleccionado dos sesiones (sobre itinerario de implementación Ágil y sobre gestión de equipos Ágiles) y un taller conjunto con Xavi Albaladejo sobre dirección de retrospectivas, cosa que me hace especial ilusión porque, aparte de que Xavi es un profesional al que respeto profundamente y del que seguro aprendo muchas cosas nuevas preparando este taller, creo que las retrospectivas son la gran herramienta Kaizen de metodologías como Scrum, y creo que la gente tiene muchos problemas para sacarle todo el partido que debería. También tendré el lujazo de asistir a Henrik Kniberg en su taller sobre mapas de flujo de valor y Kanban, ya que al ser en inglés puede que algunos de los asistentes necesiten algo de atención perrsonalizada.

Las inscripciones a la conferencia ya están abiertas, y el programa disponible. Las plazas son limitadas, especialmente en el caso de los talleres, por lo que os recomiendo a todos que os apuntéis cuanto antes (¡queda un mes y contando!).

Algo que quería hacer desde aquí es felicitar al equipo que está organizándolo todo, al que intento apoyar en la medida de mis posibilidades, porque ninguno vive de esto y sin embargo la dedicación que le están poniendo y la calidad de los resultados creo que hablan por si mismos. Si es que cuando un equipo Ágil se pone…

Compártelo

Me escribe uno de mis clientes-y-a-pesar-de-ello-amiguetes comentándome la dificultad que tiene para convencer a sus equipos de que estimen en “puntos abstractos”, una técnica Ágil empleada, entre otras cosas, para enfatizar que en un buen proceso de estimación el foco no está en la precisión, algo casi imposible de lograr en un entorno complejo como el del desarrollo de software, sino en tener una idea común de cómo de grande y compleja es cada historia y, a partir de esa idea, concentrarse en trabajar con la velocidad del equipo como métrica. De hecho, la velocidad es la métrica Ágil por excelencia, y en mi opinión es la medida última de madurez de un equipo de desarrollo: lo rápidamente que puede satisfacer las necesidades del cliente con un producto de calidad.

Vamos a empezar por lo básico. ¿Por qué inventar cosas raras cuando todo el mundo estima en horas-hombre o en días-hombre, algo intuitivo, lógico y que se basa en un patrón perfectamente conocido como la hora o el día? Bueno, es cierto que las horas son una medida muy bien definida cuando hablamos de lo que tarda una máquina en hacer mil tuercas, pero cuando empezamos a intentar definir lo que tarda una persona en hacer algo, la cosa se complica. Porque las personas no son como las tuercas: no vienen todas en la misma medida. Y si hablamos de campos como el software, en el que según Pilar Jericó contaba en su libro “Gestión del talento”, el mejor de su campo es 50 veces más productivo que la media, entonces lo de la hora empieza a desmoronarse.

Así pues, si un experto tarda ocho horas en hacer algo realmente sutil y complejo, el programador promedio tarda veinte horas y un Junior tarda treinta y cinco… ¿Cuál es la estimación que debemos dar a esa tarea?

La respuesta lógica sería que la estimación dependerá de la persona que vaya a realizar esa tarea. Pero eso nos obliga a definir desde el principio quién va a hacer cada tarea del proyecto hasta el día de su finalización, y a reajustar constantemente esa asignación conforme vaya apareciendo incertidumbre en el proyecto.

Demasiada e innecesaria gestión.

Por ello se deberían estima las tareas contra un “programador mítico promedio e ideal” y lo que este señor tarda en hacer cada cosa. De ahí libros legendarios como “The Mythical Man Month”, que debería leer todo el que esté en este negocio de crear software y, en mi opinión, todo el que gestione proyectos de cualquier tipo. Lo que pasa es que definir las capacidades de ese “programador promedio” no es sencillo: ¿Tarda lo mismo en una tarea de Java que una de .Net? ¿Sabe de bases de datos? ¿Hace el diseño? Y aunque resolvieramos todo esto, seguiríamos teniendo otros problemas.

Por ejemplo, los de medida de la productividad. Hay grandes gurús de esto que predican que no es posible medir la productividad de un programador. Yo no es que discrepe, pero añadiría “aunque se puede aproximar muchísimo, sobre todo si medimos al equipo en lugar de a la persona”. La tesis básica es la siguiente: si tú has programado ocho horas, y yo he programado ocho horas, ¿hemos programado lo mismo? O dicho de otra forma, ¿hemos producido la misma cantidad de funcionalidad?

Y en contra de la lógica que nos indica que no, lo que hace la industria del software es poner un “precio medio” por hora y dedicarse a contar todas las horas que meten los programadores ante sus teclados. Y claro, no me gusta encontrarme al final de la semana con que alguien mete menos de cuarenta horas. Que las reuniones de trabajo, los correos, la gestión del proyecto, la formación, el I+D, el team building, las retrospectivas, las entrevistas a candidatos, la redacción de informes y todo lo demás que no sea programar se supone que lo hacen los programadores en sus horas libres porque les gusta. Sonamos. En fin, prefiero no hablar de las herramientas de seguimiento horario, que luego dicen que soy un sobrao .

Seguimos con los problemas: si este año cada programador mete cuarenta horas de programación a la semana, y el año que viene sigue metiendo cuarenta horas de programación a la semana… ¿Ha aumentado la productividad? Alguien diría que no (se facturan las mismas horas), pero a lo mejor ese programador está cometiendo un 1% de los errores que cometía el año anterior, y está entregando cerca del doble de funcionalidades por semana que antes… ¿Y le seguimos cobrando lo mismo a los clientes? Es más, ¿Le estamos pagando lo mismo al programador? Que mal, ¿no?

Más razones, bordeando el campo de Earn Value Management (EVM): si en un proyecto de mil horas llevamos invertidas quinientas horas… ¿está la mitad del proyecto hecha? Respuesta típica: “esperemos por Diox que sí” . Respuesta correcta: no lo sabemos.

Es por todas estas razones y alguna más que los equipos Ágiles maduros estiman las funcionalidades que deben desarrollar en función de su tamaño, no en función de las horas o recursos necesarios para construirlas. Sería, de alguna forma, estimar cuantos “kilos” de software vamos a entregar. O cuantos cientos de líneas de código (por el amor de $deity, no estiméis vuestros proyectos en cosas como ULOC’s , espero que no sea necesario explicar por qué ).

Por ejemplo, podríamos escoger una funcionalidad prototipo que nos sirva como patrón. Ésta toma diferentes formas dependiendo del entorno tecnológico y de mercado que tengamos: puede ser un formulario básico de cuatro campos, un login/logout, una pantalla de móvil con una consulta a base de datos, un listado básico de AS400… La idea es localizar un “bloque” de trabajo básico que siempre, o muy frecuentemente, se da en nuestros proyectos, y asignarle a esta idea un valor: por ejemplo, cien. ¿Cien qué? Cien. Cien Chipiklanders, si os sentís mejor (pequeño y sentido homenaje al maestro Fuckowski).

Y ahora comparamos las demás historias del proyecto contra el tamaño de este prototipo. Esta historia es algo más del doble de grande… doscientos cincuenta. Esta es el triple: trescientos.

Ahora veamos qué pasa los primeros días que utilizamos puntos. Cuando sacamos la historia prototipo (un formulario con cuatro campos), el miembro senior piensa “bah, dos horas”, el promedio “cuatro horas” y el junior “ocho horas”. Si se ponen a discutir sobre cuantas horas necesitan, cada uno dice un número. Y todos tienen razón. Y todos están equivocados. Como en la historia del elefante.

Pero ahora es un “cien”, y todos están de acuerdo en que es un cien. De forma que cuando sale una tarea el doble de grande, el senior piensa “ok, cuatro horas”, el promedio “ocho horas”, el junior “dieciséis horas”… Y todos dicen “doscientos”.

Este proceso interno de conversión personal de puntos-horas suele darse al principio. Es lo que lo llamo el “periodo de transición al euro”, en el que al principio nos decían “veinte euros” y pensábamos “ok, 6 euros son mil pesetas, 12 son dos mil, 18 son tres mil, y me quedan dos euros, que son 2 por 166 como algo, o sea algo más de trescientas… Uuuuuh… Tres mil trescientas pesetas”. Pero cuando ha pasado un tiempo suficiente, veinte euros es un cine con palomitas para dos, o dos menús, o una camiseta, o un tercio de depósito del coche… Ese número, que antes era abstracto, ahora tiene sentido para nosotros.

Otro de los problemas iniciales es que todo el mundo está muy acostumbrado a que se les pida precisión absoluta. De hecho, cuando les piden estimación generalmente lo que les están pidiendo es un compromiso, y eso funciona muy, pero que muy mal. Pero el caso es que cuando decimos “dame una estimación para esta historia, sabiendo que esta otra (aproximadamente la mitad) es un cien”, hay quien se bloquea con los detalles. ¿Esto es con patiflux de peristone o sin patiflux de peristone? ¿Los campos tienen que esgorziarse con el tetraconmutador cíclico? ¿Contamos con un condensador de fluzo? Detalles que, casi siempre, no tiene sentido ponerse a detallar en un proceso de estimación siempre que dejemos claro que el objetivo no es la precisión (esto daría para otro ladrillo importante ). Hay un ejercicio que suelo hacer en estos casos que es preguntar “¿Cuánto vale un adosado?”, sin más detalles. Si la gente no responde, voy diciendo cosas como “¿Un millón de euros? ¿menos? ¿cicuenta mil euros? ¿más? ¿doscientos mil euros? ¿trescientos mil euros? ¿Más trescientos o doscientos?”. Y al final hay un número. Que por descontado habrá que pulir, pero lo que me interesa ahora mismo es tener un primer orden de magnitud (¿diez mil o trescientos mil?), y eso es lo que procuramos al usar puntos. Porque si usamos horas o días, inmediatamente el subsconciente de los que luego van a tener que entregar el proyecto comienza a traducir la estimación en plazos de entrega. Y entonces comienzan otra vez los problemas.

Al grano: poco a poco el equipo comienza a familiarizarse con lo que es un “cien”, un “doscientos” o un “cuatrocientos”, y comenzarán a escoger en cada iteración tantas historias como consideren que pueden terminar totalmente (terminado, terminado) en una iteración (Sprint). Con el tiempo, en media, harán más o menos la misma cantidad de trabajo en cada iteración.

Y las palabras clave son “en media”.

Porque hay semanas buenas y semanas malas. Hay semanas que haremos tres mil puntos y semanas que haremos mil quinientos. Y lo malo es que muchos gestores entonces optarán por planificar de cara a tres mil puntos por semana. Cuando los consigan (semana buena), dirán “¿veis? ¿veis como cuando queréis podéis?”. Y cuando no los consigan (semana mala: muchos Bugs, reuniones, distracciones, retrabajos, peticiones de clientes…) dirán “es que no se os puede dejar solos, hay que estar con la vara encima de vosotros todo el tiempo”.

Lo lógico es no planificar de cara a tres mil puntos por iteración ni a mil quinientos, sino analizar la media sostenida. Si la media es dos mil y planificamos contra esa media, unas semanas andaremos retrasados, otras adelantados y, en media, cuadraremos los proyectos.

Y eso nos permite otra cosa importantísima: analizar cuál es nuestra velocidad media ahora y ver cuál será dentro de un año. Y entonces si podemos aproximar si nuestra productividad ha crecido o no, porque si hace un año nuestra media era de dos mil y ahora es de dos mil quinientos, podemos inferir una mejora de la productividad del 25%.

En resumen: la estimación en puntos cuenta con grandes ventajas para los procesos de estimación y gestión de proyectos, así como para la medida de la productividad y la mejora de los equipos de desarrollo, y el único inconveniente que personalmente he podido encontrarle con el tiempo es que es poco intuitiva de usar al principio… Como cualquier innovación basada en un cambio de paradigmas, por otra parte.

En fin, que espero que este granito de arena anime a algunos a investigar más sobre el tema, y si tenéis dudas o experiencias al respecto serán bienvenidas en los comentarios.

Compártelo

Actualización: primer video subido. Hay que trabajar el tema del sonido en el futuro, me veo comprándome una petaquita de esas de ponente serio (tendré que ver si mi cámara tiene entrada de audio, que espero que sí…) . En breve el segundo video.

Actualización 30/3/2010: La presentación está disponible en Inglés gracias a la colaboración de Jaime Buelta… Espero que sirva para evangelizar allende fronteras (y espero que a Peter Jackson no le de por ponerse medieval con mi c…. ).

Actualización 1/4/2010: Segunda parte del video

Compártelo

• Por una parte los señores de CEIN en Pamplona han tenido la amabilidad de tenerme en cuenta para el ciclo de conferencias sobre metodologías Ágiles que están programando de aquí a Junio. En concreto participaré en cinco sesiones sobre Agilismo en general, Scrum, Lean+Kanban (esta en solitario, jejeje), gestión ágil de equipos y herramientas de ingeniería y gestión Ágil de proyectos. En varias de estas charlas coincido con buenos amiguetes y excelentes ponentes, Rodrigo Corral, Jorge Uriarte y Joserra Díaz, por lo que el nivel de estas charlas está asegurado
• Por otra, y gracias a la buena gente del grupo local de Galicia de Agile-Spain (Axilmente), la semana que viene tengo un espacio en Santiago en Xuventude Galicia Net (XGN) . La verdad, habiendo actividades tan divertidas como las que tienen programadas (paintball, torneos de videojuegos) no se qué clase de malditos frikis van a venir a una charla sobre metodologías Ágiles…¡enfermos! Salid a que os de un poco el aire . JM Beas, Xavi Gost, Jerónimo López, David Esmerodes y David Bonilla andarán también por ahí repartiendo caña
• Y, last but not least, si todo va bien probablemente tenga un sarao en Junio por Donosti, que me apetece mogollón porque es una ciudad con la que tengo varias deudas pendientes (gastronómicas, por supuesto ). Ya os comento cuando sea oficial.

Compártelo

Actualización 13/3/2010: Me he precipitado un poco y los videos están aun en modo privado, calculo que el lunes los amigos de Biko los publicarán. Atentos a sus pantallas.

Compártelo

Actualización: Wala! Si se puede incrustar el video de Irekia!

Compártelo

Ahora Kniberg ha sacado un nuevo trabajo comparando Scrum con una aproximación nueva que se está realizando a los procesos de desarrollo: Kanban. Kanban no es nuevo para nada, surge como todas estas herramientas y disciplinas en el seno del sistema de producción de Toyota, “la máquina que cambió el mundo”. Consiste en la generación de una serie de tarjetas que representan los productos que se están desarrollando y que actuan como testigos de una carrera de relevos a lo largo de la línea de producción, disparando los eventos de fabricación conforme van siendo necesarios. La ventaja que pregonan los partidarios de Kanban para el desarrollo de software es la reducción del número de reglas y obligaciones respecto a otras metodologías: nada de planificación de producto, nada de scrum diario, nada de retrospectivas; sólo flujo productivo, priorización y limitación del número de tareas en curso en un momento dado (WIP o Work In Progress).

Es un planteamiento muy positivo para equipos que ya han “disuelto la regla” de Scrum y han interiorizado muy bien el proceso, o bien para equipos de mantenimiento u operaciones en los que los “tickets” deben ir atendiéndose conforme van generándose y no es factible realizar planificaciones ni predicciones a medio o largo plazo. El problema estiba en que equipos sin experiencia previa en Ágile se vean atraidos por la simplicidad de Kanban y entonces no lleguen a interiorizar los importantes conceptos contenidos en los roles, procesos y artefactos de Scrum. Por ello este trabajo de Kniberg, en colaboración con Mattias Skarin, es tan importante para todos aquellos que quieran iniciar una experiencia con Kanban, ya que en él resumen tanto las diferencias como los parecidos y la manera de combinarlos ambos de la forma más efectiva posible.

Hay que reseñar que esta vez la traducción ha sido coordinada por Proyectalis pero realizada por el equipo de contenidos de Agile Spain. Concretamente hay que agradecer la colaboración desinteresada de Rodrigo Corral, Teo Sánchez, Gregorio Mena, Laura Morillo Velarde, Ángel Agueda (Legnita), Jorge Uriarte, Agustín Yague, Juan Palacio, Xavier Quesada, Javier Sánchez, Jorge Jiménez y Juan Carlos Quijano.

Así que aquí lo tenéis. A la fecha de redacción, y por culpa de as múltiples versiones de MS Word y el puñetero filtro PDF de Mac, la versión PDF pesa unos 74Mb (OMG!), pero procuraremos bajar esa cifra en los próximos días. Si alguien no tiene tanta paciencia, lo podéis ir bajando ya de aquí.

Actualización 29/01/10: nueva versión, con un peso mucho más razonable aunque con mayor margen… Gracias a Xavi Albaladejo y Antonio Kobashikawa por liarse con el PDF (es probable que subamos una versión con márgenes correctos pronto, ¡Beta perpétua!). Ah, por cierto, lo lamento por todos los que se han “fusilado” este artículo en sus sitios en vez de enlazar aquí, pero el enlace anterior ha dejado de funcionar… ¡Oooh, que mala suerte! . Esto os pasa por enfadar al enanito del Karma…

Compártelo

Nota: que pasada como abuso de los paréntesis… Y de los puntos suspensivos . Propósito de año nuevo al saco.

Compártelo

Visto lo visto en twitter, y sin falsas modestias, parece que oficialmente lo hemos petado :

• @tatai Pues al final no hemos tenido demo esta mañana, aunque ha sido un gusto volver a escuchar a @angel_m después de un año
• @alorza IMPRESIONANTE la charla de Angel Medinilla sobre Agile y Srcum -vamos a cambiar muchas cosas
• @futuretelematic Ha sido espectacular… scrum se vende facil en el caos de los proyectos ASDM pero Angel lo borda!
• @alorza @angel_m @bikolabs impresionado y decidido a cambiar, ¡gracias!
• @diegocenzano @riskyandfunky La intervención de @angel_m ha sido brillante en el desayuno Agile, así es fácil darle al twitter este…
• @jnarro RT @Biko_2: Gracias @angel_m , Iñaki Tellería y a todos los asistentes a este Biko desayuno! así que sí… Fearless Change http://bit.ly/8vRMz1
• @lullamas Un desayuno “redondo” en #pamplona. Metodología scrum por @angel_m muy bueno, transmite. Gracias @diegocenzano about 23 hours ago from web
• @bikoLabs Melé! #scrum @angel_m @agilespain
• @fegido De camino a la reunión de presupuestos. La escapada a la charla de @angel_m sobre Scrum ha merecido la pena. Thx @biko_2!! #fb
• @bikoLabs Dilbert, el caos y las metodologías sexys #scrum @angel_m @agilespain
• @fegido Disfrutando de la charla de @angel_m. Vaya crack!
• @alorza con @fegido @futuretelematic @angel_m de ponente y otros twitteros como @guzmangarmendia @acidonitrix @wila_ @diegocenzano
• @fegido Sentado junto a @alorza y @futuretelematic. @angel_m de ponente y otros twitteros como @guzmangarmendia @acidonitrix @wila_ @diegocenzano

Como había poco tiempo, organizamos la charla en sprints, de más prioritario a menos, y lamentablemente no nos dio tiempo a arrancar el sprint 3 (contratos). Para los que os quedásteis con las ganas, tenéis la presentación completa de contratos en Slideshare y la charla de Autentia grabada en video aquí y aquí.

La presentación que usamos ayer en Pamplona fue esta (es un poco refrito de las que ya conocéis los que seguís mis pobre-poings, pero bueno… Tendré que empezar a renovar un poco el repertorio para los habituales ):

Compártelo

Monos y máquinas de escribir, vaya. Quien no se crea estas cifras, que meta a 100 programadores promedio en una sala y a Alan Cox en la otra, y a ver quién termina antes con la pila TCP-IP del núcleo de Linux .

Pero antes de que despidáis a toda vuestra plantilla de programadores promedio (a mi entre ellos, jejejeje) y salgais al mercado a buscar programadores estrella, preguntaos por qué el modelo fue abandonado.

Even though, que dicen los ingleses: suponiendo que el modelo sea válido en todos los casos, el problema es que lo que me suelo encontrar en las empresas con las que trabajo son programadores my buenos, estupendos, con talento… Pero seamos francos y humildes: no somos Alan Cox .

Así que ya tenemos el primer problema de este modelo: encontrar a estas “estrellas” que hacen de todo, que son capaces de enfrentarse a todo tipo de proyectos y productos. Y pagarles. Y fidelizarles. Y que no se conviertan en “Prima Donnas” tecnológicas a la primera de cambio.

Pero incluso obviando el tema de las estrellas, el enfoque de un proyecto - una persona (a veces en relación muchos a uno, jejeje) tiene una serie de problemas considerables, que es por lo que en Agile consideramos los equipos como los bloques de construcción básicos de proyectos, procesos y empresas. Y ojo, que un conjunto de personas que se sientan juntas no es lo mismo que un equipo. Un equipo es una forma de pensar ante todo, y el espacio que comparten no puede ser únicamente físico.

A lo que ibamos, que parezco una abuela divagando. Problemas del enfoque de un proyecto - una persona:

• Escalabilidad: el modelo funciona cuando tenemos cinco o seis personas, puesto que, para ver el estado del portfolio de proyectos, no tengo más que hacer una ronda por estas personas y que me cuenten como va todo. Es el Scrum Diario de Scrum o el stand up meeting de XP. Pero cuando la empresa empieza a ir bien y a crecer el modelo no tarda en colapsarse. Cuarenta personas, todas contándonos el estado de su proyecto (o sus proyectos) todos los días, o todas las semanas… Imposible. No hay más remedio que multiplexar. Cinco grupos de ocho personas, y un responsable por cada equipo. Con eso puedo volver a mis rondas diarias con cinco personas que me resumen el estado de todo. Mejor. Cada proyecto sigue asignado a una persona concreta (por ahora), pero hemos resuelto el problema de la escalabilidad… Formando grupos de personas (aun no equipos).
• Robustez: ok, tengo ya grupos de personas, pero de repente se va Paquito, y hay que traspasar sus proyectos. Como es el único que los conoce, estos proyectos van a sufrir considerablemente. Y lo que es peor: el año que viene nos piden que repasemos algunos proyectos de Paquito y nadie sabe nada de ellos. Relexionamos: en el futuro sería interesante que tuvieramos estándares de como hacer las cosas y documentásemos bien los proyectos para que podamos solucionar estas situaciones de una forma mejor. Pero el problema es que por mucho que le decimos a la gente que documente, como siempre vamos hasta arriba, al final siempre se queda la documentación por hacer. Quizás si las personas estuvieran un poco más al tanto de lo que hacen sus compañeros… Pero es muy dificil, muy dificil. Seguimos haciendo las cosas como siempre y obteniendo los mismos resultados.
• Flujo de conocimiento: cuando alguien comete un error, típicamente lo tapa, lo corrige y listo. Mañana otra persona, en la otra punta de la oficina, cometerá el mismo error. Y pasado otra. Y cada uno da soluciones diferentes. Por otra parte, un día alguien encuentra una solución ingeniosa a una necesidad habitual de los proyectos. Pero nadie se entera. Entonces reflexionamos y decimos que hay que montar un sistema de gestión del conocimiento, y desarrollamos una intranet, un blog, un wiki… Pero nadie los usa. Si hubiera una forma de que las personas se contasen unas a otras sus problemas y soluciones, y que unos revisasen el trabajo de otros… Bah, muy dificil.
• Duplicación: al igual que ocurre con los errores, los desarrollos comienzan a duplicarse. Un día nos encontramos con que dos personas, en dos esquinas de la oficina, han desarrollado dos librerías idénticas para el mismo problema. Vaya por Diox. Si hubiera una forma de sincronizar a todo el mundo…
• Incorporaciones: cuando reclutamos a juniors, sería interesante que pudieran ir aprendiendo de los seniors. Pero los seniors están muy liados con sus proyectos como para andar enseñando a la gente. Sí, ya dijimos antes que deberíamos tener estándares de códificación, sistemas de gestión de conocimiento… Pero no se hacen. Si pudieramos organizar a la gente en equipos, equipos de verdad, no solo grupos de personas, que se sincronicen a diario, compartan tareas y proyectos, programen por parejas de vez en cuando, hagan retrospectivas de grupo frecuentemente, analicen todos los proyectos juntos, distribuyan la carga según ellos mismos convengan… Así sería mas rápido y sencillo que una persona recién incorporada fuera pillando el ritmo y el estilo del equipo.
• Flexibilidad: si una persona está muy cargada y queremos reforzar su proyecto con más personas, significa que esas personas deben coger el proyecto desde el principio y adaptarse al enfoque que el primero ha dado al desarrollo. Si de alguna forma se hubieran hecho revisiones breves del proyecto desde el principio en equipo, no solo se habría podido ir incorporando el feedback de todo el mundo al enfoque del proyecto (¿Crowdsourcing anyone? ), sino que sería más fácil incorporarse al proyecto.
• Estandarización: antes hemos dicho que sería bueno contar con estándares para facilitar el trabajo en equipos, pero los estándares son buenos per se, no solo como herramienta. Permiten, como hemos visto, que las personas que se incorporan se adapten más rápidamente y nos permiten analizar de una forma coherente y estándar el rendimiento de los procedimientos para buscar las mejores soluciones y difundirlas entre los equipos.
• Tribus: asumidlo, los seres humanos somos tribales. Los que no lo eran se extinguieron en la última edad de hielo, muertos de hambre o devorados por los tigres dientes de sable, es una cuestión puramente evolutiva. Y a todos nos gusta pertenecer a una tribu, no ser guerreros cubiculares aislados, por muy romántica que nos parezca la idea del “justiciero solitario”. El problema es que cuando formamos una tribu, lo primero que buscamos es otra tribu a la que declarar la guerra. Y si nuestra tribu es “desarrollo”, le declararemos la guerra a “QA”, a “Infraestructura”, a “Diseño”… Es mejor crear la “tribu equipo”, donde todos colaboramos para sacar adelante los proyectos. E independienteemente de si nuestros equipos son multidisciplinares o no, el pertenecer a una tribu aumenta la motivación, la la motivación aumenta la productividad (quien no crea firmemente en esto debería de reflexionar largo y tendido sobre temas más fundamentales que equipos si / equipos no)

Y se me ocurren varias más, pero entonces este artículo se haría insufrible. ¿Como lo véis vosotros?

Compártelo

Por eso me está encantando releer a mi gurú de los recursos humanos, Ricardo Semler, a quien leí antes de hacerme empresario. Mucha gente que ha ojeado “Radical” tiene la visión de que Semler predica el “flower power” de anarquía y cerveza fría, de paz, amor y el plus p’al salón. Sin departamento de recursos humanos, sin controles, sin reglas…Lógico. Uno es empleado y lee solo la parte que conviene al empleado. En Scrum por ejemplo (para mi audiencia Agilista, jejejeje ) esto sería “el Dueño de Producto no puede intervenir en el Sprint“, pero luego no aceptar compromisos, no dar estimaciones, no reportar diariamente, no mejorar la velocidad…).

Que no. Que no, hombre, que no. Que no os estáis leyendo toda la historia. Repasad. Concretamente, algunos pasajes de “El fin de semana de siete días”:

• “El primer principio que se debe aceptar es que si un empleado no siente interés por un producto o proyecto, en ese caso la iniciativa nunca tendrá éxito. Yo prefiero descubrir eso antes, de modo que pueda despedir a la persona, hacer que se despida ella, o lo que es mejor, pasarla a otro proyecto que sí le interese. […] Quiero empleados que se entusiasmen con su trabajo. Si desconocen como crear esa pasión, haré lo posible para ayudarlos. […] Para que una compañía destaque, los empleados deben estar seguros de que el interés propio, no el de la empresa, es su principal prioridad.” Lectura: que le den a la empresa, a mi lo que me interesa es jugar a la consola. Mal. Persiga usted esa pasión de jugar a la consola, caballero, pero eso implica no hacerlo aquí, ya que nosotros no nos dedicamos a eso. Si ninguno de nuestros proyectos o iniciativas le motiva, ¿se puede saber por qué demonios vino a trabajar aquí en un principio?
• “Si alguien trabaja de auxiliar de vuelo de tierra en un aeropuerto y la empresa cree que se necesitan cincuenta horas lectivas para aprender a realizar correctamente ese trabajo, ofrecerán ese curso con esa carga horaria. Pero dependerá del empleado en cuestión aceptar esas clases. La persona puede invertir ese dinero en formación para directivos o cursos de idiomas en vez de clases de control de tráfico. En vez de desalentar esas decisiones, la compañía las acepta, siempre que el empleado sepa manejar el tráfico aéreo o tratar a los clientes sin tener que recibir clases”. Lectura: debo aprender inglés, pero he visto un curso de patrón de yates que mola mucho más. Mal. Haga el curso de patrón de yates, pero en cuanto no rinda usted con el inglés consideraremos que no tiene usted criterio como para tomar decisiones por sí mismo, y como no queremos hacer de niñera de nadie le invitaremos a que madure o busque una empresa en la que les guste manejar droides sin mente.
• “Quizás las empresas no tendrían que esforzarse tanto en motivar a los empleados si intentaran hablar con ellos, descubrir lo que quieren y después otorgarles libertad para perseguir sus ideales”. Lectura: jefe, a mi lo que me motiva es tumbarme en la playita a tomar el sol. Mal. De hecho, muy bien, vaya usted a la playa y tome todo el sol que quiera, ¿qué le detiene? Lo único, claro, es que no lo va a hacer cobrando un sueldo de esta empresa. Ah, que necesita el sueldo. Bueno, puede buscar un sueldo en muchísimos sectores o empresas que no son estos. ¿Qué le detiene? Busque uno cerca de la playa. Vuelva a leer de paso el punto primero.

Al final, todo se reduce a la actitud. Semler lo resume con un ejemplo: “la mujer de la limpieza de Semco (la empresa de Semler) es tan importante como el más alto de los ejecutivos. ¿Por qué? Cuando el consejero delegado de nuestra fábrica de balanzas digitales le preguntó cuál era su trabajo, la limpiadora contestó sin dudarlo ‘fabrico balanzas’”. Mientras ni entendáis esto, queridos, ya podéis chillar, patalear, quejaros, llorar y culpar a la economía, al sector, a los clientes, a los jefes, a la vida, al tiempo, al espacio y al sum sum corda. Y sobre todo, yo no puedo explicaros lo que es Matrix: lo tenéis que ver por vosotros mismos.

Píldora roja, chicos. Píldora roja.

Compártelo

Bueeeeeeno, vaaaaale, es verdad, llevo un montón de tiempo sin escribir, vamos a darle un mínimo de literatura.

La cosa surge hace unas semanas en un proyecto con un cliente en el que estoy proponiendo, como ya he hecho con éxito en otros muchos sitios, montar una tarde de viernes de cada dos como “tarde de laboratorio”. La idea no es mía directamente, la tomo prestada de Henrik Kniberg, y como está en Internet a disposición del respetable sería tontería guardármela en plan “secreto de empresa” o “know how”. Ala, el que quiera ya puede ponerse a ello, que el mercado es de todos. Arrieritos somos .

Suponiendo una tarde cada dos semanas, la inversión total de I+D de la compañía estaría por debajo del 5%, algo que considero peligrosamente bajo en una empresa que depende fundamentalmente del capital humano y del conocimiento y capacidad de sus desarrolladores, pero por algo hay que empezar. Total, que el cliente a priori acepta bien la idea, pero hay una cosa que no acaba de ver claro. ¿Cómo le dice al cliente (al suyo) que los desarrolladores no están a piñón con el proyecto, que están “jugando” en el laboratorio?

Ahí es donde yo me quedo a cuadros claro. Quien me conoce sabe que no creo que los desarrolladores puedan sacar más de seis horas buenas-buenas de programación al día, y eso defendiéndolos a saco de interrupciones y context-switching. Lo que nos deja dos horas al día para slack (relajación, desayuno, café, facebook, twitter, blog ), gestión del proyecto, actividades de la empresa (informes, reuniones), I+D (incluiría la formación aquí) y, lo que hay que perseguir, gasto, el enemigo en Lean: re-trabajos, esperas, errores y mantenimientos, pérdidas de tiempo, procrastinación, charlitas de pasillo…

Todas esas cosas nadie las cuestiona. Se hacen. Cuando los desarrolladores reportan otra estupenda semana de 40 horas dedicadas al proyecto dormimos tranquilos, pero la verdad, la terrible verdad, es que muchas veces ni siquiera han salido 20 horas buenas en la semana. Que demonios, a veces no salen ni diez. Pero reportamos 40, el Jefe de Proyecto contento porque se factura y el cliente preocupado porque no entiende cómo leches después de 40 horas con el proyecto apenas tiene una pantallita de bienvenida a la aplicación. “Es que esto es muy complicado, Jefe”. Facturita al canto.

A lo que vamos: que podríamos ser honestos y, si cobramos 1.500 euros por consultor a la semana, reportar 20 horas a 1.500 euros. Pero entonces los chapuceros de nuestra competencia dicen que ellos son más baratos, que ellos cobran 1.500 euros por una semana de 40 horas. Sus consultores no desyunan, no van al baño, no asisten a reuniones, no responden correos, no leen en Internet, no tienen Facebook… O eso, o pasan 80 horas a la semana en la oficina, claro.

Y entonces somos poco competitivos. Así que subimos las horas y ponemos ese “100% de dedicación al proyecto” que al cliente le gusta tanto. Y todo el que ha estado en una consultora sabe que luego la gente está cargada al 200%, al 300%… Y lo que es peor: el cliente lo sabe también, pero hace como que no y baila el juego. Las cosas son así, siempre lo han sido.

Bueno, eso está bien para los que aun vivis en Matrix y dependéis del sistema tanto que matareis por defenderlo. Pero los renacidos en Sión, los que hemos estado en el otro extremo de la realidad, los que tenemos clientes con los que se puede colaborar, crecer y pasarlo bien… Nosotros vemos las cosas de otra forma.

Por lo pronto seguimos y asimilamos el dicho de Tom Peters : ¿Quién dirige la compañía? Los clientes. Los habitantes de Matrix oyen esto y dicen “el cliente quiere muchas horas gratis”, y crean una realidad en la que solo van a comprarles ese tipo de clientes. El que vaya a pedir un proyecto a una de las grandes “cárnicas” ya sabe a lo que va. Pero el estado mayor de Sión se reune y cuelga en la web (en la más fea de la Internet, eso sí) un manifiesto en el que declaran que el cliente lo que quiere es producto funcional, adaptación a los cambios, colaboración y trato personal. Y eso es en lo que creemos.

¿Quién paga las horas de I+D? El cliente. ¿Quién paga la fiesta de la empresa? El cliente. ¿Quién paga las nóminas, incluyendo la de la limpiadora? El cliente. Todo lo que no sale puntualmente de una ampliación de capital o un préstamo es, tarde o temprano, pagado por el cliente. Costes de infraestructura, maldita sea, repercutidos directamente en el coste del producto o en la tarifa horaria. Lo que el cliente quiere no es saber cuanto gastamos en donuts. Quiere un producto cojonudo muy bueno, a muy buen precio y muy rápido. Y eso se consigue siendo muy bueno y muy rápido. Y a eso se llega desarrollándose y mejorando.

Y para poder ser competitivos está bien que intentemos reducir el gasto (Muda, en la terminología Lean) y que los costes de gestión sean lo más eficientes posibles. Pero ponerse a recortar en I+D, y más con los vientos que corren… Y encima usar para ello la excusa de que el cliente es lo que quiere… En fin, no puedes salvarlos a todos, Neo.

Compártelo

Como sabréis, se trata del primer evento sobre metodologías ágiles que se celebra en España, y aunque los que lo hemos montado somos absolutamente novatos en estas lides hemos de decir que ha sido un éxito: 160 participantes de empresas de software de toda España, entre ellos (of course) muchos clientes míos . Desarrolladores, jefes de proyecto, gerentes… Muy buen nivel, la verdad, y una estupenda ocasión de networking profesional. En este sentido, el mejor evento al que he asistido profesionalmente hablando, ya que estaba absolutamente dirigido a nuestro target de negocio. Por lo tanto, magnífica inversión en patrocinio (algo que una empresa pequeñita como la mía debe medir con lupa).

Por si alguno no conocía el formato, la verdad es que fue una de las cosas que más llamó la atención y que mejor funcionó. El primer día, se forma una cola con todas las personas que están interesadas en proponer un tema de debate, exponer un asunto, aprender sobre algo en concreto… Cada persona explica su propuesta en un minuto y la anota en una tarjeta. Esas tarjetas luego son votadas por todos los asistentes por un sistema de dot-voting y se celebran las sesiones que más votos han obtenido. Self-management y arquitectura emergente en estado puro. Este fue nuestro resultado:

Lo único malo de este tipo de formato es que a muchos nos hubiera gustado ir a todas las sesiones. Se me quedaron en el tintero las sesiones de Xavi Gost (que fueron la comidilla del evento) o las de Xavi Quesada y Rodrigo Corral, a quien he emplazado necesariamente a un proyecto común el añi que viene, que seguro que nos lo vamos a pasar pipa . Procuré balancear mi elección entre sesiones técnicas (integración continua, con Juan Gutierrez, o test driven development con Carlos Ble) y las de negocio (PMO ágil, con Xavier Albaladejo). Yo dirigí una sobre implementación de Scrum (”Es muy dificil!”) y otra sobre desarrollo Offshore, y debo decir que tuve un lleno total (creo que incluso con gente de pie en ambas sesiones, ¡gracias por el esfuerzo, chicos y chicas!). Ah, esa es otra: ¡hay chicas Ágiles! ¡Existen!

Pues nada: que ha merecido la pena de largo, y que recomiendo a todos los que participéis en algún tipo de comunidad técnica (incluso dentro de vuestras empresas) a que estudiéis el formato, porque la verdad es que funciona fenomenal.

Ah… ¿La próxima en Sevilla?

Compártelo

Finalmente el curso se celebrará en el hotel Barceló Torre Arias, en la calle Julián Camarillo 19-21.

Ver mapa más grande

Compártelo

La mayoría ni os plantearéis verlo porque dura una hora y está en inglçes. Shame on you! Por si consigo engatusaros, aquí van algunas perlas anotadas:

- Demasiadas compañías comienzan centrándose en la tecnología y el producto, entonces se centran en las ventas, entonces pasan a centrarse en el marketing y la marca, entonces están gastantdo mucho y se centran en las finanzas para que entonces alguien diga “tenemos que volver a nuestros origenes y volver a la tecnología y el producto”. Entonces el ciclo comienza de nuevo, pero la respuesta no está dentro de la empresa: hay que escuchar al cliente.
- No hay documento de requisitos, por muy exquisito que sea, que un desarrollador no pueda malinterpretar
- Nada parece complicado para la persona que no sabe de lo que está hablando
- Típicamente, más documentos, más requisitos, más especificaciones, más reuniones = menos desarrollo
- “Mientras más aprietes tu puño, más sistemas se escaparán entre tus dedos”” (Princesa Leia). Tremenda cita y tremenda aplicación.
- Comparación de las empresas con Star Trek: desarrollo sería Spock: muy técnico, muy centrado en su labor y tratando por todos los medios de parecer humano; Marketing sería el doctor ‘Bones’ McCoy, quejándose constántemente de lo que NO es (’Por el amor de Dios, soy un médico, no un….”); y el Capitán Kirk sería ventas, constantemente comprometiendo la nave más allá de sus posibilidades.
- El feedback que obtenemos desde soporte técnico está basado en clientes que tienen problemas, y ni siquiera en todos ellos (¿cuantos de vosotros habéis llamado a Microsoft para quejaros de MS Project?)
- Tus actuales clientes nunca te van a pedir que sustituyas por completo su actual instalación convirtiéndola en obsoleta, aunque eso sea exáctamente lo que necesiten.
- Que una idea no tenga una evidencia de mercado no quiere decir que no sea una innovación y proporcione al mercado algo que necesita pero no ha pedido.
- De todas las reuniones que has tenido en la última semana, ¿Cuántas han sido sobre el cliente y cuántas han sido “blame management” (gestión de la culpa, echarse la culpa de todo unos a otros)?

Compártelo

Supongamos que tenemos una fábrica de magdalenas que consta de las siguientes partes:

.- Una cinta sin fin en la que se van colocando los moldes de magdalena con la masa
.- Un horno en el que se van introduciendo los moldes de cinco en cinco y son horneados durante 5 minutos
.- Una salida del horno, por la que las magdalenas ya horneadas salen en dirección al cliente

Tenemos a dos personas operando la fábrica. Una opera la cinta y va colocando los moldes. La otra opera el horno. La primera se llama Don Dueño de Producto, y la segunda se llama Don Equipo. Lo vamos pillando, ¿no?

La fábrica de magdalenas funciona muy bien y los clientes están contentos con el producto. Tan contentos que empezamos a tener más clientes, más demanda, y a Don Dueño de Producto le entran las prisas.

Entonces, en medio de una hornada, Don Dueño de Producto se dirige a Don Equipo y le dice “oye, abreme el horno que quiero ver cómo va todo”. Don Equipo le responde “no hombre, no… Si abrimos el horno se va toda la temperatura, y las magdalenas no suben”. Y Don Dueño de Producto, refunfuñando, se aguanta.

Pero entonces entra corriendo un mensajero con un encargo: un bizcocho urgente. El bizcocho ocupa el espacio de tres moldes de magdalenas. Y Don Dueño de Producto dice “parad la hornada, que hay que meter un bizcocho urgente”. Don Equipo dice “mira, la hornada lleva dos minutos… ¿No puedes esperar tres minutos más para que metamos el bizcocho?”

“¡No! ¡No lo entiendes! ¡Es urgente! ¡El cliente lo demanda!”. Don Equipo mira al cielo resignado y dice “ok, ok, paramos la hornada y tiramos estos moldes para empezar una hornada nueva de cinco minutos”.

Y entonces, para asombro de Don Equipo, Don Dueño de Producto le mira con cara de horror y dice “¡No! no lo has entendido… Hay que hacer el bizcocho en esta hornada y *además* de las magadalenas“. Cuando Don Equipo logra salir de su asombro le dice “pero vamos a ver… Lo primero es que te vas a cargar las magdalenas que estan metidas, pero incluso aunque aceptes eso, ¿dónde quieres que meta el bizcocho si el horno ya esta lleno?”.

Entonces Don Dueño de Producto se enfada de verdad. “¡Estoy harto de quejas! No entendéis los malos tiempos que vivimos y lo importante que es este encargo, el cliente siempre tiene la razón. Hay que hacerlo y hay que hacerlo. Si no se puede, pues se tiene que poder. Y punto. Y si no hay sitio, pues lo colocais encima de esos tres moldes de magdalenas, y como escuche mas quejas voy a empezar a escribir cartas de despido a la voz de ya”.

Ante la amenaza, Don Equipo abre el horno (con lo que se va la temperatura), coloca el bizcocho encima de tres moldes (con lo que el bizcocho queda cerca de la resistenci superior del horno y las magdalenas aplastadas), cierra el horno y espera tres minutos a que termine la hornada, también conocida como Sprint. El resultado es el lógico:

Claro, al realizar el envío al cliente, este lo devuelve indignado. Así que ahora tenemos que hacer cinco magdalenas, un bizcocho y las cinco magdalenas que tocaría hacer ahora. Suponiendo que hagamos bien las cosas, generamos ahora mismo un retraso de ocho magdalenas: tenemos que parar la linea, meter cinco magdalenas y luego meter el bizcocho, y aprovecharíamos el segundo turno para meter al menos dos magdalenas nuevas, así que en dos turnos produciríamos dos magdalenas nuevas además de todo el trabajo rechazado.

Si desde el principio hubieramos hecho las cosas bien y hubieramos esperado al segundo turno para meter el bizcocho, solo habríamos generado un retraso de tres magdalenas (las que ocupa el bizcocho). Ahora sin embargo hemos generado deuda técnica, y típicamente Don Dueño de Producto ser irá poniendo cada vez más nervioso y seguirá pieiendo que metamos más cosas de las que caben en el horno

Moralejas (algunas ):

1.- Los equipos necesitan su temperatura adecuada. Ni tan frío que no cueza ni tan caliente que se queme. La sopa, por ejemplo, tiene su temperatura de cocción a la que todos los ingredientes dan su punto. Más frío y no sabrá a nada, más caliente y se quemará. Esta temperatura adecuada de equipo es lo que yo denomino un “estrés saludable” o, en términos Agile, el “paso sostenible”, es decir, el ritmo que podemos mantener indefinidamente sin cansarnos.

2.- El Dueño de Producto debe de manejar la Pila de Producto, no la Pila de Sprint. Si el Dueño de Producto se dedica a interferir en el espacio de trabajo del equipo (Sprint), no podemos esperar que emerja la autogestión ni los estados hiper-productivos asociados a Scrum. Eso no quiere decir que el equipo no informe diariamente del progreso, proporcione toda la visibilidad posible y acepte el criterio del Dueño de Producto en las entregas (si el Dueño de Producto dice que no vale, es que no vale). Esto también aplica a cualquier entorno jefe-empleados, no necesariamente a Scrum: los equipos tienen que tener su espacio y su margen de maniobra, y la microgestión solo conduce a la suboptimización y al bajo rendimiento.

3.- Ante una situación de deuda técnica cualquier momento es mejor que el siguiente para decir “alto” y aplicar el principio Lean de Jidoka. Dicho de otra forma, cuando uno está en el fondo de un pozo lo primero que tiene que hacer es dejar de cavar. Tened en cuenta que, como otros tipos de deuda, crece a interés compuesto (por cierto, es falso que Einstein dijera que se trata de la mayor fuerza del Universo o el mayor invento del siglo veinte ).

Compártelo

Se trata de un evento en formato Open Space, un formato que tuve la oportunidad de disfrutar en el XP 2008 de Irlanda y que sinceramente me encantó. Estaré allí conduciendo uno o dos open spaces (segun el sitio que haya), aunque aun no me he decidido por la temática (transformación Ágil, Agile testing, juegos para Agile Coaching…¿qué os apetece? )

Más información en la página de Agile Spain.

Compártelo

Compártelo

Como siempre, confirmaremos el lugar al menos dos semanas antes, y tenéis información sobre el contenido en la web de proyectalis. Son cursos de dos días, en horario de 9:30 a 18:30 aproximadamente e incluyen el almuerzo. Para reservar plaza, por favor, poneos en contacto con nosotros en info(arroba)proyectalis.com. En los dos últimos cursos en Madrid se nos quedó gente fuera al final, por lo que os aconsejo que, en caso de estar interesados, lo hagáis cuanto antes.

Aprovecho para comentar, por si alguno aun no lo sabe, que también hacemos cursos de formación in-company para grupos de 6 a 12 personas que son más ventajosos economicamente que el curso “abierto” en caso de que tengáis suficientes personas interesadas en la empresa. Hemos publicado además hace poco un catálogo de cursos 2009 en el que podéis encontrar propuestas formativas en torno a la gestión de proyectos y temas afines como planificación estratégica, Lean, gestión del tiempo, gestión del portfolio de proyectos, creatividad y gestión de la innovación…

Quizás queráis leer algunos comentarios de asistentes a los cursos de Proyectalis, incluidos los de algun Certified Scrum Master (gracias Alejandro, el jamón ya va en camino ).

Os esperamos

Compártelo

Tienen muchísima razón al principio cuando dicen que casi todas las empresas tienen declaraciones de valores, misión y visión absolutamente vacías, incoherentes o directamente repletas de sandeces. Todo el mundo declara ser “customer driven”. Estaría bonito decir lo contratio. Por ejemplo, sería francamente incorrecto de cara al público que las compañías de telefonía declarasen que uno de sus valores preferentes es “ahorrar costes de call center” y colgarte lo antes posible. Es mucho más bonito decir que “tratamos de darte una solución rápidamente”. Juas. Y juas, añado.

A todo el mundo se le llena la boca diciendo que sus valores preferentes son la calidad, la motivación, la innovación… Luego resulta que “innovación” consiste en poner un buzón de sugerencias, y que a todo el que propone ideas se le dice que “siga con lo suyo y se deje de chorradas”. Ahora, lo que es la declaración de valores, la declaración de valores ha quedado preciosa.

Honra tus valores. Lo demás es basura.

Me gusta también que Netflix, una compañía de las que se escriben libros y uno de los paradigmas de nuevos negocios de rápido crecimiento (startups), deja muy clara la diferencia entre libertad y libertinaje que muchos parecen bordear peligrosamente (siempre a su favor) cuando estudian entornos autogestionados y auto-organizados, ya sea Agile, Google o Semco. Libertad, sí, pero responsabilidad. Alto rendimiento. No valoramos cuantas horas pases en la oficina, perfecto, pero valoramos la cantidad de trabajo que eres capaz de sacar adelante y lo rápido y eficientemente que lo hagas, sobre todo antes de los deadlines. Esperamos de ti no que seas el doble de eficiente que la media: esperamos que tu rendimiento sea diez veces superior a la media.

“La gente responsable se emociona en libertad y se gana, se merece la libertad”. No existe la libertad sin un rendimiento elevado, excepcional. Tim Ferriss lo sabe, y por eso centra la primera parte de su libro en ayudar (ligeramente, eso si) a aumentar el rendimiento en el trabajo para así poder dedicar más tiempo a lo que queremos. Libertad, pero a un coste. No “haz lo que quieras, diviertete, y no pasa nada si luego no entregas tu trabajo, lo entregas mal o directamente te niegas a hacerlo porque no te divierte ni te motiva”.

“Somos un equipo, no una familia. Somos un equipo deportivo profesional, no un equipo de chavales en el cole. El trabajo de los entrenadores en todos los niveles de Netflix es contratar, desarrollar y despedir de forma inteligente, de forma que tengamos a estrellas en todos los puestos”.Mucha de la cháchara start-up buenrollista se centra en los aspectos de la contratación: atraer el talento, detectar el talento, vender las ventajas de la empresas… Algunos se preocupan de motivar al talento, de retener al talento. Poco se escribe sobre podar las ramas que no crecen y lastran al resto de la planta. Bien por Netflix. Me gustan los valientes.

Pero claro, la gente ve Google y solo se quedan con el dinosaurio, la sala de guitar hero, los toboganes y el “haz lo que quieras”. Claro. Buen rollito. Así es como han dominado el mundo.

Cretinos.

Me gusta el enfoque Agile de Netflix: conforme creces, lo inteligente no es meter más y más procesos que al final convierten a tu compañía en otro dinosaurio burocratizado y estúpido. Crece incorporando a más personas de rendimiento excepcional y que sean capaces de trabajar de forma autogestionada. Entonces dales libertad y manten fuerte la cultura. Filosofía Scrum pura.

“Política de vacaciones y seguimiento (de dias) de Netflix: no hay política de vacaciones ni seguimiento”. No trabajamos de nueve a cinco, no medimos las horas que pasas trabajando fines de semana y noches. Nos fijamos solo en tus resultados. ¿Por qué vamos a medir cuántos días llevas de vacaciones?

La gente lee esto y piensa “estupendo, todo el año de vacaciones por la cara”. Su cerebro elimina selectivamente la parte de trabajar los fines de semana o los resultados excepcionales.

Cretinos.

A los que leeis más allá os recomiendo encarecidamente una lectura pausada de la presentación. Que demonios: os recomiendo que la leais todos los lunes a las nueve de la mañana

Compártelo

Enjoy!

Compártelo

Permanezcan atentos a sus pantallas, porque los chicos de Autentia prometen subir el video de la charla…

Compártelo

Hola a todos,

Angel Medinilla ha compartido parte del material que emplea en sus cursos de Scrum.

Antes que nada, agradecer a Ángel que comparta este material que además es, en mi opinión, bastante bueno. Pero quería hacer una reflexión sobre uno de los temas que expone en la presentación “Charla Scrum”.

En las últimas semanas he estado hablando con algunos amigos y reflexionando sobre esto de incorporar Scrum (o cualquier otra metodología ágil) a las empresas y cuando he llegado a la diapo 81 (después del cuarto acto) que dice que “la Cultura de las empresas toma Estrategias para desayunar”. Como consecuencia, Ángel propone que hay que cambiar la cultura corporativa para adoptar agilismo con garantías. (Al menos eso es lo que entendí yo cuando asistí a su curso). Y parece razonable, pero también creo que es un poco utópico.

Así que cuestiono este enfoque de introducción del agilismo “top-down” y me pregunto si no es posible (incluso mejor) hacerlo “bottom-up”, es decir, adoptando primero prácticas de ingeniería ágil y, progresivamente (a un ritmo sostenible) ir avanzando hacia terrenos más de gestión del proyecto, hasta llegar a las relaciones con los clientes. ¿Qué experiencia tenéis vosotros?”

Me encuentro con planteamientos de este tipo muy a menudo en nuestros proyectos. Al principio me frustraban bastante, luego entendí que cuando uno se mete a trastear con la cultura corporativa debe ir más despacito que un limaco. Pero hagamos una reflexión:

Si a alguien le parecen estos planteamientos utópicos, perfecto por mi, pero “utopía” implica imposibilidad real de llevar a cabo, y la realidad es que hay *miles* de empresas que han llevado la utopía a la realidad, por lo que seguir negando la evidencia es aferrarse a antiguos paradigmas. La frase “culture eats strategy for breakfast” es de Mark Fields, a la sazón presidente del grupo Ford y responsable de uno de los mayores cambios corporativos documentados. Ahora vamos nosotros y le decimos “si, ya, bueno, pero no“. Po fale.

Claro que es más facil decir “esto no es posible” (incluso contra la evidencia) que “no somos capaces de hacerlo” (ante la evidencia)… Esta manera de mitigar el trauma de la propia incapacidad (con perdón, no llamo a nadie “incapaz“, pero a veces no podemos contra la maquinaria corporativa nosotros solos) se llama disonancia cognitiva, y nos impide analizar el por qué del fallo de nuestros planteamientos y encontrar maneras mejores de perseguir nuestras metas. El primer paso consiste en aceptar la realidad tal como es, y analizar a partir de ahí la mejor estrategia posible a corto, medio y largo plazo.

Dicho lo cual: los planteamientos bottom-up de cambio corporativo son posibles, pero son un infierno y la tasa de fracaso es muy superior a la de los top-down o los mixtos. Es muy fácil que la gerencia diga “dejaos de culturas y chorradas y poneros a currar que es lo que tenéis que hacer“… En este tipo de planteamientos, lamentablemente, es mejor volar bajo el radar y vender pequeños éxitos muy poquito a poco.

Pero vamos, que esta es mi humilde opinión en base a mi pobre experiencia, y me dejo convencer por lo que vosotros mismos me contéis…

Compártelo

Sobre el curso, tal vez queráis leer algunos comentarios de asistentes. Os esperamos.

Compártelo

Gracias Luís por el impagable enlace… . Por cierto, si os molan estas cosas hay como tres mil subtitulos de la geniál escena de la película “El hundimiento”, incluyendo “Hitler hace tests unitarios“,”Hitler baneado del World of Warcraft“, “alguien robó el coche de Hitler“, “Hitler pide una pizza” y “Hitler o Bill Gates“… Todo un fenómeno de Internet.

Compártelo

Compártelo

Cito a los amigos de Autentia que lo cuentan mejor:

“Llega la quinta charla de Autentia sobre contratos ágiles, la cual se hará en colaboración con Proyectalis y Agile Spain.

La charla será impartida por Ángel Medinilla, uno de los nombres más influyentes en metodologías ágiles en España” - (nota mía: como se pasan estos señores… ) - “. Trabaja en Proyectalis, una consultora especializada en gestión de proyectos de telecomunicaciones y tecnologías de la información, y que es posiblemente la empresa lider en España en prestación de servicios asociados a las metodologías ágiles, incluyendo consultoría, formación, implantación y coaching de equipos ágiles.

Esperamos que os animéis a participar. Por nuestra parte le pondremos mucho interés y cariño y procuraremos generar tangibles que compartir con vosotros terminada la charla.”

Compártelo

El pasado 11 y 12 de mayo tuve el privilegio de asistir en Madrid al curso que imparte Ángel Medinilla sobre “Scrum: metodología ágil de gestión de proyectos”. Y si digo privilegio porque el curso es realmente interesante, y Ángel es un comunicador como hay pocos.

Se explican los conceptos, principios y prácticas de Scrum de forma clara y muy completa. Y por si fuera poco Ángel dota a todo este contenido con un enfoque práctico de como funciona Scrum en el mundo real, y de una visión empresarial de la aplicación de Scrum como he visto en pocos sitios (señores, sí, Scrum está muy bien, pero no olvidemos que hay que seguir ganando dinero con ello

Yo soy Certified ScrumMaster (y no me arrepiento de ello y sin duda puedo decir que los dos días intensos que he pasado con Ángel y el resto de compañeros del curso, han sido más productivos que cualquier otro curso o documentación o libro que haya leído hasta el momento.

Por todo esto os animo fervientemente a que, si tenéis oportunidad, asistáis a uno de sus cursos sobre la materia.”

Os recuerdo que el 29 y 30 de Junio estaremos en Barcelona y que aun hay plazas (las de Madrid se agotaron algo así como un mes antes de las fechas, así que os recomiendo que os deis prisa ). Ya sabeis: correo a info (arroba) proyectalis.com

Compártelo

Como siempre, la crítica constructiva será bienvenida.

Compártelo

Respecto al del 29 y 30 de Junio en Barcelona, todavía hay bastantes plazas libres (supongo que por la lejanía de las fechas), pero visto lo visto con los cursos de Madrid, en los que siempre se nos queda alguien fuera por poco, os recomiendo también que adelantéis lo antes posible los trámites de inscripción. Ya sabéis: correito a info (arroba) proyectalis.com

Compártelo

Lo más llamativo de esta nueva versión es que, a pesar de que conceptos como el Rolling Wave Planning que defienden la planificación en detalle de los eventos cercanos y una planificación más difusa de los bloques de trabajo a largo plazo ya estaban presentes en ediciones anteriores del PMBOK, en esta edición se introduce un especial énfasis en la planificación iterativa de proyectos. Kudoz for Agile Teams.

Hay algunos otros cambios, como una mayor profundidad en el concepto de la documentación de proyecto, mayor consistencia con los estándares de gestión de programas y portfolios de proyectos… Espero poder estudiarlos con más detalle en cuanto encuentre la forma de descargarlo, porque está accesible para miembros del PMI pero a través de un odioso applet que pega un casque bastante feo cuando intento imprimirlo en PDF… En fin, tocará pasar por caja…

Compártelo

Compártelo

• Madrid: 11 y 12 de Mayo de 2009
• Barcelona: 29 y 30 de Junio de 2009 (fechas actualizadas)

Como siempre, confirmaremos el lugar al menos dos semanas antes, y tenéis información sobre el contenido en la web de proyectalis (además de algunos comentarios de asistentes aquí, aquí y aquí). Para reservar plaza, por favor, poneos en contacto con nosotros en info(arroba)proyectalis.com. En nuestro último curso en Madrid se nos quedó gente fuera al final, por lo que os aconsejo que, en caso de estar interesados, lo hagáis cuanto antes.

Aprovecho para comentar, por si alguno aun no lo sabe, que también hacemos cursos de formación in-company para grupos de 6 a 12 personas que son más ventajosos economicamente que el curso “abierto” en caso de que tengáis suficientes personas interesadas en la empresa. Hemos publicado además hace poco un catálogo de cursos 2009 en el que podéis encontrar propuestas formativas en torno a la gestión de proyectos y temas afines como planificación estratégica, Lean, gestión del tiempo, gestión del portfolio de proyectos, creatividad y gestión de la innovación…

Ala, fin del spam por hoy

Compártelo

Vía el blog de JM Beas.

Compártelo

Concretamente, he entendido perfectamente uno de los comentarios en el que se decía “Esa es la sensación que tenemos nosotros desde hace tiempo, que decir “ágil” es dar puerta abierta a “hago lo que me da la gana y encima tengo excusa“. Efectivamente, hay equipos e implantaciones concretas en las que uno acaba teniendo esta sensación. ¿Paternalismo de los gestores? ¿inmadurez de los equipos? ¿Mala implementación?

También ha caido en mis manos un artículo sobre el supuesto fallo de Scrum y las metodologías ágiles en “enganchar” con la psicología humana. Curioso por lo menos, tratándose de una metodología que parte de los principios ágiles y que siempre presento en los cursos como la aproximación humana a la gestión de proyectos. ¿Por qué unos la vemos como la forma más humana de trabajar y otros precisamente como lo contrario? Una vez leido el artículo, la cuestión clave es: ¿confias en el equipo de trabajo? O en algunos casos, ¿se puedeconfiar en el equipo de trabajo? Si, como defiende el artículo, vives en la creencia de que el “factor humano” consiste en que las personas siempre antepondrán sus propios intereses a los del grupo, son egoistas y nunca conseguirás que se pongan de acuerdo, pues vale, Agile no es para tí. Esto vale tanto si crees esto como si tienes la certeza absoluta aplicada al conjunto de personas que te ha tocado (o has seleccionado, en cuyo caso mucho peor y debes revisar tu proceso de selección).

Partiendo de la base de que yo no pienso así, ¿qué provoca que a veces Agile desemboque en una situación de “hago lo que me da la gana y encima está justificado”? Es más que evidente que Agile, como decía en mi anterior artñiculo, no es “hacking institucionalizado” o “buenrollismo institucionalizado”. Pero creo que se hace mucho “hype” de los aspectos más “hippies” de Agile (comunidad, equipo, personas, comunicación, autogestión, no interferencia) y bastante menos reflexión sobre los nativos de la gestión de proyectos (disciplina, ritmo constante, entregas, producto terminado, visibilidad diaria, priorización, estimación, compromiso, deadlines). Es lógico, a todos nos gustan los primeros y no a todos los segundos, por lo que la estrategia de marketing de Agile (sobre todo en una implantación up-bottom, o “golpe de estado” como la bautizó genialmente hace poco un contertulio) pasa por vender lo bonito y pasar “la pildora” con el azucar.

Lo malo viene cuando solo queremos el azucar. En Scrum, concretamente, quitas un sólo tornillo y se descuajaringa todo el método, lo tengo comprobado. Jeff Sutherland ha defendido en múltiples ocasiones que no hay nada en el método que esté ahí por casualidad, que todo tiene un sentido muy específico y que el método no necesita optimizaciones, ya que es el resultado de la experiencia directa de miles de los mejores desarrolladores del planeta, la teoría de sistemas y la aplicación de las técnicas más eficaces de gestión (Lean) al mundo del software.

Pasa también que utilizamos esta estrategia de maquillaje del método (diga lo que diga algún pope del Scrum, a mi siempre me ha parecido más un método que un marco) para, como decía, hacer una venta up-bottom y, cuando el equipo se huele algo lejanamente similar a una estructura de control, se sienten engañados una vez más por los de arriba. Decepción, desmotivación, resistencia pasiva y toda la pesca.

Así que ahí va mi consejo a navegantes: si tu scrum, tu scrum. Si tu no scrum, tu no scrum. Pero scrum “mas o menos” (también conocido como “MyScrum” o “ScrumLite” o “bueno, nosotros hacemos una versión simplificada de Scrum”)… Tarde o temprano tu aplastado como uva. Scrum Master Miyagui Dixit (long ago).

Por cierto, no es casualidad que una de las dos metáforas recurrentes en cualquier curso de Scrum que se precie se la de que Scrum no es una bala de plata. El exceso de “hype” está siendo bueno para Scrum en el corto plazo (popularización), pero a la larga puede hacer mucho daño si la gente empieza a decir “esto no funciona”.

Actualización: olvidé mencionar el magnífico artículo de Management From Scratch

Compártelo

Una importante parte de este 20% de seres impermeables a la filosofía Agile suele estar compuesta de inmobilistas, tradicionalistas y escépticos, es decir, lo normal en cualquier proceso de gestión del cambio. Pero hay otra parte que comienza con cierto entusiasmo en esto de Agile, por aquello de la autogestión del equipo, que el Dueño de Producto no deba intervenir en los Sprints, que las fechas más o menos las pongan ellos (ya que son los que dan las estimaciones y deciden cuánto puedes hacer por Sprint), que no se puedan introducir cambios “al tun-tun” sino que deban hacerse al principio de los nuevos Sprints (y generalmente a cambio de otras funcionalidades o compromisos), la comunicación cara a cara… Guay.

Pero señores, no nos engañemos: Scrum y Agile no son “buenrollismo institucionalizado”, al igual que XP no es “hacking institucionalizado”. Me viene a la mente la anécdota del autor del libro “Balancing Agility and Discipline” (creo que fue este), al que, en la presentación del mismo, se le plantaron los Popes y Gurus de Agile a preguntarle que quién le había dicho a él que Agile no era disciplinado. De hecho, somos los tíos mas disciplinados del mundo. Planificamos a diario. Reportamos a diario. Entregamos continuamente. Nos comunicamos constantemente. Progresamos en orden de prioridad… ¿Sigo?

Y eso es lo que algunos equipos no pillan: que todos estos componentes de “buenrollismo” tienen un precio. A saber: desarrollaréis el trabajo en el orden que yo, cliente o Dueño de producto, determino. Me reservo el derecho de aceptar o rechazar el resultado del trabajo, pues yo soy quien tiene la visión y debo deciros si nos acercamos o no a lo que tengo en mente. Debéis reportar y aportar visibilidad a diario sobre el estado del proyecto, pues si no deberé intervenir e interrumpir para saber qué está ocurriendo. Y debo ver compromiso, rendimiento, en definitiva: entregas. Es un precio que muchos pagamos con gran satisfacción y convencidos de que merece la pena el esfuerzo.

Pues bien, cuando ponemos la ecuación completa en juego (que es lo que funciona de verdad), en estos equipos de los que hablábamos comienzan los problemas:

• No quiero hacer Scrum diario: es una forma de control y, como toda forma de control, coharta la libertad del individuo. Idem para el tablón Scrum y el diagrama de Burn Down
• ¿Que qué voy a hacer hoy? Pues estaré “con lo del cliente A”. No puedo dar más detalles, porque eso sería interferir con el equipo. No, no puedo decirte con qué tarea me pongo, ya te hemos dicho que el tablón es microgestión y fiscalización. Las cosas estarán cuado estén. ¿Es que no confías en mí?
• No controles mis entregables: si me corriges, me estás microgestionando. Si yo, que soy el que sabe de esto, digo que el producto está bien, es que el producto está bien. ¿Quién eres tú para contradecirme? Además, ¿por qué hablas tú directamente con el cliente final? Eso es que no confiais en mí. ¿Que el cliente quiere otra cosa? Bah, el cliente no tiene ni idea.¿Que hay que cambiar algo? Haberlo dicho antes, ya no se puede.
• No puedo dar estimaciones. Si doy estimaciones y luego no se cumplen, vendrás a perseguirme. Si me acorralas, triplicaré mis estimaciones para ir sobre seguro.
• Si, vale tu prioridad es la historia uno. Pero la quince es más bonita, la veinticuatro más divertida, la setenta y tres más fácil y la ciento dieciocho simplemente me apetece más. Ah, y hemos metido siete historias que a tí no se te habían ocurrido pero que nosotros estamos convencidos de que son importantísimas.
• Y, bueno, dije que iba a tener tres historias y solo hay una. No ha dado tiempo, que se le va a hacer. ¿Que en qué hemos invertido las horas? Ah, no, eso es control y fiscalización y va en contra de Agile. ¿Que a partir de la semana vamos a cumplir los horarios estríctamente? Eso va en contra de la política de flexibilidad horaria de la empresa. ¿Es que no confías en nosotros? (again)

Como comprenderéis, ante un panorama como este hay muy poquitas cosas que se puedan hacer. ¿Se os ocurren algunas?

Compártelo

Una de las conclusiones que se obtienen del estudio de la termodinámica es que el desorden de un sistema en el que no introducimos energía externa (sistema cerrado) siempre crece. Para una demostración práctica de esta conclusión, dejad de limpiar vuestra casa una temporada hasta que tropecéis con las pelusas (funciona mucho mejor si, como es mi caso, el perro está mudando el pelaje ). Este desorden siempre creciente, esta cuesta de Sísifo, este desgaste infinito se conoce con el nombre de entropía, y su concepto se introduce en el segundo principio de la termodinámica.

Algunas de las cosas que implican estos principios incluyen la imposibilidad de crear móviles perpétuos, ya sean de primera o segunda especie. No se pueden crear sistemas que producen más energía de la que consumen. Ergo si queremos mantener un movimiento indefinidamente, debemos aportar energía.

Ese es el quid de la cuestión a la que quiero llegar: si queremos que las cosas funcionen, si queremos que progresen, si queremos que mejoren, si queremos que cambien… Debemos aportar energía. El universo así lo establece, y a los que van contra el universo les suelen pasar cosas malas, no se si me explico

Por eso nunca deja de hacerme sonreir el que, al explicar determinadas técnicas, procesos, metodologías, ideas, innovaciones, herramientas o demás tricks of the trade, alguien en la audiencia diga “ya, pero es que eso no es tan fácil…”. Cuando, por cierto, yo no he mencionado en ningún momento que lo sea.

Suelo usar siempre una frase: “¿Esto es mejor o peor que lo que hacemos ahora? ¿Es mejor? ¿Es bueno? Hagámoslo“. Aunque sea cuesta arriba.

Compártelo

En primer lugar, darte la enhorabuena por el curso, ha estado muy por encima de las espectativas que tenía, que ya eran altas por todo lo que había oido !.
En segundo lugar, me gustaria que me explicases la posibilidades que existen para que me ayudeis a implantar el Scrum en mi empresa […]”

Compártelo

Finalmente lo celebraremos en el hotel Zenit Borrel, en la calle Comte Borrell 208, muy cerquita de la Escuela de Ingeniería Técnica Industrial y del metro del Hospital Clinic. El costel del curso incluye el almuerzo de los dos días, y puede ser una buena oportunidad para conocer a personas con las mismas inquietudes. Para información y matriculaciones, escribid a info (arroba) proyectalis.com.

Compártelo

Tenéis algo más de información sobre el curso en la web de Proyectalis. Se atenderán las inscripciones por riguroso orden de pago, y en el curso de Madrid se nos quedó gente fuera a última hora, por lo que os recomiendo que si tenéis las fechas disponibles os pongáis en contacto con nostros cuanto antes a través del correo info (arroba) proyectalis.com

Compártelo

Ver mapa más grande

Recordamos que se celebrará los días 14 y 15 de Octubre y que aun quedan algunas plazas disponibles. Más información aquí.

Compártelo

Un resumen del video realizado por Stefan Hagen:

Some rules and key success factors of being an agile coach:

1. Be detached from outcomes: don’t only focus on WHAT the team works on (outputs and outcomes) but also on HOW the team works
2. Take it to the team: let the team solve the project’s issues and problems
3. Be a mirror: reflect back to the team, ask questions
4. Master your face: practice non-violent communication, be relaxed
5. Let there be silence: get comfortable with un-comfortable silence
6. Model being unreasonable: be wild, be big, be bold
7. Let the team fail: teams that fail and recover together are much stronger, trust!
8. Be your team’s biggest fan: …and tell your team

What is it to be an Agile Coach?

1. Bulldozer: sweep problems and issues out of the way for your team
2. Shepherd: get them back on the path
3. Servant Leader: serve the team, be a facilitator; “Make sure that other people’s highest priority needs are being served.“
4. Guardian of quality and performance: watch WHAT and HOW your team is producing

Compártelo

La inscripción está limitada a 15 participantes, por lo que ruego a todos los interesados que formalicen la matrícula lo antes posible. Todos los que habéis contactado por e-mail en info (arroba) proyectalis.com recibiréis hoy mismo un correo con las instrucciones de matrícula.

Por otra parte, con bastante probabilidad convoquemos en breve un curso similar en Sevilla y otro en Barcelona, para lo cuál necesitaremos conocer de antemano cuántos interesados podría haber en cada ciudad. Gracias a los que ya habéis expresado vuestro interés aquí, y animo a todos los que aun no lo hayáis hecho a comentarlo en este mismo artículo.

Compártelo

En la primera quincena de Octubre estamos planteando la posibilidad de celebrar un curso abierto en Madrid. Tenemos a varios interesados, por lo que es más que probable que podamos cerrarlo pronto. Duraría dos días e incluiría ejercicios prácticos como complemento a la teoría, con el aliciente de conocer a personas de otras empresas interesadas en el mundo del desarrollo de software, Agile, la gestión de proyectos… El coste será muy reducido, para facilitar la asistencia de todos aquellos que quieran plantearselo a nivel personal, y el temario aproximado es el siguiente:

• Introducción a la gestión de proyectos
• Scrum 101
• Principios de Agile y Lean
• Planificación en Scrum
• Estimación en Scrum
• Control en Scrum
• Gestión de equipos en Scrum
• Implantando y Escalando Scrum
• Herramientas y referencias

El mínimo de asistentes será de seis y el máximo de doce. Como es habitual, se atenderán las inscripciones por orden de pago. Para más información, correo a info (arroba) proyectalis (punto) com o comentario en este vuestro blog

Compártelo

Este año no toca. Todo llegará… :_(

Compártelo

En fin, que me lío: en este ejercicio “post mortem” analizamos lo que ha ido bien y lo que necesita mejorar, lo que ha sido divertido y lo que ha sido más pesado, lo que es esencial y lo que se ha echado en falta. Lógicamente, a lo largo de varias decenas de retrospectivas el curso va mejorando, y amparándome en el hecho de que muchos de los asistentes a los cursos son lectores del blog me atreveré a afirmar que el índice de satisfacción y de éxito que estamos alcanzando con los cursos es muy alto, y en un porcentaje interesante de ocasiones conduce a proyectos más intensos o específicos.

Curiosamente, conforme se fueron puliendo las aristas más evidentes, han quedado un grupo de “deltas” que son casi una constante, y ante los que estamos replanteando incluso nuestra estrategia de comercialización. Lo cuál quiere decir que las retrospectivas están siendo una importante fuente de innovación.

La constante mas evidente es pedir un mayor grado de personalización en los cursos: atacar las cuestiones específicas de la organización y proponer soluciones. Pero claro… Eso tiene un nombre (consultoría) y un precio diferente a la exposición más o menos participativa y creativa de un mismo tema (recurrencia, señores, recurrencia… Hay que productizar ). No obstante, en lugar de limitarme a señalar este hecho (que la consultoría se paga) lo que estamos haciendo es diseñar un nuevo paquete de servicios que consiste en una consultoría previa, unas sesiones de formación y un roll-out workshop, es decir, un día de trabajo en el que los participantes se traen sus proyectos debajo del brazo y trabajamos en la definición de los mismos, el enfoque de desarrollo, las herramientas de visibilidad y control… En el caso de Scrum, creamos o mejoramos las pilas de producto, calendarizamos los sprints, preparamos un release plan, creamos los tablones de sprint, establecemos la mecánica y duración de las diferentes reuniones…

Así, cada cliente puede optar en cada momento por uno de los productos, combinaciones de dos o el paquete completo de consultoría + formación + taller. Hay quien pensará que me hago un flaco favor publicitando a los cuatro vientos nuestras innovadoras estrategias , pero en el fondo creo en esto, en difundir el conocimiento, las mejores prácticas y las lecciones aprendidas. Al fin y al cabo yo me he beneficiado de la experiencia de muchos que han avanzado antes que yo, y mi creencia firme en los mecanismos del Karma no puede empujarme a otra cosa que a compartir. Además, la experiencia me dicta que las personas que han compartido sus conocimientos recogen frutos a la larga. Al fin y al cabo, es un marketing excelente.

En cualquier caso, tanto si productizais como si no, tanto si paquetizais como si no, lo que sí es muy importante es mantener constantemente un mecanismo de revisión crítica y mejora que permita, sobre todas las cosas, escuchar al cliente, y mantener en todo momento una actitud constructica y positiva al respecto de las opiniones del cliente. Incluso cuando, según nuestro criterio el cliente se equivoca, es mucho más productivo pensar “¿por qué habrá llegado el cliente a esta conclusión? ¿En qué estará fallando mi mensaje?” que enfrascarnos en demostrar al cliente lo equivocado que está (frustrándole además por el camino).

Compártelo

Ummmmmmmm….Baaah-naaah-naaaasssss….

Compártelo

Oogway: That is bad news, if you do not believe that the dragon warrior can stop him.
Shifu: Panda ?! Master that panda is not a dragon warrior, he wasn’t even meant to be here ! It was an accident !
Oogway: There are no accidents.
Shifu: Ahhh, yes I know, you’d said that already, twice.
Oogway: Well, that was no accident either.
Shifu: Thrice.
Oogway: My dear friend, that panda will never fulfill his destiny nor yours, until you let go of the illusion of control.
Shifu: Illusion ?
Oogway: Yes, look at this tree Shifu. I cannot make it blossom when it suits me, or make it bear fruits before it’s time.
Shifu: But there are things we can control. I can control when the fruits will fall. And I can control where to plant the seed. That is no illusion Master.
Oogway: Ahhh yes, but no matter what you do, that seed it will grow into a peach tree, you may wish for an apple or an orange, but you will get a peach.
Shifu: But a peach cannot defeat Tai Lung !
Oogway: Maybe it can, if you are willing to guide it, to nurture it, to believe in it.
Shifu: But how ! How !? I need your help Master !
Oogway: No, you just need to believe. Promise me Shifu, promise me you will believe.
Shifu: I will try.

Compártelo

Ha coincidido además con un punto de inflexión en el crecimiento de mi empresa y un pico de trabajo interesante. Lo cachondo es que tengo otro punto de inflexión en ciernes a la vuelta de las vacaciones… En fin, será lo último de lo que me queje viendo los buenos resultados que estoy obteniendo del primero.

Proyectos en Sevilla, Mallorca, Madrid, Barcelona, Coruña, Munich… Muchas horas de vuelo que quitan fuerzas y tiempo blogosférico. Lo siento, no me concentro en los aeropuertos. Gran parte de la culpa la tienen los turistas sevillanos que, dicho sea desde el cariño que le profeso a mi patria chica, son los mas ruidosos, horteras y catetos de todos los aeropuertos por los que he transitado hasta ahora (crear polémica siempre sube las visitas al blog ).

No todo ha sido curro a expuertas en este periodo. He tenido el privilegio de asomarme a algunas de las mentes más brillantes en el campo del desarrollo de software, la gestión de proyectos y las pautas organizativas, tanto en vivo aprovechando el XP 2008 como a través de obras seleccionadas y recomendadas por estos mismos expertos y que voy devorando lenta, pausada pero inexorablemente, notando a cada página transcurrida, a cada conversación de pasillo, a cada café compartido, como se acumulan los niveles de experiencia y el poder de una generación de mentes privilegiadas dedicadas a crear un mundo mejor para los que vivimos en las tecnologías de la información y las telecomunicaciones . Todo un viaje que recomiendo a exploradores de las simas de la estupidez corporativa y buscadores del norte verdadero. Más pistas en breve.

En fin, que sirva este pequeño post para anunciar a la blogosfera mi vuelta y pedir a asiduos y no tan asiduos que no me abandonen, que los echo mucho de menos

The show goes on…

Compártelo

Xp2008, Katti Vilkki, Nokia Siemens Networks

Compártelo

Xp2008, Dave Snowden y Joseph Pelrine

Compártelo

Dependiendo de la tolerancia al interrogatorio y la tortura del equipo , prosigo con la exploración: “¿Avisásteis al Jefe que si teníais que atender estas tareas urgentes, debíais dejar de hacer el resto de cosas que os pidieron?“. “No…Pero se sobreendiende“. “No, no hace falta porque ya sabemos lo que nos diría“.

Y así, el equipo tiene su parte de culpa en la prolongación del esquema irreal de la carga de trabajo, lo que en Agile se conoce como “la creencia en la magia” (algo ocurrirá que hará que todo encaje en tiempo y presupuesto), simplemente porque no es capaz de decir que no. En algunos casos, pocos, que me haya encontrado, realmente no se le permite a los equipos decir que no, pero en otros muchos se trata de un problema de habilidad de comunicación, negociación y persuasión por parte de los equipos. Al fin y al cabo, predecible y comprensible: nadie se ha tomado su tiempo en enseñar a un programador a negociar, y de todas maneras muchos de ellos ni siquiera llegan a ver la utilidad de algo que no compile . Por supuesto, esto no exime de culpa a los jefes que quieren todo hecho para ayer, ya hablaremos otro día de ellos. De hecho, probablemente ellos no han sabido tampoco decirle que no al cliente, al comercial que ha vendido la moto o a su propio jefe que pide las cosas acostumbrado a la “barra libre”.

Y así logramos lo que en Lean Software Development se conoce como Trashing. Es lo mismo que le ocurre a un ordenador por encima del 100% de carga: pasa más tiempo gestionando el intercambio de tareas que realmente ejecutando las tareas, y al final nada funciona. Solo que en el cerebro humano esto ocurre en cuanto superamos más o menos el 80% de capacidad, algo parecido a lo que ocurre en carreteras y autopistas. Al fin y al cabo, cuando hay un atasco o tráfico lento, en realidad cabrían más coches entre coche y coche, ¿No? Efectivamente, no hay que llegar al 100% para provocar un atasco.

Me he encontrado con empresas que tienen listas de 300 implementaciones o mejoras pendientes, cuando su capacidad de producción es de en torno a 3, 4 o 5 historias al mes, lo que significa que tienen una lista de trabajo de seis o siete años (verídico), y eso sin contar conque la lista sigue creciendo y actualizándose constantemente. Todo por no seguir una simple práctica: decir que no. Para aquellos que quieren conservar las peticiones a título informativo o como recurso de lo que al usuario le gustaría, basta con establecer una lista de “Nunca”, como sugería Mary Poppendieck en un seminario al que asistí esta semana.

Al fin y al cabo, cuando Google ofrece a los empleados un 15% de tiempo para asuntos libres y personales, en realidad hace algo de trampa. En realidad, todos dedicamos en torno a una hora al día a desayunar, ir al baño, mandar correitos chorra, leer un blog, chatear por el messenger con un compañero, revisar la cuenta del banco y demás asuntos personales. Una hora al día representa en torno a un 13% de tiempo. Lo único que Google dice es “esta bien, SABEMOS que hacéis estas cosas en jornada laboral y nos parece bien, siempre que el restante 85% lo dediquéis a esta compañía, y lo hagáis al máximo nivel”.

Otra de las cosas que Google hace, como muchos sabéis, es reservar otro 20% de tiempo para proyectos de innovación. Y este tiempo debe ser respetado. El riesgo de esta política es que los equipos se queden más tiempo del que les toca para atender a una demanda siempre creciente de tareas, incapaces de atenderlas todas en el 65% de tiempo que les queda para el desarrollo. Muchas de estas tareas, por cierto, caerán en ese 60% de funcionalidades que, según Standish y según mi experiencia directa y la de todos los desarrolladores con los que he trabajado hasta ahora, se usan rara vez o nunca. YAGNI. Quemar recursos, dinero y tiempo de la empresa y de las personas.

Así pues, dear teams in the way of Agilehood: Just Say No. No a más trabajo del que razonablemente se puede desarrollar. Y os prometo una cosa: cuando los equipos tienen responsabilidad y se les da cierta holgura en la dedicación, la productividad se dispara. Se escribe mejor código, más limpio, con menos errores que atender y corregir en los próximos meses. Hay tiempo para aprender mejores prácticas y nuevas tecnologías. Hay tiempo para refactorizar, implementar arquitecturas mejores, mejores herramientas… Y esto, junto con un equipo motivado por el avance, es el motor del aumento de la productividad en Agile. Implementar únicamente el scrum diario, un tablón y seguir sobrecargando al equipo no llega siquiera a atisbar las mejoras reales que pueden lograrse en una implementación completa de los principios que operan tras Scrum.

Y por hoy ya vale, que me está saliendo un ladrillo considerable.

Actualización: Ofú, meneado… Mejor voy cerrando los comentarios…

Compártelo

Hay soluciones basadas en Scrum que funcionan en entornos como el que comenta Luís (os lo aseguro), pero el cliente debe estar dispuesto a un modelo más colaborativo. Me ocurre con frecuencia que, cuando comento a un cliente la posibilidad de que contrate a sus proveedores en un modelo de “fixed time-fixed money” con funcionalidad variable (es decir, contrato al equipo por seis meses y a ver cuánto somos capaz de hacer) me dicen que estoy loco, que entonces el proveedor se dedicará a tocarse las narices todo ese tiempo y que no entregará casi nada al final del proyecto. Pero sin embargo cuando se lo comparo con los contratos de outsourcing o bodyshopping comienzan a verlo más claro: el principio es el mismo, y la forma de controlar el progreso es involucrarse en el mismo de forma diaria.

De hecho, los contratos “fixed time, fixed money, fixed functionality”, es decir, contratos basados en un supuesto conocimiento perfecto del futuro y la evolución del producto a lo largo de meses y meses de trabajo, son una aberración en un mundo de productos complejos como el software y los sistemas, de forma que lo que ocurre en realidad es que el cliente trata de trasnferir todo el riesgo tecnológico y de “mutación” al proveedor, y este se blinda metiendo más colchones que pikolin. Así expresado no parece muy colaborativo, ¿Verdad? Pues por eso no funciona.

Algunas fórmulas intermedias que suelo recomendar incluyen lo que llamo el contrato de “scrumsourcing”, en el que los objetivos se dividen segun MOSCoW (Must, Ought, Could, Wish) y se firma, por ejemplo, hacer un 100% de los Must, un 80% de los Ought y un 50% de los Could en un tiempo determinado por el proveedor. Cualquier funcionalidad o historia en el que no se haya empezado a trabajar puede ser cambiada en cualquier momento por otra de valor / peso similar. Y en caso de que el cliente esté satisfecho con el nivel alcanzado en cualquier punto del proyecto, o al contratio, piense que el proveedor no avanza al ritmo adecuado, puede cancelar el contrato en cualquier momento por un coste equivalente al 20% de lo que quede por hacer. Así, dividimos el riesgo entre todos.

La típica queja que suelen elevar los proveedores es que un enfoque de este tipo les obliga a diseñar el sistema de una forma altamente modular y flexible para soportar los cambios de funcionalidades futuras. Típicamente lo expresan como “no se puede”, pero el caso es que miles de empresas de todo el mundo trabajan así, o sea que se puede, pero requiere un esfuerzo y una disciplina. Y por otra parte, ¿no es más valioso para el cliente contar con una arquitectura modular y flexible que permita incorporar cambios y nuevas funcionalidades en el futuro? ¿No es incluso mejor para el proveedor, de cara a la recurrencia del cliente?

En este tipo de enfoques, lo ideal es comenzar contratando a proveedores para proyectos de bajo riesgo y corta duración, seleccionando a los que mejor funcionan para proyectos a mayor duración y con un impacto mayor en la compañía. Esto tiene dos ventajas: por una parte, como comentaba, podemos seleccionar a los proveedores que funcionan bien con un modelo ágil. Y por otro podemos comenzar a acostumbrarnos al proceso con proyectos de bajo riesgo e ir perfeccionando los mecanismos de control, visibilidad y feedback.

Que por cierto, para este tipo de cosas hay una consultoría que… O:-)

Compártelo

Pues bien, no solo produjimos la que a mi juicio es una de las mejores presentaciones que he realizado hasta la fecha, sino que ambos aprendimos varias cosas sobre cómo realizar un power-point. Hoy mismo estoy haciendo otro y me he sorprendido utilizando intensivamente un par de herramientas y consejos que hasta ahora no había tenido en cuenta.

Al fin y al cabo, lo que estuvimos haciendo es el equivalente a la práctica de programación por parejas que describe XP (programación extrema) y, efectivamente, lejos de ser un desperdicio por tener a dos personas haciendo lo que en teoría podría hacer una, la inversión en calidad que supone tener cuatro ojos y dos cerebros revisando lo que se hace realmente paga cuando se revisa la visión global del proyecto. Item mas: el nivel de conocimiento del equipo aumenta drásticamente, ya que se produce una transferencia de mejores prácticas de forma natural.

A los que todavía no hayáis introducido prácticas de pair programming en vuestros equipos ágiles, os animo realmente a que empecéis a hacer algún experimento, porque estoy seguro de que si lo implementáis correctamente los resultados os van a sorprender mucho más allá de lo que pensáis.

actualización: me doy cuenta de que todavía no he referenciado en el sitio las estupendas “death by powerpoint” y “how to: visual effects in power-point”.

| View | Upload your own

| View | Upload your own

Compártelo

Scrum, como sabéis, establece un artefacto (la pila de producto) que permite a la gente de negocio (Dueños de Producto) manejar a la gente técnica (Scrum Master y equipo). Sin embargo, uno de los problemas típicos que nos encontramos en las implantaciones de Scrum en las que trabajamos es el de involucrar a la gente de negocio en el proceso. La implantación de Scrum suele surgir por iniciativa de los técnicos, cosa rara si pensamos que la gente de negocio debería tener una formación y un foco más “humanista” y deberían haber sido los primeros que planteasen formas de colaborar y comunicarse con las áreas de producción (notese el matiz respecto a “áreas productivas”, que esas deberían ser todas, negocio y sistemas).

Al surgir desde el área técnica, las áreas de negocio tienden a veces a considerarlo “cosas de frikis” y pasar muy mucho del tema. Por eso nuestro enfoque de implantación conlleva muchas acciones dirigidas a las áreas de negocio. El objetivo final es que las áreas de negocio nombren un determinado número de Dueños de Producto que sean los que canalizacen y prioricen las peticiones de todos los interesados, clarificando al equipo lo que deben hacer en cada momento. Con eso evitamos también el bombardeo de peticiones “no oficiales” a las que típicamente se ven sometidos los equipos de desarrollo, peticiones cuya prioridad no está clara y que la mayor parte de las veces ni cuentan con una justificación de negocio sólida ni computan luego en la productividad del equipo, ya que se hacen “de tapadillo”.

Lamentablemente, el enfoque de envagelización y colaboración no siempre funciona, y los equipos de desarrollo se enfrentan a peticiones y negociaciones que les llueven por todas partes. Es como enfrentarse a un enemigo muy superior en número y recursos. ¿Y qué podemos hacer en una situación así?

Reflexionabamos sobre esto, como os decía, y tratando de explicar el enfoque que nosotros proponemos como siguiente nivel de presión hacia el cambio corporativo se me ocurrió la metáfora de los “orcos a las puertas”: La batalla del abismo de Helm.

En la batalla del abismo de helm, los humanos se parapetan en un fortaleza que cuenta con un único punto de acceso: un estrecho puente que obliga a los miles de orcos que los asedian a formar casi de uno en uno, con lo que en las puertas de la fortaleza se monta lo que los KODT llaman una “conga de la muerte”, una estrategia perfecta para lidiar con un enemigo muy superior en número y que ya fue utilizada por los 300 espartanos en el paso de las termópilas.

¿En qué consistiría la estrategia “orcos a las puertas”? En primer lugar, en blindar el área de sistemas. Kniberg lo describe muy bien en su libro. Esto se puede hacer a un nivel organizativo o discilplinario, aleccionando a todo el mundo para que no atiendan peticiones de ningún tipo que no vengan del Dueño de Producto de Sistemas, o incluso físicamente, co-alocando a todo el equipo y dejando pocas vías por las que los extraños puedan acceder y pulular. Incluso sentar al Dueño de Producto de Sistemas al lado de la puerta para que actue como guardián del área.

El segundo paso es precisamente ese: nombrar a un Dueño de Producto de Sistemas encargado de lidiar con los orc…Digooo…Con la gente de negocio. Nada fácil, os lo aseguro. En la mayoría de los casos una estraegia pasivo-agresiva como esta suele acabar en el despacho del CEO, pero a veces es precisamente esto lo que hace falta. Por eso es también muy importante preparar documentación sobre todos los intentos previos que se hayan hecho para que el área de negocio asuma la responsabilidad y la competencia que le toca sobre la definición y priorización de los proyectos. Eso nos permitirá justificar el movimiento defensivo.

A veces lo que ocurre es que el área de negocio está encantada con tener un interlocutor único en sistemas, y la estrategia “orcos a las puertas” se convierte en una mejor práctica corporativa. Pues estupendo. De hecho, no se vive tan mal en el abismo de Helm, siempre que uno tenga un puesto calentito, dos buenas pantallas TFT y unas cuantas herramientas de desarrollo…

Compártelo

• Una barra de limpiador de gafas, muy util cuando uno se confunde y pinta con rotulador indeleble en una pizarra velleda (por cierto, ¿¿¿no os da mil patadas que la gente las llame pizarras villeda??? )
• Una navajita mulitusos (deshauciada desde que empecé a coger más aviones)
• Cuaderno tamaño cuartilla
• Post-its… Lot’sa post-its
• Rotuladores, en sus variedades: marcador fluorescente, edding de escribir post-its, edding indeleble para papelógrafos, ikea para velledas (punta fina) y bic para velleda (punta gruesa)
• Papel celo y blu-tac (moco/chicle adhesivo, vaya)
• Kleenex
• Cámara de fotos digital
• Reproductos MP3 cargado de audiolibros y algunas canciones de las de conducir (niños, no lo hagáis en casa ).
• Ocasionalmente, un proyector LG y un trípode de cámara digital
• Un limpiador de pantalla de portatil (pequeño artefacto con un borde de gamuza retractil)
• Marcapáginas adhesivos (utiles para realizar votaciones en ausencia de sticky dots)
• Montones de tarjetas de visita, profesionales y del blog
• Una mini-linterna de leds
• Un peine… Lo siento, pero a veces va uno con la moto a ver a un cliente y si no se atusa un poco al quitarse el casco parece el primo treintañero del neng de castefa
• Ocasionalmente, latas de caramelos del LIDL

Ah, sí… Y el portatil con su cargador, claro… ¿Que si pesa? Como un palet de ladrillos, la condenada…

Compártelo

En cristiano: que he empezado a centrar, priorizar y abandonar aquellas labores que menos me aportan. Y en la criba se ha caido mi colaboración con El Blog Salmón. Ohhh…Lazzztima. Justo ahora que se incorporaba Enrique era un buen momento, aunque sinceramente me hubiera apetecido trabajar con él una temporadita, aunque fuese en “asíncrono”.

Alguna novedad más: me he apuntado a XP 2008. Dado que cada vez tengo más porcentaje de negocio ligado a Agile, Scrum, Lean y todo el mundillo de los nuevos enfoques estratégicos y productivos en la industria del software, creo que es una buena oportunidad para pulsar un poco lo que se está haciendo en otros países y por donde tira el mercado. Por cierto, ni un ponente Español en el evento, ¡shame on us! Si alguien se está planteando asistir, que se ponga en contacto conmigo y haremos lobby

Más cositas: me planteo asistir al Iniciador de la semana que viene, pero coincide con la feria de Sevilla y no se qué tal andarán los AVE’s. Tengo una entrevista pendiente con una empresa de Madrid y podría aprovechar para hacer seguimiento de un par de oportunidades que tengo languideciendo por allí… No se, no se. Tomaré la decisión en el último momento responsable (¿se nota que estoy repasando Lean? )

Por lo demás, uno de los objetivos en la purga de labores que he hecho es dedicarme un poco más al blog, ya que los últimos artículos han despertado bastante interés, pero la frecuencia de publicación está sufriendo demasiado. Espero que sigáis atentos los próximos días, que tengo un montón de temas pendientes

Nos leemos…

Compártelo

MWAA-HAHAHA!! ROTFLASTC!!

Vía Sebastian Bergmann, encontrado en Flickr buscando “Agile Software Development”.

Compártelo

El libro está disponible de forma gratuita en InfoQ, un magnífico recurso para los interesados en las metodologías ágiles y el desarrollo de software en general. Dada su naturaleza abierta, hace unos meses contactamos con Henrik y le contamos que utilizábamos gran parte de su libro en la preparación de nuestros cursos o en los proyectos de consultoría e implantación de Scrum en empresas, y como agradecimiento nos ofrecimos a traducirlo al castellano. Henrik nos ofreció su colaboración y visto bueno desde el principio, y fruto de dicho ofrecimiento queremos poner a vuestra disposición el primer borrador de Scrum y Xp desde las trincheras en castellano.

La URL por si queréis incluirla en vuestros blogs sería http://www.proyectalis.com/scrum-y-xp-desde-las-trincheras. Espero sinceramente que lo disfrutéis tanto como yo.

Compártelo

Por lo demás, si las fechas no os cuadran, Madrid os pilla mal o el inglés os supone una barrera, ya sabéis que en Proyectalis organizamos cursos similares para empresas en castellano y con una duración de dos días o tres tardes intensivas (fin de la cuña publicitaria ).

Para saber más sobre el CSM, mirad aquí o aquí.

Compártelo

Scrum y Teletrabajo

Ya hemos terminado el primer apretón y estamos en el segundo, así que hay algunas conclusiones al respecto de trabajar con una metodología como Scrum, pero antes de nada, en líneas generales, el perfil del equipo de Osmius:

* Somos un equipo pequeño y no queremos crecer a más de 7 u 8. Preferimos dividir y tener otros equipos.
* Hay confianza: Tú sabrás cómo te organizas y cómo cumples tus compromisos con el resto.
* El dueño de producto es interno. No hay un cliente claro presionado aunque abrimos los requisitos además del código.
* En media nos conocemos y hemos trabajado juntos hace… unos diez años.
* Nos gusta un montón el proyecto. Pero tampoco nos importaría empezar otro en unos meses.
* En general preferimos tiempo libre a dinero.
* El equipo es partícipe de los beneficios del proyecto.
* Todos bailamos o cantamos fenomenal

Bien, pues resulta que además de meternos con Scrum hemos empezado con el teletrabajo, y algunas conclusiones han sido:

* Scrum nos ha metido presión. Sensación de ¡vamos, vamos, vamos!
* Somos más efectivos que antes. Cerramos más tareas y cuando lo ves no te lo crees.
* El teletrabajo es un lujo. Ahorro de tiempos, buenas sensaciones…
* Hay que tener contacto diario. El Scrum diario con Skype y las horas en la hoja de cálculo Google han sido fenomenales.
* Toda la semana en casa no mola. Nosotros quedamos en la ofi lunes y jueves. Menos es desagradable.
* Cada uno es responsable de sus tareas para bien y para mal, y los problemas son de todos… o nos vamos a la mierda.
* Hacemos demo en cada apretón y cada dos o tres apretones sacamos versión. Nos da sensación de avance.

Esta es la gráfica del Apretón de la alpha de Osmius 8.01. Según pasan los días vamos quitando trabajo siendo la idea estar con la línea roja por debajo de la línea azul de pendiente constante. En otra ocasión podemos comentar algunas obviedades según sean las panzas y el aspecto de la curva ¿no?

Por cierto el jueves 7 de febrero a las 20:30 hacemos demo en Peopleware. Pasaos sin más o si preferís escribidme a joseluis [puntito] marina [arrobita] peopleware [puntaco] es.

Así que ya sabéis: si queréis avanzar en vuestro camino hacia la productividad, la motivación y una vida personal y profesional más satisfactoria, Scrum puede ayudaros, y nosotros estamos a vuestra disposición.

Compártelo

There are (software development) organizations
that are more productive than others. ‘Luck’ is not the
whole story; you need to look for ways to improve.”

Myers, 1998, vía una presentación de Jeff Sutherland.

Compártelo

El scrum lo descubrí hace unos dos meses, a través de tu blog y me documenté un poco.

Hace un mes, en mi empresa ganamos dos proyectos idénticos que duraban 20 días. Yo lideré uno de ellos, y decidí aplicar un poquito de Scrum, sólo las reuniones matinales repasando qué hice ayer, qué voy a hacer hoy y qué necesito.

Situación inicial, un gerente liderando cada proyecto con una dedicación de 15 horas para los 20 días. Dos equipos idénticos con un jefe de proyecto cada uno, un analista funcional y dos analistas técnicos. Los resultados: el jueves de la semana pasada liberé un analista técnico, el viernes otro, el martes al funcional, y el miércoles al jefe de proyecto, cumpliendo exactamente los 20 días que habíamos planificado con reiteradas felicitaciones del cliente. Ni siquiera he llegado a dedicar las 15 horas.

El otro proyecto aún no ha terminado, terminará el miércoles de la semana que viene y sigue manteniendo todo el equipo.”

Sólo de pensar que hay gente que está encontrando formas mejores de hacer las cosas gracias a este blog, y que eso les está permitiendo llegar a lo que llamo el subidón de “puñeta, somos buenos“… En fin. Que me he emocionado, vaya.

Gracias, Ricard. Gracias de verdad.

Compártelo

Scrum es indudablemente más sencillo que los frameworks pesados para la gestión de proyectos como puedan ser el PMBOK o Métrica V3 (¡ergs!), e incluso más sencillo que las versiones “lite” que se han diseñado de los frameworks pesados, como puede ser Prince2. Pero eso no quiere decir que si echamos a andar los famosos tres procesos, tres artefactos y tres roles ya lo tengamos todo hecho. Hay muchos aspectos que son los que hacen que Scrum funcione, y la atención a estos aspectos marca la diferencia entre el 66% de empresas que consiguen implantar Scrum efectivamente y el 33% que abandona por el camino (datos de la Scrum Alliance).

Ahora que empieza el iweekend (que rabia habérmelo perdido) y sabiendo que Raúl está mirando metodologías ágiles para aplicarlas, me he decidido a escribir este post. En base a mi experiencia y a literatura existente (que la hay como para enterrar a un gran danés en papeles), las cosas que hacen que Scrum funcione son las siguiente:

1. Scrum es sencillo, pero muy duro. Como un canto rodado, vaya. Si pensamos que Scrum no nos va a requerir un esfuerzo, es más que probable que la gente abandone cuando se de cuenta de que exige una importante dedicación, un proceso de gestión del cambio que puede llegar a ser muy complicado y un nivel de foco superior al que se habitualmente se tiene en las organizaciones. Aun así, los resultados que Scrum proporciona en términos de productividad, calidad, satisfacción, éxito y rentabilidad de los proyectos hacen que el esfuerzo merezca la pena.
2. Scrum no es una bala de plata. Esto, junto con lo de las gallinas y los cerdos, es uno de los principios más citados de Scrum. Cuando la gente se sumerge en el mundo de las metodologías ágiles y ven lo que pueden llegar a conseguir siente la tentación de recetar “café para todos” (en palabras de Mario). Y eso no es así. Scrum tiene su territorio: proyectos complejos, con un requisitos cambiantes, organizaciones flexibles, implicación del cliente… En otros entornos es mejor usar otras cosas. Por otra parte, Scrum no va a solucionar todos los problemas de la organización. Si falta compromiso de la gerencia, si hay compañeros obstruccionistas., si el cliente es un explotador…Bueno, Scrum no va a solucionar todo eso. Si pensamos que sí y fallamos, sentiremos la tentación de abandonar Scrum. Por eso es importante recordar constantemente que Scrum no es una bala de plata.
3. Scrum es iterativo e incremental. Repetid conmigo: iterativo e incremental. Iterativo e incremental. Eso quiere decir que liberamos código (o producto) frecuentemente, y cada liberación representa un incremento sobre la anterior. Pensad más en “Casa 0.1″, “Casa 0.2″ hasta “Casa 1.0″ que en “cimientos” seguido de “paredes” seguido de “techo”. No podemos liberar una casa sin techo, pero a lo mejor sí una casa con paredes de chapa y techo de uralita (version “chabola”… Todo tiene un mercado).
4. El producto que funciona es la única medida del avance del proyecto. Si me tuviera que tatuar una frase sobre Scrum, sería esta. No cuántas horas hemos echado. No cuántos recursos llevamos consumidos. No cuántas tareas llevamos hechas. Producto que funciona. Si no hay producto que funciona, no avanzamos. Lease el punto anterior.
5. Todo en Scrum tiene un límite de tiempo. Para esto me gusta mucho la expersion inglesa time-boxed, que lo expresa mejor. Nada de “alargamos la reunión un poco más”. Nada de “El lunes, tal vez el martes”. La reunión acaba a las cuatro, y trabajaremos con lo que tengamos al final de la misma. La entrega es el lunes, y entregaremos lo que tengamos el lunes. Scrum cambia el enfoque tradicional del PMBOK de recursos+funcionalidades deseadas = fecha de entrega y lo convierte en recursos + fecha de entrega = funcionalidades que podremos entregar. Si se nos cae una funcionalidad de la lista, vaya por Diox. Pero entregamos.
6. Las entregas son productos potencialmente utilizables y/o comercializables. Shippable, que dicen los ingleses. Eso significa que nada de power point y nada de planos o documentos describiendo lo que hará la aplicación: queremos tocar, ver y usar algo, aunque sea un prototipo de la funcion de login.
7. Definir qué significa terminado. Terminado puede querer decir “rula” o puede querer decir “rula, ha pasado los tes de calidad, se ha documentado, se ha añadido al repositorio y hemos formado a soporte técnico”. No es lo mismo. El trabajo no se acaba hasta que se acaba.
8. Mantener Sprints de duración fija. Al principio es muy tentador andar tocando la longituds de los sprints para adecuarlos al producto, en vez de adecuar el producto a los sprints. Pero si hacemos lo primero nunca seremos capaces de obtener una sensación correcta en el equipo de cuánto trabajo podemos abarcar en un Sprint. Scrum es disciplina: quien piense que las metodologías ágiles on una especie de hacking institucionalizado, se equivoca.
9. Realizar los Scrums diarios. Es una de la sprimeras cosas que se abandona, como decían en su día en el blog de chuidiang. Pero el Scrum diario es la unidad atómica de Scrum, y si empezamoscargándonos esto, no podemos esperar que los ladrillos se mantengan unidos. El Scrum diario es lo que consigue que podamos controlar a tiempo, que tengamos visibilidad efectiva, que el equipo sincronice sus tareas… Hay que protegerlo a capa y espada, y ser muy estricto con su celebración. Por eso lo de “todos los días en el mismo sitio, a la misma hora”. Si empezamos a cambiar las horas todos los días, acabaremos por no celebrearlo un día. Entonces pensaremos “anda, no ha pasado nada” y empezaremos a saltárnoslo cada dos por tres. Y entonces estaremos en la situación sobre la que nos previene el ScrumMaster Miyagi: haremos “Scrum supongo”.
10. Hacer retrospectivas. Lo más importante de las retrospectivas es asegurarse de que se celebran. Las retrospectivas son lo que nos permite detectar impedimentos de alto nivel en el proceso y mejorar constantemente. Si nos enfocamos demasiado en los sprints y en producir y no nos paramos de vez en cuando a reflexionar, todo el enfoque empírico y adaptativo de Scrum se nos viene abajo. Como decían por ahi, “si siempre estás sprintando, en realidad acabarás haciendo jogging”.
11. Respetar los roles: Sólo el Dueño de Producto puede tocar la pila de producto. Solo el euipo puede tocar la pila de Sprint. Permitid que los Jefes manoseen la pila de producto o que el dueño de producto trastee con la pila de sprint y acabaréis con unos equipos que mandarán Scrum a hacer gárgaras hartos de que no se les deje trabajar ni se confíe en ellos. Scrum es adaptativo, pero eso no quiere decir que todos los días peguemos volantazos: es más bien hacer pequeños movimientos de volante constantemente para mantener al coche en la carretera. Aquí es donde viene bien la historia de las gallinas y los cerdos: distingamos también entre miembros del proyecto y stakeholders.
12. El Scrum Master no es un jefe. Es un “siervo-lider”. No le dice a la gente lo que debe hacer. No divide las tareas entre los miembros del equipo. No acepta o rechaza las funcionaldiades. El equipo es quien decide, y el dueño de producto el que evalua. El Scrum Master sólo debe preocuparse de que el proceso Scrum siga en marcha y de eliminar los impedimentos en el camino del equipo. Tiene más de Coach que de Project Manager.
13. No interrumpir constantemente a los equipos durante los Sprints. Si no confiamos en los equipos y les dejamos trabajar, ¿qué estáis esperando que ocurra? Una terminación anormal de Sprint debería significar que algo muy gordo está pasando en la empresa o en el proyecto. Y si hay que hacer re-priorizaciones, que afecten al próximo sprint en la medida de lo posible, no al que está ahora mismo en marcha.

En fin, probablemente no estén todos los que son, pero son todos los que están. Espero que esta lista os sea de utilidad implantando Scrum, y vigilaré ansioso los twitter del iweekend este fin de semana. ¡Animo tíos!

PD: Para los supersiticiosos, cogéis el punto 11 y lo dividís en “solo el dueño de producto toca la pila de producto” y “solo el equipo toca la pila de sprint”…¡Voila! 14 puntos.

Compártelo

La última vez que hablé de la situación de Inter-Project prácticamente me quejaba de la sensación de “calma chicha” que hay cuando termina un proyecto y esperas a que comience el siguiente. Esta vez realmente me empezaba a hacer falta, ya que ha coincidido un pico interesante de trabajo con que mi mujer se pusiera a todo trapo a preparar unas oposiciones y que me entrasen albañiles en la casa. Pero en fin, gracias a Diox nada que un buen Project Manager no pueda manejar con la mano izquierda…

Los últimos proyectos que he desempeñado han tenido mucho que ver con Scrum, tanto a nivel de desarrollo como en lo que respecta a consultoría y formación, por lo que la certificación me ha venido francamente bien para ponerme las pilas. Aunque sinceramente la certificación ha sido el punto de partida: desde el curso de Madrid, mi interés por Scrum aumentó considerablemente, y aunque ya había leido los clásicos sobre el tema y había utilizado Scrum, durante el último mes he incluido a la lista User Stories Applied, de Mike Cohn (mi nuevo heroe ágil), Peopleware, y varios estudios, artículos y presentaciones de la Scrum-Elite, verbigracia, el anteriormente mencionado Mike Cohn, Jeff Sutherland, Ken Schwaber y Boris Gloger. Entre estos últimos os recomiendo “The Scrum Papers”, disponible para descarga por cortesía de crisp.se, la empresa de Henrik Kniberg (autor de “Scrum y XP desde las trincheras”) y todo el material disponible en Mountain Goat.

Todo esto me ha venido de fábula, ya que de repente y para mi sorpresa y alegría recibí una petición de una empresa bastante grandecita (cotiza en el NASDAQ :-O ) para que les montase un curso de Scrum en un tiempo record (bendito AdWords). Afortunadamente tenía mucho material ya listo para el curso del 15 y 16 en Sevilla, así que entre esto y toda la anterior preparación que os comento creo que ha quedado un curso de fábula. Yo personalmente me lo he pasado en grande, y creo que finalmente hubo bastante inquietud por progresar con Scrum en el futuro. Seguiremos informando.

Siguiendo con los recursos Scrum, tengo pendientes dos cosas: una es este video que encontré ayer en YouTube, dentro de la serie de sesiones Google Tech:

Pues si, el que veis es el mismísimo Padrino del Scrum, Jeff Sutherland.

El otro es el libro (¡en castellano!) de Juan Palacio, posiblemente la persona que más ha hecho por popularizar Scrum en España. Tiene una pinta estupenda y prometo una revisión a conciencia en cuanto lo termine. Ante todo, muchas gracias, Juan

En fin, que aparte del tema Scrum, en el que estoy muy metido, las cosas van marchando francamente bien. He cerrado un bonito proyecto de desarrollo que parece apuntar a posibles ampliaciones en el futuro, comienzo en breve un proyecto de consultoría de un año, estoy con otro proyecto de gestión en paralelo que posiblemente me lleve a Munich dentro de un mesecito…Por cierto, el 26 y 27 estaré en Madrid impartiendo un curso de Scrum. Si alguna empresa quiere montar uno para el 28, 29 o 30… Me vendría muy bien de calendario, gracias…

Ah, y que volvemos a la carga con los blogs, que los tengo abandonados…

Compártelo

• Llegas tarde al Scrum
• Se muy vago sobre lo que hiciste ayer
• Intenta distraer a las personas que tienes al lado
• Se muy técnico sobre lo que hiciste o vas a hacer, de forma que nadie entienda lo que dices
• Llevas cinco días atascado en la misma tarea
• Intenta hablar lo máximo posible sobre lo que hiciste ayer o vas a hacer hoy
• Interrumpe constantemente al resto mientras hablan
• Eres el Scum Master. Debes conducir el Scrum Diario

Hay que ser muy malo para diseñar un ejercicio así, la verdad…Sólo un sádico lo emplearía en su curso…

Vía AgileSoft, web.mac.com

Compártelo

Una de las cosas más duras que tiene Scrum como metodología son los Scrum Diarios. Como sabéis, son reuniones rápidas que se realizan todos los días, idealmente en el mismo sitio a la misma hora, y en la que cada miembro del equipo comenta qué ha estado haciendo desde ayer, qué piensa hacer hoy y qué impedimentos encuentra en su tarea. El Scrum Master utiliza esta información para poder identificar y eliminar los riesgos que existan en el Sprint y para poder realizar un seguimiento del avance (aunque el equipo sigue siendo responsable de actualizar la pila de Sprint).

Como decía, esta es una de las partes más duras, y eso que se trata de dedicar cinco a quince minutos al día únicamente: parece un precio muy pequeño si con ello reducimos la carga de gestión, los informes que se deben generar cada dos por tres y a cambio ofrecemos una visibilidad superior sobre el proyecto, al tiempo que aprovechamos para reforzar la sensación de equipo y mejorar la comunicación. Pero la verdad es que pasada la novedad de los primeros días siemrpe surge quien no entiende la utilidad de estas reuniones, y las califica de un “esfuerzo” o una “pérdida de tiempo”. En otros casos comienzan a aparecer otras prioridades (”tengo una reunión con Marketing”, “mañana no puedo, que llegaré tarde”, “ahora mismo me pillas en medio de algo importante”)…

En este video tenéis a Stacia Broderick, de quien tuve el placer de aprender en el seminario Certified ScrumMaster de Madrid hace poco, interpretando con varios Certified Scrum Trainer lo que sería el “Scrum Diario del infierno”, en el que cada uno va por libre, se interrumpen unos a otros, llegan tarde, hablan por teléfono… Si vuestros Scrum diarios se parecen a esto o no los estáis haciendo en absoluto, cuidado: estáis caminando por la senda del desastre

Compártelo

- ¿Tu eres Rodrigo Corral? ¡Jo macho! Yo te leo…
- ¡Ah, si! Tu eres el que escribió lo del ScrumMaster Miyagui… Te leí también…

Como dos estrellas mediáticas, vamos… .

En fin, en serio, ha sido una auténtica pasada y este mismo momento I’m high on Project Management. Tengo ganas de iniciar varias líneas de trabajo relacionadas con Scrum que se me han ido ocurriendo durante los últimos tiempos y que he terminado de madurar durante el curso. Por supuesto os mantendré puntualmente al corriente.

Algunas de las conclusiones rápidas del curso:

• Scrum no es sólo para proyectos software o IT: puede adaptarse fácilmente a cualquier clase de proyecto en el que haya una lista de requisitos a cumplir y un equipo (o varios) de desarrollo.
• Scrum no es una moda: es una filosofía, una forma de pensar. Es Agile aplicado a la gestión de proyectos. Es sobre las personas, ser más eficiente, trabajar en equipo, colaborar con el cliente, comprometerse, entregar…
• No puede compararse la dificultad de transmitir un concepto complejo a las bravas frente a comentar con una persona aquello que acaba de experimentar por si misma. Los ejercicios del curso fueron estupendos en ese sentido, y estoy muy determinado a ser mucho más socrático en el futuro a la hora de guiar equipos de proyecto
• Todos los Jefes de Proyecto nos enfrentamos más o menos a los mismos problemas, y aunque cada caso requiere una aproximación distinta en la inmensa mayoría existen soluciones y gente que las ha puesto en práctica con éxito
• Los jueves por la noche sigue siendo imposible tapear en Almendro 13, pero la Musa de la Latina sigue estando muy bien…

En cualquier caso, no puedo resistirme a poner esta tira:

Espero que, al menos en nuestro caso, tardemos mucho en olvidar lo mucho que hemos aprendido juntos.

Compártelo

Tu Scrum “sí”…Vale. Tu Scrum “no”…Vale. Tu Scrum “supongo”, tarde o temprano…¡Chof! Aplastado como uva.”

Supongo que eso fue lo que le ocurrió a Chuidiang en su fallido intento por implementar Scrum. Tal como comenta Rodrigo Corral en el más que recomendable blog sobre programación “La masa, el ladrillo, la bota, el bocadillo…“, nadie dijo que Scrum no requiriese un esfuerzo. Y es que uno lee cosas como Scrum en cinco minutos o explicando Scrum a mi abuela y parece que esto es coser y cantar, pero no se debe confundir simplicidad con inmediatez: si uno se aventura por las aguas de Scrum sin contar primero con la experiencia necesaria en gestión de proyectos se puede acabar convirtiendo en el Scrum Master Jar Jar Binks (lectura MUY recomendada a la que llegué vía Navegápolis, igualmente recomendable).

Y no quiero decir que los documentos anteriores no sean estupendos (yo los tengo guardados y los uso). Pero no es lo mismo leer un artículo sobre física cuántica que ponerse a acelerar partículas al frente del CERN. En este sentido, a los que queráis profundizar en el uso y ventajas de Scrum os recomiendo fundamentalmente dos lecturas (aunque posiblemente no descubra nada a los que ya estáis metidos en el ajo): Agile Project Management With Scrum de Microsoft Press es el clásico, y tiene una definición muy concisa de los procesos y reglas de Scrum. No obstante, la parte relativa a las anécdotas y experiencias implementando Scrum es un poco oscura para mi gusto, quedándose en la superficie del proceso y no entrando en los detalles del día a día. En ese sentido es muchísimo más revelador el documento Scrum and XP from the trenches que, además, podéis descargar grauitamente.

Este último es sin duda magnífico, ya que está imbuido de la misma simplicidad que destila Scrum pero además te muestra al detalle cómo implementaron Scrum en una organización real, justificando cada una de las decisiones. Por ejemplo, comentan que sus Sprint duran tres semanas, y explica que es la longitud óptima a la que llegaron después de hacer varias pruebas, en las que comprobaron que si los sprint eran muy cortos, como prefieren los dueños de producto, se conseguían más entregas, más ciclos de realimentación pero también un mayor costo en términos de gestión (más reuniones de sprint, más documentación). En cambio, si los sprints eran muy largos, como prefieren los desarrolladores, había más tiempo para desarrollar, documentar y probar, además de tener menor carga de gestión, pero a cambio los desarrollos eran menos ágiles. Al final, comentan, la longitud del Sprint es un compromiso entre desarrolladores y dueño del producto, y ellos llegaron al compromiso de las tres semanas. Finalmente recomienda que, una vez escogida una longitud de Sprint, esta se mantenga inalterable para todos los equipos, de forma que se vaya formando a los mismos y acostumbrándolos a trabajar en esos plazos. Así es más fácil estimar qué se puede hacer en el Sprint y qué se saldría de las capacidades reales del equipo.

Bien, eso es gestión de proyectos en estado puro. Es incluso más, entra en el ámbito de la cultura corporativa y la madurez de las organizaciones en la gestión de proyectos. Y todo ello sin complejas fórmulas, tremendas herramientas ni farragosas burocracias. Además está mucho más justificado que el “los sprints duran 30 días y uno debe mantener el plazo” del libro de Microsoft. A lo largo del libro explican desde “trucos” para gestionar las reuniones de sprint hasta los campos que debería tener una lista de tareas de sprint o de producto, pasando por cómo mantener un “cuadro de mandos” físico del proyecto y como interpretarlo a simple vista. Genial.

Otra cosa que me encanta de este último documento es el uso que hacen de los paneles en las paredes, las tarjetas adhesivas y las pizarras. A lo largo de mi experiencia como gestor de proyectos, he encontrado que una pizarra en blanco y un taco de post-its son de las herramientas más poderosas con las que uno puede contar, y no estoy exagerando. Lo que pasa es que, y de nuevo entroncamos con Scrum, su elegante simplicidad hace que muchos no se las tomen en serio y piensen que uno está jugando a los consultores y perdiendo el tiempo cuando encierra al equipo a cal y canto y entre todos se dedican a pegar post-its por todas las paredes como si quisieran cambiar la decoración del edificio.

En cualquier caso, ¿Está Scrum orientado sólo a los desarrollos de software? ¿Podría usarse Scrum como método de productividad personal, en una especie de “Scrum de a uno“? ¿Son equivalentes el perfil de ScrumMaster y el del ProjectManager? ¿Merece la pena la certificación ScrumMaster? Creo que son preguntas interesantes a las que iré dedicando algo de tiempo en el futuro.

Compártelo