Juan Banda on Scrum

PMP vs. Agile Project Managers: Choque de Titanes

2012-05-23T13:26:00.000-04:00

Esta es una copia de la presentación que use en la conferencia del Scrum Gathering Regional Event Buenos Aires 2012:

PMPs vs Agile Project Managers - Choque de Titanes

Management 3.0 with Jurgen Appelo

2012-05-20T08:32:00.000-04:00

I just have been in a course with Jurgen Appelo, the author of the best seller Management 3.0 and I can tell that this has really been a refreshing experience. Jurgen is definitely a great trainer that has the ability to keep the class focused and at the same time having a good time. Thanks to Jurgen I now can say that I understand Dutch humor.

Jurgen approach to management, Agile management would be best to say, is definitely what we need in modern (or want-to-be-modern) organizations. His experiences are something that can, and perhaps should, be applied to other organizations that are still struggling with Agile.

Estare en el Scrum Gathering Regional Event Buenos Aires 2012

2012-05-15T08:55:00.000-04:00

Presentare el tema: PMPs vs Agile Project Managers: Choque de Titanes

Scrum 100

2012-04-23T10:47:00.001-04:00

Estas son las transparencias de la conferencia que di el pasado 20 de abril en el auditorio de la Universidad del Valle:

Scrum 100

View more PowerPoint from Juan Banda

Y estas son algunas fotos de los asistentes:

Tour Cono Sur 2011

2012-04-16T08:22:00.001-04:00

Un poco fuera de fecha pero aqui subo la presentacion que utilice para el PMI Tour Cono Sur 2011.

Administración agil de proyectos

View more PowerPoint from Juan Banda

Organizando el Scrum Bolivia Day 2012

2011-11-23T10:59:00.003-04:00

Soy parte de la organización de la primera conferencia Scrum Bolivia Day 2012, más información de la conferencia en este link http://scrumbolivia.com/?page_id=2

Después del curso de Certified Scrum Developer

2011-11-20T11:01:00.010-04:00

La semana pasada en Cochabamba-Bolivia se llevó a cabo el primer curso de CSD impartido por Kleer, el instructor fue Martin Alaimo y a continuación muestro algunas de las fotografías que tome de los diagramas que más me gustaron.

Este por ejemplo es un diagrama que muestra como se interelaciones los conceptos y prácticas de TDD (Test Driven Delopment) y ATDD (Acceptance Test Driven Delopment):Esta fotografía corresponde al taskboard que creamos con mi equipo:

Y estos son algunos de los impedimentos que encontramos en la retrospectiva con Martin después del primer sprint:

Administración Agil de Proyectos

2011-11-07T10:01:00.003-04:00

Resumen

Este artículo pretende atraer la mirada hacia el enfoque ágil de administración de proyectos que se ha venido utilizando con éxito desde hace más de una década en la administración de proyectos de desarrollo de software. Este enfoque se basa en la inspección y la adaptación continua de las tareas, procesos y buenas prácticas de interacción humana. La autogestión y el enfoque hacia tareas con alto valor para el cliente final son también componentes fundamentales de este paradigma.

Introducción

El campo de desarrollo de software es intrínsecamente complejo por los requerimientos cambiantes y poco tangibles, se suma a esto el alto grado de creatividad e innovación necesaria a la hora de construir software. En esencia los requerimientos son cambiantes porque los clientes en general no pueden definir por completo sus necesidades y porque estas van cambiando de acuerdo con las prioridades de la empresa y el rubro donde esta se desenvuelven.

Más aún, en este rubro alternativas como añadir más ingenieros a un proyecto o alargar la jornada laboral no garantizan en ningún caso que un proyecto pueda reencaminarse o siquiera terminarse.
Controlar los cambios a través de un proceso rígido de control de cambios tampoco es una alternativa pues genera excesiva documentación y burocracia. Así por ejemplo empresas con productos en la web no pueden darse el lujo de rechazar cambios o demorarse demasiado en implementarlos pues sus competidores podrían tomar ventaja si responden con mayor dinamismo.

De lo Predictivo a lo Adaptativo

Procesos tradicionales que tratan de estandarizar actividades que en esencia son creativas no funcionaron para este rubro particular. Enfoques como definir a máximo detalle y estandarizar procesos no tuvieron éxito porque simplemente cada proyecto es diferente en términos de tecnología, complejidad, interrelación y requerimientos. La creatividad que fluye en un equipo con ciertos individuos y en cierto proyecto particular es difícilmente medida, estudiada y replicada. Por el contrario, se buscaron alternativas como la “agilidad” que permite pasar de un enfoque predictivo a un enfoque adaptativo.

