Juan Banda on Scrum

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.002-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

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

Total Football and Scrum

2010-03-25T11:41:00.004-04:00

I was looking for a good analogy to compare the lack of specialization that Scrum suggest for teams, and in my search came to memory that wonderful spectacle that Johan Cruyff http://en.wikipedia.org/wiki/Johan_Cruyff and the Dutch National Football Team offered in 1974 and 1978 Football World Cups. For those of you who are not too old, that was the point in time when the 'Total Football' http://en.wikipedia.org/wiki/Total_football concept was globally introduced.

Total Football like Scrum proposes no specialization, except for the goal keeper of course, and by doing this unleashes the talent and creativity of all team members. Having no roles implies a lot of discipline and superbly physical and mental condition. Flexibility come to the team but no at no cost, the team needs to realize that switching positions on the field implies greater synchronization and responsibility.

One of the principles behind Total Football is that in theory every player can score, so why constraining all that potential? Of course chaos happens if everybody tries to score at the same time, hence the importance of discipline in self-organizing teams.

Scrum teams should run by the same venue, just think in teams with no formal roles and cross-functionality at its best. Of course chaos is there, but good chaos that foster creativity and invention. Self-discipline and team alignment are crucial though.

Following this rationale, Scrum teams with specialized team members like developers and quality engineers are in disadvantage compared to fully cross-functional ones. Further, having only four guys out of seven producing code while the rest three are testing doesn't sound like the more beneficial approach, at least not production wise. Again, unleashing everybody's potential for writing code-both product and automation code-looks more beneficial.

Scrum en Sencillo

2010-03-17T17:05:00.001-04:00

¿Qué es Scrum?
Scrum es un marco de trabajo que define roles, artefactos y ceremonias que los equipos pueden emplear para trabajar más efectivamente.

¿Qué no es Scrum?
Scrum no es una metodología de desarrollo de software, una metodología es una secuencia ordenada de pasos realizados con algún fin. Scrum no sigue ninguna secuencia, no recomienda el orden de aplicación de sus componentes, simplemente los propone para que los equipos los utilicen en paralelo y durante todo el ciclo de desarrollo.

¿Por qué se invento Scrum?
Scrum se inventó ante la necesidad de tener alguna cosa que funcione en dominios caóticos con requerimientos cambiantes. Scrum pretende hacer que los equipos que lo utilicen se vuelvan hiperproductivos, estudios empíricos reportan mejoras hasta del 80% en diferentes indicadores.

¿En que se inspiró Scrum?
Scrum recoge mucho de la influencia del Toyota Production System y la escuela de Lean Development Software que se inspiró en los principios de Toyota. Scrum también se basa en los principios del Manifiesto Ágil.

¿Scrum hace énfasis en principios ingenieriles?
No, por el contrario enfatiza en principios humanos de colaboración y trabajo en equipo. Sin embargo Scrum se complementa perfectamente con enfoques más prescriptivos como eXtreme Programming que hace fuerte énfasis en los aspectos ingenieriles del desarrollo de software.

¿Cuáles son los valores de Scrum?
Scrum promueve la auto organización de los equipos reduciendo las labores asociadas con management. Scrum creen en empowerment del equipo pero a la vez trata de mantener una alineación de pensamiento y acción que hace que los miembros de un equipo apunten a trabajar en la misma dirección y con los mismos objetivos. Otro de sus valores claves es la inspección y adaptación que conducen a la mejora continua.

¿Scrum es solo aplicable para el desarrollo de software?
No, Scrum es apto para aplicarse a cualquier campo o industria en las cuales se tengan equipos de personas trabajando. Como se dijo antes, Scrum se inspiró en la industria automotriz y se aplicó a la industria del software, pero en esencia es aplicable a diferentes industrias.

¿Quiénes deben aprender Scrum?
No solamente los managers ya que los equipos son los que se auto organizan, por el contrario es recomendable que todos los miembros de un equipo aprendan Scrum y luego entre ellos decidan que roles asumirán.

¿Dónde reside el poder de Scrum?
En la simplicidad de su enfoque y en su filosofía que permite a los miembros de un equipo ser autocríticos y buscar la innovación y mejor continuas.

¿Es difícil aprender Scrum?
No, son principios son simples pero requieren de una gran disciplina para ser aplicados. Constancia y perseverancia son necesarias. Scrum es una de esas cosas, como las artes marciales, que son sencillas de aprender en principio pero difíciles de aplicar y perfeccionar.

Sutherland y su definicion de Scrum

2010-03-10T03:39:00.002-04:00

El otro dia escuche a Jeff Sutherland dando una deficion muy simple de lo que es Scrum, segun decia Scrum es algo que permite alinear a la gente de un equipo y hacer que se muevan en la misma direccion, algo como canalizar la energia de un grupo de personas.

Suena simple pero en esencia eso es lo que es Scrum, no es algo que funcione o haya sido pensado para que una persona sea mas productiva, por el contrario es algo que se penso para que un equipo sea hiperproductivo.

Mas aun, segun Jeff Scrum tiene valor cuando la gente hace de esta su herramienta y la adapta a sus necesidades. Jeff sin embargo decia que esta no es una adaptacion libre, por el contrario es una adaptacion que se debe basar siempre en adoptar principios que hagan al equipo mas production. En otras palabras, las adaptacion que uno haga del marco de Scrum deberian caer dentro de los principios de Agile y Lean.

La suposicion que muchas veces se hace es que los equipos que produscan mas seran automaticamente mas felices, cosa que no necesariamente es cierta. No debe olvidarse la esencia humana, de lo contrario se corre el riesgo de hacer de Scrum una herramienta de explotacion del capital humano de un equipo.

Artful Making

2010-03-09T08:01:00.004-04:00

Ayer estuve en un workshop con Lee Devin, uno de los autores de un libro buenisimo llamado Artful Making

Lee tiene una carrera bastante larga y exitosa como actor profesional y director de obras de teatro. Toda esa experiencia la volvo a ensenar teatro y eventualmente conocio al coautor del libro con el cual se animo a escribir acerca de como los ejercicios de relajacion y concentracion que utilizan los actores podrian ayudar a que la gente que trabaja en software pueda trabajar mejor.

El libro fue un exito y ahora son muchos managers e ingenieros al rededor del mundo lo leen. Definitivamente hay cosas en comun, el trabajo de los artistas es altamente desafiante e intelectualmente complicado-al igual que el nuestro. Basta con imaginarse la cantidad de parlamentos que los artistas tiene que memorizar y la gran capacidad de improvisacion que tiene que tener para cada obra. A esto hay que sumarle la gran capacidad de concentracion que deben tener para concentrarse en lo suyo y abstraerse de todo lo demas que pasa en el set de filmacion.

Desde la perspectiva de un manager hay mucho que copiar y aprender de un director de cine, despues de todo ambos dirigen grupos de individuos altamente talentosos y creativos. Dejar fluir esa creatividad es como dirigir una obra, es darle poder de decision y accion a los actores para que creen sobre la marcha pero siempre siguiendo un objetivo comun.

Equipos Hiperproductivos

2010-03-09T07:41:00.004-04:00

En el Scrum Gathering de Orlando 2010 acabo de escuchar una presentacion de Jeff Sutherland que para empezar fue buenisima y para continuar me hizo pensar en algunas cosas que no son tan evidentes.

Primero, segun Jeff la razon por la que el y Ken Schwaber crearon Scrum fue para poder tener proyectos exitosos en dominios caoticos como el de desarrollo de software. Jeff, que de formacion es piloto de combate y medico, se dio cuenta cuando paso a trabajar en la industria del software que ninguno de los principos tradicionales de ingeniria eran aplicables, habia que crear algo que se adaptase constantemente a circunstancias extremas.

Segundo, Scrum tiene por objetivo hacer que los equipos trabajen cuantitativa y cualitativamente mejor. Segun Jeff equipos que mejorarn un 20% despues de comenzar a utilizar Scrum practican algo que el llama "low Scrum", es decir, usan Scrum pero todavia no le sacaron todo el provecho que podrian. Razones para estas hay varias, desde falta de conocimiento hasta falta de apoyo de las organizaciones.

Tercero, los equipos hiperproductivos de los que hablar Jeff son equipos que mejoraron 100% o mas despues de usar Scrum. Suena extremo pero segun Jeff hay evidencia empirica y practica de que esto puede pasar.

Hablando de evidencia Jeff menciono algo interesante y basico a la vez, decia que si en un user story se tiene 20% de implementacion y 80% de testeo y bug fixing entonces la tasa neta de produccion es de apenas el 20%. Si esto podria invertirse y tener 80% desarrollo y 20% testeo mejoraria sustancialmente la produccion y la calidad del codigo en general. Esto segun Jeff ya implica una mejora cuanti y cualitativa.

Finalmente Jeff hablo acerca de la integracion de Scrum con CMMI, parece interesante y es un tema que estudiare mas a detalle. La verdad no estoy muy familiarizacon con CMMI asi que sera mi proximo objetivo de investigacion.

Sabores Agiles

2010-02-25T12:54:00.007-04:00

La forma más fácil de ejemplificar el movimiento Ágil es pensar en un helado, no por lo fresco y frio sino porque viene en capas y sabores y a todo el mundo le encanta :)

La base del cono de los sabores agiles reside en toda la teoría que trae consigo el Toyota Production System que luego evoluciono hacia el Toyota Way. Subiendo un poco más hacia arriba vemos que lo anterior dio origen a la escuela de pensamiento Lean que Mary and Tom Poppendiek magistralmente plasmaron en su propuesta de Lean Software Development[1].

Lean fue uno de los puntos de inspiración para la redacción del Manifiesto Ágil[2]. Este manifiesto ha sido leído, consultado y citado en innumerables publicaciones. Sin embargo, por si solo el manifiesto no es algo que pueda ponerse directamente en la práctica.

De hecho tanto Lean como Agile son en esencia herramientas de razonamiento[3] que permiten observar, pensar y actuar de cierta forma. Por ejemplo el Lean sugiere principios como eliminar desperdicios[4] que lo que hacen es colocarnos en un estado mental predispuesto para identificar tareas que no contribuyan directamente a la generación de valor en el producto-desperdicio y que por tanto deban ser eliminadas.

En consecuencia alguien podrá decir “yo pienso agile o yo pienso lean” pero no podrá decir “yo implemento agile o yo implemento lean”. La diferencia entre el pensar y el hacer es lo que separa el cono de los sabores del helado.

