Educación en Finlandia

Voy a comentar un documental que vi gracias a la referencia que pasó Fernando Claverino.
El documental, de Tony Wagner, es de aproximadamente 60 min, con subtítulos en español. También hay una nota aquí (gracias a referencias de Martín Alaimo) y video TED (gracias a referencia de Ezequiel Kahan).

La descripción me disparó muchas coincidencias con Lean Thinking y Training from the back of the room. 
Me llamó la atención la coincidencia con una anécdota de Mary Poppendieck (cito libremente, porque no recuerdo dónde lo leí): "Cuando estaba dando un curso en Suecia, en un break se acercó un asistente y me dijo 'La relación entre los jefes y los trabajadores que describís no es rara para nosotros, es la forma en que normalmente nos manejamos.' Lo que me hizo pensar que quizás la forma de trabajo en 3M fue influenciada en la inmigración escandinava en Minnesota".
Minnesota es el estado con mayor porcentaje de descendientes de escandinavos (cerca del 10% en la actualidad). En el video se compara a Finlandia con Minnesota, por ser el estado con la mejores resultados en test de educación de USA.

Paralelos con Lean thinking

Respeto a las personas: tanto a los docentes como a los alumnos, se cree que dando el contexto y ayuda adecuada, van a hacer lo mejor posible. El sistema se basa en la confianza. No en evaluaciones o controles. La confianza, a nivel global del sistema educativo, se desarrolló a lo largo de muchos años. En el documental dicen que tardaron 25 años en delegar el contenido de ente centra a los municipios. Hay responsabilidad en los estudiantes sobre el resultado del proceso de aprendizaje.
Práctica Consiente: llegar a ser docente es un proceso largo que incluye un master y muchas horas de  observación y práctica docente. Cada observador hace una devolución respondiendo tres preguntas: ¿Qué observaste? ¿Qué harías diferente? ¿Qué te gustó?
Mejora continua: los docentes y los estudiantes de docencia pueden entrar a cualquier clase, y luego dar su feedback. Las clases suelen ser filmadas y la filmación queda pública.
Trabajadores del conocimiento: los docentes como trabajadores del conocimiento. Pueden ser expertos en su área, pero deben aprender a enseñar: aprender como las personas aprenden. Comunidades de práctica para la mejora y presión de pares. Son los que hacen los mejor capacitados para decidir como hacer.
Foco en satisfacción del 'usuario': lo importante de una práctica o tecnología es como ayuda al estudiante, no como ayuda al docente.

Paralelos con Training from the back of the room

Salir del centro: El tiempo en que habla el docente vs el tiempo en que hablan los alumnos es 85% / 15% en USA, y en Finlandia se busca que se 40% / 60%.
Conexión: iniciar la clase con referencias a situaciones que los alumnos conocen, y trabajar a partir de ahí.
Enseñarse entre los alumnos: por ejemplo, cada uno tiene un proyecto de investigación, y el resultado de eso lo pone a dispocisión para que otros alumnos lo comenten.

Es más importante enseñar a pensar que transmitir conocimiento. Los alumnos aprenden más cuando descubren y crean el conocimiento que cuando lo reciben.

Otras ideas

Las escuelas son pequeñas, las clases tienen hasta 20 alumnos. No todos los alumnos seguirán luego una carrera universitaria. Los docentes son seleccionados entre los mejores y además de una preparación equivalente a un master, tienen muchas horas de prácticas consientes.
El sistema educativo surgió de un consenso nacional sobre que se espera de la educación, y un largo proceso de mejora continua sobre el mismos. Toda la educación es estatal, e igual para todos. Los docentes ganan bien, y son respetados socialmente.

¿Y que hacemos a partir de este ejemplo?

No tengo, en el ámbito educativo estatal en el que participo (Facultad de Ingeniería - UBA), algunas de las condiciones indicadas (consenso, buena remuneración, dedicación tiempo completo). Aún así, puedo llevar muchas de las ideas a mi día a día. ¡Eso haré! (de a una por vez :D)

Sonrisas y procesos

Sonrisas

Las personas que trabajan contentas transmiten esa alegría a los clientes. Los clientes que comparten esta experiencia placentera vuelven a comprar en el lugar. Y los empleados en ese ambiente quieren seguir en esa empresa y se ocupan de mejorar lo que hacen.

Acabo de hacer un resumen en un párrafo de Fish: Una manera probada de mejorar la moral y los resultados. Y es algo que suena muy razonable. 

Si creemos esto, el problema es  lograr que este círculo virtuoso se ponga en marcha en la organización. Quizás podemos aplicar "lo que se mide es lo que se mejora". Pero ¿que debo medir? No podemos medir "contento", necesitamos una características observable.

¿Y si medimos el porcentaje de tiempo que las personas están sonriendo?
Vean el video de la derecha a donde puede conducir esto.

Procesos

Las personas que se ocupan de mejorar acuerdan un proceso estándar, que corresponde a la forma en la que hacen el trabajo hoy. El estándar es la base a partir la cual se mejora.

