Angel "Java" Lopez : Scrum

Curso de Scrum de Tobias Mayer en Buenos Aires

lopez — Mon, 14 Dec 2009 17:49:46 GMT

El bueno de Juan Gabardini anuncia en la lista Foro Agiles, un nuevo curso de Scrum de Tobias Mayer en Argentina. Copio el mensaje original:

Tobias Mayer facilitará un taller de un día en Buenos Aires, Argentina. Está orientado a Scrum Masters y agile coaches.
Para los que no lo conocen, Tobias dió el primer curso de CSM en Argentina, allá por el 2006. Luego de eso ha venido varias veces (no se cuantos, pero dió al menos 5 CSM en Bs As). ….

Se explorarán los principios y valores de Scrum. Este taller no se focaliza en las prácticas (se asume que los participantes tienen familiaridad con ellas) y explora Scrum en un nivel más profundo y humano. A través de una serie de juegos, ejercicios interactivos y conversaciones facilitadas, se adquirirá una comprensión más profunda del nuevo esquema de pensamiento requerido para hacer Scrum. Esto no es sobre metodologías o procesos, es sobre divertirse

Cuándo: 28 de enero 2010

Dónde: Perú 375, 1^er piso (Southworks)

Costo: usd 220 + IVA

Registración: http://tinyurl.com/tobiasBsAsWorkshop

Este evento es organizado por Agiles Argentina y Agilar Argentina

Este evento será dado en inglés. Aunque por el tipo de evento no es imprescindible el hablar y entender perfectamente, ya que el resto de los que asistimos podremos dar una mano. Va el detalle en inglés.

Process/Mechanics

Scrum is quickly being seen as the de facto way of starting out down an Agile pathway. People see it as a quick and easy way in. The problem is that Scrum is very easily misunderstood. There are a multitude of Scrum Facades in place around the world, companies who claim to be doing Scrum because they have people with the titles of “Scrum Master” and “Product Owner”, have daily meetings, maybe even planning meetings, reviews and retrospectives, keep a backlog of work and show some sort of burn down graph each sprint.

Underneath the facade though, the same old command and control beast lurks, the same old fear and CYA behavior. Nothing has essentially changed. So what is missing? I believe the spirit of Scrum is missing, the essence of change.

Scrum is not just a framework and a set of roles, meetings and artifacts. Scrum is a way of being that is utterly different from any previous way of working that we have encountered in the software industry. To do Scrum — to really do Scrum — requires an absolute shift in the way we think and act.

Scrum relies on some core principles:
— Empiricism
— Self-Organization
— Collaboration
— Prioritization
— Rhythm

and some essential values:
— Courage
— Trustfulness
— Transparency

This session will allow Scrum practitioners to reach the next level of Scrum by exploring some of these underlying foundations in a highly experiential way. The session will consist of a series of interactive exercises and facilitated discussion designed to help participants not just understand, but embody these principles and values at a deep level.

I create and/or adapt new games frequently, the majority require no props, and usually require the participants to be on their feet. Most have simple formats and can be easily remembered. None of them have pre-determined outcomes: they are all about self-discovery. For more detailed information on the kinds of games and interactive exercises I’ll use for this session please follow one or more of these links to descriptions of sessions I have run previously.

Agile Thinking — Agile2005 session

Great Game of Power — Scrum Exchange 2006 session

Scale Back: Small is Beautiful — Agile2008 session

Operating on the Creative Edge — Agile2008 session

This session is intended as a taster and it is hoped participants will be encouraged to explore more deeply the human interaction foundations of Scrum once they leave the conference.

Learning outcomes

Tobias Mayer has built a reputation in the Scrum world of offering highly challenging training sessions, pushing people to the edge of their comfort zone and ultimately breaking through to a new way of behaving. This session has that same outcome in mind.

Ya comenté sobre el bueno de Tobias en:

Tales from the Scrum: La esencia de Scrum
Tales from the Scrum: Un día en el equipo
Tales from the Scrum: El corazón de Scrum

Nos leemos!

Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez

Tales from the Scrum: Los Rolling Stones y cómo va su proyecto

lopez — Mon, 07 Dec 2009 09:22:09 GMT

Bueno, en realidad, no los Rolling Stones. Solamente Keith Richards, y no el de los Rolling, sino Keith Richards presidente de Keith Richards Consulting. Encuentro en un post de Gojko Adzic un post que comenta una charla de KRC:

Eight interesting techniques to test how a project is going

Es un muy interesante post, déjenme escribir esas técnicas, para saber si el proyecto y el equipo están en buena forma, sea que estén siguiendo Scrum o no. Esta es mi propia traducción de ese texto:

- 1. ¿Puede cualquier miembro del equipo escribir el objetivo del proyecto en una nota post-it con marcador grueso? Si no pueden, el final del juego no está claramente definido ni entendido por todos

- 2. Acérquese a un colega en su trabajo, y pídale ayuda para algo cualquiera. Vea cómo reacciona. Si encuentra una respuesta fría, la persona no está muy contento con su trabajo. Richards aconseja armar equipos con “aquellos que respondan ‘puedo’”. Esa gente mejorará la comunicación y el espíritu de equipo en su proyecto.

- 3. Cuando una fase del proyecto está oficialmente “hecha” (done), pregúntese a sí mismo: “¿Es seguro seguir adelante?”. Si esta pregunta le provoca una mala sensación en las tripas, es que no están listos todavía para avanzar a la siguiente etapa.

- 4. ¿Cuántos de sus proyectos terminan con una seria revisión del proyecto? Esto es, según Richards, crucial para la mejora de su organización. Permite prevenir errores repetidos y compartir conocimiento entre los equipos (yo agrego que, si trabaja en una organización con varios proyectos y equipos, tendría que haber comunicación entre equipos DURANTE los proyectos, comentando bloqueos, avances, hallazgos, problemas y soluciones; unas buenas reuniones periódicas con presentaciones timeboxed pueden ser un camino a seguir).

- 5. ¿Cómo reacciona la gente de su equipo cuando el cliente dice “cambié de idea”? Si reaccionan negativamente, el sistema que están construyendo no es tan flexible como debiera.

- 6. Pregúntele a alguien que le comente el estado actual de una tarea, y luego cállese 10 segundos; no hagan nada para provocar una respuesta. Si la persona se muestra insegura o nerviosa sobre algo, seguramente comenzará a comentarlo. Si se mantiene en silencio, las cosas van bien (este punto lo discutiría: debería haber comunicación y visibilidad sin necesidad de llegar a este tipo de “trick”).

- 7. ¿Conoce cuánto tiempo se empleó en la última iteración en pruebas? Si no puede estimarlo, no está tomando buenas métricas del proyecto. Tomar métricas de este tipo, dice Richards, es crucial para hacer estimaciones realistas (nota mía: ojalá tuviera un peso por cada vez que alguien en un equipo estimó una tarea SIN tener en cuenta pruebas, verificación, etc.; pongan atención a esto).

- 8. Tome un documento de su proyecto, usado durante una presentación. Si atrás hay diagramas dibujados a mano, señal que el documento no está claro, y necesitó de esa ayuda para ser explicado.

Me quedo principalmente con los puntos 1, 2, 3, 5 en primer lugar. Luego 7, 4.

Nos leemos!

Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez

ALT.NET Hispano VAN: Get Things Done con Jeroen Sangers

lopez — Fri, 04 Dec 2009 10:13:20 GMT

Este sábado 5 de Diciembre, 18 GMT/UTC (3 de la tarde por aquí en Buenos Aires), habrá otra des-conferencia virtual de la comunidad ALT.NET Hispano. El tema será productividad, más específicamente Get Things Done (GTD) (ver también Consigue hacer el trabajo). La presentación inicial estará a cargo de Jeroen Sangers:

http://jeroensangers.com/

@jeroensangers

Este es el temario de Jeroen:

Mi presentación va más que nada sobre Getting Things Done y consiste
de tres partes:
1. Control: un flujo de trabajo para controlar tus acciones
2. Perspectiva: dar dirección a todo lo que haces
3. Consejos prácticas para implementar un sistema de productividad

GTD se populariza con un libro de David Allen. Pueden leer la descripción de GTD en el sitio de Allen:

What is GTD?

Ahí leo:

Sophisticated without being confining, the subtle effectiveness of GTD lies in its radically common sense notion that with a complete and current inventory of all your commitments, organized and reviewed in a systematic way, you can focus clearly, view your world from optimal angles and make trusted choices about what to do (and not do) at any moment. GTD embodies an easy, step-by-step and highly efficient method for achieving this relaxed, productive state. It includes:

Capturing anything and everything that has your attention

Defining actionable things discretely into outcomes and concrete next steps

Organizing reminders and information in the most streamlined way, in appropriate categories, based on how and when you need to access them

Keeping current and "on your game" with appropriately frequent reviews of the six horizons of your commitments (purpose, vision, goals, areas of focus, projects, and actions)

Pueden encontrar una buena descripción (con diagrama incluido, como el que aparece en el libro original) de GTD y una relación con los “cuadrantes de Covey” (me gusta recordar al creador de ese concepto, que es la matriz de Eisenhower).

Mis enlaces sobre GTD, y productividad:

http://delicious.com/ajlopez/gtd
http://delicious.com/ajlopez/productivity

Bueno, ya envíe varios posts sobre las VAN de ALT.NET Hispano, pero les recuerdo:

Si no conocen qué es una reunión VAN, pueden consultar VAN meetings. Para ver cómo se desarrolla una VAN de ALT.NET Hispano, y qué software necesitan para asistir, ver Descripcion-de-Reuniones-VAN. Pueden ver el historial de anteriores reuniones VAN (visiten las que dieron, por ejemplo, sobre NHibernate, WPF y demás) (yo participé en VAN sobre Scrum y en otra sobre generación de código). También pueden suscribirse para proponer nuevos temas, y colaborar con la comunidad. Si no pueden asistir a ésta VAN, seguramente quedará publicada más adelante, con video incluido.

Nos leemos!

Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez

Recursos de Scrum, del curso de Buenos Aires

lopez — Thu, 03 Dec 2009 11:50:40 GMT

Gracias a la gente del Microsoft User Group de Argentina, ayer miércoles 2 de diciembre estuve dando una jornada de Scrum teoría y práctica, de todo un día. Con unos treinta asistentes, estuvimos viendo temas como el manifiesto ágil, y las ideas que sustentan Scrum en particular. Así como también los roles, artefactos, reuniones, que se manejan en este marco de trabajo. Discutimos tópicos como contratos ágiles, relación con el cliente, la importancia del product owner, la auto-organización del equipo, el “ownership” que tienen que ganar, la idea de trabajar a un ritmo razonable, el “entrar en flujo”, Product backlog vs Sprint Backlog, y el clásico Chanchos y Gallinas.