Dentro de este nuevo paradigma se reemplaza el enfoque que plantea la división del ciclo de vida del proyecto en fases bien marcadas y con actividades preestablecidas, por iteraciones cortas orientadas a tener productos tangibles al final de las mismas. Estas iteraciones cortas son precisamente micro-ciclos de vida que se desarrollan de principio a fin y que apuntan a construir un producto en incrementos finitos.

Al final de cada incremento finito se tiene una demostración para clientes reales de la funcionalidad implementada. Esta demostración es la que provee las entradas para adaptar el producto y encaminar mejor la siguiente iteración. Por su parte, el equipo de trabajo dentro de la iteración se auto-inspecciona constantemente y va adaptando sus prácticas y procesos para llegar a producir un producto con valor y calidad al final de cada iteración.

Enfoque en el Valor, no en las Tareas

Mucho del éxito del enfoque ágil de administración de proyectos proviene de minimizar la cantidad de trabajo innecesario que conduce a completar tareas que no contribuyen o contribuyen muy poco a agregarle valor al producto final. El valor es considerado no desde la perspectiva técnica de quienes construyen el producto sino desde la perspectiva de negocio de los clientes finales.

Priorizar tareas es clave dentro de este enfoque, la priorización se realiza tanto al inicio del proyecto como al final de da iteración. De hecho el proceso de control de cambios permite que nuevos requerimientos sean ingresados aún tarde en el desarrollo del proyecto pero estos no serán atendidos hasta que no se termine la iteración actual y hasta que hayan sido adecuadamente priorizados.

La forma en la cual se evita el scope creep consiste no en rechazar requerimientos sino más bien en aceptarlos pero manteniendo en todo momento una lista priorizada de requerimientos con alto valor para el cliente y que pueden ser implementados considerando la velocidad del equipo.

La documentación que acompaña a un proyecto es generada y mantenida siempre y cuando esta aporte valor al cliente final. Esta práctica permite liberar tiempo y recursos tradicionalmente destinados a estas tareas y reasignarlos a tareas que aporten mayor valor para el cliente.

El valor para el cliente es aparentemente difícil de medir en un producto intangible como el software, pero en la práctica las técnicas de análisis de negocios permiten cuantificar, medir y extrapolar no solo el valor de una característica para un cliente sino para una comunidad de clientes finales.

Los Principios Agiles

La agilidad se funda en los principios básicos planteados por el “Manifiesto Ágil” a los cuales se suman modelos de administración ágil de proyectos y marcos de trabajo para equipos multidisciplinarios.

Los principios del citado manifiesto se basan en pilares como el cambio de énfasis de los procesos y herramientas hacia los individuos y la interacción entre ellos. Esto viene de la mano de conceptos tales como empoderamiento del equipo y autogestión.

Se incorpora también el pragmatismo que apunta a tener software funcionando y de utilidad para el cliente final en lugar de documentos de diseño extensivos.

Un tercer pilar habla de la incorporación de los clientes en el proceso de construcción del producto, incorporación que es factible ya que al final de cada iteración el equipo puede tener un producto tangible (más no terminado) que puede mostrar para recolectar mejores requerimientos y retroalimentación. Este punto es de vital importancia ya que durante décadas se trató sin éxito de relevar requerimientos con diagramas y otros artefactos cuando en realidad lo más efectivo es acercar al cliente al producto que este espera tener como resultado de su inversión en el proyecto.

El cuarto y último pilar del Manifiesto Ágil tiene que ver con la adaptabilidad, es decir con la capacidad intelectual, organizativa, motivacional y creativa que debe tener un equipo para poder responder a los cambios inherentes al proyecto y reajustar su horizonte sin perder de vista que el objetivo final de sacar un producto al mercado con valor para los clientes.

Conclusiones

Los principios de la agilidad y la administración ágil pueden ser extensibles a otros campos de la ingeniería. Por ejemplo empresas como 3M o Nokia donde la innovación constante es fomentada, vienen aplicando estos principios desde hace bastante tiempo y con resultados por demás exitosos. Inclusive rubros en los cuales el trabajo repetitivo requiera poca invención pueden beneficiarse del enfoque de mejora continua (kaizen) que traen consigo las iteraciones.

Referencias

