Próximos cursos Lean/kanban: Madrid y San Sebastian

En Abril, Ángel Díaz Maroto y yo, vamos a impartir dos cursos de Lean/Kanban. En Madrid, y además esta vez lo acercamos un poco por País Vasco, que parece que nunca se hacen cosas interesantes por aquí ;).
Las fechas y la información son:

• Lean/Kanban en Madrid, 15-16 Abril (ATENCION, que las fechas han cambiado).
• Lean/Kanban en San Sebastian/Donostia, 25/26 Abril.

Kanban es un sistema construido sobre los principios del pensamiento Lean. Este método nos ayuda a implantar un sistema de mejora continua de los procesos, y crear espacios de colaboración y transparencia. En su vertiente de gestión de proyectos nos guía para maximizar el valor entregado, eliminar los “desperdicios” y mejorar nuestra organización paulatinamente.

• Kanban se orienta a la entrega continua de valor.
• El trabajo y su flujo de proceso se hacen visibles. 
• El trabajo en progreso se limita, y nos centramos en eliminar los problemas, y nos centramos en terminar trabajo, en vez de costosas multitareas y cambios de contexto.
• Kaizen. Las mejora continua es parte del propio sistema.

El método Kanban es una aproximación a un proceso de cambio evolutivo e incremental para las organizaciones.

¿Dónde puedo utilizar kanban?

• Proyectos y equipos de desarrollo de software.
• Gestión de proyectos de gestión del conocimiento.
• Pequeñas y grandes organizaciones.
• Areas de soporte o servicios.

¿a quién le interesa este curso?

• Jefes de proyecto y equipo
• Gestores de áreas de servicio y soporte.
• Miembros de equipos que quieren mejorar su efectividad.
• Miembros de equipos Scrum que quieren seguir aprendiendo y mejorando.

¿por qué debería asistir a este curso? ¿qué aprenderemos?

El curso presenta de manera práctica los conceptos, y es impartido por personas con experiencia en proyectos reales. Los asistentes al curso serán capaces de iniciar una implantación del método Kanban en sus organizaciones, aplicando las nociones aprendidas.

Contenidos del curso:

• Principios Lean
• Kanban como herramienta de visualización y soporte a la colaboración
• El método Kanban como proceso de mejora evolutivo.
• Identificación de los "desperdicios" de Lean.
• Patrones de diseño de procesos.
• Patrones de colaboración alrededor de kanban.
• Teoría de las limitaciones de Goldratt, cuellos de botella en los procesos.
• Métricas
• Implantación en las organizaciones.

La estimación ágil de proyectos, puntos-historia y velocidad

Uno de los temas más recurrentes, y que causa más dolores de cabeza es la estimación de proyectos. Trataré de explicar mi visión al utilizar una posible técnica: la estimación por puntos-historia utilizado típicamente en algunas de las metodologías ágiles.

Dejamos aparte por ahora el nirvana de no tener que estimar. Si ya has conseguido no tener la necesidad de estimar, enhorabuena, tus comentarios sobre el proceso serán bienvenidos :) A los demás: todo llegará ;)

Supongamos que en un determinado momento nos llega un proyecto, una visión, y nos hacen la pregunta del millón ¿para cuando estará? y sobre todo, ¿cuanto va a costar?
Es entonces cuando el equipo suspira, mira al techo, y tras asegurar que lo que vas a dar es una estimación aproximada, se pone a trabajar. Porque tus estimaciones las hará el equipo que va a hacer el trabajo, ¿verdad? ^_^

Historias de Usuario: Colaboración,
planificación, y requisitos. 