Para mí, fue una grata experiencia: es uno de los cursos donde veo que más puedo aportar, y donde podemos practicar algo que considero muy importante conocer como es Scrum. Veo que la necesidad de tener equipos ágiles es creciente, no sólo en el desarrollo de software, sino en actividades en general. La labor en equipo permite llegar a objetivos que son más difícil de lograr individualmente o en simple grupo (vean que distingo entre equipo y grupo). Hay que estudiar más en detalle cuáles son los factores que hacen que Scrum funcione (me basé mucho en la idea de No somos vulcanos): hay un bias hacia mostrar los casos de éxito en la comunidad ágil, y no comentar los fracasos. Hay que pasar de la evidencia anecdótica a un fundamento más firme, no porque el marco de trabajo en sí lo necesite, sino para poder aplicarlo mejor, entender mejor en qué circunstancias funciona, y en cuáles se complica.

La parte teórica ocupó la mañana, pero ya después los asistentes se separaron en cuatro grupos, y comenzaron a trabajar en desarrollar un entregable, en dos sprints de 3 días de 10 minutos cada día. Fue una experiencia interesante: fuimos viendo cómo mejorar las reuniones, la precisión del backlog, los acuerdos con el product owner para los entregables de Sprint Review, el reparto de trabajo, la mejor partición de las tareas en el Product Backlog, y más.

Prometí publicar un post con los recursos que mencioné en el curso. Acá van los enlaces y bibliografía, que son similares a los que ya publiqué hace unos días para otros cursos dictados, pero para más comodidad, los concentro de nuevo en este post:

Reunión virtual de Scrum, con video (gran parte de la teoría vista en el curso está en este video) (ahí están los enlaces que presento acá).

Presentación usada en el curso ScrumSpanish.pptx

Pueden usar esta presentación compartida (en varios idiomas):

A Reusable Scrum Presentation. Introduce Scrum to your team, ScrumMaster and Product Owner.

Para leer en inglés y en español Scrum Primer

http://agilethinking.net/ El sitio de Tobias Meyer, que me inició en el ScrumMastering en el 2006.

http://www.implementingscrum.com/ Sitio donde encontraran la clásica historia: The classic story of the pig and chicken

El Manifiesto Agil mencionado en la charla

Artículo corto en inglés (pdf) What is Scrum?

Reviews of Agile Product Backlog and User Story Management Tools: http://www.userstories.com/

Presentación en español sobre Contratos Ágiles

Slides: http://www.slideshare.net/proyectalis/090603-contratos-giles
Video Parte 1: http://www.viddler.com/explore/jmbeas/videos/3/
Video Parte 2: http://www.viddler.com/explore/jmbeas/videos/4/

Foro Agiles (Grupo Yahoo en español)

Blog de Juan Gabardini Software Agil

Enlaces y recursos adicionales en Scrum Práctico

Scrum Cheat Sheet

Scrum: Ficha Sinóptica

Un libro que para preparar las primeras versiones del curso

Agile Project Management with Scrum

En ese libro, están enumerados estos recursos:

Agile Software Development with Scrum, Ken Schwaber and Mike Beedle (Prentice Hall, 2001)

Teoría y práctica de Scrum.

www.controlchaos.com/

El sitio de Ken Schwaber sobre Scrum.

http://www.jeffsutherland.com/

Jeff Sutherland tiene contenido relacionado con desarrollo de software, programación, tecnología, objetos, componentes y Scrum.

www.mountaingoatsoftware.com/scrum/

El sitio de Mike Cohn sobre Scrum.

www.scrumalliance.org

El hogar de los ScrumMaster certificados.

www.agilealliance.org

El sitio de la AgileAlliance, con recursos sobre Agile y Scrum.

http://groups.yahoo.com/group/scrumdevelopment/

El grupo de discusión de Scrum, con años de existencia.

www.xprogramming.com

El sitio de Ron Jeffries acerca de Extreme Programming (XP). XP provee varias de las prácticas que Scrum implementa para asegurar el incremento de funcionalidad potencialmente entregable.

Otras lecturas recomendadas

Agile and Iterative Development: A Manager’s Guide by Craig Larman
Agile Estimating and Planning by Mike Cohn
Agile Retrospectives by Esther Derby and Diana Larsen
Agile Software Development Ecosystems by Jim Highsmith
Scrum and The Enterprise by Ken Schwaber
User Stories Applied for Agile Software Development by Mike Cohn
Artículos semanales en www.scrumalliance.org

Mis posts sobre Scrum (estoy ahí escribiendo una serie “Tales from the Scrum” donde trato más en detalle algunos puntos que tratamos en el curso).

Los enlaces que me interesaron los colecciono en:

http://delicious.com/ajlopez/scrum
http://delicious.com/ajlopez/agile

Nos leemos!

Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez

Tales from the Scrum: el Product Owner y el Product Backlog

lopez — Sat, 28 Nov 2009 11:01:47 GMT

Quisiera hoy detenerme en uno de los roles de Scrum: el Product Owner (podría traducirlo por “dueño del producto”, pero voy a seguir la costumbre de usar la denominación en inglés), y en particular, en una de sus actividades.

La principal actividad, que le compete completamente, es el mantenimiento de los items del Product Backlog, y sus prioridades. Recordemos que el Product Backlog es el documento que lista la funcionalidad que esperamos del producto terminado. Esta lista es evidentemente importante: mal armada, puede hacer que el producto a entregar no sea el que el cliente final necesita.

Esa lista no la decide el Equipo, y menos el Scrum Master. Lo decide el cliente, en reuniones anteriores al inicio del proceso, donde pueden intervenir distintos interesados, pero de ahí en más es el Product Owner el responsable de mantenerlo (un Product Backlog puede cambiar con el tiempo, no es un documento escrito en piedra). Este es el responsable de entender, mantener, y conocer las prioridades de esta lista, del que saldrá el producto que entregaremos al final del proceso.

Es común, si no se conoce Scrum, querer priorizar los items por su orden “lógico” de desarrollo. No: la idea es priorizar por importancia para el negocio, para lo que necesita el cliente. De ahí que las prioridades no las decide el Equipo, sino el Product Owner.

Esto implica que la persona que encarne ese rol, debe conocer del negocio del cliente. Debe tener contacto con los principales actores de la actividad del negocio, entenderlo, y debe conocer cuáles son las áreas importantes. Demos un ejemplo.

Si tenemos que desarrollar un sistema de seguros en línea, el Product Owner deberá decidir qué partes del sistema a entregar darán más valor al negocio, y por qué. Tal vez, el grueso del negocio sean los seguros de vida, o tal vez el seguro de camiones, o quizás el seguro de autos. Dependiendo de ese dato, se podrá priorizar el tener una aplicación para calcular un seguro de vida, antes que uno de autos. No se comienza por lo “más fácil”, o por “lo que nos están pidiendo ahora”, sino por lo más importante.

Si un equipo técnico tuviera que decidir sobre esos puntos, seguramente tomaría primero el tener una base de datos, o un sistema de seguridad, o cualquier otro punto. No es la idea en Scrum: la idea es entregar, al final de cada Sprint, iteración, algo que agregue valor. Por supuesto, lo entregado deberá cumplir con la calidad esperada por el cliente, pero debe estar alineado con los items del Product Backlog, armado y priorizado por el Product Owner.

Como escribía más arriba, el Product Backlog inicial no es necesariamente EL Product Backlog final. Pero los cambios, de items, de prioridades, deben ser hechos por el Product Owner. El Equipo podrá levantar la mano, sugerir cambios, pero la decisión de cualquier modificación, recae en el Product Owner. Y éste no deberá cambiar los items por cualquier causa: deberá consultar con los interesados en el proyecto, con los que conocen del negocio, y estar atento a cualquier cambio en el entorno, para poder priorizar los items que son necesarios mantener en el Product Backlog.

Vean entonces, la importancia del rol del Product Owner. De hecho, hay cursos especiales de entrenamiento de Product Owners, en el ambiente de Scrum. Muchas de las decisiones importantes pasan por él. Por supuesto, no son decisiones en solitario, consulta y recibe asesoramiento de otros interesados. Pero un Product Owner debe ser alguien que realmente se empape del negocio y del producto que queremos lograr. Puede que no sepa todo, pero debe tener el acceso a la información y al conocimiento de otras personas, y tener una mente y actitud de aprendizaje y atención al negocio.

Uno de los anti-patrones de Scrum que mencionaba en el post Anti-Patrones de Sprint era Demasiados cambios en los requerimientos, entre Sprints. Román Mussi comentaba:

Angel, sobre esto:

"Demasiados cambios en los requerimientos, entre Sprints"

Esto no estaría dependiendo del Product Owner? Y en ese caso... como puede intervenir el ScrumMaster para mitigar el problema?

Ciertamente, es un problema que puede nacer de un Product Backlog cambiante. Quisiera aclarar que los cambios pueden ser necesarios: tal vez el negocio de seguros cambión, y la plata ahora está en asegurar camiones: los seguros de vida donde poníamos nuestras fichas fueron afectados por algo, como la llegada de un competidor del extranjero, un cambio en la legislación, o lo que sea. Y esos cambios, el equipo debe enfrentarlos, sin perder impulso, sin sentir el “dolor del cambio”. Scrum, como todo lo ágil, está preparado para fomentar la aceptación del cambio, no de luchar contra él. Pero el anti-patrón aparece si los cambios no son producidos por una nueva evaluación del negocio.

Los cambios así sin sentido de negocio, pueden venir de varias causas. Por ejemplo, un Product Backlog débil inicialmente, que no estaba claro al comienzo, puede ir mejorando al ir entendiéndose mejor el producto a producir, y el negocio en el que está inserto. Igualmente, pediría tratar de evitar esta situación: antes de lanzar el proceso, debería quedar más claro el Product Backlog. No habría que escatimar esfuerzo en tener un buen Product Backlog. Insisto: puede que no sea el final, pero deberíamos haber invertido un tiempo para no desperdiciar tiempo y esfuerzo del equipo. Es claro que no esperamos un “gran diseño inicial”, no es un tema de diseño técnico: es tema de sentido común, sobre lo que queremos obtener.