Si, como organización, me interesa la mejora y quiero fomentarla, ¿cómo hago? ¿Puedo medirla? 

¿Y si medimos si existe un proceso estándar? ¿Y que existan mejoras sobre eso?

También me gustaría que lo hagan mis proveedores.

Y si como país queremos fomentar la mejora, podemos dar subsidios y beneficios impositivos para los que estén en esa situación.

La tristeza o ¿por qué vuelvo a hablar de esto?

Hey, ¿ya escribí sobre esto, por qué otra vez?

Me encontré en el último tiempo con varias situaciones en las que las mediciones que hacemos con la intención de mejorar provocan resultados no deseados. Es algo similar a lo que ocurre con los genios, como pueden leer en La pata de mono (un cuento breve y muy recomendable).

Uno de los resultados del caso de la sonrisa, es que ya no creemos en las sonrisas de los que nos atienden en los negocios. Asumimos que es forzada.

Forzar a que nos atiendan con una sonrisa no solo no sirve a esa empresa en el largo plazo, sino que la generalización del comportamiento nos ha llevado a descreer y no compartir la alegría ni siquiera en los casos auténticos de empleados contentos.

Esto también se nota desde el punto de vista de los empleados, que reaccionan con cinismo cuando se celebra un éxito individual o grupal. "¿Va aparecer tu foto como empleado del mes?"

Y en el caso de los procesos, ha llevado a que muchas personas descrean de los procesos y se revelen contra ellos. No se quiere reflejar las buenas prácticas actuales en procesos porque es "burocracia". Y si hay procesos, a pesar que fueron hechos por ellos mismos, no lo ven como una base sobre la cual mejorar, sino un objetivo a lograr y una vara contra la que se los medirá.

Y entonces, ¿tristeza nao tem fim?

No estamos condenados a la tristeza sin fin. Es un tema cultural, y así como nos metimos en esto, con el Taylorismo, podremos salir. 

Va para finalizar la moraleja "¡Cuidado con lo que deseas (y mides), porque puede cumplirse! (pero no de la manera que esperabas)"

Relación entre la frecuencia de entrega y los procesos

Recientemente vi un video de Kent Beck, Software G Forces: The Effects of Acceleration, comentado por Mary Poppendieck en How Cadence Predicts Process.

Kent analiza como cambian los procesos y buenas prácticas según aumenta la frecuencia de entregas (Anual, Trimestral, Mensual, Semanal, Diaria, Horas). Comenta como algunas prácticas son buenas con cierta frecuencia de entrega y son malas en otras.
Plantea la relevancia de este análisis debido a que, según su percepción, la frecuencia de entrega de los equipos de software tiene a acelerarse.

Mi intensión es hacer un resumen, pero recomiendo ver el video que, aunque dura 90 min, es mucho más rico que este post.

Entregas anuales → trimestrales

Prácticas que se agregan: Test de aceptación automatizados, refactoring, Integración continua
Justificación: No se puede solo reducir los tiempos, hay que cambiar los procesos. No puedo tener un mes de integración y corrección de bug, con una o dos semanas de pruebas manuales para hacer regresiones. Entonces aparece Integración continua, y Pruebas de Aceptación Automatizada. No puedo tener uno o dos meses de diseño, aparece la necesidad de avanzar aún sin tener todo el diseño hecho o cerrado. Estoy seguro que tendré que cambiar el diseño, por lo tanto, tengo la necesidad de refactoring.

Cambios en el negocio: Suscripción.
Justificación: No se pueden vender 4 versiones por año. Necesito bajar el costo de transacción (tanto para la empresa como para los clientes).

Entregas trimestrales → mensuales

Prácticas que se agregan: prueba por parte de los desarrolladores, reuniones diarias, tarjetas en las paredes.
Prácticas que se quitan: Departamente de QA, soporte a múltiples versiones, Documento de diseño, Control de cabios, equipo de análisis, equipo de build.
Justificación: no hay tiempo para el ida y vuelta con un grupo separado de QA. La mayoría del testing y la reducción del defectos deben ser hechos por el mismo grupo, y probablemente por la misma personas (testers en el equipo y pruebas por los programadores), en el plazo de horas, no de días. La comunicación debe ser mucho más rápida, no podemos sincronizarnos y detectar problemas una vez por semana o mensualmente. Tenemos que estar al tanto cada día, solo tenemos 20 días para entregar (reuniones diarias), tenemos que planificar y re-planificar en forma barata y rápida (tarjetas en las paredes, dejar de usar control de cambios formales). No podemos dedicar mucho tiempo para escribir las decisiones detalladas de diseño antes de usarlas (Documentos de diseño).
Al aumenta la cantidad de entregas, el costo de soporte de muchas versiones se vuelve prohibitivo, y debemos mantener una o pocas versiones del producto (soporte de múltiples versiones). Necesitamos iniciar el diseño y el desarrollo, no podemos esperar una fase de análisis o el ida y vuelta en paralelo con un grupo de análisis (mismo problema que con QA).

