Charla en Pamplona
Escrito el 28 de Noviembre de 2009 a las 13:13
Ayer viernes dí una charla-desayuno en Pamplona invitado por mis clientes y a pesar de ello amigos de Biko2 
. Asistieron mayoritariamente gestores de IT de empresas como (así de memoria), Caja Navarra, Microsoft CEIN, Aranzadi, Tracasa y representantes del Gobierno de Navarra y el Gobierno Vasco (por cierto, gracias a los que vinísteis de lejos).
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 ):
Equipos o cirujanos
Escrito el 25 de Noviembre de 2009 a las 11:16
Me encuentro ultimamente con algunas organizaciones que han ido creciendo desde equipos pequeños de personas y, conforme han ido añadiendo miembros al área de desarrollo, han ido evolucionando hacia un modelo de un proyecto - una persona. Se trata (espero) de una adaptación del “paradigma del cirujano estrella” publicado por IBM en los 60-70, en el marco del desarrollo de OS360 (¿alguien ha leido The Mythical Man Month? ). Según este modelo, los proyectos más productivos que IBM había detectado eran aquellos en los que existía un “cirujano estrella” que tenía en su mente la arquitectura y el diseño y realizaba toda la programación rodeado por un equipo de ayudantes (documentadores, testers, administradores…). Según las mediciones de IBM, un programador estrella aportaba 10 veces la productividad de un programador medio. Pilar Jericó, en “Gestión del Talento” (citada por Juan Palacio en su libro, si no recuerdo mal) va más lejos y afirma que en el mundo tecnológico los mejores lo hacen entre 50 y 100 veces mejor que la media, y la cifra aumenta conforme la tecnología se hace más compleja.
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?
Releyendo a los clásicos
Escrito el 24 de Noviembre de 2009 a las 10:43
La perspectiva de los años siempre aporta nuevas lecturas a los buenos libros. Incluso si son pocos años, si han sido intensos aportarán matices, vivencias, experiencias, nuevos paradigmas… Al final, nosotros leemos los libros, pero de alguna forma, como dice Terry Pratchett, el libro también nos lee a nosotros. A veces es como encontrarse con un viejo amigo: las cosas no son las mismas, y probablemente no sientas esa conexión tan profunda e intensa que había hace tiempo, pero también nos sirve para vernos de alguna manera reflejados en el espejo de su perspectiva y para comprobar que, a pesar de todo, las raices siguen ahí, y que siempre puedes contar con esa persona (ese libro, en este caso).
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.
¿Quién dirige y quién paga?
Escrito el 20 de Noviembre de 2009 a las 19:57
El cliente, of course. Fin del artículo, estoy muy liado.
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.
Crónica del Agile Open Spain
Escrito el 30 de Octubre de 2009 a las 19:38
Los que me seguís hace tiempo ya sabéis que cuando los posts escasean pueden ocurrir dos cosas: hastío creativo o pico de trabajo. Afortunadamente, (bendito sea el FSM), en este caso se trata de lo segundo. Pero aunque estoy recién bajado del avión despues de dos días muy productivos en Canarias y ya casi estoy haciendo otra vez la maleta para Málaga (pasando por Madrid), tengo que sacar unos minutillos para contar un poco como fue lo del Agile Open Spain del 23-24 de Octubre, que para algo lo patrocinabamos…
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?
Curso Scrum Madrid, 12-13 Nov. 2009: lugar de celebración
Escrito el 30 de Octubre de 2009 a las 19:23
Como sabéis, el 12 y 13 de Noviembre celebramos un curso de Scrum abierto en Madrid. Aun quedan algunas plazas, por lo que si estáis interesados os recomendamos que os pongáis en contacto cuanto antes con info@proyectalis.com.
Finalmente el curso se celebrará en el hotel Barceló Torre Arias, en la calle Julián Camarillo 19-21.
Steve Johnson on Product Management and Agile (a.k.a. ‘Friends build products, enemies build documentation’)
Escrito el 28 de Septiembre de 2009 a las 12:41
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)?
El horno de las magdalenas
Escrito el 14 de Septiembre de 2009 a las 14:57
Esta es una historia que cuento en mis cursos y suele gustar bastante. Tanto que ya me han pedido alguna vez que la escriba e incluso tengo un dibujo dedicado que reproduzco al final del artículo (gracias, Juanjo, iremos poniendo el resto poco a poco ). La cosa va así:
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 ).
Agile Open Spain, Madrid 23-24 de Octubre 2009
Escrito el 8 de Septiembre de 2009 a las 11:59
Con los objetivos de difundir las metodologías ágiles en España (Scrum, eXtreme Programming. Lean Software Development) y compartir experiencias, el viernes 23 de octubre por la tarde y el sábado completo tendrá lugar el primer Agile Open Spain en las instalaciones de la Escuela Universitaria de Informática en el Campus Sur de la Universidad Politécnica de Madrid. Ctra Valencia Km.7. 28031 Madrid (Localización Google Maps)”
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.
Curso de Scrum en Málaga
Escrito el 8 de Septiembre de 2009 a las 11:54
La Asociación de Empresas de Base Tecnológica EBTEcnos, en colaboración con Proyectalis, organiza los días 5 y 6 de Noviembre en Málaga el “Curso Formación en la Metodología Efectiva de Gestión de Proyectos Scrum”, con el objetivo de poner al alcance de las Empresas de Base Tecnológica, una metodología que permite el desarrollo ágil de productos y permite la gestión de proyectos. El precio es muy asequible: 260€ para socios y 290€ para no asociados, por lo que puede ser una buena oportunidad para empresas que no puedan adaptarse a otros cursos o convocatorias. Más información en la propia web de EBTecnos.
Nuevo curso de Scrum: Madrid, 12-13 noviembre 2009
Escrito el 2 de Septiembre de 2009 a las 10:04
Seguimos recibiendo de cuando en cuando correos de gente interesada en cursos de Scrum que no pueden plantearlos en sus empresas por quorum, presupuesto u otras razones, o bien que tienen interés a título personal, por lo que vamos a convocar otro curso abierto en Madrid los próximos días 12 y 13 de Noviembre (2009… Pongo el año porque luego me encuentro gente interesándose por “el curso de octubre” y es que han visto el anuncio del año pasado… Habrá que mejorar esto .
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
Valores Corporativos
Escrito el 1 de Septiembre de 2009 a las 17:37
A mediados de Agosto enlazó Diego en Externalidades una presentación de Netflix sobre sus valores y cultura corporativa. El post, al parecer, pasó sin mucha pena ni gloria, y no lo merecía, porque la presentación es una joya.
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
Video de la charla “contratos Ágiles”
Escrito el 10 de Junio de 2009 a las 14:44
Los amigos de Autentia han subido ya a su canal de Youtube los videos de la charla que celebramos la semana pasada. Como muestra un botón:
Enjoy!
Contratos Ágiles
Escrito el 7 de Junio de 2009 a las 8:01
Como prometí el miércoles pasado en la charla de Autentia y Agile Spain, aquí dejo la presentación usada para la charla de contratos Ágiles. Me lo pase fráncamente bien, teniendo en cuenta que el tema es un poco árido en comparación con otros, y me encantaría tener oportunidad para repetirlo.
Permanezcan atentos a sus pantallas, porque los chicos de Autentia prometen subir el video de la charla… 
Utopías y cambios culturales
Escrito el 29 de Mayo de 2009 a las 9:08
Me pasa JM Beas una discusión abierta en foro-ágiles a raiz de un planteamiento de mis charlas / cursos:
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…
-
Artículos recientes
-
Categorías
-
Archivos
- Marzo 2012
- Febrero 2012
- Enero 2012
- Diciembre 2011
- Octubre 2011
- Mayo 2011
- Abril 2011
- Marzo 2011
- Febrero 2011
- Noviembre 2010
- Octubre 2010
- Septiembre 2010
- Agosto 2010
- Mayo 2010
- Abril 2010
- Marzo 2010
- Febrero 2010
- Enero 2010
- Diciembre 2009
- Noviembre 2009
- Octubre 2009
- Septiembre 2009
- Agosto 2009
- Julio 2009
- Junio 2009
- Mayo 2009
- Abril 2009
- Marzo 2009
- Febrero 2009
- Enero 2009
- Diciembre 2008
- Noviembre 2008
- Octubre 2008
- Septiembre 2008
- Agosto 2008
- Julio 2008
- Junio 2008
- Mayo 2008
- Abril 2008
- Marzo 2008
- Febrero 2008
- Enero 2008
- Diciembre 2007
- Noviembre 2007
- Octubre 2007
- Septiembre 2007
- Agosto 2007
- Julio 2007
- Junio 2007
- Mayo 2007
- Abril 2007
- Marzo 2007
- Febrero 2007
- Enero 2007
- Diciembre 2006
- Noviembre 2006
- Octubre 2006
- Septiembre 2006
- Agosto 2006
-
Blogroll
Bienvenido
Presión Blogosférica es un blog en el que almaceno mis reflexiones sobre negocios, empresas, emprendedores, gestión de proyectos, Internet... Pero también es un espacio plural en el que discutir sobre dichas ideas. Puedes dejar un comentario o contactar conmigo en angel.medinilla (arroba) presionblogosferica.net. También puedes seguir el blog a través de su Feed RSS
¿Un café?
Buscar:
Suscriptores:
Kisei Dojo Aikido
Pastafari!
Tags
2.0 3G actitud Agile Agile Management agile spain apple autentia autonomos bancos barcelona Biko2 blog Blogs burocracia business angel C++ calidad cambio CEIN charla charlas clientes coaching colaboración comentarios comunicación conciliación conferencia congreso consejos consultoras consultores consultoría contactos contratos contratos ágiles control corporate culture costes Creatividad crecimiento crisis crédito CSM cultura cultura corporativa curriculum curso curso de scrum curso madrid cursos curso scrum diversión dueño de producto EBE07 economía einstein ejercicios empleados empleo Emprendedores empresa empresarios empresas encuesta equipos España estrategia estudiantes Eventos exito externalización facturas feedback financiación finanzas flickr ford Formación fracaso funcionarios funky business fábulas gente GMail Google GTD horarios ideas impuestos inglés Iniciador innovación IT iweekend jefe de proyecto Jeff sutherland jornada laboral kaizen Kanban karma lean Libros liderazgo Linus Linux liquidez Madrid Marketing Matrix mejora mercado mercado laboral mercados metodologías microsoft mision mochila motivación muebles málaga navidad negociación negocio networking oferta ofertas oficina oficinas ONG Open Space outsourcing pagos pamplona pareto paro perseverancia personal personas plan de negocio planificación estratégica PMBOK PMI PMP power point precios presentaciones presentación proactividad problemas productividad producto programación programadores project management proveedores proyectalis proyectos pruebas rendimiento rentabilidad retrospectivas riesgo salarios scrum scrumban Scrum Master selección sevilla silicon valley sistemas SL Slideshare social software start-up startup subvenciones tecnología teletrabajo tests TI tiempo tim ferris toyota transparencia twitter usuarios VC ventas venture capital viajes video videos vision wii xp xp2008 zona de confort
Que se dice por aquí:
- Sonia: Buenas tardes Ángel, he visto en on-line tu curso “Contratos ágiles: Vendiendo Scrum a tus...
- 420 college: 420 College is the premier medical marijuana school in California. We’ve been helping people find...
- Jose: Ayer acabo de despedir a un cliente, a parte de los peores “un impagado”. Con respecto a lo que...
- Miguel Angel: Interesante, especifico, me pareces una persona interesante, leí sobre tu blog por temas de Scrum,...
- Raúl Hermosilla: Me pareció interesante este micro resúmen acerca de los paradigmas. El tema es transversal en...
Qué se dice por ahí:
- La respuesta a tus preguntas sobre Internet y las tecnologías.: Feedback acerca del curso “Gestión de...
- Consultoría y Excelencia: Lo que cobran los consultores
- La Pastilla Roja: Deuda Gerencial
- Aquí sigue sobrando gente...: “CRITEO-300×250R 43;, 300, 250); 1 meneos menéalo Aquí sigue sobrando...
- No Más Hype: Empresa maltrata jugador. Jugador maltrata empresa. Repetir
Fotos
www.flickr.com
|