Pero, por lo menos, si lo anterior tiene olor de anti-patrón inicial, por lo menos el documento evoluciona hacia algo mejor, más firme. Pero otra causa para que aparezca “mal olor” en el Product Backlog (más frecuente de lo esperado, en especial en proyectos largos), es ceder a las presiones externas: de pronto, por atender lo urgente (“tenemos que tener en línea los seguros de autos para la exposición Car2009 que comienza dentro de un mes”), o requerimientos internos de gente con poder en el cliente (“mi división necesita los seguros de camiones para ayer”), el Product Owner cede y cambia el Product Backlog. A ver, pongamos alguna aclaración y contexto: si realmente el futuro de la empresa depende del impacto que tenga en la exposición de autos que viene, entonces es válido el cambio (yo preguntaría entonces: esa exposición estaba planeada desde hace un año, por qué ese cambio de dirección no se previó antes?). Pero si solamente es un cambio promovido por urgencia, y no por importancia, estamos atacando el proceso.

De alguna forma, todo lo ágil, más allá de Scrum, nos trata de proteger del síndrome “lo urgente mata lo importante”. El Product Backlog es el documento primordial, que guía las decisiones del resto del proyecto. El tener un Product Backlog “manteca”, que cambia de forma a cada momento, o según “cómo calienta el sol”, que se modifica incluso en el medio del Sprint (los dioses de Scrum no lo permitan!!), es síntoma de estar reaccionado a lo urgente, en vez de actuando sobre lo importante. El Product Owner, ayudado por el Scrum Master, y el compromiso de la dirección, deberá encarar ese problema.

Espero que haya quedado claro la importancia del rol del Product Owner (en mi postura, el eslabón más débil en Sprint, por ser el que concentra tantas decisiones), y la salud del Product Backlog. Pienso que agregando ejemplos negativos al final, quedó mejor transmitido ese mensaje. He visto proyectos bien llevados, donde todo esto pasa desapercibido, justamente, porque es lo natural. Poner énfasis en los problemas, nos ayuda a entender por qué funciona un proyecto Scrum bien manejado.

Nos leemos!

Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez

Curso de Scrum práctico en Buenos Aires

lopez — Tue, 17 Nov 2009 13:39:00 GMT

En general no anuncio los cursos que estoy por dar (la difusión queda a cargo de cada institución), pero este es un curso que quiero destacar, porque trata de un tema que pienso que todo grupo de desarrolladores por lo menos tendría que conocer y practicar en algún momento. Es un curso que hace unos meses que no estoy dando por Buenos Aires, y siempre he tenido buenas experiencias dándolo.

Gracias a la gente del Microsoft User Group de Argentina, daré un curso de Scrum con una explicación inicial, y luego todo práctica, el miércoles 2 de diciembre de 2009. Pueden ver más datos, costos, y forma de inscribirse en:

Jornada de Scrum, teoría y práctica

El contenido (lo copio de ahí):

- El Equipo de trabajo. Los Roles: ScrumMaster. Product Owner. Daily Scrum. Chickens y Pigs. ScrumMaster vs Project Manager.
- Objetivos: Control empírico del proceso de desarrollo. Dar visibilidad de lo que se está haciendo. Generar una relación de confianza y comunicación constante entre el cliente y el equipo.
- Los Conceptos: Iteraciones. Autoorganización. Descripción del método.
- La Documentación: Qué es, cómo se arman y cómo se utilizan el Product Backlog, el Sprint Backlog y Burndown Chart.
- La Práctica: Se formarán equipos de trabajo, que resolverán un caso práctico. Se asignarán los roles y se discutirá cada caso en particular, buscando arribar a la solución al final de la jornada.

Lo importante es el trabajo práctico. Iremos descubriendo juntos algunas características, prácticas, y el por qué de cada cosa, en el marco de trabajo Scrum.

Para los que no puedan asistir, recuerden que siempre escribo por acá sobre el tema en posts sobre Scrum. Ahí encontraran un varios posts, con enlaces, referencias, presentaciones, sobre el tema Scrum y ágil en general. Los posts primeros a revisar, con material relacionado, incluso un video de una charla y discusión sobre el tema, en:

Resultado de la VAN en ALT.NET Hispano sobre Scrum
Scrum Práctico
Scrum Práctico en Santa Fe
Explicando Scrum

Nos leemos!

Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez

Tales from the Scrum: La esencia de Scrum

lopez — Mon, 16 Nov 2009 09:14:45 GMT

En esta serie de post, aún falta que escriba describiendo de principio a fin lo que es Scrum. Para llegar a ese punto, primero quiero compartir con Uds. esta traducción de un post de Tobias Mayer, quien fue mi instructor de Scrum Mastering en 2006. El post original, en inglés, lo encuentran en:

Essence of Scrum

Acá va mi traducción:

Scrum comenzó su vida como uno de las nuevas formas Agiles para construir software. En estos días, se lo considera una forma que puede ser usada para mejorar el mundo del trabajo, en un sentido más general, y así, cambiar la forma en que los individuos piensan e interactúan con otros en situaciones de trabajo. El potencial completo de Scrum está por explorar.

En resumen, Scrum es una manera simple de manejar problemas complejos, proveyendo un marco de trabajo para soportar la innovación y permitir que equipos auto-organizados entreguen resultados de alta calidad en tiempos cortos. Scrum es un estado de la mente; en una manera de pensar que libera el espíritu creativo mientras se mantiene firmemente apoyado en principio sólidos y largamente respetados, incluyendo el empirismo, la emergencia y la auto-organización.

Empirismo se refiere al proceso continuo de inspeccionar/adaptar que permite que tanto trabajadores como gerentes tomen decisiones en tiempo real, basado en datos actuales, y como resultado, puedan responder rápidamente a condiciones siempre cambiantes que se presentan en el ambiente, como por ejemplo, el mercado donde el software a construir es vendido o distribuido.

La Emergencia surge de una aproximación empírica. Implica que todas las soluciones a todos los problemas se volverán claros a medida que trabajamos. No se volverán claros si simplemente hablamos de ellos. El “Big Up Front Design” (gran diseño de antemano) sólo producirá un “Big Wrong Design” (gran diseño erróneo) o a lo sumo un “Big Working But Totally Inflexible Design” (gran diseño que funciona pero totalmente inflexible). Cuando permitimos que las soluciones emerjan es siempre la solución más simple y apropiada, para el contexto actual, la que sube a la superficie. La emergencia junto con el empirismos nos guiaran a la solución más apropiada y flexible (es decir, que podemos cambiar).

Auto-organización se refiere a la estructura de los equipos que crean el producto. Se les da poder a pequeños equipos multidisciplinarios para que puedan tomar decisiones importantes, necesarias para 1) crear un producto de alta calidad, y 2) manejar su propio proceso. Acá la idea es que aquellos que hacen el trabajo conocen mejor que nadie cómo hacer el trabajo. Estos equipos trabajan de una manera altamente interactiva y generativa, donde el producto emerge del diálogo continuo, de la exploración e iteración. La auto-organización funciona cuando hay objetivos y límites claros.

Además de estos principios, Scrum se apoya en dos mecanismos principales: priorización y “timeboxing” (poner límites de tiempo a una tarea).

Priorización simplemente significa que hay cosas que son más importantes que otras. Esto es tan obvio que se olvida muchas veces cuando pensamos “necesitamos esto AHORA”. Scrum nos ayuda a poner el foco de vuelta en seleccionar cuáles son las cosas más importantes a hacer primero, y entonces, a hacerlas! Tomándose el tiempo para priorizar, y siendo rigurosos sobre eso, es esencial para el éxito de Scrum.

Timeboxing es un mecanismo simple para manejar la complejidad. No podemos imaginar el slistema completo de una vez, todo junto, entonces, tomamos un pequeño problema y en un corto espacio de tiempo, digamos una semana o un mes, trabajamos en solucionar ese problema. Los resultados de esa acción nos guiaran entonces a una solución para el próximo problema, más grande, y nos dará más conocimiento sobre las necesidades del sistema en conjunto.

Cambio organizacional

Con Scrum, las jerarquías de gerencia de las organizaciones tienden a ser niveladas y los equipos de desarrollo tienen más contacto directo e inmediato con los clientes. El ambiente de trabajo se vuelve menos “comandar-y-controlar” hacia un estilo más colaborativo. Se promueve el diálogo regular y abierto sobre la documentación extensiva, y el acuerdo negociado es preferido a los contratos de trabajo formales e impersonales.

Las cualidades de apertura, honestidad y coraje son fomentadas en todos los niveles, y la ganancia individual se vuelve secundaria ante el avance colectivo. Un ambiente Scrum es uno que soporta a la gente, donde las personas de todos los niveles muestran respeto y confianza entre ellos. Las decisiones se toman por consenso, más que por imposición de alguien de más arriba, y todo el conocimiento es compartido, de una manera transparente y sin recelos.

Scrum va en contra de lo que hacen muchas compañías de la industria del software, donde una forma en fases acoplada con un alto grado de micro-gerenciamiento, y una insistencia en procesos definidos y documentación extensiva, se han hecho la norma por treinta años. Muchas compañías se basan en el miedo y el dinero como motivaciones claves para sus trabajadores. Esta forma de trabajo ha mostrado éxitos a corto plazo, pero más y más compañías están comenzando a entender que no es una buena estrategia para el largo palzo. Sin embargo, el concepto de cambiar a algo tan radical como Scrum aterroriza a muchos corazones de ejecutivos y gerentes de nivel medio.

Scrum está aún en la etapa de los “early-adopter” (los que abrazan tempranamente las nuevas ideas). Tomará muchos años para que la mayoría de las compañías reconozcan los beneficios de crear más lugares de trabajo, llenos de confianza. Sin ese cambio, muchas compañías de software se irán hundiendo bajo el peso de sus procesos pesados, y fuerzas de trabajo sobrecargadas. Otros, aquellos que abracen el método liviano, ágil, de Scrum, tendrán la gran oportunidad de sobrevivir y prosperar. Para aquellos que pasen a Scrum, y lo abracen completamente, la vuelta atrás a a los viejos días de trabajo será impensable. Un cambio de paradigma está ocurriendo en el lugar de trabajo, y Scrum es una parte importante de ese cambio.

Nota: el término Scrum proviene de un “paper” titulado The New New Product Development game de Hirotaka Takeuchi y Ikujiro Nonaka. En rugby, un scrum es una forma de recomenzar el juego, luego de una infracción accidental o después que la pelota salió de juego. La práctica de Scrum en el mundo del software incluye reuniones regulares diarias y cortas donde los miembros del equipo se juntan para comunicar su progreso. Debido a la similitud entre la pausa del juego (trabajo), y habiendo los jugadores (miembros del equipo) armado la reunión, ésta se conoce comúnmente como el Daily Scrum. Jeff Sutherland, John Scumniotales y Jeff McKenna son los responsables de haber introducido el término Scrum en el mundo del desarrollo del software en 1993, mientras trabajaban en la Easel Corporation, una compañía de herrmientas de software de Massachusetts. Ken Schwaber escribió el “paper” original sobre Scrum, SCRUM Development Process, que fue presentado en la conferencia OOPSLA en 1995.

