Agile Open Seguridad y charla sobre Desarrollo Ágil

El sábado pasado (24 de noviembre), participé en Agile Open Seguridad, un evento del Agile Open Tour que se hizo en la Universidad de Belgrano.

El evento fue organizado y facilitado por Carlos Pantelides. En la apertura se propusieron varios temas .

Como no me quedé, pedí para hacer la sesión propuesta por mí (Qué es Ágil)en el inicio. Entre los asistentes había 3 alumnos de UB: de sistemas, de traductorado y de arquitectura. Tuve la alegría de encontrarme con Matías Wepfer, uno de los organizadores de Ágiles 2008.

Qué es desarrollo ágil

Para la charla, utilicé algo de lo aprendido en el curso de Facilitación Gráfica al que fui, usando solo tiza blanca sobre pizarrón verde.

Comenté la evolución del trabajo, partiendo de la producción artesanal, con cada producto (silla) individual, el orgullo del constructor y el sistema de aprendizaje con el maestro, oficiales y sus aprendices.

Luego la producción industrial, con la producción en serie, y al administración científica según Taylor y Ford. Lo que llevó a la división en 'los que saben' (white-collar worker, ingenieros) y 'los que hacen' (blue-collar worker, obreros). Los obreros son reemplazables fácilmente, con dos días de entrenamiento.

Llegamos a la situación actual de síntesis de las dos formas anteriores, en la que los trabajadores del conocimiento no pueden ser tratados como obreros tayloreanos. En software se vió el cambio en 2000 y se concretó con el Manifiesto Ágil (2001).

Una faceta de esto, en lo relacionado con la motivación son las ideas que presenta Dan Pink (videos TED, RSA). Nombré que existen otras visiones de la motivación.

Esta síntesis de la artesanía y la producción en serie no es única, según proponen Lee Devin y Robert Austin en el libro Artful Making.

Utilizamos Artful Making cuando:

• Necesitamos innovación
• Tenemos bajo costo de exploración
• Tenemos bajo costo de reconfiguración

Usé de ejemplo la exploración y reconfiguración un viaje de vacaciones. Y también el caso de el aula en formato anfiteatro con sillas fijas.

Comenté sobre el beneficio de un loop rápido desde la idea al producto (feedback), sobre la Ley de Conway y el caso de organizaciones sin jefes (Github, Valve).

Por último, comente aplicación de estos conceptos en la industria (las máquinas hilanderas de Toyoda y las camionetas de Toyota) y el software, con la curva de costo de cambio, y como el desarrollo ágil (por ejemplo Extreme Programming) logró achatarla.

Luego comenté brevemente Scrum (reusé el pizarrón y no lo fotografié). 

Y más breve aún sobre Open Space (pueden ver otras entradas en este blog, por ejemplo uno hecho en el bar de Exactas)

¡Gracias!

A Carlos, que se puso el evento al hombro!

A Paula Angeleri, que desde su rol en la UB consiguió el lugar y el break!

Información de contacto y para sumarse a la comunidad

Sitio de la comunidad argentina: www.agiles.org/argentina 
Lista de anuncios y organización de eventos: http://tech.groups.yahoo.com/group/agiles-argentina/
Lista de intercambio de experiencias hispanolatinoamericana: http://tech.groups.yahoo.com/group/foro-agiles
Y a mí, Juan Gabardini, me pueden contactar en twitter (jgabardini) o por mail, con el mismo nombre de usuario en computer.org

La mejor manera de probar, en Agiles@BsAs

Como parte de las reuniones mensuales del grupo Ágiles@BsAs, el martes 11 de enero presenté la charla ¿Existe 'la mejor manera' de probar? en las oficinas de Bs As de Southworks.

Pueden ver el texto en el que se basa presentación, o su versión en Software Guru (pdf) y los 'slides' prezi