Cambios en el negocio: Pagar por el uso.
Justificación: la suscripción no nos da suficiente feedback. Con pagar por el uso, sabemos realmente que funcionalidad que estamos desarrollando les interesa a los clientes.

Entregas mensual → semanales

Prácticas que se agregan: migración de datos en vivo, cero defecto, ramas temporarias, dovela clave (keystoning), kanban.
Prácticas que se quitan: equipos de test, migración en un sólo sentido, ramas de release, parches, diseño de usabilidad al inicio, venture capitals
Justificación: para poder cambiar las estructuras de datos en sitios con grandes volúmenes de datos y cantidad de usuarios, se debe hacer procesos de migración en dos o tres fases, de manera de cambiar la estructura sin nunca dejar de dar el servicio (migración de datos en vivo).
Como los tiempos son cortos, algunas funcionalidades se comienzan a agregar sin hacerlas visibles. Solo cuando está todo dispobible, se agrega la última parte (como la dovela clave de un arco de medio punto), y queda dispobible para los usuarios. Siendo que las entregas son tan rápidas, cualquier cambio, por más urgente que sea, puede incluirse en la próxima entrega. Se elimina la necesidad de procesos de emergencia (parches).

Cambios en el negocio: Bootstrap financing.
Justificación: La financiación de Venture Capitals necesita mayor predecibilidad en los planes, e impone restricciones a desarrollo de productos (a esta velocidad).

Entregas semanal → diarias

Prácticas que se agregan: inmunización, A/B testing
Prácticas que se quitan: staging, equipo de operaciones, reuniones diarias.
Justificación: algunos de los releases van a ser malos. Tenemos que tener formas muy sencillas de volver atrás o formas muy rápidas de corregir y continuar. No hay mucho tiempo para discusciones sobre diseño de interfase, se pude simplemente dar las alternativas y ver como lo usan los usuarios (A/B testing). Para hacer entregas rápidas, no podemos pasar por tantos pasos (ambientes) intermedios. Simplemente no hay tiempo para usarlos (staging), lo que se puede hacer es hacer instalaciones en distintos servidores de producción, que se va midiendo y obteniendo feedback. Todo esto lleva a que la operación debe ser parte de la responsabilidad del equipo (equipo de operaciones). La comunicación en el grupo tiene que ser tan continua y rápida, que no tiene mucho sentido para las reuniones diarias.

Mis conclusiones

Esta visión me hizo repensar mis ideas sobre La mejor manera de probar, reinterpretando parte de mis observaciones desde esta nueva perspectiva. La corelación entre ambas visiones es muy fuerte, pero no completa. Es interesante que la visión de Kent está muy asociada a situaciones en las que el software es el componente principal de los productos.

Referencias del curso de Scrum

En los últimos tiempos fui disminuyendo la cantidad de transparencias en los cursos, para dar más lugar a las actividades interactivas y a la adaptación del nivel de detalle según el interés de los asistentes.

En el último curso, me basé completamente en la dinámica que no requiere proyector. En lineas generales me pareció que la dinámica fue buena, pero una pérdida fue que las referencias a libros, sitios y eventos quedaron repartidos a todo lo largo de los dos días de curso.

Trataré de cubrir aquí esa falencia. Si quieren pueden ver la presentación previa del curso.

Grupos y sitios

Foro ágiles: lista de correo de intercambio de ideas y experiencias, preguntas y anuncios de la comunidad hispanoparlante (Latam y España)

Ágiles: uno de los sitios comunitarios de metodologías ágiles en español.

Ágiles Argentina: lista de correo de la comunidad argentina para anuncios locales, organización de eventos

Blog de Juan Gabardini: ¡Este blog! Desarrollo ágil de software, con cierta inclinación hacia el testing

Scrum Development: lista de mails 'oficial' de Scrum.

Scrum Alliance: sitio 'oficial' de Scrum. Por ejemplo tiene la lista de capacitaciones de CSM.

Agile Alliance: sitio 'oficial' sobre el desarrollo ágil. Son los organizadores del mayor evento anual, Agile 20xx.

Eventos

Ágiles 2010 – Oct – Lima: Evento anual de la comunidad latinoamericana sobre metodologías ágiles.

Agile Open Tour: Serie de eventos argentinos realizados con el formato Open Space. Se han hecho 6 durante 2009 y hay planeados 8 eventos en el 2010.

Libros y otro material

Ken Schwaber: Agile Project Management with Scrum / The Enterprise and Scrum

Libros de referencia. El primero con foco en scrum dentro de un equipo, el segundo con la implementación en toda la organización. Ver mis comentarios previos.

Rob Austin y Lee Davin: Artful Making

Una visión novedosa sobre el desarrollo de software y otras actividades (teatro, planificación estratégica), que explica la secuencia desde el trabajo hecho artezanalmente, la producción industrial y la artística, con las motivaciones económicas y implicancias en cuanto a las condiciones necesarias y la forma de trabajo resultante. Ver mis comentarios previos.

Henrik Kniberg: Scrum and XP from the Trenches

Conjunto de experiencias en todos los temas enfrentados al usar Scrum, con referencias a libros y material adicional. Disponible en forma electrónica gratuita y en español.