Otras referencias:
Scrum: its place in the world
Scrum for Software Development

Gracias a Tobias por tan buena descripción de Scrum.

Nos leemos!

Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez

Tales from the Scrum: Anti-patrones de Sprint

lopez — Thu, 29 Oct 2009 11:34:52 GMT

Recordemos: el Sprint es la iteración en Scrum: puede durar una, dos semanas, o un mes. Eso se decide según el proyecto y el equipo. En los primeros tiempos de Scrum se elegía un mes, pero ahora se prefieren sprints más cortos: una de las razones es para responder a cambios más rápidos.

El Sprint se inicia con una reunión de Sprint Planning, donde se expone el estado actual del Product Backlog (la lista de requerimientos del producto que estamos armando), y se arma el Sprint Backlog (la lista de tareas que se eligen para ese Sprint). El Sprint termina con la reunión Sprint Review, donde se presenta el nuevo estado del producto. Cada día, el equipo se reúne, y realiza la reunión diaria de Scrum, para informar el estado y comprometerse a las tareas de ese día. El ScrumMaster va acompañando al equipo para que aplique Scrum de forma efectiva.

De vez en cuando, aparecen, aún equipo saludables, algunas actitudes y actividades que podemos denominar anti-patrones: no están alineadas con los principios de lo ágil y de Scrum. Veamos algunas:

- Tomar demasiadas tareas para el Sprint: el equipo, entusiasmado (o presionado), toma más tareas que las que son materialmente cumplibles. Un equipo maduro conoce su fuerza y capacidad, y sabe hasta dónde puede llegar en cada Sprint.

- No partir bien las tareas del Sprint: Relacionado con lo anterior. Una de las actividades de la Sprint Planning es enumerar las tareas que serían necesarias para avanzar con los items más prioritarios del Product Backlog (armado por el Product Owner). La lista de tareas tiene que estar bien armada (no olvidarse de ninguna). Luego se evalúa el tiempo y esfuerzo necesario para cada tarea. Y acá he visto muchas veces esto: el equipo no parte la tarea en subtareas. Si una tarea no se parte de esa manera, es más difícil evaluarla. Yo recomendaría partir cada tarea en subtareas que puedan evaluarse en tiempo de horas. Si una tarea es “armar los reportes contables”, no dejarlo así enunciada. Pasarla a la lista de subtareas, y evaluar una por una. Por ejemplo: una lista de esos reportes, y a su vez, dividir en programar el reporte, verificarlo, documentar en el manual de usuario, armar el script de instalación, e instalarlo en el servidor de pruebas. Si no se parten adecuadamente las tareas, no podemos evaluar bien el tiempo que emplearemos. No tiene que ser una partición definitiva: se puede ir refinando con el correr del Sprint. El llevar el detalle a subtareas de horas, que puedan realizarse en fracciones de días, tiene también otra ventaja: quedan disponibles para que se tomen en la reunión diaria: la tarea de cada miembro debería ser poder terminada en el mismo día. Sino, debería anunciar qué parte de la tarea toma, y a qué punto de avance se compromete a llegar en ese día.

- Una tarea para un miembro: cada día, debería cada miembro del equipo tomar una tarea, para seguir avanzando en el cumplimiento de lo que se comprometió para este Sprint. Pero puede pasar, que una tarea queda por siempre asignada a un miembro del equipo. No es la idea de Scrum: un miembro no toma esa tarea para él por todo el Sprint. La tarea es del equipo. Que haya un miembro del equipo más capacitado para llevarla a cabo, no implica que sólo él se encargue de la tarea. Debería por lo menos hacer “pair programming”, ir educando a alguien más en el equipo, para no caer en eso de “esta tarea es para Juan” y sólo para él.

- Entregar trabajo no terminado: Iba a poner “o terminado parcialmente”. Pero no debería existir ese concepto en un Sprint. La idea es entregar una tarea, bien terminada, bien hecha. Prefiero que un equipo tome una sola tarea, y la termine bien, a que encare cuatro tareas y finalmente, a cada una le falta algo para ser considerada realmente “hecha”. Muchas veces, el equipo piensa que de esta forma va avanzando: entregar 10 tareas, aunque no estén bien terminadas. Y piensa que así es mejor. Pero la experiencia muestra que el trabajo adicional de revisarlas y completarlas más adelante, no se puede soslayar. O si lo salteamos, habremos entregado producto sin una calidad y terminación adecuada. No hay que “patear para adelante” este tipo de cosas.

- No verificar el trabajo: En el trabajo de cada, se va cumpliendo con las tareas, pero no se verifican. Así, puede pasar que lo que un miembro consideró como terminado, en realidad le falta algún detalle. Hay que recordar que el trabajo debe ser entregado de forma tal, que tenga la menor cantidad de errores o problemas al usarlo. No es cuestión de “termino tal tarea, cualquier problema me lo van a informar en el próximo Sprint”. No es la idea. El espíritu es

- Tener un Sprint de “estabilización del producto”: Como las tareas se fueron entregando de forma no “totalmente hecha”, se elige un Sprint para “pulir” el producto, revisando lo entregado, para mejorarlo y corregir pequeños temas. De nuevo, no es la idea: no debería haber, en lo posible, este tipo de “estabilización”. En vez de haber entregado esas tareas de forma parcial, se deberían haber entregado menos tareas, pero bien terminadas. Como digo, el producto de cada Sprint debe venir “en paquete con moñito”: evitar la entrega parcial.

- No hacer “pair programming”: si bien Scrum no exige esto, he visto que es común que alguna disciplina ágil, como la programación de a pares, se saltea siempre. Ya sea porque el equipo es pequeño y hay muchas tareas, o por la razón que sea, todas las tareas se ejecutan individualmente. El trabajo de a pares facilita la terminación de la tarea, dos cabezas piensan más que una, hasta se verifica mejor el trabajo entregado, y tiene un beneficio adicional: la integración del equipo.

- Demasiados cambios en los requerimientos, entre Sprints: Esto va más allá del Sprint, pero puede pasar: de Sprint a Sprint, los items del Product Backlog y sus prioridades, van cambiando demasiado. Lo que era prioridad hoy, mañana ya no es. Lo que se pidió para este Sprint “porque era importante”, resulta que para el próximo sprint ya no se tiene en cuenta. Tal cantidad de cambios, es indicación de una falta de rumbo. Y puede llegar a desmotivar a un equipo: ve que cada cosa que va armando, al final, no se usa, y se tiene que dedicar a cada momento a otra cosa.

- Olvidarse de la retrospectiva: una reunión importantísima del marco de trabajo Scrum. Parece que esta reunión muchas veces queda en el camino. Con el gusto diario de hacer tareas, con la concentración que implica el Sprint Planning, con la excitación de la entrega en el Sprint Review, al final, no hay tiempo o nos olvidamos de hacer la reunión de retrospectiva. Un gran error: es la gran oportunidad del equipo para reflexionar sobre lo que está haciendo y sobre la salud del proceso.

- Saltearse algún Daily Standup Meeting (la reunión diaria): Alguna vez, por temas de tiempo, de organización de un día en particular, se saltea esta reunión. Si una parte del equipo no puede asistir (ejemplo: fue a una reunión de capacitación), se debe acordar: o la realizamos igual, aunque sea con dos miembros, y luego, si se reintegra el resto del equipo, hacemos una sincronización; o la pasamos ese día a otro horario. Pero les recomendaría no saltearse esta reunión.

El primer paso para ir corrigiendo estas situaciones, es darse cuenta: esa es la función de la retrospectiva. El segundo paso: no corregir todo de una, sino ir encarando problema por problema: comprometerse mejorar en un punto, y revisar la mejora en la próxima retrospectiva.

Post relacionado: Tales from the Scrum- Anti-patterns de la reunión diaria

Nos leemos!

Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez

Tales from the Scrum: No esperemos a Superman

lopez — Sat, 24 Oct 2009 14:18:29 GMT

En estos días, buscando ejemplos de antipatrones de Scrum, me encuentro con el “Hero-Driven Development” (visiten todo el blog Scrum is Scrum). Hace poco comentaba sobre las “prima donnas” en desarrollo en Tales from the Scrum- No somos Q. El caso que quiero comentar ahora, es distinto. El desarrollador super héroe de nuestra historia, puede ser un tipo apreciado, querido por el equipo, reconocido en su campo. Es uno de esos desarrolladores que puede programar mucho más que los demás. Steve Mc Connell los llama 10X Developers. Pero puede causar problemas. Veamos (basado en el blog que mencioné):

Problema: En el medio del desarrollo, surge un problema. Puede ser una configuración de Windows Communication Foundation, un tema de mapeo de Hibernate, una instalación en JBoss. No importa. El problema es complejo, y bastante técnico. De pronto, se abre la ventana, y entra nuestro “programador héroe”, reluciente en su traje. Se sienta, mira el código, entiende el problema, y lo va solucionando. El equipo, arrobado, se queda atrás, mirando, cómo nuestro Superman del código, va resolviendo el más intricado nudo de desarrollo. El héroe, concentrado, no habla ni explica. Parece relajado, lo que hace es “pan comido” para él. Entonces, en un momento, para, el problema está solucionado, levanta la vista, mira al equipo, y sale volando por la ventana, directo hacia el atardecer. Gran música de fondo.

Contexto: El equipo no sabe cómo solucionar el problema técnico que surgió. Es algo en lo que tienen poca experiencia. Trataron de solucionarlo, pero no pudieron, y están entrando en pánico. Pasan las horas, y no avanzan. Todo está empantanado. Entonces, encienden la señal, para llamar al super héroe.

Fuerzas: Vivimos en tiempos de cumplir los compromisos que asumimos para la iteración. Queda poco tiempo para la entrega. Todo indica que necesitamos una solución rápida.

Solución: No hay que buscar solución rápida. Primero, habría que haber previsto el riesgo tecnológico, desde el propio equipo. Los miembros deberían haber anotado que en algún momento se toparían con una tecnología que no conocen, y tendrían que haber tomado la tarea asignándole más tiempo. Pero bueno, supongamos que no se pudo hacer eso. El problema de arriba, es que el equipo delega la solución FUERA del equipo. El equipo, de alguna forma, “se lava las manos”. La actitud del superhéroe también conspira para eso. No es ése el camino. El equipo no debería perder “ownership”, propiedad y responsabilidad del producto, y de cada pequeño o gran problema. El desarrollador super héroe, que los hay, debería haberse integrado al equipo, compartiendo su conocimiento. Debería actuar como consultor del resto del equipo, pero trabajando con él. Y cada cosa que haga, con el equipo, será considerada como cualquier otra tarea de otro miembro: deberá cumplir con los estilos pactados, las métricas adoptadas, la definición de “hecho”. No debe ser un miembro “distinguido”. Lo que haga, debe estar público y lo más entendible posible para el resto del equipo. Tal vez no consigamos una solución tan rápida como la de arriba. Pero seguramente, a largo plazo, estaremos construyendo un equipo más responsable.