El primer sabor es XP (eXtremme Programming[5]) y como en la figura es el sabor sobre el cual se apilan los demás. XP aglutina un conjunto de prácticas de ingeniería pensadas y orientadas totalmente al desarrollo de software. Consecuentemente las practicas de XP son cosas de las cuales no se puede (ni debe) prescindir en cualquier proyecto de desarrollo de software.

Me encanta hacer la analogía entre XP y un auto de F1 que fue construido con un único propósito: correr lo más rápida y efectivamente posible. A un F1 no es posible (bueno posible si pero peligroso :)) recortarle piezas; ya es una joya de ingeniería en sí que tiene lo mínimo necesario para correr. Similarmente XP es una obra maestra de buenas prácticas que deben existir (insisto todas) en un proyecto de software. XP ya es ligero como es, no hay necesidad de recortarle nada. En este sentido XP es el más prescriptivo de los sabores agiles.

El siguiente sabor es Scrum[6] que se concibió como un marco de trabajo[7] ligero que sugiere (no impone) roles, artefactos y ceremonias. Scrum es un marco de trabajo no necesariamente asociado a desarrollo de software, de hecho es tan flexible que puede ser adaptado a otros dominios de aplicación. Un ejemplo interesante ocurre en mi organización donde se está usando Scrum para impartir cursos de inglés.

Scrum formalizo-y porque no mejoro-algunas de las buenas prácticas agiles que existían desde hace tiempo como iteraciones y user stories. Una de las grandes ventajas-o desventajas como quiera verse-es que Scrum tiene detrás una organización sin fines de lucro: el Scrum Alliance[8] que es especialmente activa proporcionando entrenamientos y certificaciones.

La cereza sobre el helado es kanban[9] que es una gran mejora sobre el taskboard recomendado por Scrum.

Helado sin cono

¿Es posible aplicar kanban sin hacer Scrum/XP y pensar en Agile/Lean? Equivale a preguntarse ¿es posible tener solo el ultimo sabor del helado y además sin el cono? La respuesta es obvia, desde luego que si pero uno acaba perdiéndose los demás sabores y comodidad de tener un cono que sostenga el helado mientras uno se lo come.

¿Sería posible aplicar solo Scrum sin nada de XP? Desde luego que sí, pero en algo que no tenga que ver con software. Por ejemplo, ¿de que me serviría utilizar a cabalidad Scrum si mi proyecto no cuenta con un build machine que garantice la integración continua del código producido?

¿Tiene sentido aplicar los principios de XP sin pensar en Agile y Lean? Muchos equipos lo hacen, pero por mas fuertes que sean los principios XP estos no hacen hincapié en los factores humanos (me encanta llamar a esto peopleware) que son el gran capital de un proyecto. Lean es especialmente útil aquí, después de todo Lean es aquella cosa mágica que permitió que Toyota llegue donde llego, algo de bueno ha de tener como para dejarlo pasar :)

[1] Lean Software Development: An Agile Toolkit (Agile Software Development Series) by Mary Poppendieck and Tom Poppendieck (Paperback - May 18, 2003)

[2] http://www.agilemanifesto.org/

[3] Traduccion literal de “thinking tools”

[4] Traduccion literal de “eliminate waste”

[5] http://xprogramming.com/index.php

[6] http://www.scrum.org/newsandupdates/2010/2/18/updated-scrum-guide-released.html

[7] Traducción literal de “framework”

[8] www.scrumalliance.org

[9] http://www.infoq.com/minibooks/kanban-scrum-minibook

And Who Should Estimate?

2010-02-05T09:37:00.004-04:00

Who is responsible for providing estimations? This is a question that is frequently being asked by teammates, especially when tasks are divided in development and testing tasks.

Some points that might answer this question below:

User Stories should be estimated from the time they'll start until the time they'll be completed
All related work has to be estimated, including of course testing work
Developers and quality engineers might estimate their individual tasks but User Stories has to estimated in conjunction. There has to be agreement around how much it'll take to complete a User Story and not only about how long it will take to implemented it or just testing it
Providing estimations is a collaborative tasks, actually it's a team effort so everybody has to be involved
Teammates needs to be aware of the 'broader picture'. Sometimes teammates just care about their piece of work but forget about how that is connected to other's work
At the end doesn't really matter who provide what estimation, what it matters is that the team feels comfortable with the estimations. Being comfortable means that the team has a gut feeling that estimations don't see to far stretched from reality

Orlando Scrum Gathering

2010-02-05T09:29:00.001-04:00

Save the date in March for the Orlando Scrum Gathering

Splitting User Stories

2010-01-22T09:14:00.003-04:00

I've heard many times from my teams that they have a hard time estimating user stories that are moved from the backlog to the Sprint, the most commonly sited problems are related to the size and ambiguity of user stories. I believe that this happens partly because the confusion about the backlog, more precisely, teams tend to think that there's only one backlog.

It's crucial that Scrum teams to recognize that in fact there are two backlogs, one Product Backlog and one Sprint Backlog. I describe below some characteristics of both:

The Product Backlog contains high level user stories created mainly by the Product Owner. Those user stories has to have business value and usually will require a lot of man-hours to implement.
User Stories in the Product Backlog has to be prioritized by the Product Owner based on her perception of business. Of course teams can have an stake on this but business value should be the key driver.
During the planing stage, teams take user stories from the top of the Product Backlog, digest them and decide what to include in the Sprint Backlog. Teams are expected to split Backlog User Stories in smaller chunks if necessary. Actually, it's highly recommended that they do so. Note that Product Backlog User Stories are high level whereas Sprint Backlog User Stories has to be good instruments for estimation, planning, and tracking. The 'devide and conquer' principle is applicable here.
Even before deciding what to move to the Sprint Backlog, teams need to considered their velocity (measured in story points or hours) to have a feel of their capacity. Velocity is a great indicator that helps preventing teams for overcommitting, of course that for this to be effective, teams need to have a clear perception of their velocity.
A crucial point here is that teams and not Product Owners decide what to move to the Sprint Backlog. Of course that the PO can influence and negotiate, but she shouldn't be allowed to overload teams beyond their capacity. Successful teams don't refuse to work on something, they accept to work on that something in exchange of something else.
A symptom-at least in early Sprints-for things not going that well is that the Sprint Backlog would be bigger than the Product Backlog, this might indicate that: A, the Product Backlog doesn't exist or still in process of being created or B, the team is overcommitting and trying to complete too many User Stories in an Sprint. A could be a also a indicator that the PO is not involved in the project. B typically happens when teams aren't aware of their own velocity.

User Stories Size, Having a Problem Estimating Them?

2010-01-21T09:10:00.005-04:00

Estimating user stories size can become a dangerous obsession, I mean, what are the changes that you can accurately estimate the size of a piece of work in a changeable and fuzzy domain like software development? The more experience that you acquire on this, the more that you'd tend to answer that chances are very slim. And why is that? Part of this is because you don't have fixed requirements, actually you don't want to have fixed requirements, we're doing Agile remember?

But then, how can you provide estimates to keep your bosses happy? You might try to provide extra-super-pessimistic estimations to create some buffering in case things get ugly, but this might create the false perception in management that you are inefficient or at least lazy-not a bad estimator which in reality you maybe are.

So, the advice that I can provide is first start evaluating your user stories to order them from ultra-complex to piece of cake. Knowing that something would be twice as complex as something else will provide you visibility on what should be tackled first or by whom in the team. Once you have your user stories ordered, you can add a countable unit (like story points, complexity level, effort or whatever that you consider appropriate) to your user stories. By doing this, management would perceive the complexity (and hopefully the cost) of implementing something and would be able to pick what should be implemented first or what is more crucial.

Shifting management's focus from accuracy in estimations to complexity could give you some degrees to maneuver. At least you won't have to worry because you offset the mark for X number of hours. You'd be worried instead for keeping complexity under an manageable level.

Sprint Planning Insights

2009-11-26T16:52:00.007-04:00

We typically start Sprint planning moving user stories from the Product Backlog to the Sprint Backlog. However, we need to take into consideration that:

User stories can be split, actually they should be split to accommodate them in a three to five days time frame
User stories in the Sprint Backlog must include all necessary work; development, infodev and QE (Quality Engineering) tasks would need to be considered
User stories should be delivered on a weekly basis, we should try to avoid at all cost to deliver all user stories by the end of the Sprint. On the contrary, our target should be to deliver small increments of implemented and tested functionality each week, see the bar chart below

A collateral benefit of having weekly deliverables is that by doing this, we'll contribute to distributing work evenly during the Sprint-sustainable phase concept-avoiding peaks at the end of the Sprint that usually cause to have implemented but not tested user stories.

I think that the key for this to happen is good planning, good in the sense of team's involvement but not description of tasks to the last detail. It's very common that planning is more an individual effort focused on estimating hours the more accurately than experience and guessing can permit.

Scrum approach for this is quiet different, firstly, planning is a team's activity were everybody has an stake. Secondly, it's divided in two parts: one for understanding what has to be done for each user story, and the other for providing time estimations. Both sessions combined should not take more than eight hours-it's recommended that the team invest four hours tops in each part.

The first part is also good for developers and QEs to communicate their understanding of what needs to be done; feedback from the whole team is what in general would increase the degree of understanding of what would be done and how it would be tested.

For the part where time estimations should be provided, I've been working in an approach that might work, no magic recipe that can be extrapolated to all teams but certainly the essence can be adapted to team's particular needs.

Let's start recognizing that estimations will always be inaccurate, no matter how much effort and time you invest. Further, estimating only hours is by far the most inaccurate way to estimate tasks duration.

An alternative is to estimate size and complexity. My preferred technique for this is a vote by a show of hands. If size and complexity are defined next comes priority, again the team would need to decide what they'd need to tackle first. This goes hand in hand with Sprint Backlog prioritization.

Practical experience shows that having a target date for implementation helps QE to get prepared for receiving implemented user stories. It's also a good idea to provide an estimation for this.

Hours come next and again the team should vote for estimating them to tasks. This voting would take into consideration the other already estimated parameters and hopefully would conduct to a more educated guessing. Again, accuracy is not what we're looking for.

Lastly, team members can start to volunteer for the work they want to do for the Sprint. Work balancing would be oriented to balance complexity and size more than just hours. I present and spreadsheet that summarizes this approach:

And Who Will Guard the Guardians?

2009-11-25T10:09:00.007-04:00

Another interesting questions that I've heard the other day, do the code produced by automation guys has to be code reviewed and unit tested?