<se perdió el video de Southworks :( >
Agiles@BsAs: ¿Existe "la mejor manera" de probar? from Southworks Showcase on Vimeo.


Gracias a los asistentes, que a pesar de ser enero, se acercaron. Y gracias a los organizadores, Adrián Eidelman, y la gente de Southworks, Martín Salias y Julián Scopinaro, además de prestar el lugar, filmaron y subieron la presentación. Gracias a Masa Maeda por invitarme a publicar en Software Gurú.

Notas de facilitación de Open Space

Estuve en la organización y luego facilité el Agile Open Buenos Aires 2010 – ¡Programando!. Voy a comentar algunas cosas que hicimos e ideas sobre mejoras, que quizás puedan servir para otros que quieran organizar eventos similares.

Preparación

Luego del evento anterior en Buenos Aires (Agile Open Buenos Aires 2010 – Calidad), a varios de nosotros nos quedó la idea que hacer eventos más focalizados podría servir para tener conversaciones más interesantes para los más avanzados. Por otro lado, la idea de hacer los eventos más y más livianos en cuanto a la organización me llevó a consultar en uno de mis trabajos, sobre la posibilidad de hacerlo en Exactas.

Poner en marcha en evento fue impresionantemente sencillo:

• Hablar con el responsable de la Secretaría de Extensión, Graduados y Bienestar (Diego Quesada-Allue), y gracias a él, con el responsable del comedor de Pabellón II de Ciudad Universitaria. Resultado: el lugar y la comida, resuelto. El único costo, la posibilidad de tener que pagar 100-200$ por uso de más luces.

• Crear la página y el formulario de inscripción. Copiando de los eventos anteriores, un trabajo de un hora.

• Difundir en la lista agiles-argentina y en la lista interna de Exactas, y acá :)

• Crear el grupo de organización. ¡Gracias a los organizadores! Martín Alaimo, Diego Fontdevila, Marcelo Belnicoff y Francisco Tufró.

Con respecto a los sponsors, la duda era si buscar o no. Por un lado, el bar es barato, por lo que no es gran esfuerzo económico para los asistentes. Y entonces, no buscar sponsors simplifica la organización.

Por otro lado, siempre es simpático tener la comida esté paga, y dar lugar para que las empresas que apoyan estos temas logren visibilidad.

Decisión de compromiso, sponsors según la cantidad de inscriptos (un sponsor cada 30 inscriptos) y sólo sponsors que nos hicieran la vida sencilla.

A medida que avanzaban las inscripciones, aparecieron algunos 'problemas' (al menos en mi visión de lo que podría pasar):

• Había temáticas dispares, y me imaginaba que ser atomizarían mucho las charlas.

• Por otro lado, los temas eran interesantes, pero quizás con poca gente especialista en ellos. La gente ser vería obligada a elegir entre muchas sesiones interesantes para escuchar, aunque quizás no pudiera aportar.

Como respuesta a estas situaciones, propuse un cambio en el formato:

• Lightning talks: dedicar un tiempo (55 min) inicialmente a comentar una idea a todos los asistentes

• Facilitar la realización de un gran número de sesiones en paralelo, de tamaño y duración variable: la agenda se arma sin indicar cuantas sesiones simultáneas puede haber. Los responsables de las sesiones deben realizar un cartel que deben poner en la mesa en la que están, de esta manera el que se quiere sumar, busca la mesa con el correspondiente cartel.

• Reforzar la idea de libertad de tiempos: Las sesiones se planifican cada hora, pero se hace un aviso (cuenco japonés mediante) al cumplirse 45 min. Una señal para la gente que quiere hacer un break. Suena nuevamente el cuenco cuando empieza la siguiente hora, pero nada obliga a la gente que está en una mesa a cortar lo que está haciendo. Las nuevas sesiones sólo tienen que buscar una mesa libre.

Realización

Se lograron alto porcentaje de personas técnicas (más del 50%), y alto porcentaje de personas con experiencia en ágil (más de 50% con más de un año de experiencia).

Asistimos 34 personas. Se mantiene el promedio de aproximadamente el 50% de los inscriptos. Vinieron los amigos Julian Arocena y Esteban Roasio de Tandil y una persona de Córdoba.

Los lightning talks se usaron para presentar ideas de sesión en forma más amplia.

Como hubo menos de 11 propuestas de lightning talks, adelantamos la preparación de la agenda, que terminó relativamente rápido. Había bastante experiencia con Open Space, la gente propuso las sesiones en poco tiempo.

