• Inicio
• Acerca de
• BlogLog
• Te invito a un café
• RSS
• Mi empresa

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

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:

1. “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.
2. “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í.
3. 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.
4. 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.

Irracionalidad

Escrito el 25 de Octubre de 2010 a las 18:32 

Es curioso como mis proyectos llevan un ritmo primordial y casi arcano. El año pasado me pegué meses yendo a Madrid, el primer semestre del año ha tocado Pamplona, y de repente en Barcelona no pueden vivir una semana sin mi (¡hola chicos! ). En todos los casos he intercalado viajes a otros sitios, pero hay tendencias cíclicas, casi mareas. Y no solo en la localización geográfica, sino en los temas que surgen.

Hace unos meses el tema era la organización de equipos con un único responsable / jefe de proyecto / Dueño de Producto. Ahora, por una causa o la otra, el tema caliente en varios de mis proyectos es “mi Dueño de Producto me presiona con plazos irreales”. Y no estamos hablando de sitios en los que no existe ningún tipo de cultura respecto a la gestión de proyectos, sino casos en los que ya llevamos meses formando e implementando metodologías con toda la organización.

O sea, que no es que no le hayamos contado a los Comerciales / Clientes / Gerentes, por citar más perfiles, la historia del triángulo de hierro, la incertidumbre y cómo esta se desborda hacia las variables que no hayamos fijado, y que en el caso de que fijemos todas las variables principales (alcance, tiempo, coste) más nos vale haber diseñado un dispositivo de almacenamiento de incertidumbre, es decir, un buffer de proyecto en la terminología de CCPM o, en andalú, corshón , porque en caso contrario la incertidumbre volcará en variables como la calidad, los riesgos o los recursos humanos. O sea, que acabaremos haciendo más horas que cascoporro, entregaremos una bazofia hedionda e indocumentada que habremos de pasar por producto y suerte tendremos si no peta todo sin que tengamos un solo backup porque no había tiempo de hacer backups.

Oh, yeah!

Intento por todos los medios armar a los líderes de equipo / miembros senior / scrum master / jefes de proyecto con un arsenal de argumentos para explicar a los clientes / dueños de producto / comerciales / gerentes que, básicamente, lo que no puede ser, no puede ser y además es imposible. A lo que ellos responden “pues se tiene que poder“.

Y claro, el problema está ahí: en la irracionalidad. Ahí ya no hay argumentos que valgan. El equipo agacha las orejas, traga… Y la caga estrepitosamente, porque ahora la culpa de que todo haya ido mal es del equipo. El comercial es un heroe que vendió la moto, y el equipo unos pringaos que no consiguen que la moto (en realidad un triciclo) coja los 100 en 3,2sg. A echar horas. Y lo que es peor: quizás no sois culpables de que todo siga como siempre, pero como mínimo sois complices.

Así que ahí va mi receta para lidiar con estas situaciones: racionalidad, disciplina y coraje.

• Racionalidad: aunque la otra parte se acoja a argumentos irracionales y emocionales, nosotros somos el baluarte del orden en medio del caos. Todos los números, gráficas, documentos, ejemplos, tendencias, históricos y demás información tangible que podamos usar juega en nuestro favor. Podemos mostrar por ejemplo la velocidad media del equipo, la carga de trabajo actual, la estimación de esfuerzo de la tarea de última hora que nos piden y el impacto que tiene sobre la planificación, es decir, si hacemos esto, no hacemos esto otro, y además el cambio de contexto reduce no solo nuestra productividad sino tambiñen nuestra producción.
• Disciplina: incluso con todos los datos del mundo, el ejercito de los orcos tratará de salirse con la suya mediante lo que, para ellos, es la opción de mínimo esfuerzo, que es pedirle al equipo que meta horas. Mínimo esfuerzo para ellos porque no tienen que volver donde el cliente y admitir que han vendido una moto, o en caso de que el cliente se haya sacado la fecha de la manga, meterle en cintura y ponerse firme. Así que si nosotros no nos negamos a salirnos del proceso y de nuestros principios (como por ejemplo, paso sostenible), a ellos nunca acaba de dolerles que el cliente abuse o que las ofertas se hagan a volapluma en el Asador de Aranda entre cochinillo y rioja. Les tiene que doler. Y si hay un proceso establecido, es por algo. Si al final es la alta gerencia la que exige que el proceso se rompa, pues vale, discutiremos el coraje, pero como mínimo esta situación ya se ha hecho incómoda para un montón de gente, y podremos luego preguntar ¿no hay una forma mejor de hacer todo esto? (pista: estamos encontrando formas mejores de desarrollar software…)
• Coraje: como decía antes, si no nos enfrentamos al abuso y la irracionalidad, somos cómplices del status quo. No digo que uno tenga que estar poniendo su puesto a disposición del gerente todos los días, pero sí creo que todo el mundo debería tener muy clara la línea que no piensa traspasar, y estar dispuesto en determinados casos a poner toda la carne en el asador. Tener coraje no significa ser violento, agresivo o maleducado: hay que aprender a ser asertivo. Y para vuestra tranquilidad, sabed que a nadie le despiden de su puesto por poner algo de sentido común en la empresa. Y si lo hacen, congratulaos de poder salir huyendo subvencionados de un infierno así. . Por otra parte, si la resistencia no la ejerce una persona sola, sino todo el equipo, es virtualmente imposible que a la empresa le merezca prescindir de todo el equipo “por racionales y disciplinados”. Por supuesto, es casi inevitable la cantinela de “os parapetáis en el proceso”, “sois demasiado rígidos”, “no entendéis la criticidad del negocio”, “nos vamos a ir todos a la ruina como no hagáis esto”… Escuchad estas quejas como cánticos de victoria, indican que estáis en el camino correcto.