Again, some analysis before answering. Automation code run against a product and automatically executed test cases that otherwise would have to have been executed manually. There's an investment in building automated testing suites, but this greatly pays off when automation can be executed repetitively and in a fraction of time and cost of what it'd have taken to do it manually.

Automation can be used as part of a Build Verification Test that quickly smoke test builds to check if anything has been broken. Nevertheless, automation can also be extended to test product functionality and here's where the problem starts, what if automation is not catching errors?

Many times errors are not caught because the original test case has not been well designed or is outdated, but in many more occasions automation is failing because it has its own bugs. In past projects I've heard several times that those errors that were easily manually reproduced, passed automated test. This was of course a huge alarm sign that was pointing in the direction that code produced for automated suites had been poorly tested if tested at all.

Thus, automation can be hindered if good development practices are not applied for all code that automation team are producing. After all automation guys are still developers producing code that needs to be tested by a third party. Going back to the question, this is my two fold answers: first, automation guys should unit test and code review the code that they produced, second, Quality Engineers should test automated test cases and suites like they test other software.

And Who Appoints The Product Owner?

2009-11-24T08:57:00.005-04:00

This is a very interesting question that I think that deserves some analysis before answer it. Let's start saying that the Product Owner is usually appointed by the organization and not by the team.

Even though Scrum literature does say that the Scrum Team it's self governed and can appoint their own Scrum Master, it doesn't say much about who appoints the Product Owner and how could decide to remove him if necessary. My recommended rule of thumb would be this: the Product Owner-originally appointed by his organization-could be removed if the team agrees and present a business case that justifies this decision. Upper management endorsement would be required though.

In my experience, Product Owners have a great deal of talent and experience dealing with clients, they're part of the sales force; more clearly, they're the advance team with clients. They have a great ability convincing people-both clients and in house-and are in essence business driven individuals.

So, as you can guess, these types of individuals are not abundant. Besides, Product Owners require a deep technical knowledge, not only good selling skills.

I guess that the question have some triggers, why a team would be thinking in changing its Product Owner? Is it because o a lack or communication? Is it because the Scrum Master is not full filling his role? Before even in thinking in changing somebody my advice would be to drill down the root cause of the problem.

The Scrum Dream Team

2009-11-23T16:44:00.005-04:00

I was thinking in some of the characteristics-I guess that the word qualifications doesn't apply in this context-for a great Scrum team and I came up with a list:

It has to be self directed, meaning that it has to be capable of getting into trouble and create its own ways to strait things
It has to be self governed, meaning that it shouldn't wait for managers to be told what to do
It works more based on agreement more than on impositions
It respects everybody's personalities
It really cares about everybody's well being
It reach consensus because their team members don't have an "I win, you loose" mentality
It creates a friendly environment, a note here, I come from a Latin culture where friendly really means friendly like people eating, jogging, going out, making jokes, and drinking together. It's not uncommon to see that team mates do things together on weekends and after office hours, this creates close bonds that survive years after they finish a project
It has to have team members ready to make concessions and pact rather to go into a quarrel
It has to have a good buffer (a.k.a. Scrum Master) from external interferences
It has to have a track story of continuous improvements
It has to be willing to learn new things

Scrum Masters and Referees

2009-11-20T11:50:00.003-04:00

Watching a good football game (soccer in American sports jargon) the other day I realized how much fun you can have seeing a couple of excellent teams playing. I chanted a lot and the team that I was supporting won (of course I had no power to influence score, but it was a lot of fan screaming, jumping, and singing).

After the match I've started to think in some analogies between football and Scrum teams. Both are self-organized teams that work together in spite of their individual starts. Both has roles, specialties should I had said, like the goal keeper or the insider. But at the end anyone can score and change curse of the match in an split second.

But more importantly, there is this one character that nobody likes that much, the referee. And here I've found some interesting analogies with the Scrum Master:

The least you see from the referee, the better that the match is being played (unless of course that you have an incompetent referee afraid of doing his job)
The fewer interventions that a referee is forced to make, the better that the teams are self-governing
Referees solve complicated situations that can easily escalate to crisis
They use a mix of gentle and strong hand to keep peace in the play field
They don't appear very often but when they have to, they're not afraid to show some muscle to enforce his decisions
They are not the starts of the show, players are

At the end you might ask, why does a match need a referee? To rule or facilitate the game? See the similarities with the Scrum Master role.

Metrics and Process Improvement

2009-11-13T12:28:00.011-04:00

It's not uncommon to hear that managers are interested in improving productivity in their teams, metrics-wise this means that the indicators that they're looking at, should start to show bigger and better numbers.

Metrics are commonly applied for measuring processes and they in turn reflect internal team organization policies and practices. Following this rationale, managers should start improving processes if they want to have better metrics. But what if processes are something that you can't measure and consequently improve?

Process Definition

According to Wikipedia a process in engineering is "engineering which is collaborative and concerned with completing a project as a whole; or, in general, a set of transformations of input elements into products with specific properties, characterized by transformation parameters".

Processes in Manufacturing

This definition stresses the point that a process implies a set of transformations; further, a process in manufacturing has some interesting characteristics, to name a few:

It's standardized, meaning that it has a set of predefined set of steps that has to be followed by workers. Conversely, deviation from the standard produces defects
It's repetitive, this is key in factories and shop floors where journeymen perform the same tasks again and again. Perfection comes from repetition, and seniority is based on the number of times that journeyman executed tasks. Repetitive tasks are also great for passing knowledge from journeymen to apprentices, and of course also great for foremen supervising work in floor shops. However, repetition cuts creativity and innovation.
It can be extrapolated, the X process in the Y factory can be documented in a recipe format and then sold for use in the Z factory. This rationale of course doesn't consider that the same process in X and Z factories will be implemented by different teams. Again, focus in the process disregarding the human factor.

Process in Services

Processes in service industries like fast food franchises or banks have humans that follow some rules and procedures to provide services to other humans; however, some characteristics of this interaction can be similar to what happens in manufacturing like:

It's standardized, there are standards for food elaboration, quality, and service time. Franchises are especially prone to set standards but even the old mom-and-pop type of restaurants has standards that they employees have to meet.
It's repetitive, unless you decide to go to a very expensive restaurant, you'll be almost all the time getting the same food-good or bad no matter-that comes out of the same process that restaurant employees followed to prepare it.
It can be extrapolated, otherwise there won't be fast food franchises that can offer the same product with the same quality-again, good or bad-in different parts or the world.

The Processes in the Software Industry Dilemma

By this time you might have realized that manufacturing or services processes can't be directly translated to software industry, some reasons are:

The software development industry requires a high degree of innovation and creativity. This brings a lot of variability over processes; for instance, a test case can be executed by two different quality engineers with different results, one might have executed the test case in two hours and finding no bugs whereas the other might have execute it in half the time and with high severity bugs reported. Is the first quality engineer less effective than the second? Of course not, many factors like expertise, product familiarity, or technology knowledge make the difference. More importantly, the human factor plays here a more crucial role.
Work is essentially not repetitive, maybe some parts of testing are but development is certainly not. Programming languages have a very few and well define set of structures like repetition, bifurcation, and comments. However, these are like building blocks that you can use in an uncountable number of ways to achieve the same results. Of course that there are good practices and rules to follow, but human creativity certainly is more valuable than repetition at least in this line of business.
Recipes don't work anymore, you can't extrapolate processes from one development team to another because there are too many variables related to people that you can't control. For instance, you can't expect to have the same degree of motivation and commitment in two different teams, again soft-factors like those are what will prevent process extrapolation and consequently standardization.

So, seems like old project management techniques based on process standardization are no valid for this industry eh? Even more importantly, if you can't standardize process how could you improve metrics? I guess the question should be, is it really worth the try to look for processes and metrics applicable to the software industry? My short answer would be no, my long answer you be that we could look for a different type of metrics originated from agile processes.

Scrum Coming to Rescue

What Scrum can bring to help solve the dilemma? For starters, it doesn't prescribe a process/metrics measurement approach which I've described before simply won't be applicable in this industry.

Secondly, Scrum brings a shift in focus from control to empowerment, from contract to collaboration, and from documentation to code. This highly pragmatic paradigm requires many things for work, things like self-discipline and upper-management support, but undoubtedly empowering teams would be the cornerstone.

Just imagine having teams than can create their own process based on their needs; that can discard or modify process that are not longer applicable, and that can be able to achieve impressive results with no formal process in place. For some this might sound like project manager's worst nightmare, but for Scrum purist this could be heaven.

Self-directed teams are essentially highly committed and innovative-they have to be, otherwise they shouldn't have choose the Scrum way-that work at a sustainable phase and creates on the fly whatever process they need. Of course processes come from consensus and this in time generates internal commitment and motivation. In time this produces hyper-productive teams with competitive individuals looking for challenging stuff to work on the next Sprint.

What a Burndown Chart is Not

2009-11-11T11:38:00.003-04:00

A burndown char is not:

a fortune teller crystal ball that you can learn to use to predict how things will be occurring in the future
a time machine that will allow you to travel back and forth in time to fix things or foresee pitfalls
a single chart that will concentrate in it all the necessary information for you to see at a first glance project and team status
a chart that is magically draw by somebody everyday before you come to the office
an accurate and no misleading indicator
a complicated tool that takes too much effort to understand and maintain
a converging point tool that the team will use to agree on something
a bargain chip that managers can use for negociating witht the team
the ultimate indicator for measuring team's productivity

Locally the question would be, what a burndown chart truly is? I'll save the answer to that question for another post, stay tunned.

Sprint Planning Meetings

2009-11-04T15:09:00.003-04:00

One of the biggest confusions in the Agile community is about the need for sprint planning. Some people tend to think that since Scrum for instance is all about adaption, no planning is required.

In order to clarify this confusion is necessary to say that planning is not the same as detailed planning, the big difference is that in detailed planning we look for concrete data about what, how and who would do that during the Sprint. On the contrary, when we do Agile planning, we're just interested in understanding what needs to be done but not exactly how.

Planning sessions are also a great opportunity to question the Product Owner who in turn should look for the answers with final user or customer.

During the second part of the planning stage is necessary that the team estimates complexity for all user stories that will be moved into the Sprint Backlog. Estimated complexity is a fun exercise and an excellent opportunity for team members to make public their understanding of the work that needs to be done. One of the great benefits of this part of the planning meeting is that fosters communication among team members, explaining what one thinks will try to build in the Sprint is a perfect vehicle for understanding it better before even starting to work on it.

Finally, planning meetings should include QA work for testing and validating fixes. One common pitfall is to just plan for implementation but not for testing.