Quedó un tiempo entre apertura y la primera sesión, que se usó como un break y para socializar. Creo que se aprovechó.

La dinámica de las sesiones se apartó de lo que pensaba. Se dieron sesiones generalmente multitudinarias, normalmente había dos sesiones con más de diez personas cada una, y una o dos con menos personas.

Se crearon un par de sesiones nuevas a lo largo del día.

La energía del evento se mantuvo hasta el final, que fue a las 16hs cuando el bar cerró.

Resultados

Una demostración más de la robustez de los Open Space, y de la futilidad de tratar de prever como será el contenido.

Los lightning talks no funcionaron como me imaginaba, pero sirvieron. Muchas de las sesiones fueron habladas, sin usar computadoras, pero era lo que la gente quería. Ocurrieron, de todas formas, los intercambios mostrando ideas y herramientas directamente en la máquinas.

From 100605 AO Bs As 2010 Programando

El manejo de sesiones funcionó muy bien para el tipo de espacio en que hicimos esto.

El manejo de sponsors no fue tan transparente como pensábamos. Hay que dedicarle más tiempo.

Nos faltó proactividad para ayudar a que vengan personas de otros lugares del país. Por enfatizar el objetivo “hacer el evento lo más liviano posible”, perdimos la oportunidad de ser buenos anfitriones.

Realmente los eventos de este tipo son fáciles de organizar, pero a la pregunta, cuando es el próximo, no tenemos respuesta. Quizás sea bueno buscar ritmo (¿una vez cada 3 meses?). Y que tan no hacerlo siempre los sábados, para no dejar afuera a los que por diferentes razones no pueden el fin de semana?

Información de contacto y para sumarse a la comunidad

Sitio de la comunidad argentina: www.agiles.org/argentina
Lista de anuncios y organización de eventos: http://tech.groups.yahoo.com/group/agiles-argentina/
Lista de intercambio de experiencias hispanolatinoamericana: http://tech.groups.yahoo.com/group/foro-agiles

Y a mí, Juan Gabardini, me pueden contactar en twitter (jgabardini) o por mail, con el mismo nombre de usuario en computer.org

¡Espero recibir comentarios de los asistentes y verlos en otros eventos!

Agile Open Buenos Aires 2010

Ágiles Argentina te invitan a la próxima experiencia comunitaria: el Agile Open Buenos Aires 2010.

Tema: Calidad en el desarrollo de Software

Cuándo: 13 de marzo

Dónde: UNTREF - Sede Centro Cultural Borges - Viamonte esq. San Martín 3p.

Sobre el tema

Estamos pensando en CI, B/TDD, ATDD, pair programming, calidad por procesos, ... pero lo importante, ¿qué es la calidad para vos?

Este evento está orientado a los que están aplicado metodologías ágiles y están interesadas en contar experiencias, escuchar y aprender de otros, en todo lo que para vos esté relacionado con la calidad.

Lo hacemos bien liviano en cuanto a organización: compramos pizzas o empanadas en el momento y llevamos mate o café para los breaks. Más información.

(pero si alguna empresa quiere pagar las pizzas o traer catering para los breaks... les agradecemos, me contactan)

Inscribite

Saludos, y nos vemos!

Pueden ver como fue el evento anterior en Buenos Aires (en este blog y en agiles.org).

Libertad vs estándares

Como parte de la Scrum week @ Bs As, unas 15 personas nos encontramos en las oficinas de Southworks para pensar sobre los problemas y soluciones sobre el Escalamiento en Implementaciones de Scrum (Scaling Scrum). La consigna inicial era hacer una actividad guiada por Tobias, pero lamentablemente no pudo venir, y lo re-definimos como un open space.
Comento una de las sesiones (50 min) que hicimos.

Libertad vs Estándares

Pensamos que los estándar pueden un surgir como una imposición desde fuera del equipo, o como un aprendizaje compartido.
La primera elección debería ser que los estándar sean el resultado de compartir experiencias.
En los casos de imposición, la pregunta es quien impone. Eso nos llevó a hablar sobre quien es el dueño de los estándar (ownership).
En el caso del aprendizaje compartido, la pregunta nos llevó a como compartir el conocimiento.