Una última palabra: como en todo, no se puede ser extremista ni talibán. Hay situaciones en las que hay que arrimar el hombro y tirar millas, pero en base a mi experiencia, en equipos motivados y en entornos sanos, no hace falta ni siquiera pedirle al equipo ese esfuerzo ya que ellos mismos serán los que tomen la decisión de apretar. Pero en el momento en que se toma esa decisión por ellos y no entienden los motivos o les parecen arbitrarios y parciales… Nos vemos en el mundo de la irracionalidad.

¿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

Próximas charlas

Escrito el 18 de Marzo de 2010 a las 16:34 

En los próximos meses tengo varias charlas programadas, por si alguien tiene interés y posibilidad de asistir a alguna:

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

Videos de charla en Biko2

Escrito el 13 de Marzo de 2010 a las 21:26 

Como intuís por la (baja) frecuencia de publicación, voy hasta arriba desde que empezó el año, ¡que vivan los brotes verdes! No obstante intentaré ir subiendo algunas de las muuuuchas cosas interesantes que tengo cuasi-listas para publicar: muchos videos, algún white-paper, un ejercicio de Scrum para simulación de sprints, una aplicación de XP a la realización de documentos, una traslación de 5S a software, una aproximación a “Lone Scrum” (Scrum como herramienta de productividad personal)… como os digo, muchas cosas. Como muestra, un par de videos montados por los amigos de Biko2 en los que cuento algunas de mis metáforas clásicas como el horno de las magdalenas, los orcos a las puertas o “imprimir la wikipedia”:

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

Charla “proyectos Ágiles” en Vitoria

Escrito el 19 de Febrero de 2010 a las 13:56 

Ayer tuve el privilegio de poder hablar un rato sobre la gestión Ágil de proyectos como parte de las charlas sobre innovación pública que está organizando el Gobierno Vasco, con el impulso de los incombustibles Alberto Ortiz de Zárate(@alorza) e Iñaki Ortiz, responsables de Atención al Ciudadano y Modernización de la Administración respectivamente y promotores desde hace tiempo del blog Administraciones en Red . El video lo podéis ver en Irekia, y la presentación que usé la tenéis en Slideshare:

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

Montañas en la tierra media

Escrito el 4 de Febrero de 2010 a las 11:20 

Es descorazonadora la cantidad de gente que viene a mis cursos o charlas con hambre en los ojos, con necesidad de cambiar las cosas, angustiados, presionados, sobreviviendo en entornos corporativos agresivos, corruptos y desmoralizadores. Pero es igualmente descorazonador que mucha de esta gente, cuando se les presentan las raices y principios en los que se basan sus males y las herramientas y líneas de acción encaminadas a reducirlos o eliminarlos, responden sistemáticamente con el “Yapero”.

“Ya, pero es que nuestros proveedores nos engañan”. Pues controla a tus proveedores. O mejor, cambia de proveedores. “Ya, pero es que todo el mundo hace lo mismo”. No, todo el mundo no. Y si todo el mundo hace lo mismo, tendrás que cambiar el mundo. “Ya, pero es que no nos dejan cambiar de proveedores”. Insisto: cambia la forma en que trabajan tus proveedores. “Ya, pero es que no quieren”…