Recuerden: uno de los grandes entregables, en Scrum, es el equipo.

Nos leemos!

Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez

Tales from the Scrum: No somos Q

lopez — Thu, 22 Oct 2009 10:22:39 GMT

No se si conocen o recuerdan al personaje de Q, que apareció en el capítulo presentación de Star Trek: Next Generation. Dotado de poderes sin límites, el personaje interpretado por John de Lancie ha aparecido en varios episodios, siendo uno de los favoritos de la audiencia trekkie. En la tercer temporada de Next Generation, en el capítulo Déjà Q le quitan los poderes, y pasa a ser un simple mortal, que tiene hasta que comer para sobrevivir. Se le sugiere integrarse a la tripulación de la Enterprise, pero él responde que no está acostumbrado: “Es difícil trabajar en grupo cuando se es omnipotente”.

Q nunca podría ser un buen miembro de equipo Scrum. Recuerden: Scrum es un marco de trabajo para producir software EN EQUIPO (se puede extender para otras actividades, pero siempre en equipo). La idea de equipo en Scrum es fuerte: miembros con distintas habilidades y competencias, que trabajan coordinados para ir armando, iterativamente, el producto que el cliente necesita. En general, se usa la figura del Scrum Master para mantener el equipo dentro de las buenas prácticas, como mantener la reunión diaria, evaluar correctamente el Sprint (iteración), actualizar el backlog de sprint, ver que se arma y priorice lo mejor posible el product backlog, etc.

Pero, en el día a día, lo que cuenta es el trabajo en equipo. No hay lugar para “prima donnas” o “Qs” en un equipo Scrum. Claro que puede haber miembros con más “seniority” en un tema técnico, o en alguna habilidad (como diseño gráfico, o base de datos). Pero lo importante es que toda tarea, y su resultado, queda a cargo del equipo. No hay “me corto solo” en Scrum. No hay actitudes de “yo lo hago mejor, y hago esto, y nada más”. No hay “yo me encargo de la base de datos, lo demás no”. No hay “esto lo hago yo, porque lo hago mejor que Uds.”. Debe haber “esta tarea la tomo yo, si quieren, hago pair programming con X, y dejo claro cómo lo hice, para que mañana otro pueda seguir con esta tarea”. Si no se puede llegar a esa actitud, por lo menos, debemos luchar para conseguirla, y marcar nuestra falta en las retrospectivas (recuerden que para eso están las reuniones de retrospectivas: no para marcar errores, sino para detectar malas prácticas, o formas de trabajo no efectivas, y mejorarlas).

Cada tarea es del equipo.

Tomemos un ejemplo en concreto. Puede que haya en el equipo alguien ideal para escribir el manual de usuario de una parte del sistema que estamos armando y entregando (ciertamente, hay manuales de usuario, y es muy probable que se algo que para el cliente tiene valor de entrega y nos lo pida; sino, es, en general, un buen “over-delivery” que hace que el producto entregado tenga mejor recepción y uso). Supongamos que esa persona, llamémosla Juan, se recibió de “Technical Writer”, o que es el que mejor conoce esa parte del sistema. ¿Será él el que tome esa tarea? Un día, al comienzo, en la reunión diaria, Juan tome la tarea. Pero bien puede ser que sea una tarea que insuma varios días: hay que escribir una tabla de contenido, un glosario de los términos, una introducción, un paso a paso, sacar “screenshots” y ponerlos en el documento, escribir sobre el proceso A, el B, el C… En definitiva: la tarea puede partirse en varios pasos. Y entonces, seguramente otros miembros del equipo podrán colaborar con alguna de las subtareas. El miércoles, Juan está enfermo, y falta. Pedro, que estuvo colaborando con él, bien puede seguir con la tarea: aprendió cómo se organiza el material, cuál es el ejemplo que se estaba desarrollando en el manual, y puede seguir con el tema. Mientras tanto, el documento va quedando publicado en el repositorio de código del equipo. José “odia” hacer documentación. Pero igual revisa el documento parcial producido, y descubre que un “screenshot” no corresponde con lo el ejemplo que se explica. María detecta que se está usando mal el tiempo verbal. Francisco, que está desarrollando otra parte del sistema, y es el menos familiarizado con el tema del manual, apunta que no se entienden algunos términos, que el creador original del documento toma por sabidos por todo el mundo.

Cuando al final del Sprint, el documento es entregado, casi todos los miembros del equipo pasaron por la producción del mismo: escribiendo, revisando, juntando material, mejorando una parte, sugiriendo cambios. Y ese entregable, es responsabilidad del equipo. Si luego se detecta que hay un error tipográfico o de concepto, es el equipo el que se hace cargo de ese defecto.

Trabajando en equipo, hasta capaz le ganamos a Q y todo… :-)

Nos leemos!

Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez

Tales from the Scrum: Un día en el equipo

lopez — Tue, 13 Oct 2009 09:20:03 GMT

Una de las cosas que hay que destacar de Scrum, por si es la primera vez que lo ven, es el trabajo en equipo. Los miembros del equipo realizan una reunión diaria inicial, el Standup, se reparten las tareas, y van trabajando físicamente juntos durante el día, programando, diseñando, haciendo pruebas del software, etc… Hace un tiempo, encontré este video, donde, oh! sorpresa! el ScrumMaster es el bueno de Tobías Mayer (@tobiasgmayer) (visiten su blog Agile Thinking, y su iniciativa WelfareSCM (entramiento Scrum de bajo costo), también el video que grabó sobre el tema en InfoQ).

(Please visit the site to view this media)

Vean cómo se trabaja a veces de a pares, a veces en solitario. El ScrumMaster (el que acerca la cara y hace muecas…:-), va acompañando al equipo, de forma intermitente. El lugar físico es importante: todos se ven, todos están en contacto directo. Vean cómo van organizando las tareas en papeles. A la derecha, parece que tiene el tablero de control.

Para los que no lo vivieron, es así: los miembros van avanzando en tareas, tienen reuniones de diseño, o para discutir dudas y caminos. No hace falta comer en el mismo lugar :-) pero pueden hacerlo.

Pueden leer un post de Tobías que traduje al español en Tales from the Scrum: El corazón de Scrum.

Nos leemos!

Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez

Resultado de la VAN en ALT.NET Hispano sobre Scrum

lopez — Fri, 18 Sep 2009 10:04:00 GMT

Gracias a la comunidad de Alt.NET Hispano, en especial a @jorgegamba, de Colombia, que me ayudó a tener todo preparado, pude participar en

VAN en ALT.NET Hispano sobre Scrum

Hubo varios participantes, a destacar Gustavo Quiroz y Raul Uribe de Agile Perú. También me encontré con el bueno de @fabiomaulo, que planteó lo difícil que es llevar a cabo un proyecto ágil usando Scrum, ante la falta de un dueño de producto concreto.

Pueden ver la desconferencia en video, enlaces y recursos en:

VAN Hispano - 2009-09-06

Ahí hice mi habitual presentación sobre Scrum, cambiando el orden de algunos temas, y limitándola a 45 minutos, para dar cabida a la discusión y consultas en el resto de la charla. No pude interactuar al principio, porque tenía un problema en mi audio: no podía escuchar a los demás. Luego pude solucionarlo, e integrarme al grupo en la segunda hora de la desconferencia.

Me gusta mucho que una actividad realizada deje una traza en google, de esta forma: los que no pudieron participar, igual pueden ahora consultar lo que se hizo, y aprovechar las discusiones, opiniones, enlaces y recursos que fueron apareciendo en la charla. Hemos visto la luz! :-) :-)

Y YA se viene una nueva VAN:

Invitación a VAN Hispano Sábado 19 de septiembre - ORM con Fabio Maulo

Para alquilar balcones! :-)

Tienen siempre para visitar, los videos y recursos de las anteriores reuniones:

Historial de reuniones

Nos leemos!

Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez

VAN en ALT.NET Hispano sobre Scrum

lopez — Fri, 04 Sep 2009 10:23:04 GMT

El domingo que viene, habrá una reunión virtual del grupo ALT.NET Hispano, sobre el tema Scrum. Yo participaré dando una introducción de algunos temas:

- Marco de Trabajo Scrum
- Roles: Team, Product Owner, Scrum Master
- Product Backlog y Sprint Backlog
- Ceremonias: Sprint Planning, Sprint Review, Daily Scrum, Sprint
Retrospective

En general, las reuniones duran 2 horas, y en las últimas, los asistentes han participado activamente, con preguntas y dudas y planteos. Así que no es una típica charla de presentación de un tema, sino que también habrá discusión. Mi idea es presentar los temas de arriba rápidamente, en 45 minutos, y dejar documentación adicional por acá.

No tengo la confirmación, pero espero que participen también Raul Uribe y Gustavo Quiroz. La hora, no la vi publicada en el sitio de ALT.NET Hispano, pero supongo que será la habitual, 18:00 GMT (15hs en Buenos Aires, Argentina). En cuanto pueda, actualizo el post, con los datos en concreto.

Si no conocen qué es una reunión VAN, pueden consultar VAN meetings

Para ver cómo se desarrolla una VAN de ALT.NET Hispano, y qué software necesitan para asistir, ver Descripcion-de-Reuniones-VAN

Pueden ver el historial de anteriores reuniones VAN

Nos leemos!

Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez

Tales from the Scrum: TDD en todo

lopez — Wed, 26 Aug 2009 10:55:26 GMT

Hace un tiempo escribía sobre

Tales from the Scrum: Terminando la tarea

donde hace hincapié en verificar cada tarea, e introducía algo a discutir en otro post: el concepto de “hecho”, que tiene que estar claro en el equipo y en el dueño de producto.

Hoy quiero comentar sobre algo similar, que podemos hacer en cada tarea: aplicar ideas de Test-Driven Development. No hace falta que Ud. haya aplicado TDD: una disciplina que puede usarse en XP. Lo que quería adoptar de ahí, es, ante una tarea a realizar: escribir primero el test. Esto, a cualquier tarea. ¿A qué apunto?