¿Quién crea y mantienen los estándar? (ownership)

Los personas que están realizando las tareas son las mejor posicionadas para definir estándar sobre como hacer esas tareas. Pero solo lo harán si tienen motivación y liderazgo.
Grupos como las PMO y grupos de Arquitectura suelen ser los que hacen los estándar en muchas empresas. Pero tienen el problema que muchas veces fueron formados con personas que tienen experiencia, pero que luego quedan aislados del día a día de los proyectos. Aún así, sería bueno tener en cuenta toda la experiencia (libros, implementaciones) sobre PMO y grupos de Arquitectura.

Responsabilidad: algunos de los estándar requieren el uso de algún recurso compartido, o sincronización entre equipos. Por ejemplo, los repositorios de fuentes y los ambientes de integración continua. Sin un responsable, se produce una degradación que atenta contra la utilidad del estándar. Tiene que haber una clara responsabilidad. Una persona, un grupo de personas o un equipo.

Disciplina: los estándar deben cumplirse (mientras tenga sentido, ver más abajo). Si el estándar es una restricción auto-impuesta, entonces necesitamos auto-disciplina (auto en este caso es primero individual y luego grupal). Sin auto-disciplina, aparecen los mecanismos para imponer disciplina desde afuera (registros, auditorias) que nos llevan a algo inefectivo.

¿Cómo difundimos los estándar?

No profundizamos mucho en esto. Las formas de comunicación que surgieron son: Wiki y reuniones. Con respecto a las reuniones, el consenso es que debe ir uno o dos miembros de cada equipo. No necesariamente la misma persona, y debe ser la persona que sepa del tema a tratar. Por ejemplo, no tiene sentido que el SM vaya a una reunión sobre estándar de arquitectura. Esta reunión sirve tanto para definir como para comunicar. Luego cada asistente comunica los resultados en cada grupo. Los asistentes pueden ser rotativos, para evitar que surja el “rol de arquitecto”.

¿Qué significa tener un estándar?

Una sugerencia: nos pusimos de acuerdo con una forma de hacer las cosas que nos parece apropiada en muchos de los casos que analizamos. Pero la decisión final sobre aplicar o no es del equipo. Esto está muy ligado con la Disciplina que comentamos antes. Si no hay disciplina, va a haber muchas excepciones. No debería pasar que las excepciones sean comunes, ya que esto indicaría que el estándar no es bueno. Las excepciones son una oportunidad para revisar el estándar, pero no necesitamos un estándar que responda todas las preguntas. Sería demasiado complejo.

La representación del conocimiento actual de equipo extendido: es la forma en que comunicamos las decisiones de arquitectura/diseño, organización, etc. Deben evolucionar a medida que el equipo aprende.

Alineado con los objetivos de la empresa: lo que hacen los equipos debe contribuir a lograr los objetivos de la empresa (*). Mientras se desarrollan y revisan los estándar, es bueno tener esto presente, lo que nos ayuda a traducir los objetivos (alto nivel) con nuestras prácticas (bajo nivel).

En el cierre de esta sesión quedó inconclusa una discusión sobre Scrum y Auto-organización. Hasta donde entiendo: lo que hablamos en la sesión, aplica a Scrum o a cualquier Auto-organización. Implícita está la discusión: Scrum incluye toda forma de auto-organización, o auto-organización incluye toda forma de Scrum, o ninguna de estas.

(*) Mientras escribo este resumen, me encuentro tentado a agregar comentarios propios, no dichos durante la sesion (de la que fui moderador, por lo tanto traté de no participar opinando... mucho). En el caso de los objetivos de la empresa, por ejemplo, sería importante que los principios de Scrum (y/o auto-organización :D) se apliquen a todos los niveles. Por lo tanto, esos objetivos deberían ser un emergente de todos las personas de la organización.

Semana Scrum en Bs As!