Lo gracioso es que luego vas a trabajar con esos mismos proveedores y se repite la historia. “Ya, pero es que el cliente nos cierra alcances, tiempos y dinero”. Pues diseña y gestiona buffers de proyecto. “Ya, pero es que ni con buffers cuadra el proyecto”. Pues entonces estás perdiendo dinero y no deberías coger ese proyecto. “Ya, pero es que si cogemos este proyecto, aunque perdamos, luego podemos coger otros más jugosos”. No creo que comenzar una relación de negocios con abusos de poder y pérdidas económicas establezca un buen precedente. “Ya, pero es que si no lo coge la competencia”. Si la competencia pierde dinero, mejor para tí. “Ya, pero es que entonces nosotros nos quedamos sin clientes”. Hay millones de empresas en todo el mundo. Sal de tu terruño y búscate la vida. “Ya, pero es que para eso hay que saber inglés”. Aprende inglés. “Ya, pero…”

Ya hablé de esto con la parábola del mago del método. Y ahí estamos todos. Con picos y palas a nuestro alcance, quejándonos toda la vida de la montaña que se alza en la tierra media entre clientes y proveedores. Pero nadie mueve un dedo. Nadie pica la montaña. Nadie se pone a cavar un tunel. Nadie.

O casi.

Kanban vs Scrum en castellano

Escrito el 28 de Enero de 2010 a las 10:49 

Como algunos sabéis, hace ya un par de añitos traduje desde Proyectalis el magnífico libro “Scrum y XP desde las trincheras” de Henrik Kniberg, uno de mis heroes Ágiles de todos los tiempos. Las razones que me llevaron a ello fueron varias. Fundamentalmente, mi consideración sobre la estupenda calidad de la obra, el caracter abierto de la misma (podéis descargarla gratuitamente en InfoQ o en Proyectalis) y el convencimiento de que uno debe devolver algo a la comunidad de vez en cuando. Esto vale para el software libre, las presentaciones de Slideshare, los libros abiertos, los wifi sin contraseña y cualquier otra cosa de la que os estéis beneficiendo de forma gratuita: si creeis en los mecanismos de retribución Kármica, y ya sabéis que yo lo hago a pies juntillas, hay que ir compensando lo que uno recibe o se genera una deuda, y las deudas es lo que tienen, que crecen exponencialmente. Total, que la cosa fue bien, porque conseguimos bastantes enlaces, tráfico y el pagerank de Proyectalis mejoró. Karma wins again.

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

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

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

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

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

Scrum Multiproyectos, Métricas y Agile EVM

Escrito el 16 de Enero de 2010 a las 15:33 

He subido a Slideshare un pequeño extracto de nuestro seminario de gestión del portfolio de proyectos aliñado con unas pocas slides de nuestro curso de introducción al PMBOK desde una perspectiva Ágil, en el que introducimos el concepto de Earn Value Managemente aplicado a proyectos Ágiles y Scrum Multiproyectos (oh yeah!). No se, ayer en la ducha (suele ser mi momento más creativo e inspirado del día, qué cosas… ) se me ocurrió que tenía sentido reordenar este conjunto de slides en esta forma y dar un poco de vidilla a un concepto que está poco trabajado tanto en la literatura como en el material disponible on-line: que pasa cuando salimos del típico ejemplo de libro de “un cliente, un equipo, un proyecto” (Ein Volk, ein Reich, ein Führer! ), al auténtico carajal que vivimos todos en las trincheras reales: múltiples clientes, múltiples proyectos en distintos momentos del ciclo de vida (unos cerrándo, otros en preventa, etc.) y múltiples equipos, a veces compartiendo proyectos (relaciones “muchos a muchos” y esas cosas). Y nada, que aquí lo dejo. Ya sabéis que estoy disponible para montar saraos y hablar de estas cosas si os ape

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

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?

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?

Más antiguos →

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é?






• Artículos recientes

  • LeanCamp Barcelona
  • Felicitación Navideña
  • Jornada para Business Angels
  • Uno por ciento
  • De vuelta por mis fueros…
  • Presentaciones XP2011
  • Recursos del curso de Coaching de Equipos Ágiles
  • El Rol de Scrum Master / lider de equipo
  • La cultura corporativa en Zappos
  • El laberinto del autónomo (II)

• Categorías

  • Eventos
  • General
  • Gestión
    • Citas
    • Creatividad
    • Gestión de Proyectos
    • Gestión del Tiempo
    • Marketing
  • Internet
    • Blogs
    • Herramientas
  • Negocios y empresas
    • Emprendedores
    • Formación
    • Ideas de negocio
    • Libros

• 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

  • Desencadenado
  • Diario de un director de TI
  • Externalidades
  • Think in Blog
  • Tik&Tak
  • Vida de un Consultor

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

Twitter

Fotos

www.flickr.com Más fotos de angel.medinilla

• del.icio.us
• Digg
• Google Bookmarks
• Yahoo! My Web
• Technorati
• Barrapunto
• Meneame
• Fresqui
• Favoriting
• BlogMemes
• Chido
• Webeame
• Blinklist
• Neodiario
• Enchilame
• Mr. Wong