Fulling QA's plate

2009-11-03T08:28:00.003-04:00

Many people tend to believe that a good Scrum Smells is having QA overbooked for the whole Sprint. From a capacity standpoint this might make some sense, but from an Agile perspective this approach has several limitations, to name a few:

Overbooked personnel has no breathing room for creativity
No creativity implies repetitive work and repetitive work is enemy of reflection
No reflection cuts continuous improvement

Further, Lean-wise having QA working at full capacity all time creates waste in the form of work being piled up waiting for being processed and processed work being blocked to pass to the next server in the line because it's also booked.

Lastly, having QA at full capacity will break the continuous phase principle because engineers simply will quit the project if we make them work at this killing phase during all Sprints. The ultimate goal should not be making full use of resources from a capacity perspective, on the contrary, noble goals like team work and team empowerment should be pursuit.

What QA do During the Sprint?

2009-11-02T10:04:00.005-04:00

This has been an interesting question and debate topic. Let's start saying that in Scrum teams are not divided in development and QA, everybody is part of the whole team and takes active part in the Sprint. Further, QA's involvement goes thought all Scrum meetings, artifacts and roles. For instance, a Quality Engineer could be appointed as Scrum Master or even Product Owner.

If we think in planning meetings, QA should participate in user story definition and understanding of what is required to do. Moreover, QA has to create the acceptance criteria for all tasks. Also during the planning meetings, QA participation is crucial when estimating tasks complexity and duration. One important note here, Quality Engineers has to vote during planning poker meetings.

Remember that what we're estimating is complexity and time for tasks that has to be completed during the Sprint, and when I say completed I'm referring to the Definition of Done that has to be agreed by the team. One very common mistake is to include only development's estimations for tasks and as a result tasks get implemented but not tested or tested with bugs.

During the Sprint, QA has to participate in the Daily Scrum Meeting to report its status and blockages. One common Scrum smell is QA reporting that it doesn't have anything to test. Typically QA has almost anything to do during the first weeks of the sprint but in the last days it's suddenly overwhelmed. Again, this is a consequence of bad planning and a violation of the "Sustainable Phase" principle. Workload should be evenly distributed both for development and QA during the Sprint, avoiding killing hours of work at the end only for QA.

Also at the end of the Sprint, QA participates preparing and presenting the demo to clients. Further, during Sprint Retrospective, QA has to reflect in its work and interaction with development and make the necessary adjustments for the next Sprint. One word of caution though, don't wait for the Sprint Retrospective to adapt, adapt as soon as you feel the need.

Why Scrum is so Popular?

2009-11-02T09:11:00.005-04:00

I was thinking the other day about why Scrum is such a worldwide phenomenon in terms of popularity, I mean, why is with Scrum that everybody seems to be so eager to learn about it?

One or two steps back, other frameworks and thinking tools like XP or Lean are tremendously good, their principles are so down to the earth that you should absolutely follow them in whatever project that you try to start. Further, there's certainly too much overlap among Agile, Lean, XP, Scrum and even Kanban, but at the end of the day Scrum seems to be gaining more popularity that the other Agile flavors.

If you like the books and read Beck, Jeffries, Poppendiecks, Schwaber's and others, you'll find that all are excellent but somehow Scrum succeeding again attracting more visibility.

So, ready to develop the mystery? My theory, and please take it just a personal believe without hard data behind, is what has propelled Scrum to the top was the certification program. If you think it twice you'll see that there are around a hundred Certified Scrum Trainers around the world that has to pay a $7000 annual fee to maintain their certification status and still make a profit out of that. This small army of CST are intensively active organizing courses around the globe and as a result we currently have around 60.000 Certified Scrum Masters.

CSMs paid close to a grand in the US for a two day course, of course that is well invested money but certifications are not just for shining, has to have a practical use. CSMs do their best to introduce Scrum in their teams and organizations, but soon enough they discover that almost nobody beyond them has heard of or is willing to adopt Scrum. What they do? Convince more people to take the CMS course and keep preaching the Scrum word in their organization.

As a result we have a growing community that spreads very quickly, some people even called it "Pandemic Scrum". Of course that there's a business model and people making profit of it, but what a heck, Scrum is a great framework that is making IT people happier and more productive.

The Scrum Dream Team

2009-10-22T10:41:00.003-04:00

I was watching football (soccer in American sports terminology) the other day. I'm not a big fan these days but I used to be. Anyways, seeing Brazilian National Team playing is always a good investment of time.

While I watched the game some reflections came to my mind:

Brazil has great football players, they're all sport starts that play in the best teams in Europe. They are rich, talented, and famous, everything in the same package. But they're humble enough to accept to be coached.
Anyone in the team, except the goal keeper of course, can score goal and win a match. It's not unusual to see that Brazilian defense can also score. Team success in more important than individual recognition.
Why defense player can score? Simple, they change roles during the match and become part of the offensive. Adaptation is key here.
Brazilian National Team plays differently when it plays against South American or European National teams. Brazilian players use technique or play rough if needed. Essentially they adapt their style to circumstances.
Motivation comes from inside the team, Brazilian players believe that they're the best and always look for new challenges.

Lastly, there many national teams and thousands of excellent players around the world, but what makes this national team so successful? My answer would be that a combination of talent, humbleness, adaption, inspection and teamwork, triggered the magic of the 'jogo bonito'.

The Incomplete Judo Definition of Done

2009-10-19T09:13:00.004-04:00

One of my clear memories from youth is training Judo projections and uncountable number of times. In Judo you won a match in several ways, but the most spectacular one is when you throw your opponent to the floor over your heap. You get a full point, the match ends, you won a medal, the crowd chants your name and everybody is happy but your opponent.

But what if you for misfortune you are forced to use the same technique to protect your life in the street? Throwing somebody to the floor would be enough to neutralize your attacker? Hard to say, but statistics shows that this won't be enough, you need to immobilize your attacker to be really safe. So following this rationale, Judo projections are half done.

Extrapolating this to the Scrum world, Judo projections are like writing code: looks really cool, people love to see it, it attracts attention and respect but is still half cooked. Code that has been coded but not tested is like a furious attacker in the ground, it can counter-attack and really hurt you unless you do something to really control him.

In Judo (and more effectively in Ju-Jitsu) you use punches and locks to really immobilize your attacker. In software development you can use testing-both manual and automated-to assure that the code is good enough. Further, you need to reach consensus about the acceptance criteria and the Definition of Done. Why? Simple, it's a team's activity, without consensus effort would be wasted without favorably impacting in code's quality.

Some Scrum Fallacies

2009-10-14T08:29:00.005-04:00

I been looking into some Scrum concepts that we take from learned but are wrong from a conceptual level, I compiled a list that you can read see below.

The PO (Product Owner) prioritize team's activities. This is false. The PO main responsibilities are to provide feedback, answers questions about items in the current Sprint, and work with the stakeholders. The Team is in charge or prioritizing its activities.
The Sprint has to last a calendar month. False again. The Sprint can last a month or even less, it can also be extended under special circumstances and with PO's approval. However, the Sprint shouldn't be so long that it doesn't adjust to business events.
It is necessary to have a vision and product backlog to start and sprint. False. There are important things that you'd like to have before starting an Sprint, things like a release plan, budget, executive sponsorship, technical leadership, team space and team rules, backlog, etc. Nonetheless, those things are not essential for starting and Sprint, remember, Scrum is about adaptation and not fully detailed planning.
All the Sprint Backlog must be defined up to 100% in Sprint Planning meeting. False. The team just need to identify all the necessary tasks to complete the selected Product Backlog items that will be tackled during the Sprint.
The SM (Master Scrum) is responsible for removing team members that are not performing well or disturbing other team member's work. False. In Scrum we have self organizing teams that can decide to remove team members by themselves, the SM may provide advice but the final decision has to be team's call.
Burndown charts show how much effort has gone into the Sprint. False. Burndown chart essentially shows estimated work remaining for each day of the Sprint.
During the Sprint, identified tasks are added as soon as the PO approves their inclusion. False. Tasks needs to be added by the team as soon as their are identified, no need to wait for approval, agility and proactivity is crucial.
The team is responsible for selecting the PO. False. Even thought we have self organizing teams and that the SM role can be rotated, the PO is appointed and can't be removed, at least not for the team.
The SM has to attend to the Daily Scrum. False. The Daily Scrum is a inspect and adapt meeting for the team that does actual work in the project, so no need for the SM or PO to attend unless they are invited by the team. The SM however should collaborate setting the logistic for the meetings: reserving a conference room, providing phones, sending invitations, etc.
The Sprint Backlog will be the output of the Sprint Planning Meeting that will set the direction for the next Sprint. False. The target and direction for the team will be provided by the Sprint Goal.
The PO has to ship each Sprint increment when it'll be free of defects. False. The Po has to ship increments whenever he feels that this make sense, of course that they don't have to have defects but this more like an enabler and not the ultimate motivator for shipping.
A Product Backlog item is considered completed when all its tasks are completed. False. A Product Backlog is actually completed when it meets all negotiated acceptance criteria.
User stories are included in the Sprint Backlog. False. User stories are decomposed in tasks during the Sprint Planning Meeting and then they go into the Sprint Backlog.
The SM has to act as a go-between the PO and the team. False. This is the least communication technique that the SM could use, more effective ones are: monitor communication between the team and the PO, teach the team to talk business languages , teach the PO technologies involved in the product.
The SM or the PO are in charge of updating the Sprint Backlog during the Sprint. False. The empowered team takes the decision of updating the Sprint Backlog to reflect their decisions and tasks progress.
Teams make adjustments to their engineering practices only after consensus was reached in a Sprint Retrospective meeting. False. Teams are adaptive in nature and need to take initiative and adapt their practices whenever needed.
The SM is an engineering position. False. The SM is a management position.
The product has to be shipped at the end of each sprint. False. The product needs to be shipped when the PO decides to ship it and taking into account a release cycle that includes marketing, finantial, legal and other implications.

A Backlog for Improvements

2009-10-12T16:52:00.003-04:00

During a training session that I conducted last week, a very interesting question popped-up, how teams accounts in their improvements after Sprint Retrospectives?

What I use for my teams is a very simple technique: I take pictures of all problem insights and improvements that we''ll be tackling in the next Sprint after the retrospective. I then post those pictures in team's SharePoint and I project them in the initial part of the next retrospective meeting in order to have a feel of what has been accomplished and what not.

This works quiet well but we still miss the feeling of progress, more to the point, we're lacking the psychological effect of burning something (like hours, story point, user stories or any other indicator).

