jueves, 27 de marzo de 2008

¿Equipos autodirigidos?

Estoy leyendo el libro "Leading self-directed work teams", de Kimball Fisher. Uno de los puntos interesantes es que el nombre (SDWT) no es el más feliz. Ese nombre da la impresión que estos grupos no necesitan liderazgo. Sin embargo, lo necesitan ... pero de otro tipo. Por eso el prefiere el término "High performance work system".
Mientras leía (ver comentarios), recordé esta foto que me parece muy ilustrativa de estas ideas.
Don Guillermo Lebrón, guiando al rodeo al próximo lugar de pastura. Pastoreo Racional en “La Parcela”, en Félix Pérez Cardozo, Paraguay. Foto de Roberto Gabardini.

La forma en que se guía al rodeo cuando se aplica Pastoreo Racional implica un proceso de aprendizaje y entrenamiento, reglas claras y rituales que se cumplen en cada movimiento (diario), por ejemplo para ir a tomar agua. Por supuesto, como toda analogía, esta también tiene sus límites. Pero la comparación con respecto a la forma tradicional de manejo (Arriar el rodeo) tiene un contraste igualmente marcado.

Update08 - panel Agiles - Es para mí / para mi empresa?

La gente de Snoop organiza http://update08.org/, un evento que se realize el 16 de abril.
Entre otras cosas, se van a presentar un par de charlas sobre temas ágiles. Una será presentada por gente de Snoop, contando sus experiencias.

En otra se presentará una panel titulado: Agile – Es para mí / para mí empresa?
La idea es comentar experiencias (buenas o malas) al aplicar métodos ágiles fuera del área de confort. Por ejemplo: más de 10 personas, grupos distribuidos, relaciones contractuales fuertes (licitaciones), aplicaciones de misión crítica, alta disponibilidad o con riesgo de vida, miembros con poco seniority, componente de hardware muy fuerte, etc.

Si estás interesado en participar, por favor comunicate conmigo.

Escalando Scrum - Presentación

La mayoría de las presentaciones de Scrum hablan de la implementación en un equipo de 7+/- 2 personas. Sin embargo, en muchos casos esto no es suficiente.
Para escalar Scrum no se disponen de recetas, ni reglas claras. Autores como Ken Schwaber plantean los principios, y luego comentan ejemplos relevantes. Hay ejemplos de escalamiento en sus libros "Agile Project Management with Scrum" y en "The Enterprise and Scrum" (pueden ver mi entrada sobre equipos autodirigidos). También hay un par de papers sobre escalamiento en la Scrum Alliance, buscando por scaling. Yo tomé como base Scaling Scrum, un paper hecho por Colin Bird & Rachel Davies, lo traduje y resumí, y lo presentamos el 25 de marzo en una empresa que está aplicando Scrum en un grupo de unas 20-30 personas. Lo dejo aquí, espero les sirva!

viernes, 14 de marzo de 2008

Curso de XSL/XSLT

Durante esta semana estuve como facilitador en un curso organizado por la Facultad de Ingeniería de la UBA de XML/XSLT 2.0. ¿Por qué como facilitador, y no entrenador o profesor? Porque el 60% del tiempo trabajamos como un grupo que resolvía problemas, e intercambiaba la experiencias adquiridas. Nos organizamos en pares, que trabajaban en segmentos de 3 hs, al final del cual presentábamos las soluciones e intercambiamos las lecciones aprendidas. Los pares cambiaban luego de cada segmento.

La evaluación final fue la resolución, por parte del grupo, de un problema “real”. El problema fue dividido en tareas asignables a pares (en esta parte yo sólo participé como usuario!) y se generó la esperada, pero siempre sorprendente, dinámica del grupo en pos de un objetivo común.

Fue una muy buena experiencia, en la que fueron factores determinantes el grupo (Guillermo Caserotto, Leandro Oliveri, Pablo Rodríguez, Agustín Begue Luciano Pereira y Nicolás Pocovi) y la disponibilidad de un ámbito físico que nos permitió trabajar todos juntos. El resultado del curso es la presentación Curso de XML/XSLT con los ejemplos, la lista de problemas y la evaluación.