• Agile Project Management: Creating Innovative Products, Jim Highsmith, 2004
• Agile Project Management with Scrum, Ken Schwaber, 2004
• The Software Project Manager's Bridge to Agility, Michele Sliger and Stacia Broderick, 2008
• El Manifesto Ágil http://www.agilemanifesto.org/iso/es/
• International Institute of Business Analysis http://www.iiba.org/imis15/IIBA/Home/IIBA_Website/home.aspx
• Scrum Alliance http://www.scrumalliance.org

Las transaparencias que use para esta presentacion pueden encontrarse en este link http://percella.com/administracion-agil-de-proyecto/

Daily Scrum Meeting en Sensillo

2011-10-27T15:33:00.004-04:00

¿Qué es el Daily Scrum Meeting?

Es un meeting diario de todos los miembros activos del equipo.

¿Quienes participan?

Solamente miembros del equipo. Para que la reunión sea productiva cada miembro del equipo debe participar activamente. Managers y otras personas pueden participar solamente como oyentes.

¿Cuál es el objetivo de la reunión?

El objetivo es tener un punto de inspección/comunicación/coordinación entre los miembros del equipo. El objetivo no es reportarse ante un supervisor, el objetivo es que cada miembro del equipo habla brevemente de las tareas que realizó, realiza y los problemas que encontró.

¿Cuál es el horario y duración de la reunión?

La reunión puede programarse a cualquier hora del día pero las mañanas es más recomendable. La duración de esta reunión es de máximo 15 minutos. Si hay necesidad de seguir hablando se debe programar una reunión separada solo con los miembros del equipo interesados en el tema.

¿Alguien preside o dirige la reunión? ¿Un team leader por ejemplo?

Esta reunión es participativa y no de reporte, por tanto todos los miembros del equipo deben participar dando sus opiniones. Si puede ser de ayuda que alguien ayude a mantener el orden de quien habla cuando o que verifique que la duración no exceda los 15 minutos.

¿Cómo ayudan los managers en este meeting?

De dos formas: primero, asegurándose que el equipo tenga el lugar y espacio para reunirse y segundo, ayudando a resolver las dudas, bloqueos y/o problemas que fueron expuestos en la reunión.

¿Hay algún formato a seguir para esta reunión?

La bibliografía de referencia recomienda hacer tres preguntas: ¿Qué hiciste ayer? ¿Qué harás hoy? ¿Hay algo que bloque tu trabajo? Sin embargo en la práctica cada equipo es libre de escoger las preguntas. Lo importante es que cada miembro del equipo pueda en un corto tiempo hablar de su trabajo, el estado del mismo y su impacto en el trabajo del resto de los miembros del equipo.

Proyecto casa de los Simpsons

2011-10-25T15:12:00.016-04:00

Los estudiantes de la Maestría de Ing. de Software de la Universidad Gabriel René Moreno trabajaron el fin de semana pasado en un ejercicio grupal que consistia en realizar una réplica de la casa de los Simpsons, esta foto ejemplifica los resultados alcanzados:

Fotografias adicionales y una presentación preparada por este grupo pueden encontrarse en los siguientes links:

https://picasaweb.google.com/107712459507918881105/SETheSimpsonSHuse
http://www.slideshare.net/timoteoPonce/model-making-simpsons-house

Y este es un link a las fotos que otro de los grupos amablemente compartio en Picasa:

https://picasaweb.google.com/113911593465885757955/SCRUM?locked=true&feat=email

Y esta es su presentacion en SlideShare http://www.slideshare.net/mianmilo/casa-de-los-simpson-10027129

Luis Antonio escribió en su blog acerca de este proyecto http://ryuchananything.blogspot.com/2011/11/casa-de-los-simpson-framework-scrum.html

Estas fotografias corresponde a un tercer grupo de trabajo:

Y cuya presentación se encuentra en el siguiente link http://www.slideshare.net/ebbicita/proyecto-casa-de-los-simpsons

Este video corresponde a un cuarto grupo (el equipo de Diego porque siempre hay un Diego en cada equipo :))

https://docs.google.com/leaf?id=0B0yvfg6mi1NKMmNkMTU4MmYtNDA0NC00YjJkLWIyNDktYzY3MGY1YTljMzY1&hl=en_US&pli=1

Del grupo de Diego también están estas presentaciones http://www.slideshare.net/diegozalles/proyecto-maestria

Y finalmente este es el link a la presentación del grupo de Roberto Carlos (no el cantante sino el ingeniero :))

http://www.slideshare.net/rhunoja/proyecto-casa-de-los-simpson

Definición de Exito para un Producto

2011-10-15T18:10:00.004-04:00

