De como introducir Scrum creando un grass root movement

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

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

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?

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

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

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

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 :)