What I propose is to create a backlog of potential improvements, we could go as down as estimating effort and time and maybe creating associated tasks, but my initial feeling is that this would over complicate things. Instead the attack plan should be just logging in this backlog the list of potential improvements from the Sprint Retrospective, prioritize them and then work in the top priority areas for improvement. No much data about how improvements have been accomplished should be logged, unless somebody in the team wants to document them as case studies.

I'll be trying to implement this idea and write later with actual evidence in hand.

Jazz Band Conductor a.k.a. Agile Project Manager

2009-10-09T09:47:00.005-04:00

I though in a interesting analogy the other day, if you hear a jazz band (and hopefully a good one) you'd realize that the conductor encourages improvisation. Actually, improvisation is a distinctive characteristic of jazz music.

The conductor is someone that is deeply familiar with the instruments and music, but not necessarily plays with the band. What is important for him is that everybody plays good jazz and the audience gets satisfied. Making every musician in the band happy is of course a priority, happy people are generally more willing to improvise.

There's of course an style to follow and a lot of training, all these required for being able to improvise in the first place. But the goal is always at sight, have fun and play good jazz. Again, the conductor don't tell the team what to do, he let the team create and help it to reach the next level. This is certainly a lesson that we can translate for Agile Project Managers.

On the opposite side, this guy has everything figure out from beginning to end-or at least he likes to think so-, everybody in the chorus has to sing exactly what has been rehearsed endless times.

No deviations from the score are allowed, improvisation is not specially highly rewarded. Do you see any similarities with traditional Project Management?

The Most Important Meeting in Scrum

2009-10-07T15:15:00.004-04:00

I was thinking on which would be the most important meeting in Scrum, this questions crossed my mind because I've heard that many teams in my organization still believes that Scrum is all about the Daily Scrum Meeting. Maybe the confusion came from the fact that both Scrum-the framework- and Scrum-the meeting- has the word "Scrum" in their names. Whatever it was it's pretty obvious that is a serious mistake that needs to be corrected.

An interested behavior that I've observed on those teams is that they believe that they're doing Scrum just because they have a daily stand-up meeting. Nothing could be further from the true spirit of Scrum.

But going back to the initial question, in Scrum we have meetings like:

Planning Meeting
Daily Scrum Meeting
Sprint Retrospective Meeting (a.k.a. Post Morten meeting)
Mid-Sprint Review Meeting
Release Retrospective Meeting

This list is not definitive and surely enough more meetings will be added/suppressed by teams based on their specific needs. However, the meeting that in my humble opinion is the most important in Scrum is the Sprint Retrospective Meeting. Why? Because this is the meeting for revision and improvement and Scrum is all about inspection & adaption.

The Old McKnight Was Right

2009-10-06T11:24:00.004-04:00

William McKnight at 3M create a new mentality: let the workers innovate. This revolutionary mentality made of 3M a company capable of being always surfing the wave by introducing dozens of new products to the market and create very diverse business units.

I read a very interesting quote from McKnight:

"Hire good people, and leave them alone."
"If you put fences around people, you get sheep. Give people the room they need."
"Encourage, don't nitpick. Let people run with an idea."
"Give it a try—and quick!"

This is something that definitely goes inline with empowering the team and other core Scrum values . Again, I'd recommend that we listen to old McKnight.

Technical Debt a.k.a. Torpedo in the Water

2009-10-05T17:57:00.006-04:00

What can be more dangerous than having a armed torpedo coming fully ahead to your ship? Short answer: not knowing that the torpedo is coming and just feel the blast and have only an split second to realize that you, your ship and your crew are domed.

You could mitigate this by having some good active and passive radars that at least tell you that at torpedo is on seeking mode and looking for your ship. Of course knowing what is coming is times better than being taken by surprise.

During the Sprint we have a very good indicator-you can call it information radiator if you want-for knowing than something really bad is coming. This indicator is the technical debt which in its simplest definition is just unfinished work. But let me elaborate on this definition a little more, technical debt is:

Schedule work that has not been even started
Schedule work that has not been implemented
Implemented work that has not been tested
Tested code that failed to pass all test, bugs were encountered
Work with bugs for which fixes were provided but rejected
Retest work that is still in progress, consequently there's still uncertain that fixes actually work
Unplanned work that has been discovered in the Sprint but that has not been completed-maybe not even started
And the worst of all, undiscovered work that has not been considered but that will be necessary-armed and locked torpedo

Technical debt, like torpedoes, is lethal unless you know that it exist and is coming towards you. If you detect a torpedo in the water, you can still save your ship-and your life of course-if you launch counter-measures. The sooner you act, the more chances that you have to save your boat, sounds similar to technical debt?

Agile Flavors

2009-10-01T17:16:00.006-04:00

Thinking tools: Tools that we use in our field of expertise to build software. In other domains they’re also called mindsets or philosophies. Some examples are:

Lean
Agile
Systems Thinking
Theory of Constrains

When thinking becomes acting you need a toolkit (some people like to call it framework). There are many toolkits/frameworks out there to put Agile/Lean at work:

Scrum
eXtreme Programming
Kanban
RUP

Some thoughts on the various disciplines:

Agile: A core set values for executing projects
Lean: A core set of principles for running a company
Scrum: A set of agile management practices based on one principle: Inspect and Adapt
XP: A set of agile software engineering practices/processes

Building a Burndown Chart using Story Cards

2009-09-30T21:31:00.005-04:00

This is something that I tried the other day on a training session. I divided the class in three groups of seven to eight participants, each group created a template for its user stories cards.

I specially like this template because it has all the necessary information in just one place, it has fields like:

Developer's initials
Quality Engineer (QE) initials
User story name
Developer's estimated time
QE's estimated time
Developer's actual time
QE's actual time

By adding developer's plus QE's estimated times, one can have the total estimated time for the user story. If one does this for all user stories, one will ending up having the total schedule time for the Sprint.
This time would be the total allocated time or time that the team has to burn during the Sprint. In the chart below we had check point every five minutes (because our simulated Sprint only lasted 15 minutes) to see how much has been worked and what is still remaining. This information is what allow all three team to draw burndown charts and use them as a tool for monitoring progress and forecast Sprint degree of completion -only from a time perspective.

About Story Points

2009-09-30T10:48:00.003-04:00

Story points are a good estimation technique that you can use when you try to estimate complexity in user stories. Unfortunately, complexity is not directly correlated to effort and time so you might end up having ultra complex features that can be implemented by a very inspired developer in a very short time (yes, miracles can happen from time to time).

On the other hand, you can have low complex features that require many hours of repetitive work.

Another variable in the equation is the QE time that you'll have to commit to test the feature. Again, there's no direct correlation between the implementation and testing complexity. For instance, automated testing can save a lot of man hours and make testing easier for a highly costing -from development perspective- feature.

A guess the caveat here is not try to use story points as what they are not: a metric for progress and effort.

The Myth of the Accusatory Taskboard

2009-09-30T10:24:00.003-04:00

I've seen many teams in many projects that are afraid of updating their real status in a taskboard because they feel that if they say the truth their manager will punish them. Childish as this might sound, this situation is not uncommon and frequently leads taskboards to be an inaccurate representation of the reality.

Let's start one step back, what is a taskboard in the first place? My answer would be this: a taskboard is a collaborative tool that the whole team uses to communicate ideas and reflect tasks status.

Conversely, what a taskboard is not is a reporting dashboard that upper managers look for finding problems and bottlenecks. Further, managers can't pretend to use taskboards for micromanagement and problem diagnosis.

Two steps back, Scrum is all about empowering the team, not about managers using reporting tools to controlling things in a project.

A Foreman has no Place in Scrum

2009-09-29T09:56:00.004-04:00

I remember reading that Henry Ford T-model success came from the fact that the assembly line that he invented was able to produce 17 million of cars in less than two decades.

I also remember reading that his Detroit assembly plant hired employees from several different nationalities and around 50 different languages were spoken in the plant -something similar to the world software industry today. What make possible that all these people can work productively was Frederick Taylor invention: scientific management.

Scientific management is based on the principle that engineers -or foremen- study a process, optimized, and then teach workers how to do it. Deviations from the process are not allowed and creativity is limited at minimum. Quality is controlled on the base of how well workers sticked to the process and produced the expected results. Mechanization and mass production is the result of this management technique. Controlling and supervision is assigned to foremen that are appointed responsible from a group of workers and a portion of the production line.

This worked pretty fine for some decades until Japanese Toyota Production System changed the auto car industry forever. For starters this brought the idea of suppressing foreman and empowering teams.

It still strike me odd when somebody ask me about the best way to manage developers, Scrum principles are not about better management or better application of the scientific management. On the contrary, Scrum is about flat structures -no foremen- and creative thinking.

Metrics are not Crystal Balls

2009-09-28T12:45:00.008-04:00

Teams need visibility of their progress, but how can they get enough visibility about how they are doing in the Sprint?

There's no short answer but you can try this:

Convince your team to believe in metrics.
Choose the metrics that best work for your project -simplest one is number of completed user stories .
Make everybody look at the same set of metrics.
Put all metrics in just one place (a taskboard and burndown charts are more than probably you'll need).
Create the habit for all your team to provide initial estimates and then compare them to their actual work.
Do not waste too many cycles trying to innovate in metrics, everything has been already discovered, is just matter or look what would be good for your project.
Metrics are not black and white, there's a lot of gray areas in them.
Metrics are indicators, symptoms but not conclusions or explanations.

What the PO Does During the Sprint?

2009-09-25T17:08:00.009-04:00

Somebody asked me an interesting question: what does a Product Owner do during the Sprint? But before answering this question, let’s go one step back and see what the PO does for the release backlog.

Let’s start by saying that the PO has changing roles and responsibilities during the project. For instance, during the very inception of the project, the PO would be responsible for gathering the initial set of requirements–provided by the client–and together with the team, create an initial set of user stories.

This initial set of user stories is prioritized and estimated–using Planning Poker, T-shirt sizes or any other technique–by the team and the PO. This prioritized list of user stories is what accounts for the initial backlog or release backlog. One caveat, estimations provided in this stage are related to complexity, not to time or effort.

Building the Sprint Backlog

The sprint backlog should be a subset of the product backlog that the PO and the team agree to be worked during a time-boxed period of time: Sprint.

During the planning stage of the Sprint, the PO in collaboration with the Scrum Master are responsible for guiding the team in providing time estimates for the committed user stories. Over-commitment is hard to avoid in the first sprints because the team isn’t aware of its own velocity.

Based on the time estimates provided for each user story, the PO can calculate–adding up all the user stories times–the total number of hours that the team would be working on the Sprint. This number of hours is the total capacity allocated or hours to be burned during the Sprint. Making sure that these hours are burnt–and the associated user stories delivered–would be one of the key responsibilities of the team during the Sprint.

Running the Sprint

Scrum recommendations limit to say that the PO has to be available for the team during the planning stage and also during the Sprint, in case the team has additional questions. The PO also has to prioritize and reprioritize the backlog on a need basis. But it would seem that doing all this wouldn’t take much time, at least not to keep him fully busy during a three-week Sprint. This is one of the Scrum myths that I'll try to demystify.

So, let me bring some light to what the PO should be doing to stay entertained during the Sprint:

The PO should be in contact with the client showing and discussing results from the past demo. Showing something to a client just one time is usually not enough to have an accurate perception of what he liked or not from the product.
Clients are not always available for the PO, so chasing clients will consume cycles from the PO.
If the PO is working with a product targeted for multiple clients, the chasing/demoing activity increases exponentially consuming even more time.
Demoing a product without the team's assistance implies that the PO has to set his own environments and learn the product well enough and not only from a user's perspective. This is not a people's activity; it is more technical and will consume many cycles from the PO.
By using the product in his own environment, the PO will be discovering what I'd call "requirement issues". In fact, the PO will be doing "requirements testing" which is a validation of the product from a client’s perspective. Passing this test would guaranty that the PO has something he can sell.
Studying the market and monitoring competitors should also be in the PO’s agenda.
Defining new requirements based on client's feedbacks and market reading.
Adding new user stories into the project backlog by his own initiative and/or per team’s requests is pretty obvious, what is not so obvious is that the PO needs to ask the team to do some planning poker to estimate complexity for the recently added user stories and that the backlog would need to be reprioritized.
Grooming the backlog to accommodate new and changing requirements should be the tangible output from the PO's work during the Sprint.
Building and monitoring a burndown chart is also crucial for POs. Actually, the burndown chart should be used by the PO to see if the allocated hours are being burned at an acceptable rate that can be used to predict that all scheduled work would be completed on time.
Frequently enough, the burndown chart will show that the team is more likely to miss the mark, in these situations, the PO has the responsibility to negotiate whatever can still be completed on time. Having a bunch of user stories in progress is not as good as having a few completed–walking skeleton principle–.

As you can see, the PO has enough–and maybe more than enough–to keep him busy during the Sprint. One note thought, Scrum doesn't prescribe that the PO's tasks should be planned and tracked on a separate backlog, but what if some PO decides to do so? I'd be happy to hear about the results of this experiment.

The Real Kaizen Behind Scrum

2009-09-24T16:48:00.007-04:00

My aikido sensei told me the other day "you need more kaizen, your aikido is not flowing smoothly". I thought to myself, "is my sensei referring to the same kaizen principle that we use in Scrum?".

So, after the class I sat with my sensei and I asked, "what do you oh sensei understand for kaizen?" This is what he responded:

"Kaizen in about seeing yourself and recognizing that you still have still much to improve and learn.

Kaizen is not about beating others, it's about learning and teaching others and together improve.

Kaizen is about being humble and be ready to recognize that your learning path just started and will never really end."

Much of this can be applied to Scrum, don't you think?

Applying Queuing Theory to Sprints

2009-09-24T10:00:00.011-04:00

Queuing theory is one of those subjects that you learn in college but you never completely understand, like calculus or algebra. The problem with it is the little practical use you make of it.

I realized some time ago, that Quality Engineers (QEs) in my projects were not doing much during the first half of the Sprints and this had a recurrent pattern; they created test cases, preparing testing environments, updated existing ones, did some research, wrote training documents, etc. That sounds kind of ok, but the problem was that by the end of the iteration, they were all of a sudden overwhelmed by the amount of user stories they had to test. Consequently, they had to work killing hours (including weekends) to get the work done.

I remember that time ago, banks had a similar problem, tellers where not doing much during most of the day, but at peak hours they could hardly breathe because they would have a bunch of impatient clients formed on a line in from of them. Banks played smart and did something to improve their service systems and evenly distribute arrivals. Queuing theory-wise, if you can't increment servers, go in the other direction and look for a stable arrival rate.

It's pretty obvious that we have a lesson to learn from banks and other service industries. So what can we do in order to help balancing Quality Engineer's work? Some ideas below:

Plan for micro-deliveries, small pieces of functionality should be passed from development to quality assurance on a daily basis, if possible.
Don't pass code that is not on a build for testing, builds are great for version control and integration testing.
Automate as you implement, run Build Verification Test on a daily basis.
Write test cases as you progress with testing; don't wait to have tons of test cases written before starting to test.
Sync developers and QEs’ efforts to know what to implement and test.
Don't plan for large user stories, break them into smaller chunks of functionality–use the INVEST principle.
The acceptance criteria is not fixed, it evolves as the functionality is implemented and tested–it certainly exists from the beginning but should be refined as we move into the sprint.
Look for people that are sitting idle because they're waiting for something to test, waiting is waste and has to be eliminated.

The ultimate goal should be to have a stable flow of code from development to quality assurance and vice versa. A stable flow is what will allow you to make better use of your QEs reducing queues’ length and decreasing throughput time for user stories.

The Rule of No Rules

2009-09-23T10:45:00.004-04:00

Is Scrum all about anarchy? Well, yes and no.

Yes, because Scrum is not about forcing rules and creating enforcers of this rules. There's no hierarchy and authority representatives, no one is entitled in a controlling role.

One common misunderstanding is believing that the Scrum Master is like a police officer that has to make team member follow the rules of the "true Scrum".

No, because Scrum has values and principles that one should understand and follow. Working agreements reach consensus in the team and are applied on discretion. The team auto manages itself and decides what to do and how to do it.

Scrum is all about negotiation, inspection and adaption. No imposing something and making it work by force.

Telling the Tale Using a Task board

2009-09-23T10:22:00.005-04:00

What a taskboard is?

A communication vehicle
A wall or a whiteboard where the team post their kanban cards
A visual indicator -a.k.a. information radiator- that provides a quick status check

Who should build it?

The Product Owner should build the first version
The team can increment it's content in each Sprint

Who should maintain it?

The main responsible is the Product Owner
But this doesn't excludes the team in participating
The ultimate goal is that the taskboard accourately reflex tasks -kanbans- progress
The rule of thumb is having always updated status of tasks completion

Who should prioritize it?

In kanban the taskboard is not prioritized but in Scrum it is, so the main responsible for this is the Product Owner

Does it has to be online?

Yes, if you want to save the kanbans for later analysis
Yes, if your team is distributed
Yes, if you have way to many kanbans to put in a single wall (smells: problem indicator)
Yes, if you have found an electronic taskboard that is not complicated to use and fill your needs
Otherwise you should be using the old and simplified version: post-its and a whiteboard

Management by Sight

2009-09-22T10:50:00.004-04:00

To world famous Toyota Way, based on the Toyota Production System success, has a very interesting concept that always caught my attention: Management by Sight

So what this all about? Let me try to explain the need for this:

Manager, and why not engineers, are busy people who don't have time to crunch numbers to see how they're progressing in the project
Everybody cares about measuring progress, but managers are just big fans of it
So, we need something that people can look and instantaneously, and why not magically, can tell them whether they're on track or falling behind schedule

Once we all realize that we need some light here, we're ready to look into what Toyota discovered years ago: a simple chart that shows progress

But some conditions for the magic to work:

It has to be visual (obviously!)
It has to be public
It has to be periodically updated
It has to be easy to read
It has to be easy to understand
It's interpretation has to be clear
Only a few indicators should be considered per graph, don't try to show everything in just one chart
It has to be a communication vehicle for the team
It has to have real data, not massaging information should be allowed
It's a tool for the team, not just for managers

The Mythical Scrum Master

2009-09-22T08:21:00.004-04:00

Once upon the time there was an all powerful individual full of charm and personality, his energy and intelligence what nothing from this world. His voice was like a thunder and he has this magic thing for solving everybody's problems: his name was The Scrum Master

Unfortunately this is just a myth, no such thing exist or at least can be easily found in just one individual. But let's go one step back, why people created a myth around this character? There are some reason that I can think about:

From a management perspective it's easier to concentrate all responsibilities -and powers- in just one individual
From a team perspective it's times easier to expect that somebody leads the team and solve problems
Concentration of responsibilities in one individual is the worst enemy of team empowerment and the great ally of micromanagement
Blaming only one individual in case of failure is less harmful to morale than blaming the whole team

So what can we do to kill the myth? Several things I guess:

People believes in myths because they try to avoid reality, so let's start there recognizing that there's no Super Scrum Master
Like it happened in old towns, myths will be erased via education -so let's start by educating managers and teams
But education people on what? Short answer: Scrum
Micromanagement is good as long as the team is in charge of it: micromanagement of the team by the team is what we're looking for

When the Product Owner Has to Say No

2009-09-21T12:18:00.006-04:00

Saying no to the team, to the client or the Scrum Master, is one of the PO's more important tasks, but let's think in some situations when this might happen:

When the team wants to force the client to use a technology, platform, architecture or design that it believes that is "technically suitable" but has no value for the client -I know what is best for you syndrome-
When the client wants something that is clearly unfeasible with the given schedule and resources -the dreamer syndrome-
When the Scrum Master representing the team wants to change the scope for the project -two captains one boat syndrome-
When the team voted and decided what should be excluded from the product -technical decision without business support syndrome-
When developers want to work on an overkill solution for a problem -super engineer syndrome-
When the team wants to investigate during several sprints without guarantying practical results -researcher syndrome-
When the team and Scrum Master want to skip demos -ostrich syndrome-
When the team want to exclude the PO from all meetings because they believe they already understand the product well enough -come back when it'll be ready syndrome-
When the client want to communicate directly with the team bypassing the PO -serve yourself syndrome-

Syndromes Origin

Even though these syndromes are very common, their origins are still fuzzy, some might be:

The PO is not making a good job gathering requirements
The PO is not making a good job communicating requirements to the team
The PO is not making a good job tracking Sprint progress and backlog evolution
The PO is not making a good job interfacing with the Scrum Master
The PO is not making a good job buffering the team from external influences
The PO is not making a good job setting priorities
The PO is not making a good job using her charisma to lead/influence the team/client in the right direction

Whatever reason that is forcing the PO to says no to the team, these seems to indicate a disruption in the PO role an performance. After all a NO is not required if everybody is clear in what should be done.

Many NOs accumulated in the course of a project are a symptom of a failure in the PO performance. But in any case is times better that the PO says no and correct her course than letting things flow in a direction that will take the project to a failure.

Another of my Articles Published by the Agile Alliance

2009-09-18T17:13:00.003-04:00

Another article written by me, Definition of Done and the Quest for the Potentially Shippable Product, has been recently published by the Agile Alliance: see this link http://www.agilealliance.org/articles_by_category?id=17

The Illusion of Control

2009-09-18T16:56:00.005-04:00

Buddhists believe that the control is just an illusion, people fond to control things suffer to much when they realize that they can't control everything.

Buddhists recipe for happiness (and please don't take this literally) is not creating tight bonds to anything or to anybody, just let things flow and interact without forcing control.

What I found interesting in this philosophy is that managers tend to devote much of their time and effort to craft complex control devices, dashboards, and metrics loosing perspective that in Scrum everything is about micromanagement, but not micromanagement of the team by the manager. Micromanagement of the team by the team itself is times more efficient.

If a team learns how to manage itself, the illusion of control won't be necessary any more, managers will become coaches, and will sleep better at night.

Is the Product Owner a Villain?

2009-09-18T16:41:00.006-04:00

Short answer, yes. Long answer, still yes.

The PO hasn't has to be a villain, only look sometimes like one in front of her team.

Why such a nice gal like the PO has to look though? Simple, if she doesn't, team members will end up imposing whatever they believe that the user should need from a system rather than to hearing to user's requirements.

By the same token, as a user's representative, the PO is in charge of sometimes say "your work is not what what I need, I can't sell that to clients, you need to redo it". The team will be close to kill the PO but in the long run her firm hand rejecting not good user stories or asking for work to be redone will be key for taking the ship to good harbor.

Dirty work PO's it is, but somebody has to do it. May the force guide your steps POs.

Scrum Bolivia User Group in the Agile Alliance

2009-09-16T10:31:00.003-04:00

Our Scrum Bolivia User Group is now officially registered in the Agile Alliance group listing, see http://www.agilealliance.org/show/1641

When Pigs Become Chickens

2009-09-16T10:24:00.004-04:00

I received and interesting question, somebody asked me about some reasons why a pig might become a chicken I can think in a few:

The pig is a low performer and she is as productive as a chicken
The pig's motivation is so low that she acts like a chicken
The staff was reduced and we have less pigs or some were reassigned to other projects but still play chicken's role in our
Part time engineers that switch among projects and don't really contribute to any
Upper managers who like to play pig's role but run away when they have to get their hands dirty with complicated tasks

Mechanics and the Myth of the Satisfied Client

2009-09-10T08:38:00.001-04:00

It’s always a true in software development that we try to satisfy clients believing that they’re always right and they always know what they want. Further, we tend to think on them like almighty goddess with unlimited decision powers. But let’s think it twice, why should we be more committed to customer satisfaction than other service industries?

Let’s take this example from real life, my real life at least. I took my car to the car shop because the front wheels were making some funny noise whenever I slammed on the brakes. The mechanic when below the car, took a look and found nothing. I insisted in that the car was making noises when I drove it, the mechanic said let’s take it for a test ride. I drove the car, slammed on the breaks and again nothing: no noises, no breaks failure no nothing. The mechanics just smiled to me and charge me a no cheap fee for his time.

As a customer, what was my problem? Did my car really have a problem? It was a random not easily reproducible bug? Honestly, I don’t know, but I’m sure that I’m not crazy and the noise was there. So the point is, does the client have enough knowledge to diagnose problems? More to the point, what approach the mechanic used to try to pin down the problem with my car? No big up front requirements, the mechanic uses and iterative approach for diagnosing, fixing is incremental and many times mechanics have to inspect and adapt their work as they move.

Lastly, mechanics usually don’t tell us how much they’ll charge us for their services; they complete the work and then ask for payment. Most of the time your car is fixed and you paid without questions. What a wonderful life mechanics have, don’t you think? Something that we can copy?

My article has been Published by the Agile Alliance

2009-09-06T11:06:00.005-04:00

An article that I wrote last month, Key Metrics for Measuring Sprint Status, has been published by the Agile Alliance, see this link http://www.agilealliance.org/articles_by_category?id=10

The full article can be also found in this blog: http://juanbandaonscrum.blogspot.com/2009/08/key-metrics-for-measuring-sprint-status.html

Scrum Bolivia User Group on Twitter

2009-09-06T11:00:00.004-04:00

The Scrum Alliance officially announced the creation of the Scrum Bolivia User Group on Twitter.

The Scum Bolivia Yahoo! User Group has been Created

2009-09-06T10:43:00.007-04:00

Finally the Scrum Bolivia has an official User Group where Scrum Practitioners can meet to share experiences and learn from each other, this is an open group so no moderator approval is required. The link to this group is http://tech.groups.yahoo.com/group/scrumbolivia/

The Scrum Alliance also made public the creation of this group, and include it in its listing of official groups, see this link http://www.scrumalliance.org/user_groups/74

Plan for the Sprint vs. Sprint Planning

2009-09-04T12:05:00.004-04:00

A typical question that comes from teams is how much planning should be made for before starting a Sprint? Further, what should we plan for? These are fair questions without direct answers. Let’s start trying to solve this puzzle one piece at the time.

What is planning?

According to Wikipedia, planning is “…the psychological process of thinking about the activities required to create a desired goal on some scale”. So, if planning involves thinking next questions should be, is this an individual or collaborative activity? The answer for this seems to be quiet intuitive, it’s an individual activity that is performed in a group but not necessarily a team activity.

What is Sprint Planning?

Is the stage in which the team, and when I say the team I mean everybody that actively will contribute during the Sprint (no chickens sorry), gets together in a single room for an X number of hours and try to define what to do. Focus on what and not how. One tip: don’t let the Product Owner run without answering all your questions, lock the door if necessary.

Plan for the Sprint

This is not the Sprint planning stage; this has to do with more tangible things like: capacity planning, logistics and infrastructure. For instance, consider you will be taking vacation and what type of environments or licenses are you going to need in the Sprint. Some other questions might to consider:

Should I have to use Agile/Scrum for plan for the Sprint? Not necessarily, since this is a support part necessary for the sprint but not under the scope of the team.
Who should take care of this? Somebody in your Management and/or IT staff.
Is this really important for the Sprint? Absolutely, you can’t have a Sprint without knowing what resources you’d be committing.

Question on Why we're Always Late

2009-09-04T11:21:00.006-04:00

Why we always have Quality Engineers and Info Devs trying to catch up with development? Is this because development is moving too fast and QE/ID too slow? Or is this because development moves to slow holding back QE and ID work? We shouldn’t be asking this questions in the first place if we consider everybody as part of a single team (no dev, QE, and ID for separate) and we have a consolidated Definition of Done. DoD is what can tell us if a user story is really completed or half baked. DoD should be common and all team should aim to complete user stories under this definition.
One step back, why we plan for more than we can achieve? Part of this is because we don’t plan thinking as a team, development plan first and then QE and ID add their estimates. Development estimates might fit whiting the timeboxed iteration but QE and ID would most likely fell of the mark. The other part of this is because we don’t know for certain team velocity.
Why we don’t know team velocity? We measure progress in hours but we plan in user stories, our backlog contains user stories that when moved to iterations are tracked down using burn hours. What Scrum recommends is using burn down charts for user stories not for hours. Burning hours is not a good indicator of progress, on the contrary, it often mislead us when we try to evaluate iteration progress.
Velocity could be better indicator if we can estimate the number of user stories that the team is able to produce in an iteration. However, story points or other metric should be considered to have a correlation metric for user stories’ size and complexity.
Are carried over user stories that bad? Without question carrying over user stories break the Scrum principle of having a Potentially Shippable Product at the end of each Sprint. Moreover, from a production stand point, carried over user stories creates a technical debt that will drain team’s capacity in the future.

Definition of Done and the Quest for the Potentially Shippable Product

2009-08-03T16:56:00.003-04:00

One of the main contributions from Scrum to the software development community is the conscience that has been created about obtaining a tangible deliverable product at the end of each sprint. This tangible product, “potentially shippable product” in Scrum terminology, is what governs all efforts from the team, the Scrum Master and the Product Owner. In theory, the potentially shippable product should be ready for shipping at the end of each sprint, given that if you can find a client willing to buy a product that works with limited functionality.

Theory contradicts reality in many occasions because the team hasn’t implemented enough functionality or this has not been completely tested to be considered as a valuable product that can be delivered to clients. Furthermore, confusion within the team arises when there isn’t a clear and unified Definition of Done (DoD). For instance, for development “done” means that a user story has been implemented but not tested. The DoD needs to be understood by everybody in the team; moreover, the DoD should be extended to different levels to cover all the expectations and requirements from the team and other stakeholders. Not having a clear DoD eventually affects the chances of the team to attain a potentially shippable product; what is even worse, without a clear DoD the team will be working as if trying to hit a moving target during the sprint.

This article will present and analyze different perceptions for the DoD in order to suggest a unified version. A word of caution thought, the DoD is something particular to each project so it needs to be evolved from what we suggest here in order to be applied in particular projects.

Different Types of DoD

Let’s start saying that we have only one team but different people playing different roles in it. As a consequence of their work, engineers tend to have their own perception of how and when something can be considered done, let’s take a look at the following definitions of done:

For development some code is considered done when it has been written, compiled, debugged, unit tested, checked-in in a common repository, integrated in a build, verified by a build verification tool and documented using an automatic documentation generator.
For automation test cases are considered done when the corresponding automated testing scripts have been coded, unit tested and ran against a build.
For quality engineering done means that the user stories received on a specific build have been tested by running testing cycles, encountered bugs have been reported using a bug tracking tool, fixes provided have been validated and the associated trackers have been closed. In consequence, test cycles include both manual and automated test case execution.
For info dev done means that all the help files in the product as along with the printed manuals are written in perfect English or any other language.
For project managers done means that the sprint has ended and the user stories have been completed (not necessarily accepted by QE) and the schedule hours burned. Moreover, for managers done usually means that there’s something−anything−that can be presented to the stakeholders in a demo.

Now let’s continue analyzing why those definitions, if taken separately, won’t help to build the potentially shippable product:

Development DoD is not enough because code was produced but not tested, at least not tested from the users perspective. Crucial tests like functionality, usability, performance, scalability and stress are still pending. Without passing all those tests, at least to a certain level, the product is simply not good enough for being shipped. A big temptation is to consider that in early stages of the product, the code is not required to pass all tests or there’s no need to test it at all. This of course violates the very definitionconception of a potentially shippable product.
Automation DoD is not good enough either, because it only covers code that has been written to test code, no bugs discovered, validated, retested or closed. It’s very true that automated test cases save many man hours of manual testing, but it should only be used as a tool that helps Quality Engineers in their work and not as a milestone that if reached qualifies the product for release.
Info dev DoD is also falling short because it only considers manuals and help files, not the product itself or the quality it might have. It’s not uncommon to see technically excellent products with a high degree of associated quality but with poor documentation. The opposite scenario is also common and even more problematic.
Project Manager’s DoD it’s focused on metrics and high level information. The biggest risk for Project Managers is to look at the wrong metrics and try to put a product out of the door when it’s not complete or stable enough. Avoiding biased perceptions that come from information collected from only one group of engineers in a team is the key for telling if the product is ready or not to go into production.
Quality Engineering DoD in my opinion, this definition is the one that contributes the most to the goal of having a potentially shippable product; the reason in simple, QE should be the last check point for telling if the implemented user stories are good enough for being considered as part of a potentially shippable product. One consideration is that the documentation provided by info dev should also be reviewed for technical accuracy. Another is that automated test cases should also be checked for effectiveness and real contribution to bug detection and validation.

It is evident that we need a DoD that can work for the whole team helping it to remain focused in the right direction and serving at the same time as a true enabler for the potentially shippable product concept. But before we go into that, let’s explore the different levels of accomplishment.

Levels of accomplishment

By accomplishment we understand some milestones that the team will be reaching during the project’s execution, there are several levels of accomplishment as we describe below:

Task level means that a task, whatever it was, has been completed. Tasks are usually performed by individuals in the team and still need to be cross checked or validated. Tasks are purposely mentioned as the smallest chunk of work and will be that which has been done by somebody in the team. Tasks have an identifiable output in the form of code written, test cases written, environments set, test cases automated, documents prepared, etc.
User story level means that all tasks in a user story have been completed, when this occurs we also have fairly good chances to say that the user story has also been accepted. Albeit bugs might appear during testing, once they are fixed the user story can be marked as accepted and will go directly into the potentially shippable product.
Sprint level means that the time boxed hours have been burnt; more importantly, the planned user stories should have been accepted. One very common mistake is to consider that a sprint was successful because the team has been able to complete certain amount of work by the sprint end date; this is true to a certain degree. The problem arises when you compare the work that has been done with what can and should be included as part of the potentially shippable product.
Release level is achieved when the product finally meets all required criteria −technical, legal, marketing, financial, etc.− to be put out of the door and make it available to clients.
Products level means that the team has been able to put several releases out of the door; by releases we don’t refer to hot fixes and service packs. Hot fixes are symptomatic of poor quality as they usually indicate that urgent fixes are required by clients that are reporting serious problems with the product. By the same token, releasing many service packs might be a good radiator for suspecting quality problems in a product, the processes and/or the team.

Unifying the DoD with the level of accomplishment

The ultimate DoD should be such that it really helps the team to envision the true goal behind the sprint: build a potentially shippable product. In that sense the Quality Engineering DoD seems to be the one that gets us closer to that goal for the following reason:

It deals with user stories, quality and completeness.
It also covers automation and info dev DoD; this assertion works under the assumption that QEs are the ones who execute automated testing suites and review written product documentation for technical accuracy.
User stories accepted by QE are probably the best indicators for managers because they reflect the degree of accomplishment on a sprint and are directly correlated to functionally that can be included right into the potentially shippable product.

Consequently, this QE DoD applied to task and user story level will have a positive impact in the sprint accomplishment level, which in turn will favorably impact on the release and product accomplishment levels.

Key Metrics for Measuring Sprint Status

2009-08-03T16:49:00.005-04:00

One of the key questions in every project of any engineering field is how to measure progress. Traditionally progress is measured considering how much work has been done in how much time. This simple approach has been working and in fact works very well for intensive production systems like factories were the degree of innovation is constrained for detailed design documents. More to the point, manufacturing tangible and simple things like screws is a repetitive task that can be done always at the same velocity. Consequently, once velocity is known, it will be very easy to extrapolate and predict how long it would take to produce an X amount of screws. Even if we think of building very complex but tangible engineering masterpieces like submarines, we’ll find that the process has been well studied and described to the last details in tons of pages of design documents. Notwithstanding, building commercial software can’t be ruled by the same principles. Key differences are not well defined requirements and changing developing conditions. For years methodologists and gurus have been trying to provide a methodology that reduces complexity to a level that can allow to have predictive planning, results were null and Agile popped up as an alternative that tries not to predict but to adapt to changes and react in kind. However, Scrum practitioners have a new challenge in front of them: how to measure sprint progress. Even if you use Scrum, a project is a project and stakeholders will always ask the typical question: Are we still on schedule? This article will explore some indicators like burn down charts, user stories life cycle, estimated vs. actual hours and team velocity.

Burn down chart

The most basic chart for measuring status is the burn down chart; however it can very imprecise because of the following:

Burned hours that are not related to productive tasks, i.e. hours allocated for Spike activities, reading, researching, attending meetings, helping teammates, etc.
Hours are not the same for development, quality engineering or automation. You can’t expect that producing code is the same as testing it or automate its testing. Further, a burn down chart can look good but you don’t know exactly what sub-team is burning more hours.
Burning hours per se won’t get you close to the completion of user stories; a user story can’t be considered completed just because its planned hours were completed or even exceeded. User story acceptance criteria need to be defined instead.
Burned hours need to be baselined to initial estimation; accuracy could be a symptom of user stories slipping dates.

Some suggestions for improvements are presented below:

Create the culture in your team to log in your tracking tool (Xplanner, VersionOne, an Excel spreadsheet or something else) only the hours that are related to productive work in coding, testing or automation.
Even thought general success or failure is everybody’s responsibility, you need to distinguish the different actors that you have: developers, architects, quality engineers, automation guys, tech writers, etc. Not differentiating them will give you the false impression that everyone can burn hours at the same rate and thus create an illusory burn down chart. Separate burn down charts could be an alternative here.
Burn down hours as a metric need to be cross referenced to user story completion; again, burning hours alone is not a good indicator.
Poor initial estimation, bad reestimations and continuous addition of work are enemies of schedule. It’s almost impossible to have every task in all user stories estimated at the beginning of the sprint, and too much estimation constrains agility. Mitigation for this is to monitor the burn down chart progress against the initial estimation and when a significant gap is perceived, work should be moved back to the release backlog or at least reprioritized within the sprint.

User stories life cycle

There are a couple of good reasons for having a life cycle for sprint user stories:

You need a visual indicator that can quickly show you the progress in a specific user story
You need to have visibility of who (development or quality engineering) currently has having the user story in his/her plate. This itself is a good indicator for the progress of a user story.

During the past years I’ve been using with great success an Xplanner’s status field for indicating the stage of the life cycle that user stories are in, this field can be customized but I’d recommend keeping the default tags like this:

Draft means that a user story has been created but no time estimations have been added yet; in other words, no tasks has been created for the user story.
Planned means that the user story already has tasks with time estimations. Besides time estimates, a user story is marked as planned when development and quality engineering have both agreed in the acceptance criteria that will be applied to decide if the user story is accepted or not.
Implemented means that development has completed the implementation of the user story, all code has been unit tested and has been checked-in in the repository and passed a build verification test. Quality engineers are free to pick the code and start testing it.
Verified means that the user story failed to pass all test cases executed by quality engineers, consequently it hasn’t met the acceptance criteria and bugs were reported. At this point, the user story returns to development’s court and will be worked there until all bugs are fixed, once this happens, development will mark the user story as Implemented and the user story will be retested.
Accepted means that all test cases passed and no bugs where found or the bugs reported where successfully validated.

Using this user story status field is not complicated, but like many things in Agile, it requires discipline. The benefits for a team that fully adopts and applies this concept are great; in my experience, this indicator complements the burn down chart perfectly.

Estimated hours vs. actual hours

Much has been written about how to make good estimations, tons of books and dissertations have been prepared on the subject, but the truth is that there’s no magic formula that can allow you to have accurate estimations in all situations. The fact of the matter is that maybe you don’t need accurate estimations, at least not for Scrum sprints, some arguments in favor of this rationale are:

The planning stage for a sprint in Scrum has to be by definition very short and very light, this contradicts the goal of having solid estimates that comes from deep analysis.
Scrum is an adaptive business framework; it doesn’t have much to do with predicting things to a great level of detail and precision.
Input for numeric estimation models varies too much from sprint to sprint; sometimes this variation is so uncontrollable that the results are considerably offset in one direction or another.
Estimating tasks for developers is quite different from doing the same for quality engineers, automation guys or tech writers. The very nature of the work of each individual in a team contributes to increase or decrease accuracy. Empirical evidence collected in my projects indicates that quality engineer’s estimations tend to be more accurate than developer’s; the reason for this seems to lie behind the more repetitive tasks that quality engineers usually perform.

Consequently, I wouldn’t recommend that you make your team invest in becoming master estimators, try to use this time to mentor them in how to be reflective and learn from past sprints instead.

Team velocity

Team velocity is an interesting indicator but it has a great disadvantage: it’s based on the number of hours that the team burns and not in the degree of success (accepted user stories) that it achieves in a sprint.

Moreover, team velocity has to be carefully analyzed because it can correspond to several things, not just developers producing code; for instance.

Velocity will tend to increase when quality engineers have enough user stories to test, testing will eventually derive in bugs being reported, bugs will need to be addressed by development slowing down the work in other user stories. Even though velocity will increase, overall productivity will decrease or stay the same at best.
Which team’s velocity are we talking about? Developers’ velocity can’t be compared to that of automation guys when they execute automated test suites. Furthermore, quality engineers doing manual testing is no match for automated testing scripts. If we try to compare velocity among these teams; we’ll see no correlation because of the implicit difference of their work.
Developers writing code apply a different velocity from what they use when they have to do unit testing or bug fixing. Again, velocity can be a misleading indicator because one might tend to think that the team has boosted productivity when, in reality, it has shifted its tasks.
Team velocity shouldn’t be applied without considering individual velocity. Individual velocity can be a very good indicator for detecting blockages or not well defined requirements; in this case individual velocity will tend to cero. Team’s velocity sometimes tends to cover these symptoms because it doesn’t offer enough granularity.