James Shore hizo una presentación excelente en Agiles 2011 en la cual puntualizo su visión de éxito para un producto software, en resumen James puntualizaba que un producto tiene exito cuando tres variables convergen: el negocio, la tecnología y la satisfacción pesonal.

El negocio se refiere concretamente a que el producto pueda sea rentable en un horizonte razonable de tiempo, es decir construir algo para un mercado que lo consuma y que además sea sostenible. Esta variable implica dinero que se invierte en un producto y que debe necesariamente retornar de alguna manera para justificar la inversion.

La segunda variable tiene que ver con que no basta con que un producto se venda bien, tiene que ser tecnologicamente sólido como para permitirle evolucionar rapidamente o adaptarse a nuevos requerimientos. Aqui la arquitectura flexible y las buenas prácticas de ingeniería (XP) son claves asi como también el fuerte compromiso del equipo con la calidad.

La tercera variable es la satisfación de la gente que trabaja haciendo el producto, esta satisfacción debe traducirse en éxito personal (no solo económico). La idea es simple, individuos satisfechos y motivados se consideran así mismos exitosos y estan dispuestos a trabajar en una versión aún mejorada del producto.

Algo que James puntualizó también es que las tres variables son de igual importancia y esa creo es la clave del asunto. No tener o tener muy poco de cualquiera de estas tres dimensiones comprometera el producto a corto o mediano plazo.

Bolivianos en Agiles 2011

2011-10-15T17:23:00.004-04:00

Once compatriotas asistimos a Agiles 2011 en Buenos Aires, fue una asistencia record que esperemos vaya en ascenso para la siguiente version del evento.

En la foto de izquiera a derecha Gabriela Espinoza, Juan Banda, Victor Hugo Rodriguez, Patricia Calderon, Israel Antezana, Marco Alba Lopez, Pablo Azero y Gonzalo Solano. No aparecieron para la foto Steven Rojas, Juan Pablo Soliz y Hugo Siles.

Reflexiones despues de rendir el examen PMI-ACP (Agile Certified Practitioner)

2011-10-07T12:07:00.004-04:00

Hoy por la mañana di el examen PMI-ACP y con la memoria aun fresca me animo a compartir algunas cosas que me parecieron bastante interesantes de este examen:

1. Las preguntas del examen están bien formuladas y bien redactadas, no dan mucho lugar a malas interpretaciones y son bastante objetivas.
2. Muchas de las preguntas están relacionadas con Scrum, con los roles, ceremonias y artefactos.
3. Sin embargo hay otras preguntas que hablan de aspectos más generales de Agile y del manifiesto agil.
4. Encontré muy pocas preguntas relacionadas a Lean y Kanban y solo unas cuantas que hablaban de Agile Earned Value.
5. Retrospectives es otro tópico sobre el cual tampoco encontré muchas preguntas pero las pocas que habían estaban bien relacionadas a la bibliografía recomendada por el PMI.
6. XP si estuvo presente y fuerte, varias preguntas respecto a TDD, integración continua, pair programing, collective code ownership, etc.
7. Los aspectos suaves de coaching los vi en muy pocas preguntas, lo cual es una lástima porque el libro Agile Coaching de Lyssa Atkins es un referente fundamental.

Me animo también a priorizar un poco la lista de libros de bibliografía que recomienda el PMI, desde luego esta es una opinión bien personal mía:

1. The Art of Agile Development, James Shore
2. Agile Project Management with Scrum, Ken Schwaber
3. The Software Project Manager's Bridge to Agility, Michele Sliger
4. User Stories Applied: For Agile Software Development, Mike Cohn
5. Agile Estimating and Planning, Mike Cohn
6. Coaching Agile Teams, Lyssa Adkins
7. Becoming Agile:...in an imperfect world, Greg Smith
8. Agile Retrospectives: Making Good Teams Great, Esther Derby
9. Agile Project Management: Creating Innovative Products, Jim Highsmith
10. Agile Software Development: The Cooperative Game, Alistair Cockburn
11. Lean-Agile Software Development: Achieving Enterprise Agility, Alan Shalloway

Finalmente un recurso que me resulto muy valioso a la hora de prepararse fueron los exámenes de prueba que AgileExam tiene en su sitio www.agileexams.com

De como introducir Scrum creando un grass root movement

2011-10-06T11:54:00.005-04:00