El contenido del entrenamiento incluyó XML, SAX, XSLT con browsers (1.0) y con Saxon (2.0).


jueves, 6 de marzo de 2008

ISO 9001 y Scrum: Indicadores reloaded

Agrego una charla que tuvimos con Martín Salias y Matías Woloski en el Architect Forum en Microsoft Argentina, y algunas ideas adicionales que tuve a partir de eso.

A Martín le parece riesgoso usar un indicador de velocidad, puede haber tentación de usarlo para micromanagement. De acuerdo, pero creo que ese riesgo existe con cualquier medición. Por ejemplo, en PSP se pide que cada persona mida como usa su tiempo en las distintas actividades, con la intención de mejorarse. Esos datos se podrían usar, agrupados, para identificar posibles mejoras a nivel grupal u organizacional, pero nunca debería usarse para que el manager trate de evaluar a cada persona. Algo parecido pasa con los defectos, quien los detecta y quien los corrige, etc. Definitivamente un tema a tener en cuenta en cualquier uso de métricas.

Matías tenía preferencia por otras métricas, antes que objeciones a la velocidad. Ellos usan métricas basadas en la calidad, como cobertura de prueba y cumplimiento de standard de codificación. Esto está ligado al tipo de código que ellos hacen, en muchos casos son ejemplos para terceros, que deben mostrar buenas prácticas.

Disparado por estos comentarios, me repasé la justificación interna que hicimos (no reflejada en lo que fue al procedimiento): La idea que teníamos es que debemos medir throughput, en el sentido de la Teoría de las Restricciones (Theory of Constrains). Que es el throughput? Cuanto valor producimos por unidad de tiempo. Es la principal métrica a considerar desde el punto de vista de TOC. Cómo medimos el valor producido?
Mmm… ok, no sabemos cuanto es el valor ($) que producimos con una funcionalidad en particular, pero sabemos que valor estuvo dispuesto a pagar el Product Owner por eso. Ese valor es la estimación que tenía ese ítem o user story en el momento de la planificación. No importa si después se tardó más o menos. El PO decidió “comprar” ese ítem de backlog con la información que tenía en ese momento.

Entonces, ¿cuál es el throughput? Es el valor producido (número de días estimados al momento de la estimación para los ítems cumplidos)/por unidad de tiempo. Nosotros tomamos unidad de tiempo sprint.

Voilà! El throughput es la velocidad!

YMMV!

Architect Forum sobre Metodologias y métodos ágiles - 12 y 15 Febrero 2008


Siguiendo con el objetivo de difundir y compartir ideas y ponernos en contacto como comunidad, se realizó un evento de un día y medio, hosteado por Microsoft Argentina, en el que participamos Alejandra Alfonso presentando Scrum y Martín Salías presentando XP durante el primer día, y en el segundo día primero yo, presentando "Scrum. la perspectiva del Product Owner", y luego Gabriel Paradelo presentando "Scrum con Team Foundation Server" (usando el template Conchango), Rodolfo Finochietti y Diego Gonzalez presentaron "TDD a fondo", Martín Salías presentando "Agile una perspectiva cognitiva", Lionel Barrabino y Nicolás Páez presentando "Los métodos ágles no famosos (FDD y CC)", José Enrich, Pablo Galliano presentando "MoQ Framework"y Matías Woloski y Johnny Halife presentando "Continuous Integration"

Como se ve, hubo temas introductorios (Scrum, XP, FDD y Crystal Clear), técnicas y herramienta (TFS, TDD, MoQ), mi presentación, que intenta salir del foco en el grupo de desarrollo, para pensar como ese grupo se integra con el resto de la compañía, y la 2da presentación de Martín, que es una presentación de las meta-ideas, los fundamentos y realidades (desde la psicología, teoría de la comunicación, etc) que se tienen en cuenta cuando se definen las metodologías ágiles. (Martín, no se si es una buena descripción!).

Las presentaciones fueron muy buenas, y creo que el intercambio informa también. Entre otras cosas, nos comentó Nicolás que está en la organización de un evento (Snoop update creo) en el que piensa poner un track ágil. Y hablamos con Matías y Martín sobre mi propuesta de indicador para ISO 9001 (Velocidad). Les paso lo que hablamos (según mi punto de vista!).