CAS 2016

Resumen de la CAS 2016 (día 1 de 2)


El pasado jueves y viernes 1 y 2 tuve la gran suerte de poder asistir a la Conferencia Agile Spain, la CAS 2016 que cada año se celebra por estas fechas. En ella se reúnen agilistas de todo el país para compartir conclusiones en multitud de charlas, workshops, etc. Este año a diferencia de los anteriores no había una temática central ni unos tracks definidos. Por ello se pudo ver más variedad en los contenidos.

A continuación, te comparto algunas de las ideas que me llevé del evento.

Challenging Agile

La primera keynote a cargo de Chris Matts, fue un duro golpe inicial de realismo. Lo primero que hizo fue mostrar el grado de adopción de los principios agile en los distintos ámbitos de la organización y las herramientas disponibles para trabajarlos en cada área. Viendo el panorama, me di cuenta de dos cosas. La primera que soy un completo ignorante, ya que habló de herramientas que no tenía ni idea de que existían. La segunda es que se venden soluciones enlatadas sobre escalado de agile cuandp todavía no sabemos si aplican a todos los contextos.

Habían muchísimas ideas y propuestas valiosísimas en la presentación de Chris, y hacer un resumen de la charla daría para varios posts. Por suerte, el propio Chris Matts publicó el pasado sábado un artículo sobre su charla. El él puedes ampliar información sobre la cantidad de perlas que regaló a la audiencia.

CAS 2016 Chris Matts

Aprender a distinguir el problema de las soluciones

En la charla de Carlos Ble, vimos que habían 2 dominios diferenciados, el dominio de las necesidades y el de las solucionesUna necesidad puede tener N soluciones. Cuando elegimos una solución estamos descartando las otras que quizás son más sencillas y se ajustan mejor al problema. Esta es una de las razones por las cuales después nos vienen los cambios de requisitos. Y es que una de las tendencias de los ingenieros es buscar y centrarse en las soluciones. Bien porque nos gustan o bien porque queremos experimentar (Resume Driven Development). También es una tendencia de los Product Owners técnicos el dictar las soluciones en lugar de plantear el problema al equipo de desarrollo.

Una posible herramienta es el test de la hoja de cálculo: si el problema se puede solucionar con una hoja de cálculo quizás no merezca la pena hacerlo con un software a medida.

Contra todo esto nos sugirió la técnica del “Patadón p’alante”, que no es más que mantener las opciones abiertas hasta el último momento responsable, lo que nos da más tiempo para validar nuestras hipótesis. No hay que confundirlo con el patadón de arquitectura o la deuda técnica. Los requisitos conocidos (multilenguaje, seguridad, rendimiento…) se deben implementar con calidad desde el inicio.

Algo que también quedó claro es que si queremos encontrar una buena solución debemos experimentar el problema como lo hace el cliente, debemos dominar y entender muy bien el problema de negocio para plantear una buena solución técnica que lo resuelva.

Patterns in Scrum beyond software

Con Xavi Quesada y Joke Vandemaele vimos una aplicación un tanto extraña de un método agile para contextos en los que las fechas son restricciones fuertes imposibles de obviar. Ejemplos de estos contextos son un departamento de administración o la organización de un evento como la CAS.

Xavi y Joke utilizaron facilitación gráfica para describir un panel de matriz con 2 dimensiones, proyectos y sprints. Este panel sirve para hacer seguimiento de los elementos de más alto nivel (proyectos, objetivos…). Describió un segundo panel Kanban con los días de la semana más las columnas “en progreso” y “hecho” para las tareas de más bajo nivel o las tareas repetitivas y recurrentes.

CAS 2016 Xavi Quesada y Joke Vandemaele

Quedó claro que el objetivo no es predecir fechas como en waterfall sino no olvidar nada importante y controlar las fechas objetivas de manera visual. También clarificaron que en todos los paneles cualquier elemento debería aportar valor. Es decir, el objetivo tampoco es la microgestión de tareas sin valor.

La priorización de los elementos en los backlog se realiza en la mayoría de casos mediante acuerdos de trabajo, es decir, definiendo de antemano que cosas aportan más valor en el contexto en el que estamos. De esta forma es posible no tener Product Owner en contextos de este tipo.

Puedes ver la charla completa en el siguiente video.

Patterns in Scrum beyond software

Summary of the patterns and challenges we have found in two years of experimenting with the application of Scrum, Kanban and Visual Management outside of the software product development domain. We will cover case studies in automotive continuous improvement teams, factory maintenance, and general administrative work.

Alineando valores y principios con prácticas técnicas