La introduccion de Scrum dentro de cualquier organizacion tiene varias compliaciones iniciales y de mantenimiento que en muchas oportunidad hacen que este proceso se trunque o no se lleve a buen termino. Uno de los problemas iniciales proviene del desconocimiento que todavia existe en la comunidad acerca de lo que es agil en general. Si esta corriente de pensamiento todavia no es conocida menos aun lo son los potenciales beneficios que pueda traer.

Un primer paso es el proceso de acercamiento en que la gente dentro de una empresa comienza a enterarse de agil y en particular de Scrum. En esta etapa generalmente quien hace el rol de evangelizador menciona que Scrum aportara grandes beneficios y satisfaccion al cliente. En este momento es cuando los genrente escuchan el discurso pro Scrum, sacan la calculadora y dicen wow, "esto es una maravilla, me voy a ahorrar un monton de dinero, todos a hacer Srum ya!"

Si uno tiene la suerte (en realidad la mala suerte) de que esto pase su empresa el siguiente problema al que se enfrentara es algo a lo que yo llamo "Scrum por mandato". Scrum es en esencia una forma de pensar y de trabajar en equipo, nada de lo cual puede ser dictado, medido y exigido en su cumplimiento. Generalmente las cosas que vienen por imposicion limitan el pensamiento creativo y eventualmente se desarticulan en cuanto la presion de quien las impuso es aliviada.

Hace falta algo que se pegue mas al "suelo" y no flote en las esferas de la gerencia. Algo que venga por conocimiento y que sea colectivo y propio de la gente que efectivamente contruye a un proyecto y que ve en Scrum una oportunidad para hacer su trabajo mas ameno y productivo. Encontre una imagen (logo de una banda rockera) que ilustra el sentido de este post.

Como se ve en la imagen el pasto "grass" va creciendo pero no se desprende del suelo con el viento, puede incluso ser cortado y parcialmente arrancado pero seguir ahi y volvera a crecer. Similarmente Scrum puede ser cambiado, criticado, sacudido, podado pero eventualmente continua.

Para lo anterior es esencial tener raices "roots" que hagan que la gente cree firmemente en algo y este despuesta a seguir creyendo en que de alguna forma va hacer que funcione dentro de su entorno. Este grupo de creyentes conversos o no conversos son la clave del "grass root movement".

Cual es mi consejo final? Si Usted es un gerente, no importe creyentes, formelos y deles libertad de experimentar con Scrum, suena loco pero con un poco de suerte y honestidad los beneficios seran grandes.

Si esta del otro lado de la cerca (ingenieros y pueblo en general) piense en que hermoso seria ser parte de un movimiento que creo la diferencia en su entorno y en su profesion.

Agile Testing Cuadrants

2011-09-28T13:56:00.003-04:00

Lysa Crispin en su libro Agile Testing http://www.amazon.com/Agile-Testing-Practical-Guide-Testers/dp/0321534468/ref=sr_1_1?ie=UTF8&qid=1317232671&sr=8-1 presenta un diagrama que me pareció interesante comentar, el diagrama es el siguiente y viene de la pagina 98

El eje horizontal va desde lo mas tecnológico hasta lo mas orientado al negocio, desde luego ambas cosas tienen valor y la segunda se funda en la primera. En el eje vertical en cambio hay dos caras, una que apunta a contribuir con tests que apoyen de alguna manera las labores de testo del equipo y la otra que se orienta a criticar el producto.

Apoyar al equipo con testeo manual no siempre es la forma mas efectiva como puede deducirse de este diagrama, el testeo tiene un gran valor pero se vuelve aun mas valioso cuando deja de ser una tarea mecánica y se convierte en una tarea exploratoria tendiente no solo a buscar defectos sino oportunidades de mejora para el software.

Esta división en cuadrantes también ayuda a identificar quien testea que o que habilidades y herramientas son requeridas para realizar cada tipo de testeo. Por el ejemplo los tipos de testeo que caen en el cuadrante Q1 son testeos realizados principalmente por los desarrolladores y requieren de un enfoque como Test Driven Development. Los unit test no son generalmente escritos por un equipo separados de testers, son los mismos desarrolladores quienes tienen que producirlos y mantenerlos. La idea aquí es simple: construir el test primero y luego recién hacer el código que pase el test. Un detalle importante es que los test generados en este cuadrante no se crean automáticamente, hay que invertir tiempo en crearlos y mantenerlos. La parte que si se automatiza es la incorporación de esos test en un proceso de generación de builds diarios.