1) Obtención de las historias de usuario del proyecto

  Debemos averiguar con precisión aproximada lo que hay que realizar en el proyecto. Pero, ¿aproximada? Ten en cuenta que nunca nunca nunca se puede definir un alcance de un proyecto de manera cerrada y completa. Así que no merece la pena intentarlo. Hay que hacerse el suficiente detalle por si alguien necesita calcular el ROI o la inversión a realizar aproximado. Pero también hay que hacer ver que sabemos que va a haber cambios que imposibilitan la certeza absoluta. Y que desconocemos el el inicio de un proyecto, el alcance real. Recordad el cono de incertumbre.
 Con una visión de proyecto necesitamos hacer dos cosas: un Inception para bajarla a tierra y empezar a crear visión compartida. Y los talleres de historias de usuario que sean necesarios para generar un backlog con el que gestionar el alcance del proyecto. En este punto debes valorar el tiempo invertido en detallarlas. Es más importante lograr el máximo despliegue de historias que profundidad en cada una. Una gran técnica son los mapas de producto.

2) Aplicar la vara de medir del equipo

Planning poker

 Ahora debemos medir lo que queremos construir para saber cuando podemos terminarlo. No podemos decir el tiempo que podremos hacer en una carrera, si no sabemos la longitud de la misma. Asignar puntos en realidad no es estimar una historia, es solo medirla. Establecer el acuerdo por el que el equipo decide qué tamaño tiene. Esta es la razón por la que posteriormente las velocidades no son comparables entre equipos, simplemente porque cada equipo tiene su propia vara de medir. Y es subjetiva.
 ¿Te puedes equivocar asignando tamaños? Sí, pero NO. :) En realidad no importa mucho si te puedes equivocar o no. Lo importante es que seguro que te equivocas siempre de la misma manera, y eso nos dará predecibillidad. Asignar tamaños relativos nos ayuda a acertar por comparación, de manera que no nos hace falta demasiado detalle en cada elemento para relativizarlo unos respecto de otros.
 En mi experiencia funciona mejor crear una escala de tamaños de historia de usuarios relativa, ordenándolas de mayor a menor, y posteriormente asignándoles los puntos del "planing poker". Ver historia a historia, de una en una, y asignándole tamaños individualmente, genera reuniones tediosas y donde perdemos la visión comparativa entre historias.

3) Estimar la velocidad

 Es en este momento cuando realmente hacemos una estimación, respondiendo a la pregunta: ¿a qué velocidad avanzará este equipo en este proyecto? Esta es la verdadera piedra angular de la estimación y que nos dará como resultado una posible planificación temporal.
 La situación ideal se da en un equipo que tiene históricos anteriores. Guardamos las velocidades anteriores de los proyectos, y si el proyecto se da en condiciones parecidas, ¡la velocidad anterior la podemos proyectar al futuro!
 Cuando no tenemos históricos, es cuando realmente hacemos una estimación compleja. ¿cuantas historias de las definidas anteriormente creemos que podemos hacer por sprint? ¿vamos a ir más rápido o más lento construyendo el software? El equipo debe calcular cuanto será capaz de hacer por sprint, para estimar la velocidad. Juega siempre con un rango, una estimación pesimista y otra optimista. Es más fácil así dejar claro que es una estimación, y que puede tener un error.

4) Planificar

Índice de mi formación en Historias de Usuario.

 NO todo en esta vida, ni en los proyectos, son historias de usuario. NO intentes hacer que lo sean. A veces ;) hay que realizar formaciones, instalaciones de entornos, hacer spikes, etc. Hay que tenerlas en cuenta para calcular la fecha final, por si hay que sumar al tiempo de desarrollo, obviamente.
 Dada la velocidad y el tamaño del proyecto podemos hacer una simple regla de tres para conocer una posible planificación, entre la velocidad optimista y pesimista. Número de puntos totales dividido por la velocidad por iteración = número de iteraciones. Sumando imprevistos y cualquier cuestión que quede fuera de historias de usuario, tendremos nuestra primera aproximación al proyecto.

5) Asumir la realidad

 Esta es la parte más difícil de todo el proceso. Deja que el proyecto/producto evolucione y adáptate a los que vaya sucediendo.
 ¿el proyecto marcha a menos velocidad de la estimada? Calcula los nuevos costes, ¿son aceptables? ¿debes cortar en el alcance?
 ¿Surgen problemas que no habías previsto? Actualiza lo que vaya a afectar a la velocidad. ¿o necesitas nuevos perfiles? Actualiza el coste... compara la velocidad real con la planificada continuamente.

 En definitiva, no dejes que tu maravilloso plan arruine la realidad. Haz un chequeo a nivel global tras cada iteración, y no caigas en el optimismo de "ya mejoraremos" si tu gráfica de burn-down te dice que no hay tutía.

Retrospectiva, un año

El año pasado me decidí finalmente a dar el salto al autoempleo. El día 18 de Enero ha hecho un añito. La verdad que Biko es un gran lugar para trabajar, pero tenía ganas de "ver mundo". Ganas de ayudar a más gente con lo que los últimos años creo que he hecho bien, con lo que he aprendido, y probar si me podía ganar la vida con ello.

El resumen muy rápido-rápido es: Ya sabía que iba a ser difícil, pero no tanto. :( Ya sabía que iba a ser divertido, pero no tanto. :)

La verdad que he repasado el 2012 y he hecho muchísimas cosas interesantes y he aprendido mucho, he cometido algunos errores, he disfrutado más tiempo con mi familia, y he sufrido algunas veces con mis propias decisiones. Ha sido un año apasionante en lo personal, pero eso es otra historia, algunas de las cuales no podría contar aquí. ;)

El pequeño paréntesis en eso, lo único, mi pequeño homenaje a Itsaso, que se merece con certeza mucho más de lo que le doy, y que me da una confianza sin la cual todo esto no habría sido posible. :')

Empecé el año con mucha fuerza, llegando a un acuerdo con mis amigos de Biko, que me respaldaba buena parte del año. Sin duda me daba tranquilidad, aunque también he de decir que me embotó un poco, e inicie las acciones adecuadas a la búsqueda de nuevos clientes demasiado tarde.

Una de las mejores cuestiones que han sucedido, son la gran red de profesionales y amigos con los que voy coincidiendo. La gente, al saber de mi nueva aventura profesional, se interesaron, y de hecho los primeros trabajos fueron todos por estas redes de colaboración. Gracias a todos los que en algún momento me habéis apoyado. 

He hecho bastantes temas de formación, hice un curso de coaching, asistí a la CAS2012 y AOS2012, he leído más libros que nunca sobre mi trabajo, asistí al taller de Betacodex y he compartido horas de vuelo con compañeros increíbles como X. Quesada, Ariel Ber, Leo Antolí o Jorge Uriarte.

Sobre el propio trabajo han sido retos que no esperaba. He estado 4 meses programando en Ruby on Rails. Resulta ¡que no he trabajado casi nada con Scrum! Kanban se ha llevado todo el éxito este 2012, aunque en realidad, yo siempre hablo de lo mismo: principios y valores, aprendizaje y adaptación.

Si he subido grandes cimas, ha sido
gracias a muchos apoyos.

Mi plan de marketing incluía crear mi propia marca, imitando un poco a Teresa ;) con Skok. Me parecía que podía ser como una herramienta útil de posicionamiento. Lo tenía todo preparado para lanzar Ynspira. :) (me encanta el nombre, y me lo guardo para otra ocasión). Pero algo se cruzó en mi camino: Agilar. La idea de una organización en construcción, que sería como la construyésemos, y la persuasión de X. Quesada ;) finalmente hicieron que me uniese a ese nuestro proyecto. Es cierto que todavía es una cosa un poco rara (como organización) pero por eso es genial. Le vamos dando forma poco a poco. Ahí he podido coincidir con Ariel, Leo, Xavi, Alan, Ángel, Tiago o Enrique. Y estoy aprendiendo mucho con ellos.

Bueno, vamos a lo mejorable de este año, que si no esto no sería una retrospectiva:

• La búsqueda de nuevos cliente es hoy por hoy mi principal problema. Mi asignatura pendiente es mi propia zona, el País Vasco. Cuando trabajas, no siembras. Y eso se nota después. Debo afilar más mi hacha comercial :S
• Los problemas de liquidez se me han agravado este fin de año, debería haberlos previsto. Y mira que es un clásico entre los autónomos! :\
• Debo arriesgarme más con mis decisiones, mostrarme más como creo en las cosas. Creo que a veces me vence "el lado tradicional" y probablemente deba arriesgar más.
• La decisión de los precios. Darle vueltas a los precios me rompe la cabeza. Esto es algo que tengo que establecer con más claridad. Pero tengo la impresión que hay sitios donde aporto más valor que en otros, ¿por qué no debería cobrar entonces diferente? Esto merecerá un post más adelante.
• Mis ingresos reales han bajado respecto cuando era empleado por cuenta ajena, así que debo conseguir mayor facturación. Uno de mis objetivos también es ganar más dinero.

Y lo que más me ha gustado:

• El curso con Ariel Ber de Agile Coaching. Espero que lo repitamos pronto. Hasta me hizo dibujar. ;) Y el primer CSM de co-trainer con X. Quesada, que es un crack.
• Unirme al equipo de Agilar. Así como ratificar que el futuro está en las redes de colaboración, más que en las organizaciones formales. Conocer tanta gente.
• Las charlas en la universidad con Jessi. Hay que evangelizar, y cuanto antes mejor :)
• El foro de Adegi de emprendedores también ha sido un descubrimiento interesante.
• Este año además volví a trabajar con mi coach. Y si me lo puedo permitir lo volveré a hacer en el 2013. Creo que ha sido una cuestión que me ha ayudado mucho.
• Salir de mi zona de confort, taaantas veces. ¡Pero si en uno de mis primeros clientes ni siquiera desarrollaban software! Por cierto, genial ese proyecto y me consta que están muy contentos con los cambios. :)

 Gracias a un montón de gente por estar ahí. A algunos os he mencionado, a otros os he puesto alguna referencia que solo entendereis los aludidos ;) Pero ha habido mucha gente más este año que ha sido increíble. Gracias. Me acuerdo de todos :) 

 Y gracias especialmente a los clientes que este año han confiado en mi.
 El 2013 va a ser difícil, algo así dicen en las noticias todos los días, ¿no? Deje de leerlas el día que me puse a trabajar por mi cuenta, que para agobiarme ya me valgo solo demasiadas veces. Feliz año a todos. :)

6 tendencias para el 2013 en "Project Management"

Me he quedado con una sensación rara tras leer este artículo del ESI. Y realmente no sabía muy bien por qué, creo que no lo llego a entender del todo :\. Así que he decidido que iba a escribir las tendencias que yo veo en la gestión de proyectos alrededor de mi, y posteriormente compararlas:

Mis predicción de tendencias en gestión de proyectos para este año (y "ad infinitum") son:

• Las organizaciones se darán cuenta que no vale con tener líderes (expertos, PMs, ScMs,...), sino que hay que crear verdaderos equipos.
• Algunas organizaciones triunfarán con la implantación de Agile, y se comerán a las que no consigan adaptarse. Otras fallarán, indudablemente.
• Desaparecerá la "responsabilidad individual" de la gestión de proyectos: habrá que equipos, que simplemente, sepan -aprendan- lo que tienen que hacer para lograr el éxito.
• Las PMOs desaparecerán para ceder el control de los procesos a la gente que realmente sabe de ellos, los que lo ejecutan. Existirán comunidades de práctica mejorándolos.
• Los grandes proyectos plantean retos únicos que son cada vez más difíciles de superar. Sí. Debes contar con las armas adecuadas: gente motivada :)
• Los "gestores de proyecto" irán dando paso paulatinamente a "facilitadores de valor para la organización". Se verá el sistema, no cada proyecto peleando por "los recursos", no habrá que gestionar  un portfolio, solo sumar valor.

No sé parecen mucho a las del ESI. Pero con eso me quedaría más tranquilo. Y además, se empiezan a ver alrededor.

El mito de la organización ágil (presentado en la CAS2012)

Este post es la explicación de mi presentación en la conferencia Agile-Spain 2012. Podeis encontrar la presentación en slideshare: El mito de la organización ágil.

Cuando hablamos de organizaciones ágiles, podemos hablar ya de varios modelos sobre los que se está trabajando, como por ejemplo:

• La organización conectada, de Dave Gray. Nos muestra una organización como una serie de células, equipos aut
• El modelo de BetaCodex, de Niels Pflaeging, en donde insiste en que el management es innecesario, y habla de dos niveles, donde unos atienden al mercado, y otros dan servicios centrales, también como organización de equipos autoorganizados.

Sin embargo, no es de los modelos de lo que quiero hablar, si no de lo que nos mueve a hablar de organizaciones ágiles. A pequeña escala, a mi me transformó la idea ya comentada en este blog de que Equipo = Producto. Esta simple igualdad me hizo cambiar el chip, como responsable de equipos, desde la visión de construir software, a construir equipos capaces de hacerlo. Y ser consciente que lo bueno que fuesen los equipos, así sería el producto que produjesen.

A nivel organizativo podemos escalarlo exactamente igual, y ya había una Ley que lo enunciaba:

Ley de Conway:
Las organizaciones que diseñan sistemas están limitadas a producir diseños que son copias de las estructuras de comunicación de estas organizaciones.

Es decir, si tu organización es una basura, solo generará más basura.

Todos conocemos casos donde las organizaciones son el principal problema de la gente que se encuentra dentro de ellas. Solo tenemos que echar un vistazo a TrabajoBasura.com para observar cómo se han convertido en un verdadero problema para muchas personas.

¿qué clase de decisiones toman las organizaciones de hoy en día que nos han llevado a tenerlas como fuente de muchos problemas? ¿cuando descolgarán el teléfono de su conciencia?

NUNCA. Nunca lo harán, básicamente, por que las organizaciones NO existen. No hay nada en lo que nos podamos excusar para hacer/no hacer algo echando la culpa a una "organización". No hacemos nada por la "organización". Como ente jurídico tendrá algo de sentido, pero no en realidad, es solo una abstracción, una metáfora. ¿dónde está la organización en vuestras reuniones?

Una organización está compuesta "simplemente" de RELACIONES. Tenemos que entender qué ata a las personas para actuar cómo actúan  Entonces empezaremos a comprender ese sistema que llamamos organización. Estamos atados a otras personas, a hechos sucedidos o por suceder, y a sentimientos como el miedo o la ilusión. Esa maraña de hilos forma un sistema complejo que debemos tratar de cambiar, actuando sobre las relaciones tanto como sobre las personas.

Generalmente las organizaciones parece que nos arrollan cuando queremos realizar alguna iniciativa de cambio. Debemos conocer qué ata a cada persona dentro de un sistema para poder entenderla. Movernos a una organización ágil no será cuestión tan simple como implantar un modelo o metodología. Igual que implantar Scrum en un equipo no es tan solo hacer las reuniones y artefactos, una organización ágil debe compartir misión, principios y valores:

• Una misión: Las personas necesitamos saber el POR QUÉ. Aquello que nos mueve y nos guía. Una misión compartida creará una dirección por la que identificamos que debemos movernos. Y puede haber varias escalas de misiones, como cuando en mi pequeño equipo en Biko hacíamos retrospectivas anuales para decidirlas, o les ponía retos como convertirnos en el "mejor equipo de desarrollo de Gipuzkoa"
• Con autonomía y respeto: La autonomía es básica para poder llegar a tener equipos autoorganizados, y el respeto la base para ello. Desarrollar productos debe empezar por desarrollar y permitirle hacerlo a las personas involucradas. Son la gente que debe aprender. Se deben crear equipos capaces de definirse sus objetivos, y capaces de conseguirlos.
• Sumando diferencias: La creatividad juega un papel muy importante en nuestras organizaciones hoy en día. Nunca sabes quien puede aportar la idea brillante o sorprendente. No solo ya las cuestiones técnicas son básicas, si no que las habilidades sociales se han vuelto imprescindibles en la nueva economía.
• Con absoluta transparencia: La transparencia se convierte en una vara de medir. Si algo te da miedo a ser transparente, es posible que no vaya alineado con una organización ágil. Es un valor básica para la autonomía de los equipos, para que la información fluya entre todas las relaciones personales sin crear silos ni malentendidos.
• Donde el dinero es una consecuencia: Las organizaciones deben ser rentables y conseguir beneficios, ¡sin duda! Estamos diciendo que la consecuencia de gente motivada, con una misión, trabajando por resultados, que se autoorganiza, va a ser conseguir beneficios.

Las personas que trabajamos en un entorno como el desarrollo de software, nos vemos completamente influenciadas por el entorno en el que lo hacemos. De hecho, creo que somos el sector laboral en el que más nos afecta. Nuestro trabajo es el más intangible, y el menos técnico en realidad (¡de verdad!). La mayoría de nuestros problemas en los proyectos no son técnicos, son sociales, de comunicación, de colaboración. Y es por ello que el mundo "Agile" se está volviendo tanto hacia las organizaciones.

Y debemos mirar también alrededor nuestra, y sumar fuerzas con muchos movimientos que vienen hablando de las nuevas formas organizacionales desde otras perspectivas. Creo que será enriquecedor para todos conectar con las ideas de Lean, Worldblu o Koldo Saratxaga entre otros.

Mención especial merece, bajo mi punto de vista, el llamado "Culture Hacking". La idea es que el mismo movimiento ágil es un hack de la cultura: procedimientos y valores que podemos usar para cambiar nuestras organizaciones.
En definitiva, las organizaciones ágiles quizás no se diferencien demasiado en su estructura organizativa de las actuales (que lo harán), si no por el cambio de mentalidad en la búsqueda de la creación de equipos autoorganizados, en la visión de cada y una de las personas del sistema global, y en métricas añadidas a las financieras, como la satisfacción de cualquier persona relacionada con esa organización, interna o externa. No importará el "dibujo" de tu organización, si no el tipo de relaciones que vamos a crear diferentes entre las personas.

No olvidemos que podemos cambiar aquello que nos incomoda o molesta, mejorar nuestro mundo alrededor. Espero veros en la CAS2013 ;)

CAS2012: La confirmación de una gran conferencia

Por fin ha pasado la elegante conferencia de Agile-Spain del 2012. Para mi esta conferencia ha resultado brillante en su organización, y además he disfrutado muchas de sus sesiones. He conocido mucha gente, y cómo no, he compartido momentos entrañables con muchos de los ya amigos de los círculos de Agile-Spain.
La conferencia contaba con unas 180 personas, lo cual superó mis expectativas. El miedo a que fuese un lugar como Cáceres un impedimento se hacía patente. Sin embargo, Cáceres se ha mostrado como una ciudad ideal para congresos de este tipo, y la organización nos facilitó una excursión por la zona monumental el jueves, lo que resultó una idea fantástica.

Masa K. Maeda en la Keynote de CAS2012

El jueves comenzó la conferencia con la ponencia de Masa K. Maeda como keynote. La keynote no fue tan espectacular como las del año pasado, pero Masa se defendio bien, hablando sobre la idea de que nos debemos plantear siempre la validez de nuestras propias ideas. Ante épocas de cambio, debemos estar con mente abierta.

Mi siguiente charla fue la de Diego Cenzano. Diego ha sido mi jefe durante estos últimos 5 años que he estado trabajando en Biko. Explicó su visión de los cambios que ha sufrido su organización en estos últimos años, desde el punto de vista de un CEO. Fue una charla excelente, que hasta me hizo sentir la nostalgia en algún momento por mi antigua empresa :). No voy a explicarla pues esta me parece que quedó grabada.
Tras mi charla rápida sobre el uso de kanban en una organización industrial (no de desarrollo de software), escuché a Juanma sobre "cómo sí y no aportan valor". Creo que llegué a esta charla con una expectativa diferente, y no me encajó demasiado.
Después de comer, asistí a la primera parte de Ariel Ber sobre cómo explicar Agile. Siempre son muy entretenidos y didácticos los talleres de este argentino. Luego nos fuimos a levantar un poco de polémica con Jesús Ballano y los modelos de empresa. Otro par de personas y yo estábamos en el acuerdo de salir a "interrumpirle" y comparar el modelo BeCode con los nuestros personales. Se convirtio en una conversación entre público y ponente más que en una presentación típica.

El primer día de conferencia acabó de manera sobresaliente con una visita guiada por la zona monumental de Cáceres, y una posterior cena.

El segundo día empecé con el taller de restricciones de Masa K. Maeda. Se trataba de ejemplos de juegos para explicar la autoorganización de equipos y la teoría de Godratt. Jugamos a la factoría de los aviones, que yo he hecho tres o cuatro veces a varios equipos, y no había jugado nunca yo mismo. Es un juego muy revelador. Y acabamos todos volando los aviones por toda la sala, claro.

Descansando de la #CAS2012, en el norte
de Cáceres, S. Martín de Trevejo.

La siguiente charla, escuché a X. Albaladejo hablar sobre los mapas de proyecto, cómo representar productos mediante técnicas visuales, usando todos los recursos a nuestro alcance para lograr crear una visión compartida sobre un producto.
A última hora antes del cierre, me tocaba a mi hablar sobre "el mito de la organización ágil". En un par de días pondré las ideas principales en un post, atentos ;).

Para mi esta CAS2012 ha sido brillante. El aplauso a la organización, voluntarios todos, debe oírse bien alto. La comunidad ha evolucionado mucho desde hace cuatro años que se realizó el primer AOS, y esto se nota en el nivel de las charlas de la conferencia. Me preocupa que la gente nueva pueda encontrar una CAS un poco alejada de sus primeros problemas, ya veremos cómo podremos balancear estas necesidades en el futuro.

La verdad que es muy reconfortante saber que aquella pequeña reunión en Madrid que dio origen a Agile-Spain ha llegado tan lejos :). Gracias a todos.

Nota: Podeis encontrar más referencias sobre la CAS2012 en este documento.

Próximos talleres en Pamplona: Lean/kanban y Retrospectivas

ACTUALIZACIÓN FEB. 2013: Cursos de Lean/Kanban en San Sebastian y Madrid.

En Noviembre hemos organizado junto con CEIN dos diferentes talleres, de una mañana de duración, sobre temáticas ágiles.

Taller Lean/Kanban
El primer taller se realizará el 9 de Noviembre, sobre Kanban. Veremos cuales son los conceptos que podemos aplicar de esta metodología de manera práctica. Hablaremos sobre los principios ágiles y Lean, realizaremos una simulación, dibujaremos nuestro panel kanban... todo en 6 intensas horas de aprendizaje y experiencia.
Puedes encontrar más información e inscripciones en la web de CEIN.

Taller de retrospectivas eficientes
El segundo taller es el día 28 de Noviembre y girará alrededor de las retrospectivas y la mejora continua de los equipos. Veremos técnicas y tácticas para esta reunión tan importante en los equipos ágiles. Se tratará de aprender nuevas maneras de realizar retros, mejorar la efectividad de las mismas, y comprender la importancia de generar aprendizaje de manera constante en los equipos.
Puedes encontrar más información e inscripciones en la web de CEIN.