Veámoslo con un ejemplo. Supongamos que tenemos que migrar una base de datos contable, de un tipo de base datos (digamos Oracle), a SQL Server. Una tarea delicada. No queremos que se pierdan datos. Entonces, antes de comenzar la tarea, vamos escribiendo cuál sería el test, la prueba, a pasar luego de la tarea, para considerarla bien terminada. Podría ser:

- Hacemos select count(*) de la tabla de plan de cuentas en Oracle

- Comparamos esa cantidad con el select count de plan de cuentas en SQL Server

- Hacemos un sum de debe y haber, en Oracle

- Comparamos con el sum de debe y haber en la nueva base de SQL Server

- Tomamos el mayor de la cuenta X (que tiene pocos movimientos) en Oracle y los comparamos con los movimientos del nuevo SQL Server

- Hacemos lo mismo para el mayor de la cuenta Y (la de mayor cantidad de movimientos)

- …

Hasta podemos escribir un programa que haga estas comprobaciones, aunque no siempre es necesario o posible.

La cuestión es comenzar la tarea con un fin en mente: qué tiene que pasar al final para que podamos decir la tarea está bien completa y hecha.

Y esto, hacerlo ANTES de comenzar la tarea. El tener en claro hacia dónde queremos llegar, cuál es escenario final que queremos tener al terminar la tarea.

Lo mismo hacemos con cualquier tarea, ya sea del sprint, o particular nuestra. Si una de las tareas es instalar un servidor Apache, con PHP y MySql, entonces, el test podría ser:

- Escribimos http://localhost en nuestro navegador y aparece la página inicial

- Este servidor viene con phpmyadmin instalado, vamos a ese enlace, y vemos la página de la base MySql local

- Vemos en la lista de base de datos instalada, las iniciales de MySql

- Creamos una base con tal y tal parámetro

- En esa base creamos una tabla con tales y tales características

- …

- Subimos un archivo desde nuestro disco a una aplicación de galería de fotos que ya vino instalada (acá podemos verificar permisos de escritura)

- Repetimos estas pruebas desde otra máquina, llegando al servidor via http://<nombredeservidor>

(este último punto nos servirá para comprobar los permisos y protecciones que puede tener el servidor para los usuarios finales)

Tal vez para Uds. pueda parecer trivial todo esto. Yo quisiera recibir ahora un peso, por cada vez que vi que una tarea como la de arriba, fue considerada terminada solamente con instalar el servidor. O solamente poniendo http://localhost. O por cada vez que una migración de base de datos se dio por buena con simplemente que no de error en el traspaso de datos.

El escribir el test (en un programa, en un papel, en un email) también sirve para que cualquiera en el equipo pueda encarar más fácilmente la etapa de verificación, y para cuando alguna vez haya que repetir esa tarea. Es una especie de checklist de lo que tiene que quedar bien, en “verde” para que consideremos que lo que hicimos quedó bien terminado. Hay otras cuestiones a tener en cuenta, pero el test de cada tarea debería ser lo básico a cumplir.

Como todo en el Sprint, se puede ir refinando este documento, si descubrimos que sería conveniente tener en cuenta alguna otra cosa en la verificación de una tarea. Y el test también sirve para que podamos estimar el tiempo de verificar el trabajo hecho.

Gracias a @gabrielsz que fue el primero que me hizo ver estos temas.

Nos leemos!

Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez

Scrum práctico en Santa Fé

lopez — Sat, 22 Aug 2009 14:29:19 GMT

Gracias al MUG de Argentina, y a Software Santa Fé, ayer viernes estuve dando un curso práctico de todo un día, sobre Scrum, en la ciudad de Santa Fé, acá en Argentina. Más de 30 personas asistieron, se dividieron en 6 grupos y llevaron a cabo dos sprints simulados, practicando lo que es el product backlog, el sprint backlog, las reuniones de sprint planning, sprint review, y daily scrum. Creo que fue un curso muy interesante, en el que los asistentes participaron activamente, haciendo el trabajo encargado, y preguntando todo sobre el marco de trabajo Scrum y metodologías ágiles en general.

Si quieren saber cómo es Scrum, pueden leer la introducción (en inglés y español):

Scrum Primer

Hay un artículo corto en inglés: What is Scrum?

Pueden usar esta presentación compartida (en varios idiomas):

A Reusable Scrum Presentation. Introduce Scrum to your team, ScrumMaster and Product Owner.

Algunos enlaces adicionales:

http://agilethinking.net/ El sitio de Tobias Meyer, que me inició en el ScrumMastering en el 2006.

http://agilemanifesto.org/ Manifesto for Agile Software Development

http://softwareagil.blogspot.com El blog de Juan Gabardini, dedicado a Software Agil, en especial Scrum

http://www.implementingscrum.com/ Sitio donde encontraran la clásica historia: The classic story of the pig and chicken

http://groups.yahoo.com/group/foro-agiles Foro de prácticas ágiles, en español, muy interesante de seguir.

La presentación que usé está en mi Skydrive:

Scrum200802-2003.ppt (formato PowerPoint 2003, 7Megas)

Scrum200802.pptx (7Megas)

Scrum200801.ppt (Presentación original, más liviana, con menos gráficos, 1.2M)

Agradezco a Diego Poza, por haber mejorado y ampliado la presentación original.

Para preparar gran parte de la presentación, usé:

El libro que me sirvió de base para esta presentación

Agile Project Management with Scrum

En ese libro, están enumerados estos recursos:

Agile Software Development with Scrum, Ken Schwaber and Mike Beedle (Prentice Hall, 2001)

Teoría y práctica de Scrum.

www.controlchaos.com/

El sitio de Ken Schwaber sobre Scrum.

http://www.jeffsutherland.com/

Jeff Sutherland tiene contenido relacionado con desarrollo de software, programación, tecnología, objetos, componentes y Scrum.

www.mountaingoatsoftware.com/scrum/

El sitio de Mike Cohn sobre Scrum.

www.scrumalliance.org

El hogar de los ScrumMaster certificados.

www.agilealliance.org

El sitio de la AgileAlliance, con recursos sobre Agile y Scrum.

http://groups.yahoo.com/group/scrumdevelopment/

El grupo de discusión de Scrum, con años de existencia.

www.xprogramming.com

El sitio de Ron Jeffries acerca de Extreme Programming (XP). XP provee varias de las prácticas que Scrum implementa para asegurar el incremento de funcionalidad potencialmente entregable.

Process Dynamics, Modeling, and Control, Babatunde A. Ogunnaike and W. Harmon Ray (Oxford University Press, 1994)

La teoría que subyace a Scrum.

The Alphabet Versus the Goddess, Leonard Shlain (Viking Penguin, 1998)

El conflicto entre las palabras y la imagen.

Wicked Problems, Righteous Solutions, Peter Degrace and Leslie Hulet Stahl (Yourdon Press, 1990)

A Universe of Consciousness, Gerald Edelman (Basic Books, 2000)

Por qué es tan difícil pasar de requerimientos a código.

Managing the Unknowable, Ralph D. Stacey (Josey-Bass, 1992)

Explicando las dificultades del manejo de la complejidad.

Complexity and Emergence in Organisations, Ralph D. Stacey (Routledge, 2000)

Una crítica de cómo la teoría de la complejidad ha sido aplicada para entender organizaciones y marcar nuevas direcciones. Este libro promueve un reexamen radical del pensamiento gerencial.

Artful Making, Rob Austin and Lee Devin (Prentice Hall, 2003)

Como manejar el trabajo creativo, adaptado del teatro.

Nos leemos!

Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez

Tales from the Scrum: Cómo transferir conocimiento en un proyecto ágil

lopez — Thu, 20 Aug 2009 10:33:13 GMT

Ayer conocí, gracias a un mensaje del bueno de Jonathan Cisneros, autor del AjGenesis Studio, de este interesante experimento:

How to transfer knowledge in an Agile Project

(Ciertamente, es un único experimento que habrá que refrendar con otros experimentos). Pero he asistido a situaciones similares y puedo decir que es una forma válida de transferencia de conocimiento en un proyecto ágil, Scrum en particular.

¿En qué consistió el experimento? Steve Bockman trataba de saber cuál es la mejor forma de transferir conocimiento. En un proyecto ágil, Scrum en particular, es frecuente trabajar en un equipo con distintas habilidades y conocimientos, y es importantes que lo que un miembro del equipo conoce y sabe hacer, sea en algún momento asimilado por los otros miembros del equipo. Steve explica su experimento en:

Avoiding the knowledge transfer bottleneck

En el experimento, Steve trató de transferir conocimiento sobre un producto no usual: cómo construir un aeroplano de papel. Lo intentó de tres formas:

- Documentación: a los participantes se les dio instrucciones escritas (22 pasos) para armar el aeroplano.

- Ingeniería Inversa: a los participantes se les dio un aeroplano completo que podían estudiar para reproducir los pasos para armarlo.

- Mentoring: el “diseñador en jefe” arma el aeroplano paso por paso, y los participantes replican cada paso a medida que lo ven realizado.

El experimento fue realizado con 8 participantes, con una duración total de 5 minutos para cada escenario. Los resultados fueron:

Sólo 12.5% de las personas pudieron completar el trabajo usando la estrategia de leer la documentación. Usando ingeniería inversa, el 25% de las personas pudieron armar el aeroplano. Mientras que usando mentoring, el 100% de los participantes completó el trabajo.

Yo pienso que esto es otra forma de demostrar que no somos Vulcanos: un vulcano escribiría la documentación, de tal forma, que cualquier otro vulcano podría entenderla de primera vez, para realizar el trabajo. Y entendería casi inmediatamente el por qué de los pasos.

Tal vez, el mentoring, no transfiere tan rápidamente el “por qué” de alguna práctica. O eso lo van descubriendo los participantes con el tiempo, o por contraste con otra práctica. Ejemplo: podemos aprender pair programming, usando mentoring, pero por qué preferimos esa práctica de programación a pares, será cuestión de verlo por contraste con no hacerla.

En un anterior post:

Tales from the Scrum- cualidades de los miembros del equipo

sugería que se puede hacer pair programming en una tarea, donde uno de los participantes está más capacitado que otro. Esto tiene también la consecuencia de transferir las habilidades y conocimientos de un miembro del equipo al otro. Vean que hablo no sólo de conocimientos: también de habilidades. Yo puedo conocer todo sobre armonía musical pero no tener la habilidad de tocar el piano.

Esa forma de pair programming, viene descripto por Young Ye y Royce Fay en un paper (pdf)

Knowledge transfer using Asymmetric pair Programming

Este método lo aplican no sólo a trabajo de a pares con desarrolladores, sino también entre desarrolladores y usuarios del dominio. Pone énfasis, entonces, en la comunicación humana más que en la documentación.