El cuadrante Q2 es el clásico testeo de funcionalidad orientado a verificar que todas las partes encajen y estén funcionando correctamente, correctamente desde el punto de los user stories y las especificaciones que se desarrollaron en torno a los mismos. Este tipo de testeo esta orientado también a ver que todo lo que se prometió construir se haya construido, en otras palabras que el backlog se haya traducido en features incorporados a un software.

Q3 es sin duda el cuadrante que mas valor de negocio aporta al testeo, la estrella de este cuadrante para mi es el testo exploratorio que se basa en el conocimiento experto y la intuición de los testers. Este tipo de testeo no solamente se limita a mirar el producto como es hoy en día, sino explora y compara el producto con otros productos similares y aporta ideas de hacia donde podría evolucionar el software. Personalmente me gusta pensar en el testeo exploratorio desde dos ángulos: el primero orientado hacia la exploración interna del producto y el segundo hacia la exploración del ámbito de negocio donde coexiste el producto.La exploración interna esta orientada a descubrir bugs y limitaciones mientras que la exploración externa busca oportunidades y amenazas.

Finalmente el cuadrante Q4 se basa en el premisa de utilizar herramientas externas (o internas si hay los recursos para desarrollarlas) que sirvan para generar escenarios en los cuales el sistema sea probado con grandes volúmenes de datos o tenga tiempos de respuesta que no pueden pasar de ciertos umbrales. Estos tipos de testeo son igualmente valiosos y son clave a la hora de garantizar que un producto puedo escalar de muy pocos usuarios y transacciones hacia volúmenes significativos.

Curso de Certified Scrum Master en Santa Cruz de la Sierra

2011-09-19T09:26:00.002-04:00

En el mes de noviembre de este año tendremos el primer curso de Certified Scrum Master que sera dictado por Heitor Roriz, CST. La información de este curso se encuentra en este link http://www.scrumalliance.org/courses/20112927-certified-scrummaster

Rigidez en Scrum?

2011-08-08T11:28:00.002-04:00

Yo aporto con lo siguiente, ¿alguien podría decir que el karate es rígido? Pues al principio si lo es, rígido y repetitivo. Después de todos los movimientos del karate provienen de generaciones de practicantes que perfeccionaron cada movimiento y la forma como ensenarlo.

¿Ahora qué ocurre con los aprendices que consideran abandonar el karate porque es rígido? Pues lo abandonan con la impresión de que es un arte obsoleto e ineficiente para cualquier fin que tengan en mente.

¿Pero qué ocurre con los que perseveran y continúan practicando? Eventualmente superan la parte mecánica del aprendizaje y crean su propia visión basada en los principios recibidos. En un siguiente paso estos practicantes aprenden otros artes y los fusionan con lo que conocen y crean sus propias escuelas y llevan el arte al siguiente nivel.

Este proceso se conoce como Shu-Ha-Ri (aprender, desprenderse, trascender) y es muy similar al proceso de aprendizaje de cualquier cosa. Obviamente en la etapa de Shu todo luce rígido y de ahí la tentación es abandonar o modificar pero sin todavía tener el conocimiento suficiente como para hacer una buena adaptación. Piensen nuevamente en un karateca que en la segunda semana de práctica decide incorporar movimientos de aikido o decide "recortar" el arte eliminando ciertas patadas, ¿tendría sentido?

Para cerrar mi consejo es siempre continuar buscando que hay mas allá de la aparente rigidez, primero aplicar las reglas, luego criticarlas, luego adaptarlas y luego recién evolucionarlas. Esto es como un camino de iluminación que al igual que en las artes marciales requiere tiempo, paciencia, disciplina y algunos huesos rotos :)

LeanEssays: How Cadence Predicts Process

2011-08-01T15:36:00.000-04:00

LeanEssays: How Cadence Predicts Process: "If you want to learn a lot about a software development organization very quickly, there are a few simple questions you might ask. You might..."

It's been really refreshing reading this post From Mary Poppendieck, I recommend it a lot.

The Mythical Scrum Master

2010-07-21T17:59:00.002-04:00

I´m seeing many job posts requesting for Scrum Masters for all type of companies. Seems like more and more Scrum Masters are on high demand as they´re perceived as the ultimate professionals in our field. Still perceptions can be misleading, so let me take you back to the very definition of what an Scrum Master is (or should be).

• A Scrum Master is somebody from the team, not an outsider.
• A Scrum Master does engineering work; this is not a management position.
• As a result a Scrum Master is only assigned to one team. Actually is not assigned, is more like somebody from the team that bubble up as a potential Scrum Master.
• Scrum Masters are Scrum champions and enthusiasts, not “master” in the sense that they have the more in deep knowledge of Scrum. They know Scrum well enough to make it work for a team and guide others to learn and practice good Scrum.
• The Scrum Master title is nothing more like a role that an engineer in the team takes. Is not a position per se, is more like a role that can and should rotate among team members.
• Scrum Masters are not responsible for team´s success or failure; at the most they are responsible for the team making good or bad use of Scrum principles.
• Scrum Masters are not necessarily technology masters, they don´t have all the answers, but they can help their teams to find the right answers via collaborative work.
• Scrum Masters in reality are masters in finding ways for keeping their teams aligned and pushing in the same direction.
• Scrum Masters are like “buffer men”, they keep outsiders at the bay but are wise enough to allow the team to open for not becoming a silo.
• Good Scrum Masters are individuals that volunteer for taking the challenge to learn and help their teams to practice good Scrum.

A quick note here, what is good Scrum? Is short, this is a simple set of principles that works for your team but that still fall inside the Scrum framework. Scrum Master are not there for reinventing Scrum, just for digesting it and being humble enough to serve their teams in the journey of learning and practicing Scrum.

Agile 2010

2010-05-31T17:19:00.003-04:00

The Agile Alliance has confirmed that the 2010 conference will be in Orlando-Florida the second week of August

http://agile2010.agilealliance.org/

I´ll be there and hopefully this time I´ll have some time to visit Disney World :)

Agile Estimation and Planning: Demystifying the Black Art

2010-04-23T17:13:00.007-04:00

This article is not about how to do estimation and planning in detail for Scrum teams, no magic recipes or silver bullets, it´s not also about numerical models or techniques one hundred percent bullet proof. This is more about what I saw that it works in practice and how this correlates with Agile and Scrum values.

That been said and if still have your attention, let me start saying that I´ve borrowed the phrase "Demystifying the Black Art" from a Steve McConnell´s book. I did this for a very good reason, I´ve read that book many times and my only conclusion is that is impossible to provide accurate estimations for the simple reason that no one can predict the future. Understanding this simple fact prepare us for start doing Scrum estimations. Part of the preparation is, if you´re a manager, that you´ll need to resign to have everything accurately estimated before work even started.

But then what? Are Scrum projects totally chaotic? In a way, yes they are, the great difference though is that Scrum publicly recognizes that chaos is there, embraced it and prepares your mind set to cope with continuous change and adaptation.

Reestimate, Reestimate, ….

So, the new game becomes now not how good am I estimating, but rather how often I reestimate. Estimations in Scrum are not cemented deals, they are negotiable as work progresses through sprints, but then, how I can keep things under control without exhausting my team by adding more and more work? Answer is simple; if you add work then you move less priority work to the backlog and reestimate accordingly.

Again, is not a matter of having precise estimations, is a matter of being prepared to reestimate whenever is necessary. Further, there´s a learning curve that Scrum take full advantage of it. For instance, if you estimate a task and then keep your estimations even if you know they are not longer valid, then there´s no chance to refine them with new information and experience. Scrum on the contrary favors that you look and your estimations and make them up as many times as you feel so.

Last part sounds like nightmare for many managers, but come on, reestimating not only means that the number of hours will increase; frequently reestimations take things in the other direction. After all, everybody knows that people try to be over-conservative when providing initial estimations. So if you reestimate, there´s a fair good chance that you reduce the initial slack that you put just in case things get ugly.

No Black Art Anymore

But wait, estimation is still black art, something is missing and that is how to actually estimate. You can read many good books on the subject written by Mike Cohn, even attend to his seminars if you can afford it, but here´s is my simple and free advice: use group estimation. Estimations that are provided not only by one individual but by a group have more value and more chances to be not so much off the mark, why? Only because group estimations force the group to think it through before putting estimates.

Another piece of free advice, actually this comes from McConnell, estimate using ranges like thinking first in worst case estimates, then in best case estimates and put your more realistic estimate somewhere inside that range. Again, if you think in this as a group exercise you´d have more chances to make it successful, at least it won´t be boring :)

But what if the group can´t come to an agreement? Well you can buy the Cohn´s planning poker decks; note that you´ll need one deck per each individual in your team. I offer you a cheaper and in some cultures more fun solution: just vote using your fingers to indicate numbers, like one finger for one, two fingers for two and so on.

Team Alignment is Key