Tobias Mayer ya ha venido varias veces a Argentina, y dio 6 cursos de CSM. Alan Cyment es el único CST hispanoparlante, y dio muchos cursos en Argentina. En enero Tobias nos visita en la semana del 25 al 26 y aprovechamos con varios actividades:

Enero 25: Scaling Scrum (gratuito) (x Tobias)
Enero 26: Consultas CSP (gratuito) (Alan y Tobias)
Enero 27: The Spirit of Scrum - (pago *) (x Tobias)

Enero 28: Improvisation for agile teams - (pago *) (facilitado por Alan Cyment, co-facilitado por Tobias)

(*) En ambos casos, cada día cuesta 220 usd + IVA. Tomando ambos curos el costo es 330 usd + IVA - La facturación la realizará Agilar, que organiza estos eventos.

NOTA: inicialmente planificamos un CSM los días 25 y 26. Por el interés en los talleres avanzados, finalmente suspendimos ese CSM. Para los interesados en CSM, en marzo sr hará uno (Alan)

NOTA: Las actividades con Alan son en español, las actividades con Tobias son en inglés.

Agile Open Buenos Aires es mañana!

Que espectativa!

Mañana comenzamos el evento Agile Open Buenos Aires 2009, el primero en el Agile Open Tour (Bs As, Córdoba, Tandil, Rosario), y las expectativas están subiendo.

Por lo pronto ya tenemos más de 100 confirmados (sobre 190 interesados). Hicimos un esfuerzo para que no quede gente afuera. Confiamos en que todos los asistentes, con la ayuda de los facilitadores (Alan Cyment y Xavier Quesada Allue) vamos a ser creativos y lograr un gran evento.

Vendrán personas de España, Belgica, y de Córdoba, San Juan, La Plata, Tandil, Rosario, ...; de empresas nacionales, internacionales, del Estado, de las Universidades.

Si querés, todavía podes inscribirte.

Increible que se pueda organizar un evento de este tamaño con dos meses de aviso, y dos meses de vacaciones. Creo que es una indicación del interés y la fuerza que tiene este tema.

Nos vemos allí!

Ágiles en BsAs - Value Stream Mapping

En a segunda reunión mensual, hicimos un ejercicio llamado Value Stream Mapping. Pueden ver más fotos aquí.

Esta herramienta, parte del repertorio de Lean Software Development, consiste en rastrear todos los pasos que sigue una idea de producto o pedido de un cliente desde el momento que se origina hasta el momento en que se genera valor. Teniendo ese mapa, se puede identificar el punto dentro de nuestra cadena de valor que implica el mayor retraso (no esfuerzo, sino tiempo calendario). La visión en Lean es que si logramos disminuir el tiempo entre la idea y el valor (ver From Concept to Cash) lograremos varios efectos indirectos, como mejor calidad, más productividad, más satisfacción de los clientes.

Desde que  leí sobre Lean (y antes la teoría de restricciones) me gustó, porque dan una guía sobre que mejorar. Todos queremos la mejora continua, pero a veces nos encontramos con que no sabemos que mejorar o como priorizar las varias mejoras posibles.

En esta reunión pasó algo que se repitió todas las veces que realicé el ejercicio: la parte inicial del mapa, sea llegar al contrato, dar por aprobado un incidente para que sea corregido, etc. es el principal punto de espera en la mayoría de los mapas. Tiempos de 6 meses para la aprobación de trabajos de 1 mes no son raros.

Como resultado, para la próxima reunión, el 10 de febrero, se votó discutir sobre las formas de contratación ágiles. Si te interesa, anotate.

Inscripción reunión mensual (Ágiles@BsAs?)

Hola
Aún no tenemos nombre, pero no por eso nos detenemos!

El 1er encuentro mensual de la comunidad ágil en Buenos Aires se llevará a cabo el próximo 9 de Diciembre a las 19hs en Microsoft (Bouchard 710 4to piso). La idea para el primer encuentro es ver y debatir entre todos el video del panel de cierre de Ágiles 2008.

La agenda es:

19:00-20:00: Video panel de cierre Ágiles 2008
20:00-21:00: Debate
21:00-21:15: Decisión sobre tema a tratar en próximo encuentro

Incribirse!