Alan Skorking escribió también sobre el tema en:

Effective vs Ineffective Pair Programming

Escribe: “En mi opinión, el beneficio más importante es el hecho que trabajar de a pares es altamente favorable a la transferencia orgánica de conocimiento…. Creo que es la clave porque en un sistema grande prácticamente no hay otra forma de hacerlo bien”.

Justamente, ahora estoy envuelto en el desarrollo en equipo de un sistema con un dominio grande, y complejo. Sería interesante comenzar a aplicar este tipo de transferencia, no sólo dentro del equipo, sino también con los expertos del dominio. Esto no quita la existencia de documentación, pero es difícil de escribir en dominios complejos.

Imagen tomada de http://www.kegoodpractice.org/

Nos leemos!

Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez

Tales from the Scrum: El corazón de Scrum

lopez — Tue, 18 Aug 2009 09:20:58 GMT

Al final de un anterior post:

Tales from the Scrum: Informando el estado

comentaba que había otra herramienta para ir coordinando y viendo el avance del equipo en el proyecto. El bueno de Tobias Meyer, quien fue mi instructor de Scrum Master en el 2006, escribe en estos días un post más poético, pero que apunta al corazón del tema. Pueden leer el original en:

The heart of Scrum

Hoy les deje una traducción libre:

Cuanto más enseño y hago coaching de Scrum, más me convenzo que el tablero de tareas es el corazón del Scrum. Sin el tablero de tareas no hay centro, no hay foco. El tablero de tareas, cuando es realmente comprendido, se transforma en el hogar espiritual del equipo, en la iglesia, si quieren llamarlo así. Los miembros del equipo arguyen,discuten, innovan, alrededor del tablero de tarea, se alinean unos con otros, para corregir el rumbo, para aprender, para celebrar.

El tablero de tareas genera colaboración. Es visual, es táctil, es más grande que la vida (es más grande que la pantalla de una computadora). Se yergue como un gran y visible marcador de nuestro de progreso y de nuestro carácter. Proclama quienes somos como equipo. Es nuestra identidad. El tablero de tareas nos dice la verdad, y difunde el mensaje: no tenemos miedo.

El tablero de tareas es frecuentemente descripto como el “water cooler” (enfriador de agua) del nuevo paradigma. El paralelo, aunque tiene buen sentido, está haciendo al tablero de tarea un daño. Sí, es el lugar para interactuar. No, no es un lugar para quejarse, para esparcir rumores, o desgarrar el equipo. El tablero de tareas es el lugar para regenerarse a uno mismo, para reconectarse, para tomar respiro. Representa una carrera hacia, no un escape, una carrera de huida de.

Scrum es la antítesis del cubículo corporativo de la mentalidad de divide-y-vencerás. No necesitamos mesa de tenis o metegol para calmarnos, para crear un balance artificial de trabajo y vida. No necesitamos divertirnos como algo más allá del trabajo. El trabajo es divertido. No necesitamos momentos de “water cooler” o cortes para fumar para ejercitar nuestras profundas necesidades humanas de conversación, de interacción. En Scrum, nosotros vivimos de esta manera. Todo el día, todos los días.

Scrum es todo sobre la gente, no sobre competencias o capacidades. Scrum no es “yo” sino “nosotros”. Es acerca de compartir, aprender, mejora continua, interacción vibrante, colaboración apasionada y crecimiento personal. Scrum es sobre tribus, sobre construir comunidad. Cada miembro de la tribo necesita un sentido de pertenencia, de búsqueda personal. Tribus enteras necesitan lugares de interacción, necesitan objetos sagrados, necesitan foco y necesitan pulso. Scrum soporta esa forma de ser. El tablero de control, y el ambiente que emerge de él, provee esa fuerza central de vida, donde este tipo de cosas nacen.

Para vivir, para realmente vivir, Scrum necesita un corazón. Y ese corazón es el tablero de control. Sin él, Scrum nos parece y se siente insípido. Es débil, y delgado. Pierde su foco, y sin un controlador externo (por ejemplo, un coach, o un campeón del producto) para continuamente insuflar vida en él, el esfuerzo pronto se disolverá de nuevo en el proceso disfuncional al que quería reemplazar. Sin ese corazón, Scrum no tiene poder.

Uno de los servicios más importantes que un Scrum Master puede hacer por su equipo y por la organización en conjunto, es crear transparencia. La transparencia nos permite ver las fallas, y cuando vemos las fallas, podemos elegir hacer algo con ellas. Podemos parar de ser víctmas del proceso y comenzar a ser guerreros del cambio.

En el blog de Xavier Quesada Allue Visual Management encontraremos muchas sugerencias sobre cómo usar el tablero de tareas para alcanza el objetivo de la transparencia. El trabajo de Xavier en esta área toma el tablero de tareas y lo transforma de un objeto útil en un objeto de belleza e inspiración. Y de la manera en que lo veo yo, éste es el lugar correcto del tablero. El corazón se nutre de amor.

Les recomiendo la visita al blog de Xavier, y el de Tobias, Agile Anarchy (el actual) y Agile Thoughts (el anterior). Vean de visitar y soportar su iniciativa Welfare SCM:

Statement of Intent

WelfareCSM is a program designed by Tobias Mayer to embrace the change we are currently experiencing in the world. The aim of WelfareCSM is two-fold:

1. To offer low-cost or no-cost Scrum training, including Certified Scrum Master training to individuals in low-paid jobs, the unemployed, students and anyone working for a company that has cut its training budget in this time of crisis.

2. To spread the principles, practices and values of Scrum beyond the software world, by training people from other industries, and those involved in other kinds of work or community activities.

He tenido poca experiencia con un tablero físico, en muchos equipos se tiende a tener una herramienta electrónica. Pero cada tanto trato de armar un tipo de tablero así. Cuando existe, la reunión diaria de Scrum se realiza ENFRENTE del tablero, es el lugar donde el equipo se reencuentra con sí mismo y con el proyecto.

Nos leemos!

Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez

Tales from the Scrum: Armando un equipo automanejado

lopez — Wed, 12 Aug 2009 11:15:56 GMT

Ya sabemos que Scrum es un trabajo de equipo. Pero una cosa que diferencia a Scrum, es que el equipo es automanejado. ¿A qué apunta esto? A que el equipo toma decisiones y se mantiene y mejora como equipo, por sí mismo. Por supuesto, con ayuda, de quien quiera ayudar: desde el Scrum Master, hasta mentores, otros equipos e interesados. Pero el equipo toma decisiones en varios puntos del proceso, el principal es el planeamiento del próximo sprint, iteración.

Ya escribí que me parece importante el desarrollo del equipo; es parte del entregable, aunque no lo parezca:

Tales from the Scrum- su equipo, el próximo nivel

Pero muchas veces, el equipo no tiene toda “la salud” para auto manejarse, o sus miembros vienen de otros ámbitos donde no se fomentó esta actitud. Veamos algunos puntos a revisar, para mejorar en estos puntos.

Primero:

Deje de hacer esto

- No dejar que los participantes del equipo participen en todas las etapas del ciclo de desarrollo. Cuanto más se involucren en todas las actividades, como reuniones con los clientes, planeamiento, toma de requirimientos, diseño, mejor. No todos tienen que estar en una reunión de diseño. Pero hay que ir viendo de que todos los miembros, en algún momento, hayan tomado parte de alguna de las actividades. Un anti-pattern: sólo “los principales” miembro del equipo asisten a al reunión de cierre de Sprint. Si cada miembro del equipo participa de cada actividad, en algún momento del proyecto, verán de embeberse más del proyecto y del proceso, en vez de encerrarse en su zona de confort o “expertise”.

- Asignar tareas a los miembros: es común que alguien vaya asignando tareas a algunos miembros. Hay que dejar de hacer eso. Hay que fomentar que los miembros del equipo vayan tomando tareas, por propia cuenta. Y promover que cada miembro de equipo no se centre sólo en lo que sabe. El especialista en base de datos puede participar de una tarea de diseño de interfaz de usuario, tal vez ayudado por “pair programming” con otro miembro que conozca del tema. Esto permite que los miembros vayan interactuando, conociendo las debilidades y fortalezas de cada uno, y ayudándose y aprendiendo unos de otros al mismo tiempo.

- Decir para cuándo tiene que estar tal tarea lista: hay que recordar que esa es una decisión del equipo, en Scrum. Claro que se espera que el equipo vaya mejorando en la estimación de los tiempos y en la velocidad de avance. Pero es una decisión de los miembros del equipo cuánto tiempo necesitan para terminar con una tarea. Se podrá discutir qué hace falta para avanzar más rápido, qué cambios hacer para mejorar en eso, pero la decisión del tiempo es del equipo. Si Ud. no deja esta decisión en el equipo, no logrará que avance en las cualidades de autogestión.

- En la reunión de planeación de sprint, las tareas propuestas por el producto owner, son aceptadas sin mayor discusión, o sin evaluar si se pueden conseguir en tiempo en forma. Esta es una variante del anti-pattern “asignar tareas”. Una de las funciones principales de la reunión de planeamiento, es que el equipo (no uno, o dos miembros), discuta y tenga en claro los pasos y esfuerzos estimados para cumplir con lo que el product owner pide. Es común (y no debería serlo) que se tome eso tal cual, sin discusión, y sin haber pasado en limpio lo que implica comprometerse a realizar esas tareas.

- Saltearse las retrospectivas: no hay tiempo, siempre se posponen. No: pare de olvidarse de esta reunión. La retrospectiva es una actividad, yo diría fundamental, para que el equipo madure y mejore. Es un “parar la pelota”, ver para atrás, y señalar qué se hizo bien, regular, o simplemente mal. Y, aun más importante: en la reunión se decide qué hacer para mejorar.

Segundo:

Comience a hacer esto

- Limpie el camino para el avance. Haga que el equipo pueda avanzar, y quite los bloqueos que encuentre. Puede ser desde falta de hardware, hasta temas políticos de relación con otros departamentos. Eso permitirá que el equipo se concentre en lo que tiene que hacer, más que luchar con la fricción y los impedimentos. Cuando el equipo esté más maduro, podrán los propios miembros del equipo ocuparse de esto, tal vez rotando en la tarea por Sprint, pero al principio, habrá que permitir que el equipo crezca, sin tener que lidiar tan directamente con estos problemas.

- Sea un facilitador y mentor. Como facilitador, vaya por el anterior punto. Como mentor, observe, comente, señale la actividad y actitud del equipo, proponga mejoras (no las imponga), sea un entrenador de cada persona, reconozca en qué son buenos, en qué son regulares, y trabaje con ellos para ir mejorando.

