Scrum es un framework, no una metodología

photo_2016-11-01_14-18-28

Se dice que Scrum es un Framework [1].
Framework
es una palabra anglosajona que significa armazón, estructura o cimientos.

Lógica mediante: A entonces B. B entonces C. A entonces C…

Si queremos definir una metodología de trabajo para nuestro equipo, Scrum funciona como armazón de la misma. Si bien Scrum nos brinda ciertos elementos que ayudan a navegar la complejidad accidental de nuestros proyectos [2], nos deja en el umbral de la incertidumbre sobre el cómo llenar ese armazón. Es necesario complementarlo, está incompleto por diseño.

photo_2016-11-01_14-18-26 [1] “Scrum is a framework for developing and sustaining complex products.” http://scrumguides.org/

[2] https://es.wikipedia.org/wiki/Accidental_complexity


Artículo escrito en pares por Pablo Tortorella y Camilo Velásquez

Anuncios

Referencias acerca de Kanban

Los tableros visuales “kanban” son una de las técnicas que más fácilmente potencian a los equipos. Estos tableros dieron nacimiento al método Kanban, muy difundido y reconocido en el mundo de las ahora famosas “Metodologías Ágiles”.

Decimos que potencian fácilmente a los equipos porque su adopción inicial no requiere grandes cambios en la dinámica de trabajo… aunque las consecuencias de su utilización a consciencia, podrían (y deberían) traer aparejados, una buena cantidad de observaciones, reflexiones y mejoras (léase cambios e impactos) en el equipo y en cada persona involucrada.

Se trata de un método basado en la visualización del flujo de trabajo y la búsqueda de su mejora continua siguiendo ciertas prácticas y principios que están muy bien resumidos en este video de nuestros amigos de Fuerza Tres:

Quienes estén interesados en conocer más acerca de Kanban, encontrarán valiosos conocimientos en estos libros que recomendamos:

Dos libros disponibles gratuitamente online:

El libro original, pago, muy claro y también traducido al español:

  • Kanban por  David J. Anderson

Adicionalmente, Kanban se complementa muy bien con Value Stream Mapping, sobre el cual escribimos juntos* un breve capítulo en el libro Herramientas Ágiles; y está muy relacionado con Lean y sus 7 principios.

¡Los invitamos a que compartan en los comentarios de este artículo, otras referencias que encuentren de utilidad relacionadas con Kanban!

* Escrito en pares por Pablo Tortorella y Pablo Lischinsky, Agile Coaches de Kleer.

Ágil para lo que le conviene, o cómo gestionar riesgos colaborativamente

construyendo-juntosMi cliente dice que quiere trabajar ágilmente, pero me pide una fecha y un presupuesto para el proyecto.

Mi proveedor lleva ya 10 semanas trabajando y todavía no terminó la versión inicial del producto, la cual dijo que nos entregaría de forma temprana.

Este es un artículo sobre las relaciones entre proveedores y clientes, las cuales en general están enmarcadas en contratos, los cuales pueden determinar el tipo de relación que tendrán durante el proyecto.

Todo es muy lindo cuando se leen o escuchan los valores y los principios ágiles, pero “en la realidad” la poesía se vuelve algo dramática, si no tenemos en cuenta algunos temas.

Los escenarios, desde los puntos de vista del proveedor y del cliente

El riesgo más habitual del lado del proveedor:
Todos los proveedores conocen y mitigan, sí o sí, un riesgo: “El proyecto que están presupuestando no será rentable“. Nadie quiere trabajar para perder dinero. Entonces, a la estimación, se le suele agregar un colchón, también llamado buffer. Es decir que, casi siempre, se “infla” el precio y el tiempo del proyecto. Y lamentablemente, ese tiempo suele consumirse como parte del proyecto. Todos saben que existe ese colchón, aunque no se explicite en cada oportunidad.

El riesgo más habitual del lado del cliente:
Todos los clientes conocen y mitigan, sí o sí, un riesgo: “El proyecto terminará y no tendremos lo que queríamos”. Nadie quiere empezar un proyecto sabiendo que no resolverá los problemas que tenemos. Entonces, a la hora de iniciarlo, buscaremos que el proveedor nos asegure cuánto nos costará y cuánto tiempo tardará en hacer el trabajo pre-fijado. Es decir que se buscan fijar todas las variables: Costo, Tiempo y Alcance. Y lamentablemente, esas variables no son fijas y suelen alterarse… todas o casi todas.

Algunos mecanismos para co-crear relaciones colaborativas, desde los contratos colaborativos

Si queremos llevar adelante un proyecto exitosamente, debemos pensarlo bien desde el momento en el que acordamos los términos contractuales. Un contrato colaborativo (también llamado “contrato ágil”) establece reglas no nocivas y provee a las dos partes mecanismos de trabajo y de resolución de conflictos.

Si ya sabemos que hay riesgos que nos quitan el sueño (los mencionados u otros que sean más específicos en situaciones particulares), una estrategia que nos permite colaborar durante el proyecto, es explicitarlos al inicio del proyecto para poder pensar de forma conjunta un plan de mitigación.

Que todo el equipo del proyecto conozca bien al cliente, al negocio y a la tecnología puede ayudarnos a mitigar el riesgo de no terminar a tiempo. Que el equipo se conozca trabajando antes del proyecto que arrancaremos, también nos puede ayudar en esa misión. Esto se puede plantear como una parte del proyecto y algunas de las mencionadas, pueden colocarse como actividades a llevar adelante al inicio del proyecto, incluso se pueden colocar en el mismísimo contrato.

Visualizar tanto el trabajo realizado como el que queda pendiente, en cada día y en cada semana del proyecto, puede ayudarnos a mitigar el riesgo de no resolver el problema: nos permitirá ajustar el alcance a tiempo y prever cambios de calendario y presupuestos de forma oportuna. También los anteriores mecanismos que involucran al equipo de trabajo pueden ayudarnos a mitigar este riesgo potencial.

Otra forma es que un experto del negocio esté disponible un ratito de cada día y algunas horas de cada semana, para que pueda re-priorizar dinámicamente las características de la solución. Este requerimiento de disonibilidad se puede colocar en el contrato. No queremos que el problema se quede sin resolver, entonces lo atacaremos a partir de su raíz, aplicando el Principio de Pareto (siempre estar atentos, para identificar cuál es el 20% del trabajo que resolverá el 80% de mi problema).

Algo que ocurre mucho en proyectos pseudo-ágiles, es que los equipos realizan un trabajo que no puede ser validado por el cliente ni el usuario sino hasta muy tarde en el proyecto. Esto hace que la retroalimentación, también llamada feedback, llegue demasiado tarde y el re-trabajo sea muy costoso. Con la anterior cláusula, se mitiga este problema y se aprovecha mejor cada día y cada semana de trabajo del equipo.

La clave es que no hay una sola clave, sigamos aprendiendo juntos

Así como estas recomendaciones, existen muchas otras, las cuales se pueden expresar de forma explícita en el contrato que rige el comportamiento de los proveedores y los clientes durante los proyectos que los unen.

Espero que este artículo pueda serle útil a la comunidad y a la industria, y también espero que compartan conmigo otras técnicas que les hayan sido útiles y qué cláusulas han agregado en sus contratos para lograr relaciones de confianza y proyectos exitosos.


¡Aguardo sus comentarios!

Si te interesó este artículo, también podés leer un artículo relacionado, que escribió Ricardo Colusso, al respecto de tipos de contratos.

PaTo RiCo y sus preguntas para problemas complejos

PaTo RiCo, una técnica para comprender problemas complejos durante preventas, análisis de requerimientos y sesiones de coaching y consultoría.

PaTo RiCo es una técnica que se basa en la frase “how you sell is how you solve” (así como vendes es como trabajas) y se viene utilizando tanto en procesos de preventa consultiva así como en el análisis y entendimiento de problemáticas organizacionales complejas.

Su nombre viene de los nombres de sus creadores: Pablo Tortorella y Ricardo Colusso.

Consiste en llevar adelante una conversación (o varias, de ser necesario) recorriendo diversas aristas de un problema u oportunidad: desde el contexto, pasando por las evidencias que permiten constatar que se trata del problema que se cree, hasta el entendimiento cabal del impacto, tanto de la situación actual -si se mantuviera- como del escenario con el problema ya resuelto o en vías de resolverse.

Un diferencial de esta técnica, simple y poderoso, es preguntar por las acciones que ya se hayan llevado adelante -anteriormente- para la resolución del problema.

Casi siempre se acompaña a la conversación con un tablero para ir dejando documentado de forma dinámica y en vivo, las diversas partes de la problemática en cuestión.

Los tableros con los que se puede llevar adelante la técnica son variados dependiendo de los tiempos y las características de la sesión de trabajo.

image

También puede complementarse con varias técnicas y frameworks más difundidos, como la japonesa “Nemawashi”, muy útil para lograr acuerdos de forma efectiva, Pairing (trabajo en pares), Remoto+Local (cuando la sesión es distribuida), “traigan al del problema” y Cynefin, entre otras.

En próximos artículos publicaré más detalles sobre PaTo RiCo!

Hackathon ágil y solidario (invitación y recursos interesantes!)

El martes 24 de junio de 2014 facilitaremos Juan Gabardini y yo, ambos de Kleer, un Hackathon Ágil en la sede de Yatay 240 del Instituto de Tecnología ORT (Buenos Aires, Argentina).

La inscripción está abierta y la participación es gratuita, con cupos limitados!
http://www.ort.edu.ar/hackathon/

El objetivo principal es trabajar en equipos para desarrollar aplicaciones (web y/o mobile) que den soporte a dos organizaciones no gubernamentales: Proyecto Nahual y Tiflo Nexos.

Tiflo Nexos Proyecto Nahual

El evento empezará puntualmente a las 14:30 hs
y terminará a las 23 hs.

Por su duración (~8 horas), esperamos desarrollar productos pequeños e incrementales, que tengan el mayor impacto posible. Para ello, buscaremos resolver necesidades específicas de Nahual y Tiflo Nexos, para lo cual estarán presentes varios representantes de ambas organizaciones.

Todos los desarrollos serán Open Source, con licencias Apache, GPL, LGPL o MIT (¡¡que viva el Software Libre!!).

Serán bienvenidos todos aquellos que quieran colaborar. No es necesario contar con conocimientos técnicos específicos sino mucho entusiasmo y ganas de aprender y ayudar.

Para que se pueda aprender durante el evento, tendremos disponibles varias Estaciones de Auto Aprendizaje, sobre diversos temas técnicos relacionados con prácticas ágiles de desarrollo de software, preparadas por Kleer para la comunidad.

Facilitación del evento y contenidos por parte de Kleer

Facilitación del evento y contenidos por parte de Kleer

… Y hay buenas noticias al respecto! Algunos de esos materiales ya están disponibles en el sitio web del Hackathon: http://www.ort.edu.ar/hackathon/

Sin más preámbulo, los invito a inscribirse y participar del Hackathon (o Hackatón).
Nos vemos el martes 🙂

hackathon-ORT

Mi paso por Girardot – IV Foro de Ingeniería de Software

“¿Qué mejor para cerrar el mes de mayo, que un viaje a Colombia, para visitar la cálida ciudad de Girardot?” – pensé.

Y así fue que la Universidad Piloto de Colombia me invitó como conferencista de la 4ta edición del “Foro Internacional de Ingeniería de Software“, cuyo foco este año lo acaparaban el Emprendimiento y la Innovación Social.

En la puerta de la Universidad Piloto de ColombiaLlegué al aeropuerto internacional Bogotá El Dorado y dos personas de la universidad me esperaban: Leonardo Andrés (del área de Relaciones Internacionales) y Don Víctor (a cargo ni más ni menos de llevarme a la conferencia!).

Luego del viaje llegamos a la sede de la Universidad en la cual, esa misma tardenoche, comenzaría el Foro. Conocí las oficinas administrativas y a muchos de los docentes, administrativos y directivos en una amplia recorrida guiada por Carolina, también de Relaciones Internacionales.

En la apertura del Foro tuve una participación de aproximadamente 10 minutos, luego de que los organizadores dieran las palabras de inicio y que escucháramos las estrofas del Himno Nacional de Colombia. Allí comenté la experiencia comunitaria emprendedora de la creación y el crecimiento de las Comunidades Ágiles de Argentina, Colombia y Latinoamérica; así como también resalté brevemente ciertos aspectos de la informática aplicada a la inclusión social, de la mano de las Redes Libres y del Proyecto Nahual.

Luego de mi charla expusieron varios emprendedores más, tanto de la ciudad de Girardot como de otras ciudades y de Colombia.

Más tarde cené junto a docentes, directivos y organizadores del Foro una deliciosa comida local en un bonito restaurante del centro de la ciudad.

Antes de describir los siguientes días haré una especial mención al alojamiento: en un acto notable de hospitalidad y buen trato, la Universidad Piloto me dio hospedaje en el hotel número uno de Girardot, el Hotel Tocarema. Se trata de un hotel de gran categoría en el cual me brindaron excelente alimentación (desayunos y almuerzos), servicios ( qué piscina!) y alojamiento (muy cómoda habitación!).

Hotel Tocarema de GirardotEl sábado comenzó temprano y terminó tarde:
– por la mañana facilité un taller introductorio de métodos ágiles.
– por la tarde facilité el primer Coding Dojo de la historia de Girardot.
– por la noche participé de un panel junto a otros conferencistas en la Cámara de Comercio de Girardot.

En el Taller matutino realizamos actividades lúdicas y dinámicas en grupo para aprender y conocer en detalle al Manifiesto Ágil y algo de Scrum y Kanban.

2014-05-30 13.16.40 2014-05-30 13.17.12
2014-05-30 13.17.16 2014-05-30 13.17.26
2014-05-30 13.17.33 2014-05-30 13.17.37

En el Dojo de la tarde, la mayoría de los participantes -de casi todos los semestres de la Universidad Piloto y otras instituciones educativas de la región- realizaron por primera vez pruebas unitarias automatizadas. Practicamos TDD (Test Driven Development) y Programación de a Pares (Pair Programming).

2014-05-30 17.12.12 2014-05-30 17.12.48
2014-05-30 17.18.59 2014-05-30 17.19.04

Ya por la noche, el foco de mi charla de 15 minutos lo tuvieron:
– el agilismo y la actividad comunitaria como motores del emprendimiento, y
– los conocimientos informáticos como herramienta de inclusión social.
Compartí el panel con notables expositores colombianos de diversas instituciones (Fundación Todos Podemos Ayudar, HETAH, Universidad del Tolima y la Secretaría de Ciencia y Tecnología de Cundinamarca), y al finalizar todas las charlas recibimos preguntas de los aproximadamente 100 asistentes que había en la colmada sala.

Panel sobre Innovación social y emprendedorismo en la Cámara de Comercio de GirardotEsa noche la cerramos con una reunión de camaradería en la casa de un emprendedor local, con música y buena onda.

Al día siguiente cerró el foro. Cada expositor tuvo 45′ para entrar más en detalle de alguno de los temas de su incumbencia. Yo me adentré en las técnicas que se suelen llevar a cabo al inicio de un proyecto ágil, aplicadas tanto a la construcción de productos como también a otro tipo de proyectos, tales como el dictado de una materia en el marco de la educación.

Al respecto de la agilidad en la educación, esa misma mañana calurosa también tuve el placer de poder compartir -con casi todos los docentes de la institución- algunas herramientas pedagógicas y de organización de clases y materias. Hablamos de Kanban, de “Training from the back of the room”, de Educación Participativa, de Retrospectivas en las aulas, de autoevaluación y de salones con sillas dispuestas en círculo. En esta charla me acompañó mi colega Camilo Velásquez, uno de los jóvenes agilistas más activos de Fusagasugá y Colombia.

2014-05-31 12.04.23Luego del cierre del evento, almorcé en el hotel y disfrutamos del partido amistoso de Colombia contra Senegal, en la preparación del equipo para el Mundial de Fútbol que se acerca, y más tarde fuimos nosotros los que practicamos ese hermoso deporte.

2014-05-31 16.27.17 La jornada terminó con otra cena de camaradería, más numerosa cada día.

2014-06-01 02.07.01

Al día siguiente me despedí de Girardot cuando mi amigo el Ingeniero Wilson Gordillo me llevó hasta Fusagasugá a continuar con mi labor de difundir métodos y prácticas ágiles por el mundo 🙂

Agilizando ando!

Dibujo realizado por @coti_mol

Un especial agradecimiento para Elkin Forero Soto y Wilson Gordillo por haber confiado en mí para este IV Foro Internacional de Ingeniería de Software.

… Y hasta la próxima!

Desarrollo ágil potenciado por prácticas! Láminas sobre TDD, ATDD y CI

Está muy debatido en la comunidad ágil el uso de prácticas y técnicas (como automatización, ejecución periódica de build y pruebas), como complemento necesario de las metodologías como Scrum y Kanban.

Existen ciertas técnicas que solemos difundir en charlas, eventos, cursos y publicaciones, que entran dentro de esta categoría. Se trata de TDD (Test Driven Development), ATDD (Acceptance Test Driven Development) y CI (Continuous Integration).

He aquí tres láminas que hicimos junto a Ángela Castaño Restrepo, del equipo de Arquitectura de software de Sura, una de cada uno de estos temas. Las realizamos en el marco de un curso de “Desarrollo ágil de Software”, en Medellín. La facilitación gráfica y la práctica concreta nos ayudan en estas capacitaciones para que los participantes entiendan y fijen mejor los conceptos.

TDD – Diseño guiado por pruebas

TDD es una técnica de diseño que implica mucha disciplina y que -cuando se aplica bien- hace ahorrar mucho tiempo y dinero a los equipos de desarrollo. Su principal ventaja es la simplicidad.

TDD y su ciclo "RGR" (Red, Green, Refactor)

TDD y su ciclo “RGR” (Red, Green, Refactor)

ATDD – Diseño guiado por pruebas de aceptación

ATDD es una técnica de diseño que involucra de forma temprana a usuarios, testers y demás interesados en el producto, que permite definir escenarios que guiarán el diseño y el desarrollo de dicho producto.

ATDD y su ciclo anidado RGR para Vista y Controlador, junto con TDD para el Modelo (contexto: arquitectura MVC).

ATDD y su ciclo anidado RGR para Vista y Controlador, junto con TDD para el Modelo (contexto: arquitectura MVC).

CI – Continuous Integration

CI significa “Integración Continua” en español. Es un concepto compuesto por prácticas, herramientas y actitudes, a saber: un repositorio compartido de código, políticas de utilización de dicho repositorio, un servidor de integración continua, y en los mejores casos, tambien pruebas automatizadas y algunos otros procesos automatizados, trabajo en equipo y colaboración frente a conflictos).

No subir al repositorio compartido el código si no funciona las pruebas tanto de mi código como del código ajeno integrado. CI es un concepto que hace referencia a la integración del equipo, apoyada en herramientas y prácticas.

No subir al repositorio compartido el código si no funciona las pruebas tanto de mi código como del código ajeno integrado.
CI es un concepto que hace referencia a la integración del equipo, apoyada en herramientas y prácticas.

Cada uno de estos conceptos amerita mucho más material y práctica para poder ser bien aprovechado, por lo cual posiblemente dedique más artículos al respecto más adelante.

Espero les sean de utilidad las láminas!

Sura y Kleer, colaborando con la agilización del ecosistema paisa y colombiano!

Sura y Kleer, colaborando con la agilización del ecosistema paisa y colombiano!