If we reach this far you’re almost ready to discover the secret behind planning: the truth is that Scrum planning is not more than a short meeting (by short I mean less than four hours) divided in two halves whereas the first half is for understanding what user stories are and the second for providing estimations. Again nothing new here, Scrum has been talking about planning meetings for quite a while now. Understanding what to do seems to be crucial, but wait we´re doing Scrum, aren’t we? Don´t fall in the trap of trying to understand what needs to be done to the last detail even before coding a single line, the only way to truly understand something is when you actually do the work.

What´s the value of having planning meetings? The answer is quiet simple: you get all your team in room and make them talk about their understanding of what needs to be done. That simple exercise will do the magic of aligning everybody´s energy and attention towards a common goal (a.k.a. Sprint goal). Like Jeff Sutherland said "Scrum is all about aligning your team in the same direction" and hence is the true value of planning meetings.

Orlando Scrum Gathering

2010-04-23T17:08:00.004-04:00

What a fantastic conference this has been! Check this link for a promotional video

http://www.scrumalliance.org/pages/media

And this other one for the presentations

http://www.scrumalliance.org/resources?tag=2010+Orlando+Gathering

Hope the Scrum Alliance continue organizing such great conferences

Agiles 2010

2010-04-19T17:54:00.009-04:00

La conferencia Latinoamericana de Metodologías Agiles ya está en marcha, más información aquí http://agiles2010.agiles.org/lang/es/

Herramientas Electrónicas y Scrum

2010-04-19T17:08:00.005-04:00

Veo un tema que se repite una y otra vez en varios foros y grupos de discusión, siempre hay alguien que repite la misma pregunta, ¿cuál es la mejor herramienta para hacer buen planning y tracking con Scrum?

Dependiendo del grado de conocimiento y experiencia de la gente de estos grupos de discusión, las respuestas varían desde herramientas sofisticadas y costosas como VersionOne, Rally o ScrumWorks hasta cosas más simples como Scrumy o algo en el medio como Xplanner o PivotalTracker. Inclusive Microsoft hizo su aporte con su herramienta-super-complicada-apta-para-todo-uso Team Fundation Server.

Desde luego siempre habrá buenos vendedores que recomendaran utilizar sus herramientas ofreciendo soporte, descuento por licencias o quien sabe que otro atractivo. Pero hay algo de más de fondo, ¿qué tan exitosa puede ser una herramienta en un equipo que no crea en su uso? Más aun, las herramientas por si solas no harán ningún bien, más bien complicaran el trabajo de un equipo creando un overhead a la hora de registrar user stories y horas.

Yendo un paso mas atrás, ¿porque se deben utilizar herramientas electrónica para hacer tracking del progreso? La respuesta Scrum a la pregunta es porque tenemos un equipo distribuido, de los contrario deberíamos volver la vieja y efectiva escuela del post-it.

Una paso mas atrás todavía, ¿de qué sirven las herramientas si los equipos nos tienen sólidos principios ingenieriles y de trabajo en equipo? En mi experiencia las herramientas no hacen ningún bien por si solas sino vienen acompañadas de una solida base en Agile, XP, Scrum y otro sabores agiles.

Ahora bien, una experiencia interesante es introducir herramientas en paralelo a la introducción de conceptos agiles. Esto puede tener sentido ya que el equipo recibe la influencia directa de la herramienta y puede corresponderla con los conceptos.

Finalmente, la utilización efectiva y constante de las herramientas dependerá de cuan convencido de su utilidad el equipo este. Los buenos vendedores pueden vender licencias, mas son los coaches los que llevan a los equipos a su utilización efectiva, constante y productiva.

Agile Course Related Blogs

2010-04-05T11:41:00.003-04:00

Some of the guys in the last Agile Course have been kind enough to publish in their blogs some notes and comments, check this out:

http://wildergonzo.blogspot.com/2010/04/curso-de-metodologias-agiles.html?showComment=1270474534800_AIe9_BFZkvKYElg2ocw7fbQt0vcRAEmLETc1kXOhaGYA9zITuSuMnTJ69yC-_y_IUgjnbtzoEG7UM3rmcaqjhfGCsy7WCSUlqUj59CCctVK_FjoZDHhDGjTIdYFNH71bL_ZtcN3uz7W796EFNkLEq_h751Bj5wyKyrDgV8kVyyszInX8bIE0dnc3PYgJ8MvwpbUuCcZVJDw0wzFOHgMQmTAo7Izy5rNqZT9yQFWCOuCAG5CVy-glRdDDSb7SY76LWhagWnZJRNnd#c32697514463012739

http://ajayu.memi.umss.edu.bo/jwuo/weblog/la-primera-exp