- Mida el avance. El equipo se auto organiza, pero comience a medir el avance, y difundiendo esa medición. Esto hará que el equipo tenga una imagen de cuán bien o mal están yendo. Cualquier desviación del plan de trabajo, debe surgir lo más pronto posible, para que el equipo autoorganizado pueda detectar el problema, la causa, tomar una acción correctiva, y aprender a no caer de nuevo en ese paso.

En un equipo maduro, cada miembro se ocupará, casi automáticamente, de estos puntos. Pero al principio, habrá que cultivarlos activamente. Con el tiempo, llega el momento en que el equipo “cuaja”: comienzan a entrar en pista, a ganar confianza, a ver que la forma de trabajo que eligieron funciona, y entran “en flujo”: una forma continua, rítmica, de avance, hacia el objetivo final.

Varios de estos puntos los tomé, e interpreté y comenté a mi manera, del post:

How to Build Self-Managed Teams

Imagen tomada de: http://www.skyjump.com/Pages/SkydivingPhotosVideos.html Photo by Phil Robertson

Nos leemos!

Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez

Tales from the Scrum: Ser easy to work with

lopez — Tue, 11 Aug 2009 11:12:52 GMT

Ya sabemos que el avance en Scrum es un trabajo de equipo. Como miembro del equipo, uno tiene que colaborar con los otros miembros para conseguir que el trabajo avance. Una de las cualidades que deberíamos perseguir, para cada uno de nosotros y para el equipo, es lo que en inglés se escribe “easy to work with”: que los demás perciban que es fácil trabajar con nosotros.

Como otros conceptos, puede ser más fácil describirlo con algunos ejemplos negativos:

Si uno llega tarde a las reuniones diarias, reiteradamente y sin buenas razones y no avisa, eso no es ser “easy to work with”.

Si uno hace una tarea y no informa que la terminó, o en qué estado la dejó, el resto del equipo no podrá aprovecharse de ese resultado, y Ud. no será “easy to work with".

Si Ud. codifica algo, y lo envía al repositorio de código, y está mal escrito, de forma que cualquiera que tome la última versión, encuentre una solución que no compila, eso es no ser “easy to work with”.

Si cada tarea que Ud. termina, al revisarse para verificarla, se encuentra que tiene muchas correcciones a hacer, y esta situación se repite, entonces, Ud. no será “easy to work with”.

Si lo que escribimos produce un aumento en las infracciones de Code Analysis, y otro tienen que pasarse un tiempo corrigiéndolas, y eso se repite, entonces no seremos “easy to work with”.

En definitiva, si alguien, con su trabajo, produce un montón de trabajo EVITABLE en los demás, ese alguien no será “easy to work with”.

Si alguien es así, a la larga pasará que nadie va a querer trabajar con él, y no confiarán en lo que produzca.

Lo mismo puede pasar a nivel de equipo. Si como equipo entregamos la nueva versión del software al final del Sprint, y el cliente no tiene instrucciones para instalarlo, o tiene que armar una máquina virtual durante dos semanas para poder ejecutar lo que entregamos, no seremos “easy to work with”. La solución: ir mejorando en cada Sprint, para que lo entregable sea fácilmente consumible, por ejemplo, dándole una máquina virtual ya armada, y el software e instrucciones para correrla.

Pero aparte de estos temas técnicos, hay temas de cualidades de relación con los demás, de los “soft skills” tan importantes en todo grupo. Veamos algunas cualidades para ser “easy to work with”:

- Sea flexible. Si Ud. no es ágil para actuar en un ambiente cambiante, con requerimientos que se van modificando, tendrá problemas. Si Ud. es un cabezón que siempre cree tener la razón, y si no se la dan, se empaca, también tendrá problemas. A veces, hay que ser flexible, entender a los demás, y ver que no siempre se puede seguir el camino que a uno le parece mejor. Explore nuevas formas de hacer las cosas, no rechace algo de antemano solamente por que sí.

- Sea un buen comunicador: no es indispensable, pero es bueno tener buenos comunicadores en el equipo. He visto buenos miembros de equipo, callados, pero que compensan esa escasa comunicación, siendo un “tanque Sherman”: gente que toma una tarea, y la termina, sí o sí y con calidad. Pero volvamos a la comunicación: es importante, porque no todo es código. Recordemos que lo que hacemos lo tenemos que mostrar, tenemos que informarlo, tenemos que interactuar con los clientes. Si todo lo que hacemos es maravilloso, pero no lo comunicamos, es como si no lo hubiéramos hecho. A veces, uno piensa que armar una presentación es una pérdida de tiempo, pero no: puede ser la pieza clave que falta para conseguir apoyo de los interesados en el proyecto. Si Ud. es un buen comunicador, otras partes (otros equipos, product owner, stakeholders, clientes, usuarios) querrán interactuar con Ud. Y será alguien “easy to work with”, no un erizo a evitar.

- Esté disponible. No hace falta estar disponible 24 horas, 7 días. Si el equipo se organiza, se debería organizar todo para cinco días a la semana, y 10 a 18hs. Pero en ese tiempo, si alguien necesita su ayuda, tenga planeado tiempo libre para poder ayudarlo. En la reunión diaria no tiene que comprometer las 8hs de trabajo: es de profesional, reconocer que hay tareas que pueden surgir, y reservar entonces tiempo para esos casos que pueden aparecer en el transcurso del día. Cuando alguien vaya a preguntarle algo o a pedirle ayuda, irá con la expectativa “Fulano me va a ayudar”. Otra forma, indirecta, de estar disponible, es haber escrito instrucciones de cómo usar algo, o dejado información sobre lo que uno hizo. Por ejemplo, si Ud. diseñó un parte del sistema, si alguien quiere preguntarle sobre una decisión de diseño, puede hacerlo, pero si no está disponible (está enfermo, de vacaciones), que por lo menos pueda encontrar fácilmente un documento (no tiene que ser extenso ni “fancy”) que explique lo que hizo.

- Sea positivo: Si cada vez que abra la boca, es para tirar abajo algo, pasarán dos cosas: la gente lo evitará, o dejarán de tomarlo en cuenta. “Ahí viene el tiramerdis” pensarán cuando lo vean venir. No confundir una actitud positiva con un “está todo bien” a ultranza. Hay que reconocer los problemas. Solamente hay que ser también, parte de la solución, o por lo menos, ayudar a que en equipo consigamos la solución. A quién quiere tener al lado al naufragar en una isla desierta? Alguien que diga: “Viste, yo te dije que no teníamos que venir, ahora está todo mal, no me hicieron caso…”, y se pase todo el día lamentándose así, o a alguien que diga: “Tenemos un problema, veamos como lo podemos solucionar”.

- Sea honesto: si Ud. ve un problema, o tiene un bloqueo, o no sabe como encarar una tarea, dígalo. En el equipo tiene que reinar la honestidad y la comunicación. Acá no se busca castigar al que no sabe o no tiene tal capacidad. Si hay un problema en ciernes, lo mejor es comunicarlo. Si ve que hay algo mal en el equipo, dígalo. Pero también combine esto con todo lo de arriba: comuníquelo bien, sea positivo, no señale con el dedo a personas sino a problemas, vaya con algún atisvo de solución.

- Diviértase: nadie quiere a un “caracúlico” al lado todo el día… :-)

Habría tanto para comentar. Pienso que en todas las relaciones, más allá de un equipo de Scrum, tenemos que ir cultivando el ser alguien “easy to work with”. Ud. puede ser el gran gurú en un tema, pero estará solo y no conseguirá nada, si los otros no ven en Ud. alguien en quien pueden confiar, alguien con quien sea fácil trabajar.

Para las últimas cualidades, consulté y expuse a mi manera, lo del post:

Be easy to work with

Nos leemos!

Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez

Tales from the Scrum: Anti-patterns de la reunión diaria

lopez — Fri, 07 Aug 2009 09:49:07 GMT

Hace unos días escribía sobre la reunión diaria de Scrum:

Tales from the Scrum: la reunión diaria de standup

describiendo cómo se desarrollaba, y cuáles eran las motivaciones para ese tipo de reunión. Quiero hoy enumerar algunos anti-patrones que deberíamos tratar de evitar:

- Llegar tarde a la reunión. Se debería planificar la reunión para que todos puedan llegar. Si no todos están a las 9hs, pueden planearla para las 10hs, pero una vez consensuado el horario, habría que exhibir puntualidad. No llegar a tiempo, no un día, sino varios, indica que no hay manejo de los tiempos por parte del miembro infractor, o que tiene otros problemas, que deberá plantear al equipo.

- Hacerla unos días y otros no. La reunión se llama “diaria” por alguna razón, capisce???

- Hay diálogos. En vez de que cada miembro conteste las tres preguntas de rigor, se producen diálogos entre los miembros, con preguntas, respuestas, aclaraciones, descripciones detalladas de algo, discusiones, etc… No, todo eso se debe tratar en otra reunión, que perfectamente pueden organizar en el momento, luego del daily scrum.

- Largas contestaciones. Las respuestas a las tres preguntas, en vez de ser concisas, terminan en largos discursos, explicando cada detalle de lo que se hizo y se piensa hacer. Hay que explicar brevemente qué se hizo, pero no cómo. Cualquier detalle importante a comunicar al resto del equipo, debería haber quedado en algún informe de estado o documento.

- Se toman tareas sin respetar prioridades del backlog. No se conoce el backlog, o se toman las tareas que más nos simpatizan, en vez de tener en cuenta la prioridad dada por el sprint backlog.

- Todos le hablan a una persona. En vez de ser una reunión de información al equipo y sincronización, todos le habla a una persona, una especie de Program Manager implícitamente nombrado.

- Una persona reparte los trabajos. Alguien va dando tareas a cada miembro, en vez de que cada uno elija alguna tarea según las prioridades del sprint backlog.

- Estar distraído. Seguir contestando emails, mensajería instantánea, o leyendo Twitter.

- Falta de time-boxing. No se plantea que la reunión tiene un tiempo acotado, y no termina en un horario determinado.

Debe haber más anti-patrones. Los mencionados atentan contra la idea de lo que debe ser una daily meeting. Recuerden que es la actividad más frecuente de Scrum, y una forma de tomar el pulso del equipo, de la salud del proceso, día a día. Es una actividad importantísima, que permite ir detectando cualquier desviación en el desarrollo de la iteración.

Otros posts a leer:

Agile anti-pattern: the Daily Pseudo-Scrum Meeting

Scrum team Anti-patterns: How to piss off your ScrumMaster

Scrum – Challenges, Risks & Anti-Pattern

Nos leemos!

Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez