LeanCamp Barcelona
Escrito el 27 de Enero de 2012 a las 11:18
El próximo sábado 11 de Febrero estaré por el LeanCamp Barcelona dando una charla sobre el lado humano de Lean… En Inglés, of course 
. Habrá ponencias y debates muy interesantes sobre Lean Startup, UX, Agile, Customer Development y temas relacionados. Además, es un evento conectado internacionalmente (hay ediciones en Nueva York, Londres, San Francisco, Amsterdam…).
Para que vayáis calentando motores, aquí tenéis la charla sobre Lean Startup que dí en Polonia hace unos meses:
Angel Medinilla from e-nnovation on Vimeo.
Presentaciones XP2011
Escrito el 12 de Mayo de 2011 a las 10:16
¡Hola chic@s! Un par de líneas para dejar links a las presentaciones sobre gestión Ágil y Scrumban que he podido celebrar en el XP2011. Lo siento, están en inglés, pero son bastante autoexplicativas, así que espero que os sean de utilidad. En el blog en inglés tengo algo más de información sobre las sesiones, por si estáis interesados
Recursos del curso de Coaching de Equipos Ágiles
Escrito el 21 de Abril de 2011 a las 10:09
Los días 4, 5 y 6 de Abril tuvo lugar en el ámbito de la ScrumWeek de Madrid nuestro curso de Coaching de Equipos Ágiles. La verdad es que tuvo una acogida espectacular y esperamos poder realizar más sesiones abiertas de este curso que típicamente celebramos en empresas.
Eduardo Zamora, de mis clientes y aun así amigos de Mobivery, se ha pegado la currada de recopilar algunos si no todos los recursos que mencionamos en este curso, que pongo aquí a vuestra disposición por si andáis en busca de alimento cerebral (he marcado en negrita los imprescindibles) 
. En nombre de todos, ¡gracias Edu!
Libros:
- “Emotional Intelligence”, by Daniel Goleman
http://www.amazon.com/
- “Drive: The Surprising Truth About What Motivates Us”, by Daniel Pink
http://www.amazon.com/Drive-
- “Crossing the Chasm: Marketing and Selling Technology Project”, by Geoffrey A. Moore
http://www.amazon.com/
- “Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency”, by Tom DeMarco
http://www.amazon.com/Slack-
- “Flow”, by Mihaly Csikszentmihalyi
http://www.amazon.com/Flow-
- “PeopleWare”, by Tom DeMarco and Timothy Lister
http://www.amazon.com/
- “Delivering Happiness: A Path to Profits, Passion, and Purpose”, by Tony Hsieh
http://www.amazon.com/
- “The 7 Habits of Highly Effective People”, by Stephen Covey
http://www.amazon.com/Habits-
- “Management 3.0: Leading Agile Developers, Developing Agile Leaders”, by Jurgen Appelo
http://www.amazon.com/
- “No Miedo”, by Pilar Jerico
http://www.casadellibro.com/e-
- “La Nueva Gestión del Talento: Construyendo Compromiso”, by Pilar Jerico
- “Good to Great: Why Some Companies Make the Leap… and Others Don’t”, by Jim Collins
http://www.amazon.com/Good-
- “The Five Dysfunctions of a Team: A Leadership Fable”, by Patrick Lencioni
http://www.amazon.com/Five-
- “Coaching Agile Teams: A Companion for ScrumMasters, Agile Coaches, and Project Managers in Transition”, by Lyssa Adkins
http://www.amazon.com/
- “Tribal Leadership”, by Dave Logan, John King and Halee Fischer-Wright
http://www.amazon.com/Tribal-
- “Tribes: We Need You to Lead Us”, by Seth Godin
http://www.amazon.com/Tribes-
- “Fukowski, memorias de un ingeniero”, by Alfredo de Hoces
http://www.alfredodehoces.com/
- “Maverick: The Success Story Behind the World’s Most Unusual Workplace”, by Ricardo Semler
http://www.amazon.com/
- “The Seven-Day Weekend: Changing the Way Work Works”, by Ricardo Semler
http://www.amazon.com/Seven-
- “How the Brain Learns”, by David A. Sousa
http://www.amazon.com/How-
- “Training From the Back of the Room!: 65 Ways to Step Aside and Let Them Learn”, by Sharon L. Bowman
http://www.amazon.com/
- “Who am I? The 16 Basic Desires that Motivate Our Actions and Define Our Personalities”, by Steven Reiss
http://www.amazon.com/Desires-
Articles
- “We Tried Baseball and it Didn’t Work”, by Ron Jeffries
http://xprogramming.com/
- “Top Ten Ways To Be Happy At Work”, by Susan M. Heathfield
http://humanresources.about.
Videos
- “El Coeficiente de Optimismo”, by Emilio Duró
http://vimeo.com/19994624
http://vimeo.com/19996142
- “The First Follower”
http://www.youtube.com/watch?
- “How Open Source Projects Survive Poisonous People”
http://www.youtube.com/watch?
- “Clientes en situaciones de la vida real”
http://www.youtube.com/watch?
- “His Holiness the Dalai Lama Speaks: Peace and Prosperity”
http://www.amazon.com/His-
- “Bill Clinton: The Power of Eye Contact” (Éste lo comenté yo :P)
http://www.fourhourworkweek.
- “Steve Jobs Stanford Commencement Speech 2005: Stay Hungry, Stay Foolish”
http://www.youtube.com/watch?
- “Abraham Lincoln - Gettysburg Address”
http://www.youtube.com/watch?
- TEDTalks
http://www.youtube.com/user/
- TEDex
http://www.ted.com/tedx
Movies
- “Office Space”
http://www.imdb.com/title/
- “Gandhi”
http://www.imdb.com/title/
Slides
- “Círculos viciosos” (transparencías de Proyectalis vistas en el curso de “Coaching de equipos ágiles”)
- “Netflix Corporate Culture”
http://www.slideshare.net/
- “Shock Therapy” (Implementación corporativa de Scrum en MySpace, dónde existían equipos que no estaban convencidos con la metodología)
http://rapidscrum.com/shock.
Series
- SuperNanny
http://abc.go.com/shows/
- El encantador de perros
http://www.cesarsway.com/
El Rol de Scrum Master / lider de equipo
Escrito el 26 de Marzo de 2011 a las 11:00
Esta semana había una discusión interesante en Agile Spain y me dió por resumir lo que, de alguna forma, cuento en los cursos de Scrum sobre qué significa para mi el rol de Scrum Master. Creo que ha quedado apañado, así que lo recojo aquí para que no se me pierda
El problema cuando hablamos del SM es que hay muchos tipos de SM. Para mi (o mejor dicho, en la escuela de pensamiento en la que yo milito) el SM no es un estado, sino un camino. Este camino tiene varios estadíos:
- “Scrunch Master” - El SM convoca las reuniones y poco más. Como no tiene mucha dedicación, suele ser alguien que trabaja en el equipo y, a ratos, hace de SM. Quizás actua como portavoz del grupo. Se habla de rotar el puesto de SM entre los miembros del equipo.
- “SM Mamá”: El SM comienza a tomar decisiones para el equipo en lo relativo a Scrum / Agile y a los impedimentos a los que el equipo se enfrenta. Elimina impedimentos para el equipo en la forma de “Ya lo hago yo”. Si el equipo o el P.O. no cumplen con alguna de sus responsabilidades también las asume él (”ya reporto yo en el tablón”, “ya escribo yo las historias de usuario”). Mayordomo y secretaria del equipo “para que el equipo no se desconcentre y no pierda el tiempo”, línea de pensamiento preliminar en las implementaciones que, si bien puede ser necesaria al principio, es peligrosa a largo plazo, ya que puede conducir a que el equipo no sea convocado a las reuniones por lo mismo. Interlocutor / Interfaz del equipo (misma consideración respecto a peligrosidad en el largo plazo). Comienza a moderar las reuniones. Es un avance respecto al Scrunch Master, pero no debería quedarse aquí.
- Scrum Master: Facilita y dinamiza las reuniones. Actúa de formador y mentor: enseña a cada uno a ejecutar su papel dentro de Scrum. Evangeliza en la organización y en el equipo sobre las prácticas ágiles, no solo Scrum (programación por parejas, refactorización, TDD, propiedad colectiva de código, estimación en puntos, planning poker, Kanban…). Es un agente del cambio organizativo. Es un lider del equipo. Mantiene y ejecuta con el equipo un plan de mejora continua. Diagnostica problemas y propone soluciones.
- Scrum Sensei / Agile Coach: Maestro de la escucha. Nunca decide ni sugiere soluciones: hace preguntas. Pero son las preguntas correctas. Respeta las decisiones del equipo, pero hace al equipo responsable de ellas. Ayuda al equipo a identificar problemas, descubrir soluciones e implementarlas por ellos mismos. Trabaja aspectos como el trabajo en equipo, la comunicación, la colaboración… Bajo su influjo emergen equipos de alto rendimiento con el máximo nivel de compromiso, motivación y rendimiento.
DISCLAIMER: utilizar la estrategia del Agile Coach con un equipo principiante solo conduce al desastre. Al igual que el SM, el equipo debe andar un camino.
ScrumWeek - Madrid, 4-8 Abril
Escrito el 8 de Marzo de 2011 a las 14:41
Un par de líneas para avisaros de que queda menos de un mes para la celebración de la ScrumWeek 2011 en Madrid, uno de los mayores eventos formativos y divulgativos en torno a las metodologías Ágiles organizado en España hasta la fecha. Organizado por Proyectalis y Plain Concepts, las dos empresas líderes en la prestación de servicios Ágiles en España, la ScrumWeek incluye cursos, seminarios, charlas y eventos de networking incluyendo:
- Curso de certificación Professional Scrum Developer (PSD)
- Curso de Scrum
- Curso de Coaching de Equipos Ágiles
- Curso de Arquitectura Ágil
- Seminario de Gerencia Ágil (Agile Management)
- Seminario sobre testing unitario
- Scrum Clinyc, con Ángel Medinilla y Rodrigo Corral
- Sesiones gratuitas sobre Cultura Coporativa
- Sesiones gratuitas sobre Visual Studio
Es una oportunidad inmejorable para poder enviar a formación a personas de vuestra empresa que no pudieran hacer los cursos de Scrum en su día, así como para perfeccionar a los profesionales encargados de las metodologías ágiles en vuestra empresa (gerentes, Scrum Masters…) o simplemente refrescar conocimientos, resolver dudas e impedimentos y conocer de primera mano el “estado del arte” en la implementación de Agilel en la empresa
Tienes toda la información en www.scrumweek.com y puedes realizar la compra de plazas directamente en scrumweek.eventbrite.com. Te agradeceremos que divulgues esta información aquien creas que pueda estar interesado o pueda beneficiarse de esta convocatoria tanto dentro de tu empresa como a través de Twitter, blog…
ScrumWeek
Escrito el 24 de Febrero de 2011 a las 12:33
La semana del 4 al 8 de Abril Plain Concepts y Proyectalis organizamos la ScrumWeek, una semana de formación con tres tracks separados en los que habrán sesiones sobre Scrum, Coaching de equipos Ágiles, Agile Management (gerentes Ágiles), cultura corporativa Ágil, un Scrum Clinic con Rodrigo Corral y conmigo, unit testing, visual studio, certificación PSD… En definitiva, creo que es una iniciativa bastante pionera en España y una muy buena oportunidad para todos los que ya conocéis los cursos de Proyectalis y de Plain Concepts y queréis ampliar conocimientos o tenéis a alguien en vuestra empresa que se ha quedado “rezagado” y podría ser interesante poder mandarle a un curso de refresco .
Los precios son también bastante competitivos, incluyendo varias sesiones gratuitas como las de Cultura Corporativa o las de Visual Studio Ágil, y hay plazas limitadas (que ya se están vendiendo), por lo que os animo a que si estáis interesados lo arregléis con vuestras empreasas cuanto antes. Ah, en este sentido, hay cursos de sólo mañanas (como por ejemplo el de Coaching de equipos Ágiles), con lo que debería ser más fácil convencer a vuestra empresa que os deje ir… Si vivís en Madrid, claro 
.
¡Os esperamos!
Agile Lean Europe
Escrito el 24 de Febrero de 2011 a las 12:12
Si estáis interesados en Agile y en Lean, vivís en Europa y habéis estado viviendo en una cueva informativa durante la última semana tal vez se os haya pasado el nacimiento de una nueva red de profesionales y pensadores de Agile y Lean en Europa de la mano de Jurgen Appelo.
El propósito de esta red todavía se está discutiendo, pero con toda probabilidad incluirá el proporcionar una mayor visibilidad del proceso de transformación Ágil y Lean en Europa, actuar como centro de soporte, recursos y colaboración para todos los profesionales de Agile y Lean y organizar algún tipo de gran evento europeo en el que todos los que trabajamos en este tipo de entornos podamos intercambiar información (aunque algunas ya han apuntado que eventos existentes como la XP o Lean Kanban Europe podrían proporcionar este marco).
Ahora mismo la red se ha creado en LinkedIn y, en pocos días, ha alcanzado casi 350 miembros. ¡Enhorabuena, Jurgen ! La verdad es que espero que grandes cosas y grandes ideas surjan de esta iniciativa, y tengo muchas ganas de comentarlas con varios de los miembros de esta red en el próximo XP2011 (Madrid, Mayo).
Tomates en el campo
Escrito el 20 de Febrero de 2011 a las 19:29
En el pasado he utilizado muchas veces la expresión “team building”. Pero ya no. Me he dado cuenta de que los equipos no se construyen: se cultivan. Uno selecciona cuidadosamente las semillas (contratación), prepara y abona el terreno (entorno), quita piedras y hierbajos (impedimentos), riega la planta (recursos), la protege de los pájaros (defender), la refuerza con un tutor si se tuerce (liderazgo, alineamiento) e incluso le habla un ratito todos los días (coaching)… Pero con todo y con eso no tienes garantías de obtener un tomate perfecto. Eso sí: mejoras drásticamente las posibilidades.
Siendo el tomate una planta, en teoría debería poder encontrar de vez en cuando un lustroso tomate en medio del campo. Al fin y al cabo solo hace falta que una semilla encuentre el sitio correcto y no sea atacada. Pero curiosamente nunca he encontrado un tomate salvaje, y sí muchos tomates espléndidos en huertas (ay que ganas tengo de veranear en Conil otra vez… ).
Con la metáfora quiero decir que las Culturas Corporativas excepcionales, Ágiles, de alto rendimiento, de mejora continua… pueden surgir por azar, porque se den los factores adecuados de forma puramente casual, pero generalmente cuando estudias una de estas culturas lo más probable es que haya existido un esfuerzo, consciente o no, por parte de los creadores de la empresa, los líderes o de todos sus integrantes. Este esfuerzo pasa habitualmente por adquirir una consciencia de grupo, honrar unos mismos valores, compartir un propósito, comunicar agresivamente y normalizar una serie de costumbres, prácticas y maneras. Y pasa también por purgar abiertamente a todos los agresores, es decir, aquellos que van contra los valores y formas acordados entre todos bien abiertamente o bien en la variedad pasivo-agresiva. Puede que “manzanas podridas”, como los catalogaba mi amiga Ana María en los comentarios del último post, puede que simplemente jetas o vagos… O puede que sean personas perfectamente válidas en otro entorno pero se sientan perdidas en este.
Dedicaré tiempo a la fumigación de pulgones, pero ahora mismo me gustaría continuar reflexionando sobre la selección de semillas y la preparación del terreno. Lamentablemente, en la inmensa mayoría de los casos que conozco el terreno y las plantas ya existían cuando el jardinero llegó a la empresa, y uno tiene que empezar a trabajar con lo que tiene (como decía Sergio)… Espero poder reflexionar también sobre ello.
Cultura Corporativa
Escrito el 6 de Febrero de 2011 a las 19:38
La frase “la cultura se desayuna a las estrategias” (culture eats strategy for breakfast) la atribuyen tanto a Peter Drucker como a Mark Fields. El primero, Drucker, es considerado “el hombre que inventó el management”, aunque suele afirmar que el 90% de las cosas a las que llamamos Management consisten en impedir a la gente poder desempeñar su trabajo 
. El segundo, Fields, es vicepresidente ejecutivo de Ford y alma mater del programa “Way Forward” que implementó un cambio drástico en la compañía. Cualquiera de los dos me vale para iliustrar lo que quiero contar. Y lo que quiero contar es que, como ya dije hace tiempo en este blog, todas las iniciativas que diseñemos, por muy acertadas y estupendas que sean, serán irremisiblemente arrasadas si no están en consonancia con la cultura corporativa.
¿Y qué es esto de la Cultura Corporativa? Ese es el primer problema, que es algo muy intangible y por tanto complicado de definir. Complicado, que no imposible. Afortunadamente todo un nuevo cuerpo de conocimiento está emergiendo en torno a este concepto y su ilimitado potencial. Por sentar algunas bases, digamos que la cultura corporartiva engloba lo que los miembros de la empresa valoran, su código de conducta y su estilo de comunicación y colaboración.
Cuidado: el código de conducta de la empresa y los valores de la empresa rara vez coinciden con la cultura corporativa. Esto parece un perogrullo, pero es tan simple como que no basta con enmarcar una rimbombante y altamente intercambiale declaración de valores y decirle a la gente “esta es nuestra cultura corporativa”. No funciona así. El hecho de que esté repetidamente comprobado que no funciona así no ha hecho desistir a muchos de implementar su propia versión del “cargo cult” copiando las declaraciones de valor o los códigos de conducta de grupos altamente exitosos en el vano convencimiento de que “si nosotros también ponemos una sala de guitar hero, seremos como Google”.
Reconoces una cultura corporativa de alto rendimiento en cuanto la ves. Grupos de gente concentrada, gente disfrutando de lo que hacen, sonrisas, actitud de “podemos con todo” y “hagámoslo”, resultados sobresalientes, identificación con el propósito de la compañía, compromiso, sensación de propiedad, intolerancia y firmeza hacia el que va a remolque del resto, responsabilidad… Y por contra, una cultura corporativa caducada huele desde antes de entrar por las puertas: caras de disgusto, bajas por depresión, ventanillas funcionariales kafkianas, calentamiento de asientos, cafelitos eternos, “esa no es mi responsabilidad”, “a mi dámelo mascadito”, “no me pagan por pensar”, “eso no va a funcionar”, “el cliente no tiene ni idea de lo que quiere”, “los jefes no entienden una leche del negocio”, “para que te metes en eso”, “tú hazme caso, que llevas poco y todavía no sabes de qué va esto”, “trabajando tanto nos dejas mal a los demás”, “otra vez lo mismo”, “si ya te lo decía yo”… En fin, podríamos seguir así todo el día, ¿verdad?
El caso es que durante mucho tiempo se me ha escapado cuáles eran los factores que llevan a unas empresas a crear culturas de alto rendimiento y cuáles llevan a muchas empresas a fracasar en este aspecto. Incluso cuando las intenciones han sido buenas y muchos ingredientes como la confianza, el respeto, la autogestión o los recursos han sido puestos en juego, muchas han fracasado en conseguirlo, pero últimamente comienzo a entrever una serie de patrones comunes en los casos en los que la cultura corporativa ha conseguido emerger como un factor clave de éxito.
No es algo que se pueda resumir en un post, pero espero empezar a escribir y, lo más importante, trabajar sobre ello. En ese sentido, en el marco de la ScrumWeek de abril en Madrid, celebraremos dos sesiones abiertas (lunes y martes, 19-21) para poder exponer el marco de trabajo que estamos desarrollando y poder compartir experiencias entre todos aquellos que estéis interesados en este concepto, podáis contarnos cómo habéis logrado una cultura corporativa de alto rendimiento en vuestra empresa o (y esto es importante), podáis compartir vuestros fracasos y problemas a la hora de intentar implementar este tipo de entorno, ya que muchas veces no se aprende de un éxito fortuito y sí de un fracaso correctamente estudiado, meditado y analizado a posteriori. Por supuesto, queda abierto este espacio para que podamos empezar a compartir estas experiencias
Saraos, extremistas, fotos, videos y presentaciones
Escrito el 27 de Noviembre de 2010 a las 10:14
Octubre y noviembre han sido dos meses ajetreados. A los habituales proyectos de formación y consultoría se han unido dos eventos interesantes: El Agile Open Spain 2010 y el Amsterdam Scrum Gathering.
Del Agile OPen Spain 2010 tenéis un par de fotos aquí. Me volví con una sensación agridulce, la verdad. Por una parte, es patente como ha subido el nivel del evento, con mucha más gente dispuesta a aportar experiencia real y con preocupaciones más relacionadas con la implementación y práctica de metodologías Ágiles que con descubrir de qué tratan. Bien por la comunidad Ágil española. Pero por otra se pudo respirar muy evidentemente algo que ya se intuye por los espacios virtuales: se están creando dos corrientes de pensamiento, y una de ellas está de alguna forma enfrentada a la otra.
Concretamente, existe un nucleo duro de “Anarco-sindicalistas del teclado” que han creado un espacio extremista en el que “lo único” importante es la programación, el código bonito, TDD, disfrutar programando, la excelencia técnica y las camisetas con chistes en binario. Que no es que no sea importantísimo. Pero no es “LO” importante, en plan “todo lo demás es malignmo y debe ser descartado de la faz de la tierra”. Para ellos, “Scrum es cosa de gerentes” y los procesos son algo a ser destruido junto con la documentación, las herramientas, los contratos y los planes. Es decir, realizan una lectura extrema del manifiesto Ágil y se olvidan de la parte de “aunque valoramos los elementos de la derecha, valoramos más los de la izquierda“.
Son gente que dice cosas como “no se puede programar sin TDD” (aunque productos como Linux o Apache se hayan hecho sin TDD), “no se puede ser Ágil si no haces programación orientada a objeto” (aunque haya gente haciendo Agilidad en Cobol o, ya puestos, en Marketing o en equipos que hacen televisión) o “no se puede hacer Scrum sin técnicas de programación Ágil”. Que no es que “La excelencia técnia no mejore la agilidad”, por citar un principio Ágil, pero en ninguna fuente autorizada sobre el universo Ágil se citan estas técnicas como condición “sine qua non” o “necesaria y suficiente” para ser Ágil.
De hecho el manifiesto cita cuatro valores, ninguno de los cuales se refiere directamente a la ingeniería, y 12 principios, de los cuales solo uno cita una “mejora” de la Agilidad mediante la aplicación de la excelencia técnica.
Insisto: me paso la vida evangelizando sobre cosas como la automatización de tests, la propiedad colectiva de código, los estándares de programación, la integración continua e incluso los repositorios de código y el control de versiones. Creo que en pleno siglo XXI un equipo que busca la mejora continua acabará tarde o temprano enfrentado al estado del arte. Pero si de buenas a primeras te atrincheras en un elitismo taliban y, además, condenas cualquier cosa que huela a proceso u organización, luego no te quejes de lo dificil que es que te dejen ser Ágil en la empresa. Porque para empezar, no has entendido nada.
El problema es que muchas masas oprimidas en las trincheras de la programación se están arremolinando en torno al ideal libertario de los verdes pastos de la comuna digital y se están creyendo cosas como “si el código está bien hecho, lo demás no importa”. Hartos de entornos viciados, compañeros tóxicos y jefes incompetentes, creen que la salida es echarse al monte compilador a cuestas y entonar cánticos de integración continua y refactorización en torno a la hoguera comunitaria del subversion.
Bueno. Tiempo al tiempo. 
El otro grupo (en el que me auto-alineo, claro), discute frecuentemente sobre aspectos culturales de la Agilidad, el comportamiento de las personas, la frontera entre disciplina y auto-organización, los procesos que no se anteponen a los individuos, la mínima documentación que debe existir con cada incremento de código funcionando, negociar y colaborar con el cliente, crear equipos de alto rendimiento, las retrospectivas, los planes de mejora, la adaptación al cambio, el concepto de valor, el diseño emergente, la definición de set mínimo de funcionalidades con valor de mercado, el coaching de equipos, personas, gerentes y clientes, los contratos que reflejan nuestra forma de trabajar, la gestión de proyectos, los sistemas complejos… Y no condenamos las prácticas de ingeniería ($deity nos libre). De hecho las recomendamos. Y sin embargo existe un cierto interés en hacernos aparecer como “el enemigo”. Dejo a criterio del lector el decidir por qué, que bastante me estoy mojando ya con este rant.
He estado también como decía en el Amsterdam Scrum Gathering, del que tenéis varias fotillos aquí. Será porque “Scrum es cosa de gerentes”, pero ni aquí ni en la Lean Kanban Europe pude respirar este mismo clima de “talibanismo técnico” que me pareció respirar en la #aos2010.
Tuve la oportunidad de hacer una lightning-talk o “charla relámpago”, de la que pude grabar este video (la presentación está aquí):
Sustainable Pace: The Boxer, The Aikidoka and the Katana Suburi from Proyectalis on Vimeo.
También pude hacer un Ideacamp sobre Scrumban parecido al que hice en a Agile Open Spain. Gustó tanto que varias personas me pidieron que hiciera un “whitepaper” sobre esta aproximación, pero como eso es muy aburrido en su lugar he hecho esta presentación que espero que pueda ayudar a los que intentan compaginar Scrum con un entorno de alta incertidumbre en el que, en el día a día, siguen surgiendo muchas otras cosas que también deben ser atendidas:
La experiencia del Lean Kanban Europe y la del Scrum Gathering han sido tan buenas que me he decidido a abrir un blog en inglés dedicado específicamente a la Agilidad. Seguiremos informando
Actualización: borraré inmisericordemente cualquier comentario en la línea de “para ti las prácticas de ingeniería no son importantes / son secundarias / son optativas”, ya que no es eso lo que he dicho como cualquier lector con dos dedos de frente podrá interpretar
Por qué digo que no hay una industria del software en España
Escrito el 30 de Septiembre de 2010 a las 10:56
Bueno, la primera razón es que me gusta el rollo “profeta del apocalípsis” : me da muy buen resultado en las charlas, como en esta de la Conferencia Agile Spain 2010, en la que solté esta perla y fue ampliamente comentada:
Pero en serio, el caso es que llevo tiempo queriendo escribir sobre el tema siguiendo con la línea de mis dos post anteriores (consultoría Don Simón, Chapatas calentitas), y el hecho de que Xavi me haya remitido hoy un enlace a este artículo referenciado en barrapunto me empuja a hacerlo. La verdad es que coincido en gran mayoría de los aspectos y argumentos comentados por el autor, y específicamente la diferencia fundamental y no entendida entre los procesos de fabricación industrial (Taylorismo / Fordismo) y la naturaleza intrínseca del desarrollo de software es algo que se ha comentado ampliamente en la comunidad Ágil y que podéis ver en algunas de las presentaciones que he realizado al respecto (verbigratia, esta slide).
Naturalmente, cualquier afirmación grandilocuente, generalista y extrema como “No hay una industria del software en España” es tremendamente injusta, ya que al fin y al cabo se trata de un recurso retórico . Por supuesto que hay empresas dedicadas al software. Pero el promedio de la industria no es ese, y la dispersión respecto a la media no es muy grande que digamos. Si nos preguntamos cuál es la industria media del software en España, habrá poca gente que piense cosas fuera de un circuito “consultoras, banca, administración…”. Y ahí es donde digo que eso no es una industria del software, porque este tipo de empresas no te venden un software: te venden “horas de programador”. Como si una hora de programador fuera una commodity, es decir, algo perfectamente intercambiable por la hora de cualquier otro programador, y cuyo único valor reside en la cantidad de producto que poseemos o negociamos.
Oh. Dios. Mío. Las cosas pueden estar algo más rotas, pero no mucho, la verdad.
Pensamientos como este conducen a desastres organizativos como las “líneas de montaje” consultor-analista-desarrollador-tester en las que diagramas UML, mapas entidad-relación, modelos de datos y documentos de requisitos viajan por correo electrónico entre personas que no hablan nunca entre ellas. Como si un programador fuera una máquina a la que alimentamos con UML y escupe código. Y claro, en algún momento acabamos por pensar si no habría forma de diseñar algún tipo de máquina o herramienta (no se, llamemoslas CASE) para librarnos del incordio de los programadores, que son unos tíos raros que llevan camisetas frikis, huelen mal y protestan por todo. Bloody programmers.
¿Veis lo roto que llega a estar todo?
Claro, si al final la oferta se basa únicamente en “horas de programador” y no en producto, la discusión comercial ya no va en términos de funcionalidad, calidad, rendimiento… Si discutimos cobre una commodity, como por ejemplo el petroleo, solo discutimos el precio del barril y dónde me lo vas a entregar. Y cuando de repente vendo diez mil barriles, da igual si cojo dos mil de aquí, tres mil de allá, cuatro mil de acullá y luego voy “sisando” otros mil barriles poco a poco de otros sitios: el proyecto ha sido un éxito.
Pero cuando intento hacer una operación a corazón abierto, a nadie se le ocurre que la primera hora la haga un cirujano, la segunda otro distinto y la tercera ya veremos si pillamos a alguien por el pasillo para que la termine. La ventaja con la que cuentan los médicos es que ya llevaban miles de años gestionando hospitales antes de que los industriales del automovil se alzaran como adalides de la producción en cadena, las economías de escala y los sistemas MRP.
Lo mismo ocurre con los equipos de desarrollo. Nadie que de verdad conozca cómo funciona la creación de un producto sofwtare puede pretender que enfoques como el “pool de recursos” proporcionen mejor rendimiento que un modelo basado en equipos comprometidos, autogestionados y capacitados. Tendré que hacer otro articulo para hablar de los factores de motivación inherentes al trabajo en equipo y su efecto en el rendimiento cerebral de una persona a la que, en realidad, no pagamos por calentar un asiento o imputar horas de “farmville” al proyecto, sino por resolver problemas complejos y únicos de la forma más eficaz y eficiente posible.
¿Alguien puede creerse aun que las economías de escala funcionan necesaria y directamente en el mundo del software? Si eso es así, y teniendo en cuenta que una consultora puede considerarse afortunada si genera entre 60.000 y 200.000 euros por empleado, ¿Cómo es posible que compañías como Craiglists, con 30 empleados, generen un ratio de más de tres millones de dólares por empleado? ¿Cómo consigue 37Signals, creadores de Basecamp y Ruby on Rails, dar soporte a más de tres millones de clientes con una plantilla de en torno a 18 personas?
Y seguimos sin entederlo. Medimos los proyectos por el número de horas que imputamos, y claro, si te acercas a una de estas empresas y les dices “puedo enseñarte cómo hacer ese proyecto de doce años en solo uno” te miran con cara de susto y te responden “¿tú eres idiota? ¿por qué debería cobrar sólo por un año si puedo cobrar por doce?”.
Y tienen razón. Y ganan pasta. Mucha.
No vendemos software: vendemos servicios. Vendemos disponibilidad, horas suboptimas de bajo rendimiento pero en gran cantidad y baratas, muy baratas, más baratas. Las primeras compañías que se dieron el batacazo con el offshoring ya se dieron cuenta que externalizar el trabajo a una compañía que te vende las horas a mitad de precio no es tan buen negocio si luego las horas crecen al cuádruple porque no sabemos gestionar bien proyectos con el “ruido” que introduce un entorno offshore o porque los programadores tan baratos que nos han vendido no distinguen un ordenador de un piano. El panorama ha cambiado y después de décadas de offshoring los proveedores de estos servicios han descubierto muchas cosas respecto al negocio en el que operan, y ahora mandan a gente al origen para que haga de puente entre sus clientes y ellos, forman a sus trabajadores, protegen a sus equipos… Y usan metodologías Ágiles de desarrollo, pero esa es otra historia.
Tengo muy pocas esperanzas puestas en que el negocio de las “cárnicas” cambie, pero las pocas que existen están en el lado del cliente más que en la capacidad de los equipos y miembros de estas empresas para cambiar una mentalidad directiva que solo ve los resultados desde la perspectiva del dividendo y la cifra de negocio. Las consultoras comienzan a llamarme para que las forme porque sus clientes empiezan a exigir enfoques Ágiles de los proyectos, y esto es una gran noticia. Esperemos que la cosa prospere a partir de ahí: mucho más bajo no podemos ir…
Conferencia Agile Spain 2010
Escrito el 11 de Mayo de 2010 a las 18:20
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…
¿Horas ideales o puntos abstractos?
Escrito el 11 de Mayo de 2010 a las 18:10
Artículo ladrillaco por encargo, como los escritores de verdad . Es técnico y está muy orientado a las metodologías Ágiles, pero creo que todo el que tenga que realizar estimaciones en un proyecto se puede beneficiar de muchas de las ideas que contiene. Allá vamos.
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.
Charla sobre Lean y Kanban
Escrito el 27 de Abril de 2010 a las 22:41
Un par de líneas para dejaros esta charla realizada en el marco de las presentaciones sobre Itinerario Ágil organizadas por CEIN en Pamplona. Gracias a todos los asistentes, a los que espero ver en las próximas citas que tenemos dentro de este ciclo de charlas.
Scrum: El Señor de los Pardillos
Escrito el 29 de Marzo de 2010 a las 8:57
En realidad me pidieron que diera una charla sobre Scrum y desarrollo Ágil, pero con ese título iba a sonar un poco fuera de lugar en un evento como el XGN, así que al final decidí echarle un poco de fantasía y… Bueno, dejo que lo veáis vosotros mismos. En breve el video y la presentación en Inglés
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
-
Artículos recientes
-
Categorías
-
Archivos
- 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 perseverancia personal personas plan de negocio planificación estratégica PMBOK PMI PMP positivismo 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í:
- Ernesto Sáenz Horna: Buenas tardes. La impresión que tengo sobre el tema es que a la mayor parte de personas nos...
- Manuel: Buenas. Soy Manuel, editor de Genbetadev. He leído tu artículo: “Por qué digo que no hay una...
- Luis Fraile: Genial Ángel, sois grandes.
- Pepito: Muchas felicidades Ángel, considero que tiene un enorme valor hacer eso. Independientemente de cuál sea la...
- Luis Miguel: Ole, ole y ole. Predicando con el ejemplo. Gracias!
Qué se dice por ahí:
- No Más Hype: Empresa maltrata jugador. Jugador maltrata empresa. Repetir
- El Pito Doble: El Pito Doble y Garrafablog se fusionan
- Consejos para empresas: Considerando el espacio: para la Depresion: Consejos de Ayuda para la DepresionAcercando...
- recursoshumanosproyectos: Cultura de proyectos: un reto para las empresas
- Agilismo: Después de la XGN 2010
Fotos
www.flickr.com
|
