tag:blogger.com,1999:blog-98369932024-03-13T22:53:18.089+01:00Metodologías ágiles. De lo racional a la inspiración.Scrum, Lean, XP, Kanban,... pero sobre todo, su filosofía y a quien aplica: las personasJoserrahttp://www.blogger.com/profile/10913840576521473720noreply@blogger.comBlogger271125tag:blogger.com,1999:blog-9836993.post-39442259472142978382018-11-27T19:32:00.005+01:002023-10-26T23:11:58.028+02:00Scrum master a tiempo completo: 42 TareasUno de los artículos que más referencio en mi <a href="https://wearetayari.com/que-hacemos/educacion-profesional-agilidad/formacion-en-scrum/">formación en Scrum</a> cuando hablo de las labores del Scrum Master es: <a href="http://agiletrail.com/2011/11/14/42-tasks-for-a-scrum-masters-job/" target="_blank">42-tasks-for-a-scrum-masters-job</a>. Por alguna razón, todo el mundo parece entender que el Product Owner es un trabajo a tiempo completo, o ser miembro de un equipo también, pero que probablemente el rol del Scrum Master puede ser realizado a media jornada o incluso menos.<br />
El scrum master <i><b>también</b></i> tiene mucho trabajo en equipos medianos o grandes, o nuevos. Y es preferible que se centre en sus tares como scrum master, compartiendo su trabajo entre dos equipos por ejemplo, que trabajar también con la gorra compartida de miembro del equipo. ¿Por qué? Por que las labores que tenderá hacer son las de desarrollador antes que las de scrum master.<br />
<br />
He querido traducir este artículo, para que quede en castellano, con permiso de <i>Bernd Schiffer</i>, para que quede constancia, y pueda referenciarlo en nuestro idioma :)<br />
<br />
Artículo original:<a href="http://agiletrail.com/2011/11/14/42-tasks-for-a-scrum-masters-job/" target="_blank"> 42 Tasks for a Scrum Master’s Job</a><br />
<br />
<div class="p1">
<span face=""verdana" , sans-serif">Las siguientes preguntas aparecen a menudo cuando realizo formaciones o consultorías en Scrum:</span></div>
<div class="p2">
<span face=""verdana" , sans-serif"><br />
</span></div>
<blockquote class="tr_bq">
<span face=""verdana" , sans-serif">¿Por qué los roles de Scrum Master y Project Manager deberían ser llevados por personas diferentes? </span><span style="background-color: white; color: #333333; font-family: "baskerville" , "georgia" , "times new roman" , "times" , serif; font-size: 16px; font-style: italic; line-height: 24px;">(</span><a href="http://www.quora.com/Why-should-the-Scrum-Master-and-Project-Manager-roles-be-filled-different-people" style="-webkit-transition: all 0.2s ease-in-out; background-color: white; color: #743399; font-family: Baskerville, Georgia, "Times New Roman", Times, serif; font-size: 16px; font-style: italic; line-height: 24px; transition: all 0.2s ease-in-out 0s;">Quora</a><span style="background-color: white; color: #333333; font-family: "baskerville" , "georgia" , "times new roman" , "times" , serif; font-size: 16px; font-style: italic; line-height: 24px;">)</span><span face=""verdana" , sans-serif"><br />
</span><span face=""verdana" , sans-serif">¿Será el Scrum Master una ocupación al 100% o puede un programador ocuparse de ello si tiene mucha experiencia en planificación ágil? </span><span style="background-color: white; color: #333333; font-family: "baskerville" , "georgia" , "times new roman" , "times" , serif; font-size: 16px; font-style: italic; line-height: 24px;">(</span><a href="http://www.quora.com/Will-a-scrum-master-for-a-team-of-10-be-a-full-time-position-or-can-a-programmer-fill-this-position-if-highly-trained-in-agile-planning" style="-webkit-transition: all 0.2s ease-in-out; background-color: white; color: #743399; font-family: Baskerville, Georgia, "Times New Roman", Times, serif; font-size: 16px; font-style: italic; line-height: 24px; transition: all 0.2s ease-in-out 0s;">Quora</a><span style="background-color: white; color: #333333; font-family: "baskerville" , "georgia" , "times new roman" , "times" , serif; font-size: 16px; font-style: italic; line-height: 24px;">)</span><span face=""verdana" , sans-serif"> </span></blockquote>
<div class="p2">
<span face=""verdana" , sans-serif"><br />
</span></div>
<div class="p1">
<span face=""verdana" , sans-serif">Tras estas preguntas está la suposición de que el Scrum Master no es un rol a tiempo completo. Quien hace esas preguntas conjeturan con la posibilidad de ahorrar dinero juntando dos roles en una sola persona.</span></div>
<div class="p2">
<span face=""verdana" , sans-serif"><br />
</span></div>
<div class="p1">
<span face=""verdana" , sans-serif">Las preguntas son realizadas por novatos como Scrum Masters, por product owners, por miembros del equipo, por managers, por stakeholders de cualquier tipo. De los tres roles en Scrum, todos parecen inferir inmediatamente que ser miembro del equipo es un trabajo a tiempo completo -por que desarrollan software el día completo - y que ser un product owner es también a tiempo completo - por que desarrolla el producto todo el día-, pero parece difícil de imaginar cual es el trabajo de un Scrum Master pueda ser y el por qué diablos sería un trabajo a tiempo completo, también.</span></div>
<div class="p2">
<span face=""verdana" , sans-serif"><br />
</span></div>
<div class="p1">
<span face=""verdana" , sans-serif">¿Quizás esos que preguntan no sepan que es lo que un scrum master hace todo el día?</span></div>
<div class="p2">
<span face=""verdana" , sans-serif"><br />
</span></div>
<div class="p1">
<span face=""verdana" , sans-serif">Aquí presento una lista de 42 cosas que diría que son parte del trabajo de un scrum master:</span></div>
<div class="p2">
<span face=""verdana" , sans-serif"><br />
</span></div>
<div class="p1">
<span face=""verdana" , sans-serif"><b>Reuniones</b></span></div>
<div class="p1">
<span face=""verdana" , sans-serif">- Facilitar reuniones para el equipo. Esto incluye:</span></div>
<div class="p1">
<span face=""verdana" , sans-serif"> - Preparar</span></div>
<div class="p1">
<span face=""verdana" , sans-serif"> - Moderar</span></div>
<div class="p1">
<span face=""verdana" , sans-serif"> - Postprocesar</span></div>
<div class="p1">
<span face=""verdana" , sans-serif"> - Realizar retrospectivas, que son especiales, por consiguiente las cuento separádamente.</span></div>
<div class="p2">
<span face=""verdana" , sans-serif"><br />
</span></div>
<div class="p1">
<span face=""verdana" , sans-serif"><b>Dinámicas de equipo</b></span></div>
<div class="p1">
<span face=""verdana" , sans-serif"> - Realizar coaching a los miembros del equipo (p. ej. coaching 1a1)</span></div>
<div class="p1">
<span face=""verdana" , sans-serif"> - Mediar en los conflictos</span></div>
<div class="p1">
<span face=""verdana" , sans-serif"> - Ayudar al equipo en la toma de decisiones</span></div>
<div class="p1">
<span face=""verdana" , sans-serif"> - Fomentar la auto-organización del equipo</span></div>
<div class="p1">
<span face=""verdana" , sans-serif"> - Mediar en el conflicto de objetivos entre el equipo de desarrollo (alta calidad técnica) y el product owner (más funcionalidad)</span></div>
<div class="p2">
<span face=""verdana" , sans-serif"><br />
</span></div>
<div class="p1">
<span face=""verdana" , sans-serif"><b>Aprendizaje</b></span></div>
<div class="p1">
<span face=""verdana" , sans-serif"> - Continuar aprendiendo todo lo relativo a Agile (p. ej. visitar grupos de comunidades, atender a conferencias, leer libros, escribir blogs,…)</span></div>
<div class="p1">
<span face=""verdana" , sans-serif"> - Asesorar a los miembros del equipo en todo lo relacionado con Agile.</span></div>
<div class="p1">
<span face=""verdana" , sans-serif"> - Ayudar al equipo a crear <a href="http://alistair.cockburn.us/Information+radiator" target="_blank">radiadores de información</a>.</span></div>
<div class="p1">
<span face=""verdana" , sans-serif"> - Dar feedback al equipo.</span></div>
<div class="p1">
<span face=""verdana" , sans-serif"> - Fomentar el uso de prácticas de ingeniería ágiles dentro del equipo de desarrollo (esto es un enorme trabajo para invertir el tiempo de un Scrum Master, incluyendo por ejemplo, publicación/releases automáticas, entrega continua, TDD, y muchos más).</span></div>
<div class="p1">
<span face=""verdana" , sans-serif"> - Desafiar al equipo con nuevas ideas sobre Agile Management (p. ej. <a href="http://confluence.atlassian.com/display/DEV/Atlassian+FedEx+Days" target="_blank">FedEx -Days</a>).</span></div>
<div class="p1">
<span face=""verdana" , sans-serif"> - Colaborar constantemente con otros Scrum Master en la organización (p. ej. a través de la comunidad de práctica).</span></div>
<div class="p1">
<span face=""verdana" , sans-serif"> - Bajar al <a href="http://en.wikipedia.org/wiki/Gemba" target="_blank">Gemba</a>.</span></div>
<div class="p2">
<span face=""verdana" , sans-serif"><br />
</span></div>
<div class="p1">
<span face=""verdana" , sans-serif"><b>Producto</b></span></div>
<div class="p1">
<span face=""verdana" , sans-serif"> - Ayudar a escribir o dividir historias de usuario.</span></div>
<div class="p1">
<span face=""verdana" , sans-serif"> - Ayudar a escribir o adaptar la visión del producto.</span></div>
<div class="p1">
<span face=""verdana" , sans-serif"> - Ayudar a ordenar los elementos de la pila de producto.</span></div>
<div class="p1">
<span face=""verdana" , sans-serif"> - Ayudar con la planificación del sprint.</span></div>
<div class="p1">
<span face=""verdana" , sans-serif"> - Estar familiarizado con el trabajo del equipo (p. ej. el producto)</span></div>
<div class="p2">
<span face=""verdana" , sans-serif"><b><br />
</b></span></div>
<div class="p1">
<span face=""verdana" , sans-serif"><b>Visión general</b></span></div>
<div class="p1">
<span face=""verdana" , sans-serif"> - Juntar a la gente que debería hablarse entre ellos.</span></div>
<div class="p1">
<span face=""verdana" , sans-serif"> - Estar en contacto con los stakeholders regularmente.</span></div>
<div class="p1">
<span face=""verdana" , sans-serif"> - Ayudar al equipo a informar a management.</span></div>
<div class="p1">
<span face=""verdana" , sans-serif"> - Ayudar a fortalecer la comunidad ágil dentro de la organización</span></div>
<div class="p1">
<span face=""verdana" , sans-serif"> - Organizar eventos de intercambio como Open Spaces o World Cafes para el equipo, stakeholders y el resto de la organización</span></div>
<div class="p1">
<span face=""verdana" , sans-serif"> - Compartir ideas y análisis en la compañía (micro-blogging, blogging, conferencias internas,…)</span></div>
<div class="p1">
<span face=""verdana" , sans-serif"> - Ser la persona de contacto para todos en el equipo y los stakeholders en todo lo concerniente a Agile. </span></div>
<div class="p1">
<span face=""verdana" , sans-serif"> - Dar oportunidades de aprendizaje a la gente en la organización (p.ej. charlas o talleres) y permitirles aprender conceptos Agile importantes como p.ej. la <a href="http://martinfowler.com/bliki/TechnicalDebt.html" target="_blank">deuda técnica</a>.</span></div>
<div class="p2">
<br /></div>
<div class="p1">
<span face=""verdana" , sans-serif"><b>Cambio</b></span></div>
<div class="p1">
<span face=""verdana" , sans-serif"> - Ayudar al equipo a eliminar impedimentos.</span></div>
<div class="p1">
<span face=""verdana" , sans-serif"> - Sugerir nuevas métricas para el equipo como catalizadores del cambio</span></div>
<div class="p2">
<span face=""verdana" , sans-serif"><br />
</span></div>
<div class="p1">
<span face=""verdana" , sans-serif"><b>Espejo</b></span></div>
<div class="p1">
<span face=""verdana" , sans-serif"> - Reflejar los valores ágiles y de scrum al equipo.</span></div>
<div class="p1">
<span face=""verdana" , sans-serif"> - Recordar al equipo sus acuerdos (p.ej. políticas)</span></div>
<div class="p1">
<span face=""verdana" , sans-serif"> - Ayudar al equipo a mejorar constantemente sus procesos.</span></div>
<div class="p1">
<span face=""verdana" , sans-serif"> - Reflejar los problemas al equipo a través de la observación desde fuera.</span></div>
<div class="p1">
<span face=""verdana" , sans-serif"> - Hacer preguntas abiertas.</span></div>
<div class="p1">
<span face=""verdana" , sans-serif"> - Comprobar los modelos que usa el equipo (p.ej. sprint backlogs, métricas, etc.) y mostrarles las diferencias entre el modelo y el mundo real.</span></div>
<div class="p2">
<br /></div>
<div class="p1">
<span face=""verdana" , sans-serif"><b>Varios</b></span></div>
<div class="p1">
<span face=""verdana" , sans-serif"> - Ayudar al equipo a mantener el foco (p.ej. actuando como un buffer entre las distracciones externas y el equipo)</span></div>
<div class="p1">
<span face=""verdana" , sans-serif"> - Ayudar al equipo a mantener sus herramientas scrum (paneles, pilas de acciones, gráficas, backlogs,…)</span></div>
<div class="p1">
<span face=""verdana" , sans-serif"> - Ayudar al equip y el product owner para encontrar los adecuados:</span></div>
<div class="p1">
<span face=""verdana" , sans-serif"> - Definición de terminado (DoD).</span></div>
<div class="p1">
<span face=""verdana" , sans-serif"> - Definición de preparado (DoR).</span></div>
<div class="p2">
<span face=""verdana" , sans-serif"><br />
</span></div>
<div class="p1">
<span face=""verdana" , sans-serif">¿Has hecho o considerado todo lo mencionado anteriormente? Tomate un respiro, ¡debes estar agotado!</span></div>
<div class="p2">
<br /></div>
<div class="p1">
<span face=""verdana" , sans-serif"> Creemos que el scrum master es un rol a tiempo completo para una persona en un equipo Scrum. <a href="http://www.scrummastermanifesto.org/scrummaster-manifesto/A_ScrumMaster_Manifesto.html" target="_blank">Scrum Master Manifesto</a>.</span><br />
<span face=""verdana" , sans-serif"><br />
</span></div>
<br />
<div style="text-align: center;">
<span face=""verdana" , sans-serif"><b>¿Interesado en <a href="https://wearetayari.com/que-hacemos/programa-transformacion-agil/"><i>mentoring</i> de Scrum Master</a>? </b></span><br />
<span face=""verdana" , sans-serif"><b><a href="https://wearetayari.com/contactar/">Contacta -TAYARI-</a></b></span></div>
Joserrahttp://www.blogger.com/profile/10913840576521473720noreply@blogger.com2tag:blogger.com,1999:blog-9836993.post-63147870752281764142018-11-06T00:00:00.001+01:002021-01-04T13:34:51.729+01:00Agile Fluency Model en castellanoHe publicado el <a href="https://wearetayari.com/modelo-fluidez-agil/">modelo de fluidez ágil</a> en castellano.<br />
<br />
<a href="http://2.bp.blogspot.com/-F7l7_5gM5Js/W-CvjcP-YhI/AAAAAAAABs8/us7vHL2AH_wwB-IAqr2n3fJXAQjv1zPZACK4BGAYYCw/s1600/agile-fluency-model-v2-simple-2-1.png" imageanchor="1"><img border="0" height="200" src="https://2.bp.blogspot.com/-F7l7_5gM5Js/W-CvjcP-YhI/AAAAAAAABs8/us7vHL2AH_wwB-IAqr2n3fJXAQjv1zPZACK4BGAYYCw/s400/agile-fluency-model-v2-simple-2-1.png" width="400" /></a><br />
<br />
Este modelo desarrollado por James Shore y Diana Larsen proporciona una interesante perspectiva sobre el camino al agilismo por los equipos.<br />
<br />
<a href="https://wearetayari.com/modelo-fluidez-agil/">Modelo de fluidez ágil</a>.<br />
<br />Joserrahttp://www.blogger.com/profile/10913840576521473720noreply@blogger.com0tag:blogger.com,1999:blog-9836993.post-71431058494812646872017-11-12T20:17:00.000+01:002017-11-12T20:18:58.897+01:00CAS2017: Conferencias Agile-SpainLa CAS2017 ha sucedido hace un par de días, y empiezo a leer las primeras impresiones, felicitaciones, quejas, enhorabuenas y protestas...<br />
<br />
<b>Mi visión sobre la CAS2017</b><br />
<div class="separator" style="clear: both; text-align: center;">
<a href="http://1.bp.blogspot.com/-zOJjuFF-5xY/WgiaOgvU4YI/AAAAAAAABUI/9jD5RNxKOMogsKeyGYeEHBYUltJDY5bIwCK4BGAYYCw/s1600/2017-11-09%2B14.08.20.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="240" src="https://1.bp.blogspot.com/-zOJjuFF-5xY/WgiaOgvU4YI/AAAAAAAABUI/9jD5RNxKOMogsKeyGYeEHBYUltJDY5bIwCK4BGAYYCw/s320/2017-11-09%2B14.08.20.jpg" width="320" /></a></div>
<br />
¿Qué ha sucedido este año? Desde mi punto de vista personal, no puedo dar muchos detalles del contenido. ¡He visto muy pocas charlas! :) La CAS tiene cada vez para mi más de punto de encuentro que de conferencia dónde aprender. Puede haber temas interesantes, pero la verdad es que no voy por el aprendizaje. Además tiene ese puntito de satisfacción de ver cómo la comunidad ha conseguido poner en marcha semejante evento, tras verla nacer hace 8 años en un bar de Madrid.<br />
<br />
<br />
<br />
<a href="http://3.bp.blogspot.com/-4yqDfJ2227c/WgiZ11zlhuI/AAAAAAAABUA/g5mkVpJul0EquJf8aFmw4AlEDYtXf2BkwCK4BGAYYCw/s1600/2017-11-09%2B14.44.23.jpg" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" height="240" src="https://3.bp.blogspot.com/-4yqDfJ2227c/WgiZ11zlhuI/AAAAAAAABUA/g5mkVpJul0EquJf8aFmw4AlEDYtXf2BkwCK4BGAYYCw/s320/2017-11-09%2B14.44.23.jpg" width="320" /></a> Este año fui seleccionado para dar un taller sobre <b>Liderazgo para la transformación</b>. Recogí buen feedback sobre la sesión, y sobre todo, me llevo algunas preguntas muy interesantes que me hicieron reflexionar sobre el contenido. Ahora estoy preparando un taller de dos días sobre liderazgo, y es impresionante cómo cuando impartes un taller, aprendes tanto o más que los asistentes si estás abierto a escuchar.<br />
<br />
<br />
Sobre la conferencia de este año:<br />
<br />
<ul>
<li>ME GUSTÓ:</li>
<ul>
<li>Traer ponentes/keynotes de fuera del mundo Agile.</li>
<li>El espacio: las salas estaban cerca y eran mayoritariamente cómodas. No hubo atascos.</li>
<li>El control de tiempos de las charlas. La puntualidad era buena.</li>
<li>Como siempre Autentia, grabando todas las charlas, estoy deseando ver alguna de ellas.</li>
<li>El concepto tras la idea de "las chapas", para controlar el acceso a los talleres.</li>
<li>La keynote final de Neil Killick donde después de 2 días de procesos, herramientas, ideas,... nos volvió a centrar en qué es realmente Agile.</li>
<li>Las cajas para recoger el feedback, ¡genial! Sencillo, en el momento, y rápido.</li>
</ul>
</ul>
<ul>
<li>PARA MEJORAR en CAS2018:</li>
<ul>
<li>La agenda debe estar definida con más tiempo de antelación. Además, más claridad en la selección de las charlas, con feedback a los ponentes, más feedback de calidad de las mismas, mayor visibilidad del proceso</li>
<li>Añadir track técnico. Más contenido para las bases del agilismo. ¿quizás otros formatos de talleres con esta orientación?</li>
<li>Añadir dos tracks en inglés, mayor internacionalización.</li>
<li>Se debe dar más visibilidad a patrocinadores pequeños/medianos.</li>
<li>Hay que dar contexto a quién viene de fuera del mundo Agile para una keynote. La keynote de Ramón Cabezas parecía un <i>speech</i> de venta con cupón de descuento.</li>
<li>Las salas para los talleres, al menos donde me tocó a mi, deben estar mejor preparadas, más espaciosas, y cómodas.</li>
<li>La comida. O sea,... el queso ;)</li>
<li>Las chapas era buena idea, y debía haber sido informada antes, y evitado también la acaparación de múltiples talleres de los primeros que llegaban.</li>
</ul>
</ul>
<div>
Como siempre, un aplauso especial para los voluntarios. Claro que nunca hacen una conferencia perfecta a los ojos de todos. Pero la HACEN. <b>Gracias</b>.</div>
<div>
<br /></div>
<div>
<b>Mi visión sobre la CAS (en general)</b></div>
<div>
<br /></div>
<div>
El jueves por la tarde, tras el día de conferencia, tuvimos la enésima discusión sobre lo que queremos que sea la CAS. Como evento de referencia que se ha convertido en el panorama nacional (no hay más que ver dos empresas del IBEX-35 como patrocinadores), me pregunto si debemos dar un paso en su profesionalización. Para ello deberíamos ponernos de acuerdo como comunidad.</div>
<div>
Me gustaría en realidad que la asociación representase a una mayoría de esa comunidad (Únete! <a href="https://agile-spain.org/asociate/">https://agile-spain.org/asociate/</a>), y tuviésemos claro el círculo de decisión sobre la CAS, podríamos dotar de mayor infraestructura a la organización, y permitir que los voluntarios se centrasen en el contenido.</div>
<div>
Mientras tanto, la dinámica de voluntarios ha funcionado, y espero que lo siga haciendo. :) Gracias de nuevo a todos.</div>
<div>
<br /></div>
<div>
Como siempre, la CAS es un momento de referencia para estar si te interesa el movimiento Agile. Las personas involucradas lo hacen especial. Cada año.</div>
Joserrahttp://www.blogger.com/profile/10913840576521473720noreply@blogger.com0tag:blogger.com,1999:blog-9836993.post-42278512250962195952016-06-29T19:26:00.000+02:002016-06-29T22:23:43.191+02:00The "Groundhog day" retrospective<div class="p1">
Some months ago I was feeling bored and tired of facilitating retrospectives. I have facilitated several hundreds of retrospectives, and sometimes you start again with a new team, you repeat a lot of techniques and for sure continuously became a better facilitator (if deliberate practice, and feedback). Of course that every team is different, and the great part is the outcome, to feel their change. But at some point I was bored.</div>
<div class="p2">
<br /></div>
<div class="p1">
So now I tend to mix classical exercises with more tuned approaches to create new things for the teams. Please, give me your opinion about this: the groundhog day retrospective:</div>
<div class="p2">
<br /></div>
<div class="p1">
- First, you can do a classical check-in. For this first time I did Appreciation round, and review previous actions.</div>
<div class="p1">
- Then, you draw a timeline for the past sprint. i asked the team to identify (with color codes) three things: </div>
<div class="p1">
1) problems identified during the sprint</div>
<div class="p1">
2) improvements that they thought should have done</div>
<div class="p1">
3) Facts, things that happened, observations.</div>
<div class="p2">
<br /></div>
<div class="p1">
When they finished the identification, I made the following statement: “Remember the film "<a href="http://www.imdb.com/title/tt0107048/" target="_blank">Groundhog day</a>"? So now, suppose we come back next day for the sprint planning, and suddenly, we discover we are in the same sprint. People live in the same day of the previous planning. We remember everything, but nothing is done. And the same thing will happen again. We have the same stories in the top of the backlog, and we are back in the same sprint planning than two weeks (length of the sprint) before. Look the sprint again, with new eyes, but with the same work to do”</div>
<div class="p2">
<br /></div>
<div class="p1">
And now you ask three questions, and after each you repeat the statement.</div>
<div class="p1">
1) Individually, write ONE postit looking at the problems on the timeline. If you could solve one of these problems, now that you know it´s going to happen, what would you have done to solve it during the sprint?</div>
<div class="p1">
(let them work and put the ideas on the wall, and repeat the statement again, adding that the same sprint is back again! :)</div>
<div class="p1">
2) Individually, write ONE postit looking at the improvements on the timeline. If you could do one action to improve the sprint, what would you have done to improve the sprint?</div>
<div class="p1">
(let them work and put the ideas on the wall, and repeat the statement again, adding that the same sprint is back again! :)</div>
<div class="p1">
3) Individually, write ONE posit looking at the observations, evaluating their impact, What would you change on the team behaviour, on the team reactions to those things to perform better during the sprint?</div>
<div class="p1">
(great! finally we achieved an incredible sprint, we can move to the next one!)<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://2.bp.blogspot.com/-JnWdOhjWk-w/V3QH-Ha0nxI/AAAAAAAAAr0/mukKuRWlOG8O5fe_jLDyWEuoqSs9dD-_wCLcB/s1600/groundhog.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="223" src="https://2.bp.blogspot.com/-JnWdOhjWk-w/V3QH-Ha0nxI/AAAAAAAAAr0/mukKuRWlOG8O5fe_jLDyWEuoqSs9dD-_wCLcB/s320/groundhog.jpg" width="320" /></a></div>
<br /></div>
<div class="p2">
<br /></div>
<div class="p1">
Take a look at the wall, let them search for patterns and groups. What´s there?</div>
<div class="p2">
<br /></div>
<div class="p1">
Decide actions, observe if there is need for dot voting to prioritise, or some informal agreement emerge.</div>
<div class="p2">
<br /></div>
<div class="p1">
And close the retrospective, get some feedback, and make sure that every action has a responsible.</div>
<div class="p2">
<br /></div>
<div class="p1">
Notes: (I only have used this retro once)</div>
<div class="p1">
- I found that those questions and the power to change the past generated a good analysis and powerful debates.</div>
<div class="p1">
- If the team is young, you probably have to explain the film first. Seriously. :D</div>
<div class="p1">
- I think that if you use it for releases, longer times than iterations, probably the divergence will be too high. But, tell me if you try it, please!</div>
<div class="p2">
<br /></div>
<br />
<div class="p1">
Comments are welcome! </div>
Joserrahttp://www.blogger.com/profile/10913840576521473720noreply@blogger.com1tag:blogger.com,1999:blog-9836993.post-75357065238243418402016-06-01T20:29:00.000+02:002016-06-29T22:23:33.245+02:00Retrospectiva - Comunicación no Violenta (NVC)Una de las herramientas que más he utilizado estos dos últimos años ha sido la <a href="http://www.cnvc.org/" target="_blank">Comunicación No Violenta</a> (NVC, por sus siglas en inglés). De hecho, lo tengo como algo más que una herramienta, es una manera de relacionarte con el mundo.<br />
Principalmente lo he usado como técnica de coaching y resolución de conflictos, pero sobre todo, como herramienta de auto-análisis y comprensión de mis interacciones con otras personas.<br />
<br />
Así que me propuse utilizarlo para facilitar una retrospectiva, y encontré <a href="https://www.linkedin.com/pulse/non-violent-communication-agile-retrospective-rod-sherwin" target="_blank">este artículo</a>. Basándome en él, realicé la siguiente retrospectiva:<br />
<br />
<ol>
<li><b>Check-in: </b>Revisión de acciones anteriores. Y en este equipo: revisión del calendario <a href="http://www.geocities.jp/nikonikocalendar/index_en.html" target="_blank">Niko-Niko</a> del equipo, y de la felicidad del mismo (mediante autopuntuación individual). </li>
<li><b>Introducción a NVC:</b> Explicación del fundamento de la comunicación no violenta, y explicación de las tarjetas que iban a tener que crear basado en el típico esquema de NVC: Observación - Sentimiento - Necesidad - Petición. Obviamente tanto para necesidades satisfechas como insatisfechas :)</li>
<div>
<div class="separator" style="clear: both; text-align: center;">
<a href="http://4.bp.blogspot.com/-3DOnc2cELKA/V08hZSTB31I/AAAAAAAAAqo/96t7B72DWfg8ZNNkz1QnpWnM6TnebzNngCK4B/s1600/format-nvc.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="242" src="https://4.bp.blogspot.com/-3DOnc2cELKA/V08hZSTB31I/AAAAAAAAAqo/96t7B72DWfg8ZNNkz1QnpWnM6TnebzNngCK4B/s320/format-nvc.png" width="320" /></a></div>
<span id="goog_930232378"></span><span id="goog_930232379"></span>
</div>
<li><b>Tarjetas</b>: Individualmente, reflexión durante 15 minutos y escritura de las tarjetas, con una sentencia por tarjeta. Les pido que se enfoquen en las observaciones y sensaciones del último sprint. También les pido que escriban aquello que incluso no se atreverán a compartir después. Que lo escriban para su propia reflexión, y que se lo guarden para ellos mismos.</li>
<li><b>Trabajo en parejas:</b> Se trabaja en parejas, cada tarjeta de la siguiente manera: El autor la lee, y su compañero ESCUCHA, y pregunta con CURIOSIDAD para obtener más información sobre el contenido. Sugiero evitar consejos, juicios,... solo dejarse guiar por la curiosidad.</li>
<li><b>Compartir en equipo</b>: Invito a cualquiera a compartir para todo el equipo sus reflexiones, si les apetece y se sienten cómodos. No feedback del resto, solo escucha de nuevo.</li>
<li><b>Revisión de peticiones, generación de acciones</b>: Se vuelve a trabajar en parejas, y esta vez se analizan las peticiones finales de cada tarjeta. Se generan acciones en post-its para el equipo en base a esas peticiones personales. ¿cómo puede el equipo ayudar a satisfacer esas necesidades personas?</li>
<li><b>Agrupación y priorización</b>: Compartimos las acciones en la pizarra, las agrupamos y las priorizamos. Asignamos responsables y las hacemos lo más concretas posibles. </li>
<li><b>Check-out</b>: Feedback sobre el ejercicio. Gracias al equipo.</li>
</ol>
<div>
<br /></div>
<div>
<u>Mis sensaciones como facilitador:</u></div>
<div>
- He realizado esta retrospectiva en hora y media. Creo que para un equipo de 10 personas es poco tiempo, hubiese necesitado más tiempo para la explicación inicial, e insistir con ejemplos de confusión de necesidades o "malas" observaciones. Si no conocen NVC, es realmente clave.</div>
<div>
- He observado útil repartir un pequeño inventario de <a href="https://www.cnvc.org/es/training/learn-nvc/needs-list/lista-necesidades" target="_blank">necesidades</a> y <a href="https://www.cnvc.org/node/28576" target="_blank">sentimientos</a>.</div>
<div>
- Siempre he hecho <b>invitaciones</b>: a compartir, a expresarse, a contar sus sentimientos,..., dejando muy claro que cualquier persona era libre de pasar. No era un ejercicio obligatorio (obviamente, ¡como ninguna retro!).</div>
<div>
- Considero clave también el ofrecimiento a <b>escribir, pero no compartir.</b> Da la oportunidad de reflexión individual, incluso sin participación activa en la retro.</div>
<div>
- El feedback ha sido positivo. Las acciones que han salido, poderosas. Y sin embargo, mi sensación como facilitador ha sido que tenía perdido al grupo. Tengo que analizar más esto :)<br />
<br /></div>
<div>
<br /></div>
<div>
<br /></div>
Joserrahttp://www.blogger.com/profile/10913840576521473720noreply@blogger.com2tag:blogger.com,1999:blog-9836993.post-51767257544599786212015-05-05T11:52:00.002+02:002021-01-04T13:35:49.934+01:00Marco Scrum<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="http://1.bp.blogspot.com/-UDTcdxG36Eo/W9y_h3XDPyI/AAAAAAAABss/91rtNny-TXweFP0eya6adt_u7wfBDxPngCK4BGAYYCw/s1600/scrum%2Bframework.jpg" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img alt="Marco de procesos Scrum " border="0" height="285" src="https://1.bp.blogspot.com/-UDTcdxG36Eo/W9y_h3XDPyI/AAAAAAAABss/91rtNny-TXweFP0eya6adt_u7wfBDxPngCK4BGAYYCw/s400/scrum%2Bframework.jpg" title="Marco de Scrum" width="400" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Marco de Scrum<br />
<br />
<h2>
<span style="font-size: large;"><i><span style="color: blue;"><a href="https://wearetayari.com/que-hacemos/educacion-profesional/curso-de-scrum/" target="_blank">Curso de Scrum</a>:</span> </i>Contactanos si estás interesado.</span></h2>
</td></tr>
</tbody></table>
¡Aquí puedes ver el último <a href="https://www.youtube.com/watch?v=4pCmi4y7lvo">video sobre Scrum</a> en 9 minutos que hemos publicado!<br /><div class="separator" style="clear: both; text-align: center;">
</div>
<br />Joserrahttp://www.blogger.com/profile/10913840576521473720noreply@blogger.com1tag:blogger.com,1999:blog-9836993.post-1516758867028919032013-10-13T23:25:00.000+02:002013-10-24T22:25:27.614+02:00CAS2013: Scrum y management, ni cerdos ni gallinas.<center>
<iframe allowfullscreen="" frameborder="0" height="356" marginheight="0" marginwidth="0" scrolling="no" src="http://www.slideshare.net/slideshow/embed_code/27133058" style="border-width: 1px 1px 0; border: 1px solid #CCC; margin-bottom: 5px;" width="427"> </iframe> <br />
<div style="margin-bottom: 5px;">
<strong> <a href="https://www.slideshare.net/jrramon/scrum-y-management-ni-cerdos-ni-gallinas" target="_blank" title="Scrum y management: ni cerdos ni gallinas.">Scrum y management: ni cerdos ni gallinas.</a> </strong> from <strong><a href="http://www.slideshare.net/jrramon" target="_blank">Jose Ramón Díaz</a></strong> <br />
<br />
Puedes ver el video: <a href="http://www.youtube.com/watch?v=8AhWMPgRQoM" target="_blank">Joserra Díaz, scrum y management</a>.</div>
</center>
<div class="p1">
<br />
La metáfora de los cerdos y las gallinas es un drama. Y afortunádamente se dejó de usar en la guía de Scrum. Como chiste pase, pero diferenciar entre comprometida e involucrada en un proyecto, diferenciando su grado de compromiso es un poco anti-colaboración. Y con esos nombres... ¿algún cerdo en la sala? :\<br />
<br /></div>
<div class="p1">
Una de las gallinas es la capa de management, así que se supondría que no están comprometidas (sic) con los resultados de los proyectos (¿suena absurdo verdad?). </div>
<ul class="ul1">
<li class="li1">Henry Fayol – “Gestionar (management) es prever y planificar, organizar, mandar, coordinar y controlar”</li>
<li class="li1">Control y gestión de los recursos de una organización para producir valor a los clientes</li>
<li class="li1">Managers are the people who interrupt the ones working. Jason Fried (37 signals)</li>
<li class="li1">Hay opiniones para todo, en general, Management es lo que hacen los managers. Así es más sencillo. Cada organización es un mundo</li>
</ul>
<div class="p1">
Ahora llegamos con una herramienta: Scrum. Que es <a href="http://www.forbes.com/sites/stevedenning/2011/04/29/scrum-is-a-major-management-discovery/" target="_blank">el gran descubrimiento para el management</a>. Lo dice Forbes nada menos, hace ya casi 3 años. ¡Ya les costó darse cuenta! ;) PERO, pero, hay algo que a veces no encaja… ¿qué tiene Scrum que no es una herramienta tan sencilla de utilizar en las organizaciones actuales?</div>
<div class="p2">
<br /></div>
<div class="p1">
Por alguna extraña razón la metáfora es entendida de otra manera. Y ni unos ni otros están del todo contentos con la nueva situación. El cambio de una mentalidad "command&control" a una verdadera autoorganización no es fácil, y no sabemos cómo usar esta nueva herramienta.</div>
<div class="p1">
En general:<br />
<br /></div>
<div class="p1">
- Mira la película completa, no microgestiones el equipo, sin tener en cuenta las influencias externas. El impacto en la organización completa.<br />
<br /></div>
<div class="p1">
- Sal del edifico. Baja y comprueba in situ qué sucede, a la gente usando Scrum, a los equipos, a los usuarios, a los clientes,… ¡pasea por el gemba!<br />
<br /></div>
<div class="p1">
- Cambia el foco: la gente sabe cómo definir procesos, planes y todo eso… eso es fácil. Cambia tu foco a las personas, mira si hay colaboración, comunicación, entendimiento,…</div>
<div class="p2">
<br /></div>
<div class="p1">
Así que si como manager quieres usar Scrum, ¿dónde te colocas?<br />
<br /></div>
<div class="p1">
- Si pasas a set <i>product owner</i>… o mejor no. NO lo hagas. Parece el camino más natural, pues controlas <i>releases</i>, planificaciones, hablas más con los usuarios, stakeholders, etc. Pero ser jefe de equipo, y product owner desequilibra la balanza PO <-> SM. Totalmente. Si no tienes tiempo para algo, será el equipo el que lo sufra. <!-----><!-----></-><br />
<br /></div>
<div class="p1">
- Si eres un manager externo al equipo, y este cuenta con su PO y su SM, puedes tener la sensación de "y ahora, ¿qué hago?" Pero si la organización está arrancando con Scrum es fundamental su protección y ayuda al <i>scrum master</i> a que no se de cabezazos con el resto de la organización. Que el equipo no pierda de vista el propósito de lo que está haciendo. Ayúdales en eso.<br />
<br /></div>
<div class="p1">
- Si eres un manager de varios niveles superiores, pasea por el gemba, baja a ver qué sucede, atento a lo que suceda en los equipos scrum, las personas alrededor de los equipos en otras áreas de la organización, identifica a tu equipo de trabajo y trabajad para mejorar el sistema, y apoyar aquello bueno que emerja.<br />
<br /></div>
<div class="p1">
- Si eres jefe de equipo, el paso lógico es ser scrum master. Recuerda, <a href="http://najaraba.blogspot.com.es/2008/02/el-producto-es-el-equipo.html" target="_blank">equipo = producto</a>. Trabaja en el equipo. Cambia de chip, prueba la autoorganización, ayúdales… y dales espacio.</div>
<div class="p2">
<br /></div>
<div class="p1">
En definitiva, una organización que empieza a hacer Scrum requerirá que el management se centre en las personas y el sistema completo, y no luche contra la organización si no que colabore, haga amigos, y la transforme.</div>
<div class="p2">
<br /></div>
<div class="p2">
<br /></div>
<div class="p1">
* Nota, hablo de Scrum como una herramientas… y en realidad NO lo es. Es mucho más, incluye valores, principios, cambio de mentalidad… ¡¡por eso es difícil!!</div>
<br />
<div class="p2">
<br /></div>
Joserrahttp://www.blogger.com/profile/10913840576521473720noreply@blogger.com2tag:blogger.com,1999:blog-9836993.post-13075194080483350642013-10-13T23:14:00.001+02:002013-10-13T23:15:08.628+02:00Visión personal de la CAS2013<div class="p1">
La <a href="http://conferencia2013.agile-spain.org/" target="_blank">conferencia Agile-Spain 2013</a> ya ha sucedido.</div>
<div class="p1">
<br /></div>
<div class="p1">
Echando la vista atrás ya se han <b>olvidado</b> los ratos (largos) haciendo facturas, comprando billetes de avión, reservando hoteles, el esfuerzo de un equipazo de organización,… </div>
<div class="p1">
<br /></div>
<div class="p1">
Ahora <b>recordaré</b> a la inspectora de la fundación tripartita y la casi-evacuación masiva del edificio donde tomaba lugar la conferencia (!), las risas del equipo de organización, la brillantez y calidez de los keynotes, el abrazo con Tobias Mayer, la cercanía de Koldo Saratxaga, la amistad de Ángel Medinilla, las numerosas gracias recibidas desde los asistentes, las sonrisas cómplices con los amigos que desde lejos te buscaban a ver si necesitábamos ayuda, las amistades que nacen y crecen en estas ocasiones, las cervezas con compañeros de viaje, y... más cosas ;)</div>
<div class="p1">
<br /></div>
<div class="p1">
Me <b>dolerá</b> de esta conferencia <b><i>el tiempo robado a mi familia</i></b>, el no habernos acordado de los vegetarianos para el catering, el no haber compartido más tiempo con viejos amigos, y el hecho de que no acabe la burocracia en el mismo momento que termina el evento :)</div>
<div class="p1">
<br /></div>
<div class="p1">
Y <b>celebro</b> haber ayudado a la comunidad, haber colaborado en el camino hacia la maestría de tanta gente, a que los asistentes disfrutasen de dos días alrededor de un tema que nos apasiona.</div>
<div class="p2">
<br /></div>
<div class="separator" style="clear: both; text-align: center;">
<a href="http://2.bp.blogspot.com/-KsnftPIsq2E/UlsL5EM0G3I/AAAAAAAAASA/tzuGbRjJoyE/s1600/org-cas2013.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img alt="Equipo organización CAS2013" border="0" height="300" src="http://2.bp.blogspot.com/-KsnftPIsq2E/UlsL5EM0G3I/AAAAAAAAASA/tzuGbRjJoyE/s400/org-cas2013.jpg" title="Equipo organización CAS2013" width="400" /></a></div>
<div class="p1">
<br /></div>
<div class="p2">
<br /></div>
<br />
<div class="p1">
Así que debo agradecer esos ratos a todos y cada uno: Aitor, Iñaki, Abdul, Frank, Vicenç, Bea, Anaje, Gorka, Cristina, Joseba,… y a esos alumnos de la universidad, que lamentablemente me acabo de dar cuenta no sé ni sus nombres. GRACIAS.</div>
Joserrahttp://www.blogger.com/profile/10913840576521473720noreply@blogger.com3tag:blogger.com,1999:blog-9836993.post-30964301714593646342013-05-23T16:05:00.000+02:002013-05-23T16:05:34.762+02:00Estimación ágil de proyectos (y 2): Equipo multiproyecto.Hablábamos el "otro día" sobre la <a href="http://najaraba.blogspot.com.es/2013/02/la-estimacion-agil-de-proyectos-puntos.html" target="_blank">planificación ágil</a>, y explicábamos el proceso para estimar un proyecto, y ver su evolución. Trabajábamos con la hipótesis de que era un proyecto para un equipo, un entorno que no siempre se da en las empresas.<br />
El mecanismo que aplicamos en un entorno multiproyecto es básicamente el mismo, pero contamos con una nueva incógnita: la dedicación del equipo a cada proyecto.<br />
<br />
Sabemos lo perjudicial que es para nuestra cabeza la multitarea, lo negativo que es para un equipo el multiproyecto y lo fatal para una organización la pérdida de foco y capacidad de ejecución. Sin embargo, en muchos entornos, se sigue empezando cualquier proyecto que se nos pase por la cabeza, antes que <b>priorizarlos claramente y dedicar energías a aquello que nos aporta más valor</b>. Este es un tema muy importante, y que influye poderosamente en la capacidad de trabajo de una organización.<br />
<br />
Así que, si trabajas en un equipo multiproyecto, las posibilidades de tener un buen lío son abundantes. Y la estimación va a depender tanto o más de gerencia como del equipo. ¿por qué? Simplemente por que si la dedicación no es conocida, o no es sostenida, no puedes estimar. Así que añadimos una nueva hipótesis a la hora de dar fechas. Y es arriesgada, probablemente no cae en la responsabilidad del equipo.<br />
<br />
Si decides trabajar en multiproyecto (recuerda, <b>es una decisión</b>, quizás no es tuya, pero es de alguien) a la hora de estimar, deberás asignar un porcentaje de dedicación a cada proyecto. Si tienes datos históricos de porcentajes de puntos historia por proyecto, te podrán ayudar a trabajar con una hipótesis lo más cercana a la realidad posible.<br />
<br />
<br />
<br />Joserrahttp://www.blogger.com/profile/10913840576521473720noreply@blogger.com0tag:blogger.com,1999:blog-9836993.post-71955528448305517662013-02-25T12:48:00.001+01:002013-02-25T12:56:44.715+01:00Próximos cursos Lean/kanban: Madrid y San SebastianEn Abril, <a href="https://twitter.com/adiazmaroto" target="_blank">Ángel Díaz Maroto</a> 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í ;).<br />
Las fechas y la información son:<br />
<br />
<ul>
<li><a href="http://www.agilar.es/trainings/107-lean-kanban-madrid" target="_blank">Lean/Kanban en Madrid, 15-16 Abril</a> (ATENCION, que las fechas han cambiado).</li>
<li><a href="http://www.agilar.es/trainings/108-lean-kanban-donosti" target="_blank">Lean/Kanban en San Sebastian/Donostia, 25/26 Abril</a>.</li>
</ul>
<div>
<div style="font-family: verdana, arial, helvetica, sans-serif; font-size: 12px; padding: 0px;">
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.</div>
<ul class="ul1" style="font-family: verdana, arial, helvetica, sans-serif; font-size: 12px;">
<li class="li1"><div style="padding: 0px;">
Kanban se orienta a la entrega continua de valor.</div>
</li>
<li class="li1"><div style="padding: 0px;">
El trabajo y su flujo de proceso se hacen visibles. </div>
</li>
<li class="li1"><div style="padding: 0px;">
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.</div>
</li>
<li class="li1"><div style="padding: 0px;">
Kaizen. Las mejora continua es parte del propio sistema.</div>
</li>
</ul>
<div style="font-family: verdana, arial, helvetica, sans-serif; font-size: 12px; padding: 0px;">
El método Kanban es una aproximación a un proceso de cambio evolutivo e incremental para las organizaciones.</div>
<h4 style="font-family: verdana, arial, helvetica, sans-serif; font-size: 12px;">
¿Dónde puedo utilizar kanban?</h4>
<ul style="font-family: verdana, arial, helvetica, sans-serif; font-size: 12px;">
<li>Proyectos y equipos de desarrollo de software.</li>
<li>Gestión de proyectos de gestión del conocimiento.</li>
<li>Pequeñas y grandes organizaciones.</li>
<li>Areas de soporte o servicios.</li>
</ul>
<h4 style="font-family: verdana, arial, helvetica, sans-serif; font-size: 12px;">
¿a quién le interesa este curso?</h4>
<ul style="font-family: verdana, arial, helvetica, sans-serif; font-size: 12px;">
<li>Jefes de proyecto y equipo</li>
<li>Gestores de áreas de servicio y soporte.</li>
<li>Miembros de equipos que quieren mejorar su efectividad.</li>
<li>Miembros de equipos Scrum que quieren seguir aprendiendo y mejorando.</li>
</ul>
<h4 style="font-family: verdana, arial, helvetica, sans-serif; font-size: 12px;">
¿por qué debería asistir a este curso? ¿qué aprenderemos?</h4>
<div style="font-family: verdana, arial, helvetica, sans-serif; font-size: 12px; padding: 0px;">
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.</div>
<h4 style="font-family: verdana, arial, helvetica, sans-serif; font-size: 12px;">
Contenidos del curso:</h4>
<ul style="font-family: verdana, arial, helvetica, sans-serif; font-size: 12px;">
<li>Principios Lean</li>
<li>Kanban como herramienta de visualización y soporte a la colaboración</li>
<li>El método Kanban como proceso de mejora evolutivo.</li>
<li>Identificación de los "desperdicios" de Lean.</li>
<li>Patrones de diseño de procesos.</li>
<li>Patrones de colaboración alrededor de kanban.</li>
<li>Teoría de las limitaciones de Goldratt, cuellos de botella en los procesos.</li>
<li>Métricas</li>
<li>Implantación en las organizaciones.</li>
</ul>
</div>
Joserrahttp://www.blogger.com/profile/10913840576521473720noreply@blogger.com0tag:blogger.com,1999:blog-9836993.post-66827696358070520202013-02-10T17:19:00.003+01:002013-02-10T17:19:47.008+01:00La estimación ágil de proyectos, puntos-historia y velocidadUno 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.<br />
<blockquote class="tr_bq">
<i>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á ;)</i></blockquote>
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?<br />
Es entonces cuando el equipo suspira, mira al techo, y tras asegurar que lo que vas a dar es una estimación <i><b>aproximada</b></i>, se pone a trabajar. Porque tus estimaciones las hará el equipo que va a hacer el trabajo, ¿verdad? ^_^<br />
<br />
<table cellpadding="0" cellspacing="0" class="tr-caption-container" style="float: left; margin-right: 1em; text-align: left;"><tbody>
<tr><td style="text-align: center;"><a href="http://3.bp.blogspot.com/-Qcqodr8NzMo/URfBgBPXW0I/AAAAAAAAAM0/jHpTHCzNFOM/s1600/hist-usuario-paraque.png" imageanchor="1" style="clear: left; margin-bottom: 1em; margin-left: auto; margin-right: auto;"><img border="0" height="307" src="http://3.bp.blogspot.com/-Qcqodr8NzMo/URfBgBPXW0I/AAAAAAAAAM0/jHpTHCzNFOM/s320/hist-usuario-paraque.png" width="320" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Historias de Usuario: Colaboración, <br />
planificación, y requisitos. </td></tr>
</tbody></table>
<br />
<b>1) Obtención de las historias de usuario del proyecto</b><br />
<br />
Debemos averiguar con precisión aproximada lo que hay que realizar en el proyecto. Pero, <i>¿aproximada?</i> 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.<br />
Con una visión de proyecto necesitamos hacer dos cosas: un <i><a href="http://agilewarrior.wordpress.com/2010/11/06/the-agile-inception-deck/" target="_blank">Inception</a></i> 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.<br />
<br />
<b>2) Aplicar la vara de medir del equipo</b><br />
<br />
<table cellpadding="0" cellspacing="0" class="tr-caption-container" style="float: right; margin-left: 1em; text-align: right;"><tbody>
<tr><td style="text-align: center;"><a href="http://3.bp.blogspot.com/-LzNawIVFZSU/URfBjNvDBXI/AAAAAAAAAM8/w2SMVFPXpV0/s1600/histusuario-poker.png" imageanchor="1" style="clear: right; margin-bottom: 1em; margin-left: auto; margin-right: auto;"><img border="0" height="320" src="http://3.bp.blogspot.com/-LzNawIVFZSU/URfBjNvDBXI/AAAAAAAAAM8/w2SMVFPXpV0/s320/histusuario-poker.png" width="254" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Planning poker</td></tr>
</tbody></table>
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. <i><b>Asignar puntos en realidad no es estimar una historia, es solo medirla</b></i>. 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.<br />
¿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.<br />
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.<br />
<br />
<b>3) Estimar la velocidad</b><br />
<br />
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.<br />
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 <b>condiciones parecidas</b>, ¡la velocidad anterior la podemos proyectar al futuro!<br />
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.<br />
<br />
<b>4) Planificar</b><br />
<br />
<table cellpadding="0" cellspacing="0" class="tr-caption-container" style="float: right; text-align: right;"><tbody>
<tr><td style="text-align: center;"><a href="http://3.bp.blogspot.com/-jCks-A0l_pc/URfC4SrAP0I/AAAAAAAAANE/fKZPjduVUBU/s1600/Taller.png" imageanchor="1" style="clear: right; margin-bottom: 1em; margin-left: auto; margin-right: auto;"><img border="0" height="320" src="http://3.bp.blogspot.com/-jCks-A0l_pc/URfC4SrAP0I/AAAAAAAAANE/fKZPjduVUBU/s320/Taller.png" width="265" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Índice de mi formación en Historias de Usuario.</td></tr>
</tbody></table>
NO todo en esta vida, ni en los proyectos, son historias de usuario. <b>NO intentes hacer que lo sean</b>. A veces ;) hay que realizar formaciones, instalaciones de entornos, hacer <i>spikes</i>, etc. Hay que tenerlas en cuenta para calcular la fecha final, por si hay que sumar al tiempo de desarrollo, obviamente.<br />
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.<br />
<br />
<b>5) Asumir la realidad</b><br />
<br />
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.<br />
¿el proyecto marcha a menos velocidad de la estimada? Calcula los nuevos costes, ¿son aceptables? ¿debes cortar en el alcance?<br />
¿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.<br />
<br />
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 <a href="http://en.wikipedia.org/wiki/Burn_down_chart" target="_blank">burn-down</a> te dice que <a href="http://www.wikilengua.org/index.php/no_hay_tut%C3%ADa" target="_blank">no hay tutía</a>.<br />
<br />
<br />
<br />
<br />
<br />
<br />Joserrahttp://www.blogger.com/profile/10913840576521473720noreply@blogger.com2tag:blogger.com,1999:blog-9836993.post-11837141999790027592013-01-18T23:52:00.001+01:002013-01-18T23:52:19.137+01:00Retrospectiva, un año<br />
<div class="p1">
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 <a href="http://www.biko2.com/" target="_blank">Biko</a> 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.</div>
<div class="p2">
<br /></div>
<div class="p1">
El resumen muy rápido-rápido es: <i>Ya sabía que iba a ser difícil, pero no tanto. :( Ya sabía que iba a ser divertido, pero no tanto. :)</i></div>
<div class="p2">
<br /></div>
<div class="p1">
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 <b>eso es otra historia</b>, algunas de las cuales no podría contar aquí. ;)</div>
<div class="p2">
<br /></div>
<div class="p1">
El pequeño paréntesis en eso, lo único, mi pequeño<b> homenaje a Itsaso</b>, 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. :')</div>
<div class="p2">
<br /></div>
<div class="p1">
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.</div>
<div class="p1">
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. </div>
<div class="p1">
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.</div>
<div class="p2">
<br /></div>
<div class="p1">
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: <a href="http://najaraba.blogspot.com.es/2012/10/si-llevo-kanban-tambien-llevo-los.html" target="_blank">principios y valores, aprendizaje y adaptación</a>.</div>
<div class="p2">
<table cellpadding="0" cellspacing="0" class="tr-caption-container" style="float: right; margin-left: 1em; text-align: right;"><tbody>
<tr><td style="text-align: center;"><a href="http://1.bp.blogspot.com/-aLw4Qkbmeww/UPnQPwzgFqI/AAAAAAAAALA/stKWulXnRi0/s1600/A5Wrr65CAAEy2WO.jpg" imageanchor="1" style="clear: right; margin-bottom: 1em; margin-left: auto; margin-right: auto;"><img border="0" height="150" src="http://1.bp.blogspot.com/-aLw4Qkbmeww/UPnQPwzgFqI/AAAAAAAAALA/stKWulXnRi0/s200/A5Wrr65CAAEy2WO.jpg" width="200" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Si he subido grandes cimas, ha sido<br />gracias a muchos apoyos.</td></tr>
</tbody></table>
<br /></div>
<div class="p1">
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 <a href="http://ynspira.com/" target="_blank">Ynspira</a>. :) (me encanta el nombre, y me lo guardo para otra ocasión). Pero algo se cruzó en mi camino: <a href="http://www.agilar.es/" target="_blank">Agilar</a>. 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.</div>
<div class="p2">
<br /></div>
<div class="p1">
Bueno, vamos a lo mejorable de este año, que si no esto no sería una retrospectiva:</div>
<ul class="ul1">
<li class="li1">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</li>
<li class="li1">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! :\</li>
<li class="li1">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.</li>
<li class="li1">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.</li>
<li class="li1">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.</li>
</ul>
<div class="p1">
Y lo que más me ha gustado:</div>
<ul class="ul1">
<li class="li1">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.</li>
<li class="li1">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.</li>
<li class="li1">Las charlas en la universidad con Jessi. Hay que evangelizar, y cuanto antes mejor :)</li>
<li class="li1">El foro de Adegi de emprendedores también ha sido un descubrimiento interesante.</li>
<li class="li1">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.</li>
<li class="li1">Salir de mi zona de confort, taaantas veces. ¡Pero si en uno de mis primeros clientes <a href="http://najaraba.blogspot.com.es/2012/05/agilismo-sin-software.html" target="_blank">ni siquiera desarrollaban software</a>! Por cierto, genial ese proyecto y me consta que están muy contentos con los cambios. :)</li>
</ul>
<div class="p4">
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 :) </div>
<div class="p4">
Y gracias especialmente a <b>los clientes que este año han confiado en mi</b>.<br />
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. :)</div>
<div class="p2">
<br /></div>
Joserrahttp://www.blogger.com/profile/10913840576521473720noreply@blogger.com3tag:blogger.com,1999:blog-9836993.post-67900290314068606522013-01-10T15:31:00.001+01:002013-01-14T15:54:14.726+01:006 tendencias para el 2013 en "Project Management"Me he quedado con una sensación rara tras leer este <a href="http://proyectosgestionyexcelencia.com/2013/01/10/esi-international-anuncia-su-top-10-de-tendencias-en-project-management/" target="_blank">artículo del ESI</a>. 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:<br />
<br />
Mis predicción de tendencias en gestión de proyectos para este año (y "ad infinitum") son:<br />
<br />
<ul>
<li>Las organizaciones se darán cuenta que no vale con tener líderes (expertos, PMs, ScMs,...), sino que hay que crear verdaderos equipos.</li>
<li>Algunas organizaciones triunfarán con la implantación de Agile, y se comerán a las que no consigan adaptarse. Otras fallarán, indudablemente.</li>
<li>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.</li>
<li>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.</li>
<li>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 :)</li>
<li>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.</li>
</ul>
<br />
<br />
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.Joserrahttp://www.blogger.com/profile/10913840576521473720noreply@blogger.com3tag:blogger.com,1999:blog-9836993.post-46695211570197726142012-11-02T12:52:00.000+01:002012-11-02T13:15:34.627+01:00El mito de la organización ágil (presentado en la CAS2012)<span style="font-size: x-small;">Este post es la explicación de mi presentación en la <a href="http://conferencia2012.agile-spain.org/" target="_blank">conferencia Agile-Spain 2012</a>. Podeis encontrar la presentación en slideshare: <a href="http://www.slideshare.net/jrramon/el-mito-de-la-organizacion-agil" target="_blank">El mito de la organización ágil</a>.</span><br />
<br />
Cuando hablamos de organizaciones ágiles, podemos hablar ya de varios modelos sobre los que se está trabajando, como por ejemplo:<br />
<ul><li>La <a href="http://connectedco.com/" target="_blank">organización conectada</a>, de Dave Gray. Nos muestra una organización como una serie de células, equipos aut</li>
<li>El modelo de <a href="http://www.betacodex.org/" target="_blank">BetaCodex</a>, 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.</li>
</ul><div>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 <a href="http://najaraba.blogspot.com.es/2008/02/el-producto-es-el-equipo.html" target="_blank">Equipo = Producto</a>. 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.</div><div>A nivel organizativo podemos escalarlo exactamente igual, y ya había una Ley que lo enunciaba:</div><blockquote class="tr_bq"><b>Ley de Conway:</b><br />
<span style="font-family: Leelawadee; font-size: 12pt;">Las </span><span style="font-family: Leelawadee; font-size: 12pt;">organizaciones</span><span style="font-family: Leelawadee; font-size: 12pt;"> </span><span style="font-family: Leelawadee; font-size: 12pt;">que</span><span style="font-family: Leelawadee; font-size: 12pt;"> </span><span style="font-family: Leelawadee; font-size: 12pt;">diseñan</span><span style="font-family: Leelawadee; font-size: 12pt;"> </span><span style="font-family: Leelawadee; font-size: 12pt;">sistemas</span><span style="font-family: Leelawadee; font-size: 12pt;"> </span><span style="font-family: Leelawadee; font-size: 12pt;">están</span><span style="font-family: Leelawadee; font-size: 12pt;"> </span><span style="font-family: Leelawadee; font-size: 12pt;">limitadas</span><span style="font-family: Leelawadee; font-size: 12pt;"> a </span><span style="font-family: Leelawadee; font-size: 12pt;">producir</span><span style="font-family: Leelawadee; font-size: 12pt;"> </span><span style="font-family: Leelawadee; font-size: 12pt;">diseños</span><span style="font-family: Leelawadee; font-size: 12pt;"> </span><span style="font-family: Leelawadee; font-size: 12pt;">que</span><span style="font-family: Leelawadee; font-size: 12pt;"> son </span><span style="font-family: Leelawadee; font-size: 12pt;">copias</span><span style="font-family: Leelawadee; font-size: 12pt;"> de </span><span style="font-family: Leelawadee; font-size: 12pt;">las</span><span style="font-family: Leelawadee; font-size: 12pt;"> </span><span style="font-family: Leelawadee; font-size: 12pt;">estructuras</span><span style="font-family: Leelawadee; font-size: 12pt;"> de </span><span style="font-family: Leelawadee; font-size: 12pt;">comunicación</span><span style="font-family: Leelawadee; font-size: 12pt;"> de </span><span style="font-family: Leelawadee; font-size: 12pt;">estas</span><span style="font-family: Leelawadee; font-size: 12pt;"> </span><span style="font-family: Leelawadee; font-size: 12pt;">organizaciones</span><span style="font-family: Leelawadee; font-size: 12pt;">.</span></blockquote><div>Es decir, si tu organización es una basura, solo generará más basura.</div><div>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.</div><div>¿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?</div><div><br />
</div><div>NUNCA. Nunca lo harán, básicamente, por que <a href="http://fractalsauna.wordpress.com/2012/09/01/there-is-no-organization/" target="_blank">las organizaciones NO existen</a>. 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?</div><div>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.</div><div>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:</div><div><ul><li><b>Una misión</b>: 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"</li>
<li><b>Con autonomía y respeto</b>: 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.</li>
<li><b>Sumando diferencias</b>: 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.</li>
<li><b>Con absoluta transparencia</b>: 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.</li>
<li><b>Donde el dinero es una consecuencia</b>: 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.</li>
</ul><div>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.</div></div><div>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 <a href="http://en.wikipedia.org/wiki/Lean_software_development" target="_blank">Lean</a>, <a href="http://www.worldblu.com/" target="_blank">Worldblu</a> o <a href="http://www.k2kemocionando.com/k2khaciendo.html" target="_blank">Koldo Saratxaga</a> entre otros.</div><div>Mención especial merece, bajo mi punto de vista, el llamado "<a href="http://newtechusa.net/agile/culture-hacking/" target="_blank">Culture Hacking</a>". La idea es que el mismo movimiento ágil es un hack de la cultura: procedimientos y valores que podemos usar para cambiar nuestras organizaciones.<br />
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. <b>No importará el "dibujo" de tu organización, si no el tipo de relaciones que vamos a crear diferentes entre las personas.</b><br />
<br />
No olvidemos que podemos cambiar aquello que nos incomoda o molesta, mejorar nuestro mundo alrededor. Espero veros en la CAS2013 ;)</div><div><br />
</div><iframe src="http://www.slideshare.net/slideshow/embed_code/14996043" width="476" height="400" frameborder="0" marginwidth="0" marginheight="0" scrolling="no"></iframe><br />
<br />
<div><br />
</div>Joserrahttp://www.blogger.com/profile/10913840576521473720noreply@blogger.com0tag:blogger.com,1999:blog-9836993.post-63609375109098473132012-10-29T17:14:00.001+01:002012-10-29T17:23:58.077+01:00CAS2012: La confirmación de una gran conferenciaPor fin ha pasado la <i>elegante</i> conferencia de <a href="http://conferencia2012.agile-spain.org/" target="_blank">Agile-Spain del 2012</a>. 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.<br />
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.<br />
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="float: left; margin-right: 1em; text-align: left;"><tbody>
<tr><td style="text-align: center;"><a href="http://3.bp.blogspot.com/-UayEh_Y55tU/UI2mw69O1_I/AAAAAAAAAHo/FVyRHAfmqNI/s1600/keynote.jpg" imageanchor="1" style="clear: right; margin-bottom: 1em; margin-left: auto; margin-right: auto;"><img alt="Masa K. Maeda en la Keynote de CAS2012 " border="0" height="150" src="http://3.bp.blogspot.com/-UayEh_Y55tU/UI2mw69O1_I/AAAAAAAAAHo/FVyRHAfmqNI/s200/keynote.jpg" title="Masa K. Maeda en la Keynote de CAS2012 " width="200" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Masa K. Maeda en la Keynote de CAS2012</td></tr>
</tbody></table>
El jueves comenzó la conferencia con la ponencia de <a href="https://twitter.com/masaKmaeda" target="_blank">Masa K. Maeda</a> 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.<br />
<br />
Mi siguiente charla fue la de <a href="https://twitter.com/diegocenzano" target="_blank">Diego Cenzano</a>. 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.<br />
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.<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<table cellpadding="0" cellspacing="0" class="tr-caption-container" style="float: right; text-align: right;"><tbody>
<tr><td style="text-align: center;"><a href="http://4.bp.blogspot.com/-bUEluNb8Pjg/UI6qD6q8iGI/AAAAAAAAAH4/j0vquMcko1c/s1600/san+martin+de+trevejo.jpg" imageanchor="1" style="clear: right; margin-bottom: 1em; margin-left: auto; margin-right: auto;"><img alt="san martín de trevejo" border="0" height="200" src="http://4.bp.blogspot.com/-bUEluNb8Pjg/UI6qD6q8iGI/AAAAAAAAAH4/j0vquMcko1c/s200/san+martin+de+trevejo.jpg" title="san martín de trevejo" width="150" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Descansando de la #CAS2012, en el norte<br />
de Cáceres, S. Martín de Trevejo.</td></tr>
</tbody></table>
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.<br />
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 ;).<br />
<br />
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.<br />
<br />
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.<br />
<br />
Nota: Podeis encontrar más referencias sobre la CAS2012 en <a href="https://docs.google.com/document/d/1SOxDNJd0c_14W2J1ZCyDEJp6NVYc1F5UQRpL7WyjoGo/edit" target="_blank">este documento</a>.<br />
<br />Joserrahttp://www.blogger.com/profile/10913840576521473720noreply@blogger.com2tag:blogger.com,1999:blog-9836993.post-81343804369043793872012-10-23T10:34:00.000+02:002013-02-16T17:14:09.494+01:00Próximos talleres en Pamplona: Lean/kanban y Retrospectivas<i><b>ACTUALIZACIÓN FEB. 2013: Cursos de <a href="http://www.agilar.es/trainings/108-lean-kanban" target="_blank">Lean/Kanban en San Sebastian</a> y <a href="http://www.agilar.es/trainings/107-lean-kanban" target="_blank">Madrid</a>.</b></i><br />
<br />
En Noviembre hemos organizado junto con <a href="http://www.cein.es/" target="_blank">CEIN</a> dos diferentes talleres, de una mañana de duración, sobre temáticas ágiles.<br />
<br />
<b>Taller Lean/Kanban</b><br />
El primer taller se realizará el<b> 9 de Noviembre</b>, 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.<br />
Puedes encontrar más información e inscripciones <a href="http://www.cein.es/cursos-y-eventos/taller-leankanban/" target="_blank">en la web de CEIN</a>.<br />
<br />
<b>Taller de retrospectivas eficientes</b><br />
El segundo taller es el día <b>28 de Noviembre</b> 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.<br />
Puedes encontrar más información e inscripciones <a href="http://www.cein.es/cursos-y-eventos/taller-asegura-la-mejora-continua-con-retrospectivas-eficientes/" target="_blank">en la web de CEIN</a>.Joserrahttp://www.blogger.com/profile/10913840576521473720noreply@blogger.com0tag:blogger.com,1999:blog-9836993.post-71597390347671245462012-10-01T13:03:00.000+02:002018-12-17T23:59:53.904+01:00Si llevo Kanban, también llevo los principios ágilesRecientemente se está hablando de si <a href="http://www.forbes.com/sites/stevedenning/2012/09/25/what-exactly-is-agile-is-kanban-agile/" target="_blank">kanban es una metodología ágil</a> o no. Creo que la primera vez que me lo plantee fue al leer una serie de magníficos posts de Michael Sahota sobre la cultura de las organizaciones.<br />
<blockquote class="tr_bq">
<i><b>NOTA:</b> Es realmente curioso que un tema tan específico haya llegado a una revista como Forbes. <a href="http://blogs.forbes.com/stevedenning/" target="_blank">Steve Denning</a>, al que debeis seguir atentamente si no lo haceis ya, está "fusilando" las ideas de Agile, pero moviendolas exactamente allá donde las necesitamos: en el mundo fuera de IT, hablando a la gente de siglas raras (CEOs, CTOs,...) y el resto de "managers" que no entienden el mundo IT.</i></blockquote>
M. Sahota empezó identificando los principios ágiles sobre una <a href="http://agilitrix.com/2011/03/how-to-make-your-culture-work/" target="_blank">clasificación de culturas organizacionales</a>.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="http://1.bp.blogspot.com/-O9zgpsB2DmQ/UGl1oWAvX-I/AAAAAAAAAHI/LGaA_dCCT5k/s1600/Schneider-Culture-Model-630x461.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="291" src="https://1.bp.blogspot.com/-O9zgpsB2DmQ/UGl1oWAvX-I/AAAAAAAAAHI/LGaA_dCCT5k/s400/Schneider-Culture-Model-630x461.jpg" width="400" /></a></div>
<br />
Este modelo, de <a href="http://www.amazon.ca/Reengineering-Alternative-William-Schneider/dp/0071359818" target="_blank">William Schneider</a>, tiene dos ejes, uno para la orientación a realismo/posibilismo y otro para la orientación de orientación a las personas o a la compañía. Sahota clasifica las regiones COLABORACIÓN y CRECIMIENTO como las que <a href="http://agilitrix.com/2011/03/agile-culture-is-all-about-people/" target="_blank">encajan con la cultura Ágil</a>. En resumen, establece los principios alineados con la cultura más adecuada a cada uno de ellos, y es donde se situan la mayoría de los 12 principios del manifiesto.<br />
Posteriormente <a href="http://agilitrix.com/2011/04/kanban-aligns-with-control-culture/" target="_blank">analizó kanban</a> como metodología, aplicando el mismo sistema, y Kanban según él, pertenece a al cuadrante de CONTROL.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="http://4.bp.blogspot.com/-zcP8gB7frHs/UGl2ClW0krI/AAAAAAAAAHQ/zvFa27nKdF8/s1600/Kanban-Culture-630x458.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="290" src="https://4.bp.blogspot.com/-zcP8gB7frHs/UGl2ClW0krI/AAAAAAAAAHQ/zvFa27nKdF8/s400/Kanban-Culture-630x458.jpg" width="400" /></a></div>
<br />
Se centra en el sistema, en los procesos, y únicamente hace una pequeña (aunque importante) referencia a mejorar colaborativamente. No quiere decir esto que kanban no pueda dar soporte a los principios ágiles,<a href="http://positiveincline.com/?p=727" target="_blank"> todos tienen cabida</a>.<br />
La clave para mi es la siguiente: Una vez comenté en un tweet, imposible de encontrar ya :(, que Kanban bien hecho llevaría a terminar haciendo Scrum. Por supuesto hablaba del desarrollo de producto, donde encaja muy bien Scrum. Pero a lo que realmente me refería, es que no concebía kanban sin aplicar los principios ágiles. Buscando la mejora continua con los valores y principios ágiles, en los cuales Scrum se fundamenta. Sin principios ágiles no hay Scrum. Sin embargo, sí podrías hablar de kanban sin esos principios.<br />
<br />
<div>
En realidad, kanban, como todas las herramientas es absolutamente agnóstica en cuanto a principios y valores. Más de una vez he insistido en la idea que podría parecer que hacer Scrum, sin hacerlo realmente. Si utilizas las reuniones, roles y artefactos de Scrum, pero no buscas la aplicación de los principios en los que se basa, no estás haciendo Scrum.<br />
<br />
Así que cuando voy a trabajar con un equipo que utiliza o empeiza a usar kanban, siempre llevo en la maleta los principios ágiles. El concepto de la gestión del flujo de trabajo y minimizar el trabajo en progreso de kanban, más los principios ágiles que nos guíen en nuestra mejora continua, crean una combinación ideal: un punto de partida muy útil para aquellos equipos que por las razones que fuera no pueden o no quieren empezar a trabajar con Scrum.<br />
<br />
<b>Actualización Enero 2013</b>: Un enlace interesante con la misma idea: <a href="http://agiletrail.com/2013/01/22/99-second-presentation-kanban-values-or-how-i-almost-attacked-a-manager-with-hot-coffee/" target="_blank">Kanban Values or How I Almost Attacked a Manager With Hot Coffee</a><br />
<br />
<b>Actualización Noviembre 2018 (!)</b>: Mi última visión sobre <a href="https://www.ynspira.com/la-mayoria-de-edad-de-agile-y-los-principios-agiles/">los principios ágiles</a>. ¿los hemos perdido?<br />
<br />
<b>Actualización Diciembre 2018</b>: Sobre el <a href="https://www.ynspira.com/puentes-para-un-agile-manager-cas2018/">Agile Manager</a>.</div>
<br />Joserrahttp://www.blogger.com/profile/10913840576521473720noreply@blogger.com2tag:blogger.com,1999:blog-9836993.post-66114615786179400212012-09-04T22:42:00.000+02:002012-09-04T22:42:28.106+02:00Formación en Agile Coaching - Noviembre 2012Este Noviembre <a href="https://twitter.com/berariel" target="_blank">Ariel Ber</a> y yo vamos a impartir una <a href="http://www.agilar.org/trainings/70-agile-coaching" target="_blank">formación en Agile Coaching</a>, con Agilar. Se realizará en Madrid, y haremos un curso muy práctico, intentando transmitir también nuestra experiencia. No debéis dejar pasar esta oportunidad de escuchar a Ariel en acción ;)<br />
Os pego la introducción al curso. Daos prisa que hasta el 24 de Septiembre hay descuento por inscripción temprana :)<br />
<br />
<br />
<div class="p1" style="font-family: verdana, arial, helvetica, sans-serif; font-size: 12px; padding: 0px;">
Si te has hecho alguna de estas preguntas: </div>
<ul class="ul1" style="font-family: verdana, arial, helvetica, sans-serif; font-size: 12px;">
<li class="li2">¿Observas que tus equipos hacen agilismo, pero no <b>son</b> ágiles?</li>
<li class="li2">¿La mejora continua hace tiempo que dejó de ser continua?</li>
<li class="li2">¿Echaste en falta técnicas para trabajar con un equipo?</li>
<li class="li2">¿Cómo ayudar a los Scrum Masters de los equipos? ¿Necesitas comprender las motivaciones de las personas?</li>
<li class="li2">¿Cómo me enfrento a nuevos retos, tras los primeros pasos en el agilismo de los equipos?</li>
</ul>
<div class="p1" style="font-family: verdana, arial, helvetica, sans-serif; font-size: 12px; padding: 0px;">
<br />
Entonces, has encontrado lo que buscas.<br />
<br />
Si sientes que necesitas superpoderes porque has sobrepasado tu zona de confort como Scrum Master y la organización te pide abordar el trabajo con varios equipos a la vez o atravesar las fronteras y conquistar terrenos hasta entonces desconocidos (involucrar al resto de la organización, gerencia, clientes, etc.).<br />
Las herramientas que adquieres como Scrum Master son beneficiosas e imprescindibles para aplicar en equipos ágiles. Sin embargo, ya sea por su escalabilidad o por demandas de equipos avanzados, necesitas ampliar la visión del sistema. A través de este curso les proponemos desplegar y potenciar toda vuestra capacidad y habilidad para orientar y acompañar en la evolución a los equipos y a las personas. Un paso fundamental en el camino ágil hacia el máximo rendimiento.</div>
<br />
<br />
URL: <a href="http://www.agilar.org/trainings/70-agile-coaching">http://www.agilar.org/trainings/70-agile-coaching</a><br />
<br />Joserrahttp://www.blogger.com/profile/10913840576521473720noreply@blogger.com0tag:blogger.com,1999:blog-9836993.post-11990036278086133172012-09-02T17:01:00.001+02:002012-09-04T20:01:46.968+02:00Mi paso por la ALE2012<br />
<div class="p1">
<a href="http://4.bp.blogspot.com/-1QophQtpd6c/UEN0JolPbDI/AAAAAAAAAGo/5JG2wef37tY/s1600/1346244041029.jpg" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" height="240" src="http://4.bp.blogspot.com/-1QophQtpd6c/UEN0JolPbDI/AAAAAAAAAGo/5JG2wef37tY/s320/1346244041029.jpg" width="320" /></a>La comunidad <a href="http://alenetwork.eu/" target="_blank">ALE</a> ha creado una <a href="http://ale2012.alenetwork.eu/" target="_blank">conferencia impresionante</a> esta semana en Barcelona, tanto de organización como de contenidos. He disfrutado de tres días muy intensos en varios aspectos. Por un lado, he aprendido mucho y me llevo un montón de ideas. Además, he disfrutado del tiempo con la gente española que había por allá, conociendo a más gente mejor, y viendo que soy capaz de defenderme en inglés. Y por último, he charlado con uno de mis ídolos de <i>teenager</i> ágil :_)</div>
<br />
<br />
<div class="p1">
<br /></div>
<div class="p2">
<br /></div>
<div class="p1">
Decir que había niños jugando alrededor de los ponentes, indios cantando y gente danzando alrededor y castellers; es decir muy poco de esta conferencia. Ante todo he visto <b>grandísimos profesionales</b>, de esos que valoran hacer las cosas bien, compartir, e intentar cambiar el mundo de su alrededor. </div>
<div class="p2">
<br /></div>
<div class="p1">
<a href="http://4.bp.blogspot.com/-6l-gNVV2Lo0/UEN0PkkXvVI/AAAAAAAAAGw/ig8TqItmlHo/s1600/1346253597197.jpg" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" height="200" src="http://4.bp.blogspot.com/-6l-gNVV2Lo0/UEN0PkkXvVI/AAAAAAAAAGw/ig8TqItmlHo/s200/1346253597197.jpg" width="150" /></a>El tema que más recurrente ha sido en mi conferencia, ha tratado alrededor del <a href="http://adamfeuer.com/blog/2011/11/20/culture-hacking/" target="_blank">Culture Hacking</a>, del diseño consciente de las organizaciones. Del cambio que debe producirse para que las organizaciones tóxicas y enfermas cambien hace lugares más humanos, felices. La duda es si realmente este cambio se puede hacer siempre, porque una idea recurrente en esto es: abandona si ves que te das de cabezazos contra una pared. No intentes ayudar al que no quiere cambiar. Nadie tiene una receta de a dónde ir, pero si tenemos una guía de cómo buscar el camino. </div>
<div class="p2">
<br /></div>
<div class="p1">
La democracia en el trabajo es otro concepto interesante, pero confuso en mi opinión. Si entendemos la democracia como el poder de la mayoría, no deberíamos hacerlo. Debemos buscar la unanimidad para las decisiones. Las jerarquías no son ni buenas ni malas de por sí, es solo una conclusión de nuestra limitada capacidad de manejar información.</div>
<div class="p2">
<br /></div>
<div class="p1">
<a href="http://4.bp.blogspot.com/-0A9Mr2IMtGE/UEN0UpdA77I/AAAAAAAAAG4/Lqm-8yxqdEE/s1600/IMG_20120831_105311.jpg" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" height="240" src="http://4.bp.blogspot.com/-0A9Mr2IMtGE/UEN0UpdA77I/AAAAAAAAAG4/Lqm-8yxqdEE/s320/IMG_20120831_105311.jpg" width="320" /></a>Como cosas más prácticas, me llevo más de una idea para las retrospectivas, por ejemplo, cómo emplear metáforas potentes y una gestión de hipótesis para mover a la acción. También un ejercicio interesante sobre cómo poner en práctica la creación del árbol de valores y principios de Lysa Adkins. En realidad, tengo el cuaderno lleno de notas en los lados, sobre aplicaciones concretas que he encontrado para usar en consultorías con equipos y organizaciones.</div>
<div class="p2">
<br /></div>
<div class="p1">
Lo más fantástico de esta conferencia para mi, ha sido la conversación que tuvimos con <a href="https://twitter.com/mccarthyjim1" target="_blank">Jim MacCarthy</a> durante más de dos horas, sentados en un pasillo :) Empecé a hablar con él contándole como su idea de Equipo=Producto <a href="http://najaraba.blogspot.com.es/2008/02/el-producto-es-el-equipo.html" target="_blank">me había influido en mi camino</a> hacia el agilismo. Lo he contado tantas veces, que creo que solo me quedaba él :D. Se nos fue uniendo gente, y tuvimos una fascinante charla sobre su trabajo en Microsoft anteriormente, su visión del software, de cómo los <a href="http://www.mccarthyshow.com/the-core-protocols-online/" target="_blank">Core Protocols</a> nos ayudarán al hackeo y diseño consciente de las culturas en la organizaciones, del trabajo en equipo,… Awesome!!</div>
<div class="p2">
<br /></div>
<div class="p1">
Jim dio la primera keynote, francamente me gustó, aunque reconozco que estaba ya predispuesto. La keynote de Henrik Kniberg fue genial, al cierre de la conferencia. Muy pragmática, con consejos concretos, y divertida. No os las perdais, supongo que irán poniendo todos los contenidos <a href="http://ale2012.alenetwork.eu/2012/09/02/content-and-impressions-from-ale2012/" target="_blank">en este post</a>, así que seguidlo atentos.</div>
<div class="p2">
<br /></div>
<div class="p1">
Me pensé mucho si asistir a esta ALE2012, la verdad que me frenaba la barrera del idioma. Me he perdido algunos detalles, creo, pero he quedado muy satisfecho. Eso sí, mucho margen de mejora :) Pero ha merecido la pena. Ha sido una gran conferencia, y espero poder asistir el año que viene, allá donde sea. </div>
<div class="p1">
Un especial aplauso para los organizadores, que siendo como es una conferencia de la comunidad, sé bien lo que se curra en su preparación :)</div>
<div class="p2">
<br /></div>
<div class="p2">
<br /></div>
Joserrahttp://www.blogger.com/profile/10913840576521473720noreply@blogger.com2tag:blogger.com,1999:blog-9836993.post-40932207756253020952012-08-27T13:11:00.004+02:002012-08-27T13:11:57.220+02:00Agilar: jugando en equipoUno de los comentarios más certeros sobre mí, me lo dijo <a href="https://twitter.com/iturriozbeitia" target="_blank">un buen amigo</a> al decirme: "<i>Tú eres un jugador de equipo</i>". Esto dicho cuando te acabas de poner como freelance para buscarte la vida por tu cuenta, puede sonar a golpe bajo (¡ouch!), ¿para que quieres tener un coach personal teniendo amigos así? :) Pero en realidad, no le faltaba razón.<br />
Lo cierto es que me gusta trabajar en equipo. Compartir los objetivos. Compartir las alegrías y problemas del camino. Ayudar. Y es algo que cada vez iba a hacer menos trabajando por mi cuenta. En realidad, me han salido muchísimas colaboraciones y propuestas con más personas. Pero cada vez, las decisiones y los objetivos eran más individuales.<br />
<br />
<a href="http://3.bp.blogspot.com/-uth05SfjhXI/UDtVsrw6mdI/AAAAAAAAAGY/8-HUD3Mhxu4/s1600/agilar-logo.png" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" src="http://3.bp.blogspot.com/-uth05SfjhXI/UDtVsrw6mdI/AAAAAAAAAGY/8-HUD3Mhxu4/s1600/agilar-logo.png" /></a>Así que ahora, al cruzarme con un proyecto para trabajar en equipo (¡y vaya equipo!) no me ha costado demasiado trabajo decidirme. Me uno a <a href="http://www.agilar.org/" target="_blank">Agilar</a> para continuar desarrollando mi camino como "Agile Coach". Agilar está en un momento muy interesante, reinventándose como organización. Tenemos mucho trabajo por delante para crear la clase de organización que se adapte al agilismo y a nosotros. X. Quesada lidera la idea de crear la organización que este fundada por los valores ágiles. No podría estar más de acuerdo :)<br />
<br />
Sigo siendo autónomo, freelance. Tengo muchas colaboraciones entre manos, independientemente de este proyecto todavía. Dependo de mis propios pasos para llegar donde quiero (como todos en realidad, ;) supongo...). Pero ahora<i><b> juego en equipo</b></i>.Joserrahttp://www.blogger.com/profile/10913840576521473720noreply@blogger.com0tag:blogger.com,1999:blog-9836993.post-50999531803331828432012-07-11T00:32:00.000+02:002012-07-11T00:36:19.756+02:00Protocolos básicos para mantener la visión compartida (#coreProtocols) en un equipoCon un par de semanas de retraso, pero es que <a href="https://twitter.com/joserra_diaz/status/220552822649913344" target="_blank">me pillaron las vacaciones</a>, publico este post explicando uno de los temas que propuse en el AOS2012: los "<b>Core Protocols</b>" o comportamientos básicos para crear y mantener la visión compartida en un equipo.<br />
<br />
Mi presentación en el AOS traté de explicar y dar a conocer brevemente los Protocolos Básicos de comportamiento, que propone Jim McCarthy para el trabajo en equipo. Básicamente la idea nace de un concepto muy simple: <b>Equipo=Producto</b>. (Esta ecuación ya <a href="http://najaraba.blogspot.com.es/2008/02/el-producto-es-el-equipo.html" target="_blank">cambio mi mundo</a> en el 2008).<br />
Con esa idea en mente, los McCarthy se embarcaron en un experimento que debio ser bastante alucinante. Basicamente estudiar como diferentes equipos trabajaban juntos, observando y estudiando qué les hacía funcionar mejor. El mismo <a href="http://liveingreatness.com/origin-of-the-core-protocols/" target="_blank">lo explica ampliamente en su sitio</a>. Y el libro original lo podeis <a href="http://liveingreatness.com/software-for-your-head-book/" target="_blank">conseguir libre</a>.<br />
<br />
Doy acceso a un <a href="https://docs.google.com/document/d/154WO-WIl1Mn8ZACkPwYVxUo5KwOejullO1eofpTOEZg/edit" target="_blank">documento compartido</a> donde estábamos traduciendo algunos de los protocolos, y están traducidos los compromisos. Os explico qué hay en ese documento:<br />
<br />
Traté de explicar en la sesión del AOS lo que he leido sobre los protocolos y algún experimento que hemos hecho y lo que hemos trabajado. Básicamente se componen de dos partes. Primero, los <b>compromisos básicos</b>, una serie de principios, que deben ser compartidos por el equipo. Cuando los lees generalmente piensas que son obvios, y en cuanto rascas la superficie, te das cuenta del número ingente de veces que nos los saltamos. ¿quién no ha estado en una reunión escuchando y "aguantando" sin estar realmente presente, sin aportar valor? ¿quién no ha rechazado ideas sin evaluarlas, solo por que las dice Fulano o Mengano, al que no aguanto? Creo que es un ejercicio ver negro sobre blanco esta serie de asunciones, que no nos atrevemos a hablar en voz alta. (<i>Ya tienes tema para una retro de equipo ;)</i> )<br />
<br />
Por otro lado, hay una serie de protocolos... digamos, una serie de reglas de comportamiento. Sí, reglas. Sí, de comportamiento. Esto es lo que más rompe los esquemas. ¿reglas? ¿no debíamos basarnos en principios? ¿y además de comportamiento? ¿no es ir un paso más allá de donde es necesario? Pues ahí está mi duda. Como herramientas, muchas de ellas me parecen fabulosas, para tomar decisiones rápidas, para trabajar en reuniones, para asegurarte que entregas valor en cada situación productiva... y son cuestiones que se pueden ir incorporando a las técnicas de un equipo. Pero no sé como funcionará como reglas "de obligado cumplimiento" en un equipo. Todo será probarlo, e introducirlas como experimento poco a poco.<br />
La verdad es que da la impresión que encorsetará demasiado a un equipo. Por otro lado, me fascina tanto la posibilidad de que se pueda llegar a tener algo que nos acerque hacia el trabajo ideal en equipo, que me parece que merece una oportunidad. En realidad, sé que volvemos a lo de siempre, y es que si no se cree en los compromisos (principios) ninguna regla va a ir a poner orden en un equipo. Pero, podrían ayudar una vez en esa situación?<br />
<br />
Por otro lado, si alguien va a trabajar y experimentar con estos protocolos, dos cosas: No os olvideis de contármelo después :), y que sepáis que Jim McCarthy estará a finales de Agosto en la <a href="http://ale2012.alenetwork.eu/" target="_blank">ALE2012</a> en Barcelona, donde seguro que nos habla de su libro ;) Además, haré un descuento importante en algún trabajo de consultoría si quereis que lo trabajemos juntos :)<br />
<br />Joserrahttp://www.blogger.com/profile/10913840576521473720noreply@blogger.com0tag:blogger.com,1999:blog-9836993.post-43596099151782339682012-06-26T23:34:00.002+02:002012-06-26T23:35:54.804+02:00AOS2012, mi visiónEl pasado 22 y 23 de Junio tuvo lugar el <a href="http://aos2012.wordpress.com/post-aos" target="_blank">cuarto Open Space</a> general organizado por algunos voluntarios alrededor de la <a href="http://agile-spain.org/" target="_blank">Agile-Spain</a>. Lo que más debemos admirar y agradecer de todo esto, es que haya gente cada año, dispuesta a meterse en el follón de organizar un sarao. Bien un Open Space, o bien una conferencia a nivel nacional como la CAS. Yo solo sé mis razones por las que lo he hecho en otras ocasiones, pero intuyo que son poderosas en todas y cada una de las personas que lo hacen. Bravo por ellos. El año que viene en Canarias, el AOS2013, que ya tenía ganas el #comandomuyayo.<br />
¿cómo fue el AOS de este año? Para mi un Open con la gente de nivel que había junta alrededor de un panel, es prácticamente imposible que salga mal. Puedes equivocarte escogiendo sesión, pero siempre puedes cambiar. Puede no salir el tema que necesitas hablar, pero siempre puedes proponerlo. Lo peor sería que la gente de alrededor no fuese interesante, y eso, en este AOS, no fue así.<br />
Yo asistí a las siguientes sesiones, os cuento un poco cada una, por que para saber qué me gustó y qué se podía mejorar, lo podeis encontrar en el hilo del grupo de Agile-Spain, con el que intenté recabar precisamente un poco una especie de retrospectiva y poder sacar acciones más formales. Espero que sirvan a los organizadores del AOS2013.<br />
<br />
<ul>
<li>Kaizen + Kaikaku, esta charla de Ariel Ber y <strike>Jose Manuel Beas</strike>, intentaba mostrar los dos tipos de cambios que se pueden introducir. Podemos introducir los cambios de manera gradual, o de manera radical, rompedora. Cada tipo tiene sus beneficios y sus contras, y en general, creo que depende mucho del contexto. Particularmente, siempre me inclino más por el cambio gradual, que de tiempo a la gente a asimilar lo que se está haciendo, pero nunca se sabe...</li>
<li>Core Protocols, esta charla la propuse yo y hablamos de los protocolos y compromisos del libro "Software for your head". He hablado varias veces en este blog del mismo, y pronto pondré otro post un poco más extenso sobre esta sesión, y publicaré los protocolos que tengo traducidos.</li>
<li>Teatro del oprimido: Aquí pudimos ver todas las "virtudes" del modelo de empresa tóxica representados en un teatro, y pudimos hacer de espect-actores. Fue propuesta por Alan Cyment. Trabajamos un situación de dificultades laborales, muy típicas de algunas empresas en nuestro sector. En general, lo pasamos genial, y creo que se pudo entrever el potencial de esta técnica. Ahora bien, se la voy a dejar a psicólogos o especialistas, la verdad, por que me parece que puede ser brutal para situaciones de conflicto.</li>
<li>Estais Condenados, con ese título, solo podía ser de Xavi Gost. Xavi es el caballero negro con antorcha intentando quemar a los campesinos que adoran al rey. Así que intenta que creemos algo nuevo, algo donde podamos sustentar un crecimiento diferente, que no dé de comer al rey sus lacayos, las organizaciones malignas. Me hubiese gustado que esta sesión hubiésemos concretado un poco más en qué se puede hacer y cómo darle forma: redes de profesionales, organizaciones ¿diferentes?, cooperativas,... </li>
<li>Agile Coaching, esta sesión la propusimos entre Ariel Ber y yo. Francamente, ninguno de los dos quedamos demasiado contento con cómo nos salió. Así que espero que a alguno de vosotros que acudisteis os sirviese de algo. Nosotros al menos, aprenderemos un poquito, y la próxima vez que colaboremos, ya tenemos dónde mejorar... ah, y lo haremos pronto ;)</li>
</ul>
<div>
Lamentablemente no pudimos quedarnos la "kuadrilla" a las cervezas del sábado, pues había que volver pronto a casa.</div>
<div>
Me encanta volver a estos saraos y ver a mucha gente con la que comparto intereses, inquietudes, filias y fobias. Me encanta ir con amigos, evento tras evento. A los que faltaron, les echamos de menos ;)</div>
<div>
<br /></div>
<div>
Gracias a la organización, y por cierto, la aplicación para ver la parrilla en el móvil, simplemente genial. Ojalá la reaprovechen futuros eventos, y se vaya completando.</div>Joserrahttp://www.blogger.com/profile/10913840576521473720noreply@blogger.com1tag:blogger.com,1999:blog-9836993.post-32490666964510143902012-05-24T23:15:00.004+02:002023-02-15T09:59:47.401+01:00Open Space, para un roto o para un descosidoNOTA: Estoy escribiendo la guia de <a href="https://wearetayari.com/blog/open-space-guia-de-facilitacion/">facilitación de Open Space</a>.<br />
<br />
Hemos hablado varias veces aquí ya de los <a href="https://wearetayari.com/blog/open-space-guia-de-facilitacion/">Open Space</a> como un formato increible para la organización y <a href="https://wearetayari.com/blog/facilitacion/" target="_blank">facilitación</a> de conferencias. En Agile-Spain hemos organizado ya tres a nivel nacional, y han surgido multitud de pequeños "opens" para tratar muchos temas alrededor del agilismo.<br />
Si no sabes qué es un Open Space, echa <a href="http://www.proyectosagiles.org/que-es-open-space" target="_blank">un ojo a esta explicación</a>, o no entenderás demasiado el siguiente post :)<br />
Pero un Open Space puede servir más que para la organización de conferencias. Veamos una definición usada en http://www.openspaceworld.org/:<br />
<blockquote class="tr_bq">
<span style="background-color: white; font-family: "verdana" , sans-serif; font-size: x-small;">Open Space Technology is one way to enable all kinds of people, in any kind of organization, <b>to create inspired meetings and events</b>. Over the last 20+ years, it has also become clear that opening space, as an intentional leadership practice, <b>can create inspired organizations</b>, where ordinary people work together to create extraordinary results with regularity.</span></blockquote>
Me gusta por que coincide con uno de mis mantras: "<a href="http://najaraba.blogspot.com.es/2012/02/organizacion-agil-de-lo-racional-la.html" target="_blank">De lo racional a la inspiración</a>". Se puede usar el formato de Open Space como herramienta de gestión del cambio en las organizaciones. Es un formato que ensalza la participación, y que crear espacios de colaboración realmente potentes.<br />
Hasta ahora había visto este formato más como organización de conferencia o encuentros. Pero he visto el verdadero poder al facilitar un Open en una organización. Cuando participamos en un Open como formato de conferencia, cada uno se lleva lo que escucha y lo que aprende. Cuando realizamos un Open en una organización, es importante que quede constancia de los temas que se traten y las conclusiones a las que se llega. Es un regalo para la organización. Un punto de partida desde el que trabajar, donde la gente interesada ha participado para crearlo. Co-crear el cambio en una organización es un punto clave para que sea aceptado, y vaya en la dirección adecuada.<br />
<ul>
<li>Intenta involucrar al mayor número de personas posibles, pero no obligues a asistir. Insiste ;) , pero no obligues.</li>
<li>Calma en el momento de sacar temas. A veces parece que no salen nuevos temas, ten sangre fría :) siempre se generan muchas ideas.</li>
<li>Controla los tiempos, es importante cumplir los plazos marcados en la agenda.</li>
<li>Haz consciente a todos los asistentes que ni el facilitador ni la organización dirigen la reunión. Que un Open es SU reunión, SU agenda, y SUS conclusiones.</li>
<li>Haz enseguida un plan de acción para tratar las conclusiones.
</li>
</ul>
<div>
Dar la posibilidad a la gente de actuar en los cambios abre muchas puertas, muchas ideas, y genera una confianza increible en sus propias posibilidades. El camino del cambio en las organizaciones sufre muchas dificultades. <b>Inspira a la gente hacia la dirección adecuada</b>.</div>
<div>
<br /></div>
<div>
<br /></div>
Joserrahttp://www.blogger.com/profile/10913840576521473720noreply@blogger.com0tag:blogger.com,1999:blog-9836993.post-64252412668192434942012-05-24T09:19:00.001+02:002012-05-24T10:58:19.473+02:00Escuchando a la comunidad, a la gente, a los alumnosEstos dos últimos meses hemos pasado mi amiga <a href="https://twitter.com/#!/jessi_aguado" target="_blank">@jessi_aguado</a> y yo por tres universidades, proyectando nuestra visión del desarrollo de software, del agilismo, y básicamente, de buena parte de entender nuestra vida. En principio nos invitaron de la FISS de Donosti para dar una charla sobre metodologías ágiles, y de ahí, por una pequeña casualidad, Amalia (<a href="https://twitter.com/#!/amaliahern" target="_blank">@amaliahern</a>) me comentó de ir a Burgos a dar una charla con la misma idea: hablar a los alumnos sobre las metodologías ágiles. Así que amortizábamos un poquito más la charla y la dábamos dos veces. Finalmente, el día que la dimos en San Sebastian, nos invitaron también a Bilbao, así que ha sido un auténtico Agile Tour Universidades para nosotros. Jessi nos cuenta con mucho más detalle en su blog en su <a href="http://workingpasion.blogspot.com.es/2012/05/agile-tour-2012-cronica-de-una.html" target="_blank">particular crónica</a>.<br />
<br />
Esta es una de las cosas más agradecidas de cuando empiezas a trabajar para la comunidad. Al empezar a formar Agile-Spain, al ir a dar charlas en la Melee, a organizar conferencias a nivel nacional, al mover eventos locales,... siempre hay alguien que te pregunta: "<i>¿y cuanto dinero ganas con eso?</i>" Generalmente miro con cara de pena a quien me pregunta eso, porque tengo la impresión que se está perdiendo algo grande. No doy lecciones a nadie de lo que tiene que hacer, yo obtengo muchas satisfacciones de "trabajar" en un montón de historias que no me dan "pasta". Obtengo formación y aprendizaje, contactos, historias que contar,... pero también, y mejor aún, he hecho amigos, aventuras y tengo una sensación agradabilísima de haber hecho cosas importantes para la gente de alrededor.<br />
Ahora como profesional autónomo he cambiado bastante la idea de lo que significa invertir el tiempo, y sacarle un rendimiento económico al mismo. ¡No queda más remedio! :) Pero hay otra serie de cosas que seguiré haciendo mientras mi ya justa disponibilidad me lo permita. Es puro egoismo en realidad, me proporciona mucha más satisfacción que trabajo dedicado :)<br />
<br />
Os dejo a continuación la presentación, con explicaciones, preparada para los alumnos de universidad que quisieron venir a escucharnos. Intentamos que fuese una charla muy motivadora, hablando de lo que nos interesa, básicamente, ser felices en el trabajo.<br />
<br />
<div id="__ss_13049690" style="width: 477px;">
<strong style="display: block; margin: 12px 0 4px;"><a href="http://www.slideshare.net/jrramon/agiles-para-universitarios" target="_blank" title="La visión "ágil" del software para universitarios">La visión "ágil" del software para universitarios</a></strong> <iframe allowfullscreen="" frameborder="0" height="510" marginheight="0" marginwidth="0" scrolling="no" src="http://www.slideshare.net/slideshow/embed_code/13049690" width="477"></iframe> <br />
<div style="padding: 5px 0 12px;">
View more <a href="http://www.slideshare.net/" target="_blank">documents</a> from <a href="http://www.slideshare.net/jrramon" target="_blank">Jose Ramón Díaz</a> </div>
</div>Joserrahttp://www.blogger.com/profile/10913840576521473720noreply@blogger.com0tag:blogger.com,1999:blog-9836993.post-52866022327403466152012-05-16T23:26:00.002+02:002012-05-16T23:44:52.882+02:00Agilismo sin softwareAl establecerme como profesional independiente, queriendo ganarme las habichuelas como Agile Coach danzando al viento para esparcir los principios ágiles, no había pensado, que uno de mis primeros trabajos sería en una empresa NO relacionada con el desarrollo de sw.<br />
Por casualidades de los contactos (¡gracias!) estoy colaborando con una empresa de fabricación de componentes mecánicos para aeronautica. (!) Y <b>no producen software</b>. Aquí trabajan con la creación del proceso de industrialización, antes de crear piezas en serie. Así que mi primera reacción ante la petición de ayuda fue pensar, "¿y qué hago yo aquí?" Sin embargo, viendo el objetivo de la organización: crear equipos, organizar el trabajo del conocimiento, realizar cambios culturales,... le di una vuelta, y me di cuenta que era en gran parte lo que había tratado de hacer estos últimos años.<br />
Así que estoy trabajando con una organización que realiza industrializaciones de piezas de aeronautica, implantando Kanban, ayudando con la gestión de equipos, técnicas de retrospectivas y en general, ayudando a trabajar con una filosofía de mejora continua basada en Lean.<br />
<br />
Los problemas que he encontrado son básicamente los mismos que en los equipos de desarrollo de software, solo que aquí no entiendo nada de lo que producen :) ... ¡y no importa! Es verdad que en este area no puedo recomendar montar un servidor de integración continua, o explicar como hacer TDD. Pero puedo hablar de comunicación, de gestión de equipos, trabajar con paneles kanban, trabajar la organización del proceso,... es decir, transmitirles algunos de los valores más importantes para mi con el agilismo: transparencia, mejora continua, trabajo en equipo.<br />
<br />
La principal sorpresa fue trabajar con un <b>panel kanban de más de 40 fases</b>. Y comprobar que todos hacen falta. Olvidémonos de nuestro mítico análisis-diseño-desarrollo-testeo-deploy :)<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="http://1.bp.blogspot.com/-UQlZcdnhUxo/T7QW0tS44PI/AAAAAAAAAE0/N-K52Sc5dfA/s1600/panelKanban.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="196" src="http://1.bp.blogspot.com/-UQlZcdnhUxo/T7QW0tS44PI/AAAAAAAAAE0/N-K52Sc5dfA/s640/panelKanban.jpg" width="640" /></a></div>
<br />
El poder de reflejar el trabajo en un panel kanban es impresionante. De repente, tenemos información, y sobre todo, un lugar desde el que partir para mejorar. El equipo empieza a organizarse alrededor de ello. Y a contagiarse las ganas de hacer las cosas bien y mejor cada vez.<br />
<br />
Las prácticas y principios que hemos aprendido desde el desarrollo de software y metodologías ágiles, son transportables a otros mundos, donde el principal problema en común es la gestión del conocimiento. Lugares comunes donde la inspección y adaptación y las personas, son los mejores enfoques para afrontar los problemas.<br />
<br />
<br />Joserrahttp://www.blogger.com/profile/10913840576521473720noreply@blogger.com4