La siguiente charla fue a cargo de la gente de Alea Soluciones, Rubén Eguiluz, Isidro López y Alberto Pérez. En ella describieron el escenario del equipo de Alea, en el que valores Scrum como el respeto y la transparencia se vivían en las diferentes prácticas en el día a día. Hablaron de que gracias a la comunicación constante con el equipo de operaciones se podían permitir hacer despliegue continuo y que mantienen sesiones de trabajo mensuales con el CEO para resolver dudas en ambas direcciones.

También se sinceraron y explicaron un caso reciente de pérdida de confianza por algunos errores, y de cómo estos valores les permiten continuar haciendo su trabajo para recuperar esta confianza con resultados.

Una frase inspiradora que compartieron en su presentación: “Si quieres ir rápido camina solo, si quieres llegar lejos ve acompañado”.

Tu código es una mierda (Comunicación en el desarrollo de software)

Posteriormente fui a la charla de Xabier Saez, donde se trató el tema de la comunicación. Se planteó como una reflexión sobre la importancia de la comunicación a todos los niveles.

En el nivel más bajo, el código, necesitamos cuidar la información, teniendo en cuenta que un desarrollador pasa aproximadamente un 60% de su tiempo codificando. Prácticas como TDD ayudan a esto, muy por encima de la documentación. También me quedé con la expresión “hacer un Mariano Rajoy”, por no entender tu propio código.

CAS 2016 Xabier Saez

A nivel más de comunicación directa entre personas, se habló de la inteligencia emocional y de la comunicación no violenta. Ésta última nos permite comunicarnos desde los sentimientos para maximizar la conexión y empatía con la otra persona. De toda la charla me quedo con la cantidad de etapas que intervienen y así la cantidad de elementos que pueden fallar en la comunicación:

  1. Mi contexto: Totalmente personal.
  2. Codificación del mensaje: Fallo por una mala elección del lenguaje, símbolos.
  3. Emisión: Fallo porque el medio está colapsado o hay mucho ruido.
  4. Recepción: Fallo por una mala concentración y atención a la hora de recibir el mensaje.
  5. Decodificación: Nuevamente si no compartimos símbolos o no los interpretamos de la misma forma.
  6. Su contexto: La interpretación según su contexto personal.

Ya puedes ver la charla completa en el siguiente video.

Tu código es una mierda

Tu código es una mierda (Comunicación en el desarrollo de software) Cuando empecé a desarrollar software siempre decía que lo que menos me gustaba de mi trabajo era que “es poco social”. Ahora no puedo estar menos de acuerdo.

El arte del patadon pa’lante / posponer decisiones

La penúltima charla del jueves fue la de Eduardo Ferro.  En la charla Eduardo explicó qué opciones existían a nivel técnico a la hora de posponer decisiones hasta el último momento responsable. Fue una extensión de la charla de la mañana con Carlos Ble. Los motivos fundamentales son un aporte de valor mayor al tener más información sobre el problema a resolver. También una solución más sencilla y por tanto más barata en todos los aspectos. Para ello es fundamental ser parte del negocio, y entender el problema antes de plantear soluciones.

Las soluciones deben ser sencillas y comprometernos a poco (reversibles). Además, aplicar los principios de diseño y arquitectura con cabeza (por ejemplo, racionalizar el concepto de DRY). Me quedo con la cita de Uncle Bob “Buena arquitectura es aquella que nos permite posponer decisiones”.

El mismo Eduardo ha dejado en su blog un artículo sobre su charla, así que para más información visita su blog.

El backlog del equipo de transformación

El primer día de CAS acabé en la charla de Gerardo Ponte. Me gustó mucho la sinceridad y la transparencia a la hora de mostrar todos los experimentos que habían probado y que fallaron. Por ejemplo la liga de incidencias, en la que los equipos participaban en una competición virtual donde la mejor clasificación la obtenía el equipo que menos bugs generaba.

Habló también de la idea de aplicar la dinámica del inception deck para la creación del equipo de transformación agile (no para el producto). De esta forma es posible arrancar con un backlog consensuado desde el primer momento.

En el siguiente post explicaré las charlas que pude disfrutar el segundo día de la CAS. ¡No te lo pierdas!

También te puede interesar...

Cómo definir criterios de aceptación Los criterios de aceptación nos permiten definir una historia de usuario en un producto agile. Pero aprender a escribir buenas historias de usuario y ...
Cómo iniciar tu primera comunidad de práctica (II)... En el artículo anterior definimos las comunidades de práctica como un espacio abierto en el que cualquiera puede aportar y participar. En un entorno c...
Crea ya tu lista de impedimentos en Scrum El rol del Scrum Master incluye eliminar impedimentos, pero ¿qué son los impedimentos en Scrum concretamente?¿Qué debe hacer el Scrum Master?¿cuáles d...

Dejar un comentario

Tu dirección de correo electrónico no será publicada. Los campos necesarios están marcados *

4 ideas sobre “Resumen de la CAS 2016 (día 1 de 2)