Mike Cohn: User Stories Applied / Agile Estimating and Planning

Libros de referencia obligada para temas los temas del título. Además Mike tiene muchos recursos disponibles gratuitamente.

Craig Larman: Agile & Iterative Development: A Managers Guide

Buena introdoción a la idea general y sumario de los distintas 'metodologías'. Tiene varios libros interesantes y algunos documentos gratuitos muy interesantes, como Lean Primer

Kent Beck: Extreme Programming Explained: Embrace Change

Uno de los primeros libros sobre Desarrollo Ágil, con contenido relacionado con las pácticas técnicas, que no están cubiertas en los libros mensionados anteriormente.

Mary & Tom Poppendieck: Implementing Lean Software Development

Los conceptos de Lean están atrás de muchas de las buenas prácticas Ágiles. Uno de los tres libros de los Poppendieck (todos recomendables).

David Anderson: Agile Management for Software Engineering: Applying the Theory of Constraints for Business Results / KANBAN, Successful Evolutionary Change For Your Technology Business

En el primer caso, David toma los conceptos de TOC aplicados al Software. El segundo es un libro de próxima publicación (con traducción a español) con la aplicación de Lean que el inició y nombró.

Costo de multitarea personal

Hace un mes, en una charla que dió Xavier Quesada Allué sobre Lean Software development y Kanban, realizó una actividad nueva para mí. La medición del costo de cambiar de tareas. Es muy sencilla de explicar, requiere pocos elementos, y tiene resultados llamativos.

Se pide a las personas que se organicen en pares. Uno tiene que medir los tiempos (cronómetro con segundos) el otro tiene que escribir en una hoja, de dos maneras distintas.
El resultado final es siempre el mismo, tres columnas, la primera con números arábigos (1-10), la segunda con letras (a-j), la tercera con números romanos (I-X)

1. La primera vez, deben escribir por columnas, primero los números arábigos, luego las letras, luego los romanos.
2. Se registra el tiempo.
3. Opcional: se puede indicar que, dado que ya tienen experiencia, esperaríamos tener mejores resultados.
4. Luego se escribe por fila (1, a, I), (2, b, II), etc.
5. Se registran los tiempos.

Se pide a todos que indiquen cuanto tardaron comparativamente.

En casi todos los casos, la diferencia en la segunda forma de realizar el ejercicio es mayor de 10%.
Un caso interesante fue que la segunda vez se tuvo un error. Se salteó una letra, y se detectó recién al llegar a la última fila.
En el caso de Lima, con unas 200 personas, hubo alguien que indicó haber tardado menos en la primera vez. No tuve oportunidad de averiguar con más detalle que habia pasado en ese caso.

En la discusión posterior se puede comentar sobre la técnica de Pomodoro o Pair programming/testing

Panel CMMI vs Ágil (2/2)

Voy a comentar algunas de las preguntas que nos hicieron al panel (parte 1: resumen de las presentaciones del panel) y algunos pensamientos y situaciones que tuve luego del evento.

asistente: ¿Puede aplicarse ágil en grupos grandes?
yo: ¿qué es grande para vos?
asistente: El sistema de defenza de China
(no conteste, alguien más lo hizo)
Ugh? ¿acaso estaría esa persona en ese equipo? ¿si no, que interés práctico puede tener una pregunta así? Mi hipótesis es que hay una suposición subyacente: lo que es bueno a un proyecto enorme, debe ser bueno para un proyecto chico. Según esta hipótesis, los problemas de escalamiento sólo se darían al agrandar, no al achicar.

asistente (otro):¿cómo logro con ágil que todos los equipos trabajen en forma similar?
yo: ¿Por qué querés que trabajen en forma similar?
asistente: la compañía tiene que tener una forma definida de hacer las cosas
yo: ¿Qué valor de negocio tiene eso? (y comenté el caso de Toyota, en el que cada planta que hace el mismo vehículo tiene layout diferentes, y cada uno es óptimo en cuanto a condiciones locales)
asistente: pero los trabajos que hacen deben tener algo en común ...
(perdí la atención del asistente, y el hilo del diálogo fue hacia otro lado)

¿Por qué la unificación de las formas de trabajo es visto cómo una verdad indiscutible?

La semana pasada estábamos en una clase de la facultad, en la simulación de una retrospectiva. El problema a resolver era: requierimientos muy cambiantes.
alumno: una mejora sería "estandarizar el proceso de elicitación de requerimientos"
yo: ¿Por qué te parece que esto resolvería el problema?
alumno: está muy estudiado como deben obtenerse los requerimientos. Deberíamos incorporar esto a los procesos.
yo: ¿Pero eso ya se hace en la compañia?

alumno: ...

yo: Digo, porque si decimos que queremos estandarizarlos es porque en algún área o grupo ya se están aplicando y queremos llevarlo a otros, no?

alumno: ...

yo: Si no se usaron nunca, quizás debiérmos probarlos en algún grupo, antes de estandarizarlos

alumno: (cara de no estoy de acuerdo con lo que decis pero sos el docente)

Ya no es sólo la unificación dentro de una compañia, sino la unificación a nivel industria. Implísita está la idea de que debe haber sólo una forma de manejar los requerimientos.

Paréntesis

Recientemente me prestaron Artful Making, espero postear más extensamente sobre el libro, pero para este post basta con comentar que los autores plantean que hay dos formas de hacer las cosas: Artful Making, muy ligada a la innovación, con costo de iteración y de error bajo (ejemplos: teatro, software, estrategias corporativas); e Industrial Making, que es lo que ha tenido tanto éxito (revolución industrial), que nos parece como natural e innegable (producción en serie, economía de escala).

¿Qué encuentro en común en las sitiaciones descriptas arriba?

La idea de "la mejor solución". Esta es una visión Taylorista, en la que alguien pude analizar el problema y encontrar la mejor forma de hacerlo. Por lo tanto, los operarios deben seguir al pié de la letra esa solución, ya que es la mejor.

Esto tiene dos problemas: por un lado, si estamos en una situación que permitiría usar Artful Making, lo estamos perdiendo. Por otro lado, si estamos en una situación de Industrial Making, nos quedamos con métodos de principios del siglo XX. Todo lo aprendido a partir de los '60 por los japoneses, y a partir de los '80 por el resto del mundo, no lo aplicamos: Lean Production.

¿Es esto un problema?

¿Es un problema que algunas personas mantengan la idea de "la mejor solución"? Vuelvo sobre mi post CMMI y Agile, y le doy otra vuelta de tuerca, porque voy a tocar el proceso de evaluación.

En una charla con Mary Poppendieck, ella comentó los efectos nefastos y no deseados de las certificaciones: se incian tomando las buenas prácticas, se estandarizan, se instruye a los evaluadores y se los controla para evitar desvios y subjetividades, esto pone restrincciones externas a las empresas, que para no perder su status (certificación) establecen áreas internas que replican la idea de evaluadores que controlan el cumplimiento.

Todo esto genera una gran inercia. Si una empresa quiere innovar tiene que convencer a sus auditores, que tendrán que convencer a los evaluadores, que tendrán que convencer al organismo originador del estandar.

En el panel, yo noté exactamente esa dinámica. El movimiento ágil se desarrolló casi totalmente fuera del alcance del SEI y las empresas CMMI. Luego que tomó fuerza, se hizo notorio que es algo bueno, por lo que muchas empresas emprezaron a usarlo y el SEI se puso a trabajar (luego que las ideas llegaron al mainstream) en mostrar que CMMI no es incompatible con Ágil. Y ahora está tratando de convencer a sus evaluadores de esto (y le cuesta).

Replanteando la pregunta, ¿será que por construcción el CMMI refleja el mainstream, lo común, y no fomenta la innovación?

¿Puede incorporar el estado actual de las prácticas ágiles, pero inmediatamente lo congelará como el nuevo estándar, sólo para ser superado por las empresas que no son CMMI?

Juegos en educación

En la enseñanza de el desarrollo ágil solemos usar actividades lúdicas (también llamados juegos :D).
En los cursos oficiales de Certified Scrum Master suelen usarse. En los cursos de Scrum que yo doy (no oficiales) uso juegos. También los aplicamos en las clases de la materia Administración de Proyectos Informáticos II - FI UBA. El juego del Pajarraco (una versión del XPGame hecha por Alan Cyment, pueden ver algunas fotos aquí) lo uso en toda ocasión en que necesito explicar desarrollo iterativo e incremental.
El IEEE tiene un programa (TISP) orientado a acercar a los estudiantes secundarios a las ingenierías a través de juegos.

Hay muchos más, y paso una lista de recursos para los que les interese.

Para los que quieran recursos,
http://blog.tastycupcakes.com/ (el caso de Mr Happy Face)
http://wilderdom.com/games/InitiativeGames.html
http://www.dosideas.com/wiki/Juegos_Agiles
http://www.tryengineering.org/

Agile Open La Plata

El sábado nos reunimos en la Universidad Católica de La Plata unas 70 personas para intercambiar experiencias sobre el desarrollo ágil de software.

Como en todos los casos en los que participé (Buenos Aires, Córdoba, Tandil), la experiencia fue muy buena. Las gente es entusiasta, y se crea un clima de aprendizaje muy bueno.

Verán en las fotos que no logramos hacer que la sesión inicial y el cierre fueran con un círculo plano. Sin embargo esto no afectó el funcionamiento. Además, hacer las sesiones en un museo, entre pinturas y esculturas, le dió un toque interesante. Podríamos haber usado el patio, pero estuvo lloviznando de a ratos.

Martín Alaimo facilitó la apertura y las dinámicas de las sesiones, mientras que Diego Fondevila facilitó el cierre.

Apertura: En la apertura, tardamos en votar y en armar la agenda. Creo que fue por no tener suficiente lugar para que varias personas estén paradas frente al mercado o a la agenda. La gente para votar se toma un par de minutos, leyendo las propuestas. Esto es algo parecido a lo que pasó en Córdoba. Pero no encontramos mucha alternativa.

Las sesiones salieron rápidamente, sin miedo. Pero también se cortaron rápido. No fue necesario descartar sesiones, cuando se unieron las similares, había suficientes slot para todas.

Sesiones: a diferencia de otros AO, no estuve en ninguna sesión con poca gente (menos de cuatro). Las sesiones fueron muy buenas. Tuvimos el juego del pajarraco, que facilitó Nico Paez, pero pasé a tomar fotos.

En otra sesión se dió un caso interesante: en una sesión se dieron cuenta que todos querían escuchar una intro a metodologías ágiles, pero no había nadie presente para comentar el tema, ¿cómo lo resolvieron? se fueron a la sala de al lado y pidieron ayuda. Nico tomó la posta.

En un par de sesiones me levanté luego de un rato. Un poco porque habían perdido empuje, y otro poco para fomentar que la gente se mueva un poco. No vi mucho movimiento, me parece que la gente en general se quedó en las sesiones.

Las sesiones a las que fui: Intro Lean, Equipos Chicos, Testing, Retrospectivas, Arquitectura.

Cierre: como en los cierres de Cba y Tandil, el radar/termómetro del final es bueno por paliza. Esto no es tan raro, ya que se quedan hasta el final los que están más enganchados, pero aún así, se quedaron muchos. Hubo muchos comentarios positivos, y se habló un poco de como seguir. Sin embargo, los próximos pasos fueron más hablados en los pasillos, y en los mails posteriores.

Termino agradeciendo a Liliana Rathmann, Horacio Sampaoli y Martín Alaimo, que llevaron en sus hombros gran parte del peso organizativo (el costo de ser local!)

090620 AO La Plata

CMMI y Ágil - ¿Choque de civilizaciones?

Fui invitado por Liveware para un evento sobre CMMI y métodos ágiles (parte 1, parte 2). Después de consultar con la comunidad sobre opiniones, di varias vueltas para elegir un tema y buscar un balance entre algo picante que haga interesante el panel y mi natural postura ecléctica. Decidí hablar sobre una diferencia cultural que percibo entre los viene del campo CMMI y los que vienen de Desarrollo Ágil.
Posteo la versión larga, tuve que reducirla para que entre en 10 min.

Una comparación superficial entre empresas CMMI y Ágiles muestra grandes diferencias. Pero en ambos casos los espacio de posibles implementaciones son amplios, con intersección, y hay implementaciones que son tanto CMMI como Ágiles, como lo demuestran casos de empresas como las que estuvieron representadas en el panel.

Podemos encontrar bases comunes, como las ideas de Deming, y en el foco en la mejora continua.

Tuve la suerte de escuchar a Watt Humphrey en Santiago de Chile (SEPGLA 2007), en su presentación comentó "La clave para manejar trabajadores del conocimiento es: los trabajadores deben manejarse a sí mismos." … Lo podría haber dicho un gurú Ágil.

En el libro de Boehm “Balancing Agility and Discipline”, Boehm comenta una comunicación personal de W. H. diciendo que un equipo XP cumple con el TSP con “sólo agregar algunas métricas”. “sólo agregar algunas métricas”… después vuelvo sobre esto. Alan Cyment comentó alguna vez que lo que define a Scrum es la mejora continua, todo el resto es modificable.

Podría seguir con similitudes y puntos de contacto… pero hablemos de las diferencias.

Antes de seguir, un disclaimer. Se puede hablar de “qué es CMMI”, está el SEI para decirlo. Es más difícil con Desarrollo Ágil, no hay una fuente oficial.

Al recibir la invitación para el panel, decidí hacer un experimento, pregunté en una lista Latinoamericana que pensaban de la interacción de CMMI y Ágil. Recibí algunas respuestas negativas, pero la mayoría de los que tuvieron experiencia real con ambas formas de trabajo, dicen que se pude implementar ideas ágiles con CMMI. Sin embargo no hubo ninguna respuesta que recomendara implementar CMMI para empresas ágiles.

Esto llama la atención. ¿Cómo es posible que un modelo hecho para que las empresas mejoren no sea recomendable?

Se entendería para barreras de entrada, como SOX. Nadie espera ser más eficiente por cumplir con SOX. Es un mal necesario si quiero entrar en cierto mercado.

CMMI tiene dos caras: ser una barrera de entrada (evaluación), y por otro lado un modelo de mejora. No voy a discutir la primera parte. Hablemos de la mejora, desde varios puntos de vista.

Observo que las empresas CMMI tienen algunas características que no se encuentran en empresas ágiles:

• Mejora cuantificada: Existencia procesos y sus métricas como precondición a la mejora.
• Mejora centralizada: un grupo de mejora o un consultor externo.
• Foco en la repetibilidad y el cumplimiento de normas.

Mejora cuantificada: Los procesos en las metodologías ágiles

Un amigo empezó a trabajar en la planta de Toyota en Zárate desde el día uno. Me comentó que el layout inicial era ultra sencillo, lineal, sin paralelismos. El único objetivo: producir la primera camioneta, como sea. ¿Era eficiente? No. Pero a partir de ahí, se ponía en marcha la mejora continua. Con todo lo que sabía Toyota de fabricación, podrían haber hecho un mejor layout, no? NO. La planta es sólo un paso en la generación de valor, todo el ecosistema de autopartistas, canales de distribución, … es necesario para entregarle una camioneta al cliente, y ese ecosistema es único y cambiante. La forma óptima es que la planta local se amolde al ambiente existente y influya en el ambiente, en un proceso de continua adaptación y mejora.

Los procesos surgen como las reglas que cada equipo se impone. Son el resultado de un trabajo ordenado y de la mejora continua, no al revés.

Pero si yo mido existencia de procesos como forma de medir la madurez, promuevo que aparezcan procesos aunque no tengan valor para el equipo. Doy un ejemplo: si creemos que un cliente que va a un restaurante va a están más satisfecho si lo atienden personas que están contentas con lo que están haciendo, podría verme tentado a sugerir a los empleados que atiendan siempre con una sonrisa, pero si planteo esto como obligatorio, obtendré de los empleados una continua sonrisa vacía, que tiene un efecto contrario al esperado.

Mejora centralizada: El control y la confianza

La estructura de los programas es un reflejo de la estructura del grupo que lo hizo. No sé quien es el autor de la frase, pero creo que muchas veces es verdad. Si un equipo no está aglutinado, se tendrán un producto hecho por pedazos, cada uno de los pedazos más o menos integrado con el resto.

Creo que algo así pasa con las organizaciones. El SEI y el CMMI nacen de la relación de desconfianza institucionalizada que existe entre el DoD y sus proveedores. Esta estructura macro (dos partes involucradas, que desconfían entre si, usan un tercero “neutral”) se repite a nivel empresa (QA: valida que los procesos se cumplan) y equipo (Test: valida que lo que pidió el usuario se cumpla).

La falta de confianza está también reflejada en organizaciones fuertemente jerárquicas, en la que cada nivel “superior” comanda y controla al nivel “inferior”.

Foco en repetibilidad y cumplimiento: Cómo analizamos los problemas y cómo aprendemos

La forma CMMI de mejora tiene mucho en común con el método científico. Fijo las condiciones (proceso), planteo la hipótesis (cómo mejorar el proceso), hago el experimento, mido los resultados. ¿Es lo esperado? Si, mi hipótesis es la correcta. Paso a la próxima hipótesis. ¿Cuál es el problema?... ¿de dónde surgen las hipótesis? No es algo que el método científico resuelva.

¿Es la única forma de mejorar? ¿Cómo hacen los grupos de teatro?¿Los músicos? No parece que sepan mucho de control estadístico de procesos, por lo tanto debe haber otra cosa.

El desarrollo de software tiene un fuerte componente social. Si queremos resolver la dinámica de grupo con el método científico, me parece que no llegamos a nada.

Por otro lado, si queremos lograr aumentar la confiabilidad de un servicio, un análisis de modos de fallo, Ishikawa y otras técnicas de mejora de proceso probablemente nos ayuden mucho más que una retrospectiva en que tratemos de evaluar como nos sentimos (enojado, triste, contento) cuando se cayó el servicio y nos llamó el cliente para decir que no cumplíamos con el SLA.

Ahora la pregunta del millón, si quiero innovar, ¿me alcanza con el método científico?

Estas tensiones aparecen incluso dentro de la comunidad ágil.

¿Hay diferencias culturales?

No sé suficiente de CMMI como para asegurar que las diferencias observables en cultura son una consecuencia inevitable o, si por el contrario, es sólo un resabio indeseable de formas superadas de implementar el modelo.

Lo que si tenemos que tener en cuenta es que esa diferencia cultural suele estar presente y debemos considerarla. No sé si pueden convivir dos culturas tan diferentes en una organización. Me parece que lo más probable es que una de ellas prevalezca, absorbiendo o desplazando a la otra.

En cualquier caso creo que en el intercambio ambas culturas pueden salir enriquecidas.

Aprendiendo Lean Manufacturing con un juego

En la materia Adm. y Control de Proyectos II vemos el modelo de organización por procesos y también técnicas de desarrollo ágil, como Scrum y Lean Software Development.

Estamos siempre buscando mejores maneras de aprender estos temas.

Este cuatrimestre decidimos probar con Mr. Happy Face, uno de los juegos propuestos en Tasty Cupcakes. Es un lindo lugar para buscar ideas.

 

El resultado, como siempre que hacemos juegos, fue tener una clase muy entretenida, con todos los participantes prestando mucha atención. El resultado fue muy bueno, se pudieron comentar los principios Lean y algunos conceptos como JIT, Pull y Kanban desde la experiencia.

Ricardo Colusso se tomó el trabajo de filmar partes de las actividades. Gracias!

En la primera parte se trabaja con una linea de montaje "tradicional", tratando de predecir las ventas. En la segunda parte se usa pull, produciendo sólo lo vendido, y usando kanban para comunicar las necesidades de partes a lo largo de la linea.

Finalizando una stand-up meeting

Fowler tiene un buen artículo sobre las stand-up meeting (o daily scrum). Una de las cosas que recomienda es que se marque el final de la reunión claramente .

El hecho de marcar claramente el final:

• Facilita que la reunión se mantenga acotada: hay personas con fobia al vacío, y que tienen tendencia  a llenar el vacío con palabras. Ante los segundos de silencio antes de ir a nuestros lugares de trabajo, estas personas encuentra siempre un tema más que es necesario resolver ahora. 
  
• Mantiene la energía: el equipo reunido genera mucha energía, al separarnos, parte de esta energía se pierde. Marcando el final, transferimos esa energía, esa urgencia de hacer, a la próxima tarea que encaramos.
• Nos une. Los pequeños rituales ayudan a identificarnos como equipo.

En un equipo en el que estuve marcabamos el fin de la Stand-up Meeting con 3 aplausos sincronizados. Un compañero de equipo de esos tiempos (Pablo Molinelli) hace poco me recordó esta práctica y me preguntó de donde salía.

Viene de la cultura japonesa y es usada en los círculos de calidad. 

Estoy hablando del Tejime, la práctica de finalizar una reunión con golpes de palma con una secuencia particular.

La forma tradicional pueden aprenderla en este video, aunque nosotros usábamos una forma ligeramente distinta:

1. Cuando el último había hablado (las 3 preguntas), alguno preguntaba "Estamos?" o "Listo?" , poniendo las dos manos listas como para aplaudir.
2. Si no había respuesta rápida, dabamos 3 golpes de palma, y con eso terminaba la reunión.

Viendo ahora la forma tradicional, incorporaria el "Yooo...", ya que teníamos problemas sincronizandonos. 

Además, podría extenderse a otras reuniones, pero al no ser algo entendido culturalmente, hay que manejarlo con cuidado. En nuestro caso dio para malos entendidos y se extendió en forma extraña a otras partes de la organización, pero eso es para otra historia!

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

Inscribite en Agile Open Buenos Aires 2009!

¡Ya podés inscribirse en Agile Open Buenos Aires 2009!

Y porque querrías hacerlo, te preguntarás.

• Porque nos juntaremos 100 personas con muchas ganas de implementar metodologías ágiles en nuestros trabajos
  
• Porque tu participación será activa, con el formato Open Space (ver abajo)
  
• Porque lo organizamos de manera que te permita asistir sin depender de otros (gratuito, fuera de horario laboral, lugar de fácil acceso)

Cuando: marzo 6 (18:30 a 21hs) y 7 (9 a 18hs)

Dónde: Centro Cultural Borges (Viamonte y San Martín)

Costo: gratis (excepto quizás la comida, depende de los sponsors que consigamos).

Más información en http://www.agiles.org/agile-open-buenos-aires-2009

 

Formato Agile Open / Open Space

Esta forma de organización de eventos permite con relativamente poca preparación previa realizar eventos de alta calidad en forma auto-organizada. Funciona para reuniones desde 5 personas hasta reuniones de varios miles de personas.

Es particularmente apto para encuentros en los que se discuten temas que son relevantes, complejos y que los asistentes tienen interés y pasión por tratar.

La pasión y el interés se logra por un proceso de autoselección ya que una vez definido el Tema de la conferencia, los asistentes a los que les interesa el tema se anotarán, y al ser en un día no laboral, no dependen tanto del interés de las empresas en las que trabajan como en su deseo personal de participar. A su vez, los temas a tratar en cada sesión son propuestos y votados por los asistentes.

Ver ejemplos y más información

   http://www.agileopen.net / http://agileopencalifornia.com / http://www.agileopennorthwest.com

   http://www.openspaceworld.org/

 

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!

Agiles 2008. Done!

Ágiles 2008 pasó.... y creo que dejó mucho.

Ya sabemos que es posible (v1) y al menos algunas incógnitas y riesgo fueron resueltas.
Al menos tenemos un punto de datos.

En otro lugar agradeceremos con más detalle, pero va mi agradecimiento especial, entre los speakers, sponsors y otras yerbas, a los que confiaron en nosotros cuando no eramos más que un par de tipos con ideas locas, asegurando que representaban a un grupo de 10-20 personas que iban a organizar un evento que no se sabía dónde era, ni quién vendría a dar charlas, ni quien asistiría (para los nostalgicos). Empresas como Intel, Sabre y Three Melons, speakers como Tobias Mayer y Matt Gelbwaks, organizaciones como SADIO.
También un agradecimiento a Epidata, SABRE y Microsoft, que nos ayudaron quitandonos parte del problema organizativo: diseño, pasajes, libros.

Ya tenemos algunos post, y seguro va a dar para mucho más:
http://blog.salias.com.ar/2008/10/agiles-2008-la-emocin-de-que-las-cosas.html
http://carlosgranitto.blogspot.com/
http://agilethinking.net/blog/2008/10/23/getting-trashed-by-the-lean-machine/