Decisiones: ¿Tecnológicas o Estratégicas?

the garden of forking paths

Estamos actualmente en el desarrollo en un momento que yo comparo a veces con la adolescencia. No sabemos qué somos, ni a qué queremos dedicarnos.

Solo importa la tecnología.

La vorágine de frameworks que está asolando el panorama del Frontend actual es para plantearse si las decisiones de cambio de lenguaje a lo último de lo último, ¿son como  resultado de una buena pensada de pros y contras, o más bien porque sabemos alzar la voz por encima de todos los demás?

Parece que lo que buscamos es que nos dejen elegir la tecnología en la que queramos trabajar sin tener que justificarnos, sin tener que compartir nuestra decisión, …

Entonces sufre el equipo, el compañerismo, preocuparse por el otro, aprender juntos, enseñar, mentorizar, …

Estamos de acuerdo que la tecnología es un medio… ahora bien, ¿al servicio de un fin para qué o para quién? Porque puede ser que sea sólo al servicio de uno mismo.

¿No debería estar al servicio de la estrategia que queremos como empresa? O por lo menos al servicio de lo que queremos como equipo.

Debería estar alineada con la estrategia de la empresa.

Creo que nunca debería estar al servicio personal, sería como disparar con la pólvora del Rey.

En un proyecto que acabamos de empezar, la elección del framework fue Angular 1.5. Más popular y quizás menos moderno (aka “tiene más de seis meses”) que otros en el mercado. Lo inesperado fue que ha provocado estos efectos muy positivos:

  1. Fue una decisión tomada por la Comunidad de Práctica de JS interna de la empresa con el refuerzo consiguiente para todos.
  2. Angular 1.5 a pesar de ser antiguo tiene una orientación a componentes muy moderna, por lo que no hubo nada de rechazo.
  3. Al ser un framework popular , tiene muy buena documentación y ha permitido que compañeros de back se vean con ganas de hacerse un tutorial “por si hay que echar una mano algún día”. Algo impensable.
  4. Al haber mucha experiencia previa en proyectos, se han podido establecer nuevas relaciones de mentoring entre compañeros con diferentes niveles de conocimiento.

Creo que está siendo una gran decisión y nos está haciendo madurar como empresa y como equipo.

¿Te has encontrado con estos problemas alguna vez?
¿Cómo decidís la tecnología de vuestros proyectos?

Photo by Craig Cloutier

 

Anuncios
Etiquetado , ,

¿Cómo se ve la comunidad de Madriagil a sí misma?

Reflexión Madriagil

¿Por qué venimos a los eventos de Madriagil?

 

Esta foto es el resultado de un ejercicio que hicimos buscando el por qué venimos a los eventos y por qué creemos que vienen los demás. Fue en el  Madriagil: Inicio de temporada + Dojo de CNV, celebrado el pasado 8 de octubre de 2015,

Al final sacamos esta Lista ordenada de razones por las que asistimos a los eventos de Madriagil:

  1. Compartir
  2. Formación gratis
  3. Experiencias
  4. Ver a la gente
  5. Aprender
  6. El tema es importante para asistir
  7. Vivir mejor (aprender a)
  8. Uniqueness (Ocasiones únicas, como visitas de algún miembro de otra comunidad)
  9. Energía (recargar)
  10. La idea feliz
  11. Incluir a más gente
  12. Persona (Ponente) conocida
  13. Promocionar mi curso

 

¿Qué te parece? ¿La compartes?

Mi opinión

En mi opinión esta lista es bastante genérica y no refleja ni la conversación que tuvimos allí, ni la sensación que tengo de la actividad que tiene Madriagil como tal.
Lo primero no creo que cumplamos las condiciones para definirnos como Comunidad. Quizás tenemos intereses y valores comunes, pero nos falta algo más importante como la identidad o el sentido de pertenencia.

Y a continuación en modo lista los problemas que veo:

  • No creo que seamos un grupo equilibrado.
  • Muy pocos son los que proponen temas para hacer las reuniones.
  • La acogida de cada charla y la atención que genera es muy irregular, dependiendo en gran medida de cada una de las razones expuestas más arriba.
  • La asistencia final respecto a la confirmación suele ser del 50-60%.
  • El nivel de los asistentes es irregular, puede haber gente con mucha experiencia y con poca.

Analizando un poco más un par de temas…

Cómo se convocan las reuniones.

Las últimas convocatorias han sido siempre fruto de una iniciativa individual. Aunque es genial, que la primera noticia de un evento llegue por un correo de la plataforma meetup,  nos resta identidad.

La asistencia es del 50-60%

JMBeas señaló el año pasado de la falta de compromiso de las personas que no iban a los eventos de meetup tras confirmar asistencia. Se habló bastante sobre el tema e incluso como respuesta, Bonilla le dedicó la Bonilista de esa semana: “Una silla vacía”.
Creo que el fondo de la cuestión, es que el compromiso con el evento hay que construirlo, y es el resultado de construir una comunidad, con una identidad, formada por un conjunto de personas que se conocen. Si no tenemos esa comunidad, no nos extrañe que el nivel de compromiso de un “Me apunto” en una página de un Meetup sea bajo.

El nivel de los asistentes.

Obviamente no vamos a hacer una comunidad exclusiva para novatos o para expertos. Tiene que haber de todo. Lo que creo que está pasando es que no lo estamos gestionando adecuadamente. Uno de los signos más obvios es que de las personas que yo considero ‘experimentadas’ de la comunidad es MUY raro que coincidan más de dos en un mismo evento.
¿Por qué no vienen? Para mi está claro. La ratio beneficio/esfuerzo resultado de asistir a estas reuniones en muchas ocasiones no está clara y en otras muchas es inferior a uno. Ni siquiera sirve como networking, pues la falta de relación personal entre las personas que van últimamente no dan ni para una caña después del evento.

Y sorprendentemente…

el número de personas que asisten por primera vez a un evento de Madriagil es muy alto en cada ocasión. A ojo quizás sea del 20-25%. ¿Qué hacemos con estas personas? ¿Les damos una calurosa bienvenida a la comunidad? #nope

 

¿Qué podemos hacer?

Algunas ideas

Convocatorias

Sería bueno realizar un par de mejoras a esta manera de reunirnos. Primero fijar una frecuencia para hacer las reuniones y segundo mandar un correo a la lista previo, buscando una pequeña tormenta de ideas. Igual que hace MadridGUG.

Nivel de los asistentes

Crear eventos específicos más horizontales, donde el nivel y motivo de las sesiones sea más claro.
Aquí cabe la idea de ampliar la idea de Comunidad de Práctica que propusimos a unos cuantos Juanma y yo viniendo del AOS de Asturias. Esto se va a hacer en febrero, pendiente de fecha.

Construir más comunidad

Sinceramente, ni idea cómo hacer esto. Imagino que es un resultado de todo lo anterior.m

 

A partir de aquí igual todo es importante y no hago más que relacionarlo con el tema abierto en Agile Spain, relativo a que todavía no ha salido nadie para organizar la siguiente CAS.

O no lo es en absoluto, y solo hay que respirar, ser más indulgentes con nosotros mismos y seguir adelante preocupándonos únicamente de conectar con aquellos que realmente nos aportan energía.

Un abrazo a todos y ¡Feliz Año 2016!

Etiquetado , , ,

Mi primer Agile Taste y el Sushi Kanban

IMG_20151127_210207

¡Gracias por la invitación!

Así empezó mi participación en mi primer Agile Taste, con la invitación de un buen amigo, Diego Rojas de Thinking With You.

Para que este comentario sea valioso voy a intentar ser breve e ir a lo que más me llamó la atención. (da igual, espero lo disfrutéis) 🙂

La bienvenida

Nos recibieron Diego Rojas y Pepe Vazquez con un cafetín para calentar, mientras íbamos conociendo a los integrantes del taller y nos familiarizamos con el entorno. El lugar era Sueños de Cocina, una escuela que parecía con un buen espacio para hacer la actividad.

De paso nos presentan al cocinero y responsable del local: Nacho Garbayo. Será nuestro maestro y como veremos luego nuestro chef y jefe del restaurante.

El taller que dimos estaba basado en éste, aunque más corto y adaptado para solo cuatro horas largas.

Introducción

Lo primero nos dan una pequeña charla sobre en qué va a consistir el curso y luego pasamos a que Nacho, el cocinero, nos enseñe cómo preparar las variedades de sushi que vamos a tener que realizar durante la tarde.

La dinámica consiste en ser el equipo de cocina de un restaurante japonés y tenemos que satisfacer a nuestros insaciables clientes, Pepe y Diego, y con la vigilancia muy de cerca de Nacho, el jefe de cocina, que cuidaba que sobre todo las medidas de higiene y contra la contaminación de alimentos se cumplían.

Comienzan las hostilidades, primera iteración.

Nos dividen por equipos, en nuestro caso dos de cinco personas, nos dan solo cinco minutos para organizarnos y a continuación tenemos que preparar en veinte minutos todo un repertorio de comandas que van a ir pidiendo prácticamente sin parar nuestros dos hambrientos clientes.

En esta primera iteración no hay kanban, autoorganización directa.

A mi me tocó ser camarero y responsable del flujo de trabajo y fue una auténtica locura, me tuvieron para arriba y para abajo todo el tiempo. Fue bastante agotador y casi no tuve capacidad de comprobar nada del flujo. Así y todo salvamos muy bien el tipo, siendo, según nos contaron luego, el equipo que más producto había sacado nunca en su primera intentona. La organización previa había salido muy bien.

Segunda iteración, kanban style.

Hacemos una introducción a kanban y cómo lo podemos aplicar directamente a nuestro trabajo en la cocina.

Tras una pequeña preparación para que se adapte la cocina a nuestro nuevo proceso de trabajo, empezamos. La productividad no fue tan alta, pero la sensación de calidad, desahogo y capacidad para ayudar al compañero y poder optimizar el flujo subió exponencialmente.

Conclusiones

Es un taller con una sensación de mundo real muy bien conseguida. Está muy centrado en el proceso y realmente el cocinar no es importante. Todo el tiempo mi sensación no era de no tener capacidades para cocinar o hacer la tarea encomendada, el problema siempre venía de la coordinación.

La formación muy clara y sencilla, en píldoras de información directamente aplicables.

Sobre la iteración 1, me sentí en todo momento muy agobiado y con una falta de visión de lo que estaba pasando total.

En la iteración 2, como decía antes, sensación de mucha más holgura, de que podía ayudar a mis compañeros, que podía preguntar a los demás, e incluso al cocinero si no entendía el pedido (nos hicieron un pedido que no había explicado Nacho :P).
Y sobre todo, con la ayuda de políticas explícitas, tenía la confianza en mi equipo de parar la cadena entera si lo veía necesario. Como de hecho pasó, cuando estábamos montando un pedido mal y hubo que rehacerlo.

Conseguimos un equilibrio que enseguida vimos que se podía optimizar. Por ejemplo en el puesto de preparar el relleno y colocarlo que podíamos aumentar el WIP limit a 2, metiendo otra persona para trabajar en paralelo.

Hasta entró un pedidos urgente que entró por un carril prioritario y !salió a tiempo!

Finalizando el taller

Para terminar Diego y Pepe se extendieron en los valores de Kanban y aquí hago una selección de los que más relevantes me parecieron para esta dinámica.

Valores

Transparencia – en lo que desconozco
Colaboración
Acuerdo y compromiso
Respeto, refuerzo positivo

Principios

Empieza por donde estás
Entender expectativas del cliente BIEN!!
Cambio incremental y evolutivo
Alentar liderazgo

Prácticas

Feedback
Políticas explícitas
Gestionar el flujo
Limitar el wip
Visualizar el flujo

Cierre

Aquí os dejo unas fotos por si queréis ver cómo fue el taller:
https://goo.gl/photos/xCTekDGwK8KiAnYM9

En definitiva, un taller muy bonito e intenso que recomiendo sin dudarlo.

Etiquetado

Deberíamos darnos la vuelta más a menudo. Primer comentario de la CAS 2015.

CAS teatro

Primer comentario en alto después de la CAS 2015.

Copio aquí el comentario que hice en el post de Carlos Ble: Reflexiones tras una emotiva CAS2015.

Hola Carlos!

Como followup a este tuit.

El pensamiento sobre aprender de todos viene de ésto.

Me imaginaba que todos en la sala podemos identificar a nuestros padres y madres en el agile. Y seguramente estén sentados a escasos metros de nosotros.
Y luego nosotros somos los iniciadores para otros.

Eso hace que parezca que hay diferencias de experiencia y de nivel… y lo digo porque se nota un regustillo a diferentes niveles de ‘profi’ en la aplicación del agile en tu vida durante la conferencia.
Comentarios de que las charlas son básicas, o que luego nos juntamos siempre entre los mismos conocidos, no nos abrimos a gente nueva.

Tendríamos que darnos más la vuelta y volver a hablar con esos ‘padawans’, y tratarlos como iguales y hacer un esfuerzo por aprender también nosotros de ellos. Me sorprendo continuamente los retos a los que se enfrentan cada uno de ellos en su día a día y que dan mil vueltas a lo que yo les pude mostrar alguna vez.

Mi No-charla en la CAS 2015 : Necesidades vs Soluciones: una vista diferente al Crossing the Chasm

Este año presenté un par de charlas[1][2] para la CAS 2015.
El nivel es realmente extraordinario, así que no me extraña demasiado que al final no se aceptase ninguna. La parte buena es que podré ir mucho más relajado.

Presenté charlas más como un ejercicio de colaboración con la comunidad que por un objetivo personal. Este año me lo había tomado como de descanso, después de haber ido como ponente a un montón de sitios en el 2014.

Pero lo que me trae a escribir este post rápido es compartir con vosotros el abstract de la charla que creo es muy interesante, así que me encantaría prepararlo y contarlo en un @madriagil.

Necesidades vs Soluciones: una vista diferente al Crossing the Chasm

En mi entorno existe una gran inquietud tecnológica. Llega a ser un ansia feroz por buscar el siguiente best-framework-ever, por no conformarse con soluciones bien probadas.

El pasado agosto estuve en Sofía asistiendo a la ALE y conocí al genial Chris Matts que hizo la keynote inaugural. Hizo una aproximación al clásico Crossing the Chasm, mapeándolo por encima con otros modelos como el Cynevin, Meme Lifecycle o Real Options.

Fue realmente revelador. ¿Por qué algunos se conforman con una solución suficientemente buena y otros buscan continuamente la excelencia? ¿Por qué las buenas prácticas no son tan buenas? ¿Por qué reinventar continuamente la rueda? ¿Qué motivaciones existen en unos y otros?

En esta charla veremos las diferentes comunidades que tenemos a nuestro alrededor y trataremos de alinear todas estas motivaciones dándoles un objetivo común.

Articulos relacionados de Chris Matts Communities of Need & Community of Solutions y Agile – The Broken Learning Machine

Un pequeño sketch que hice ayer para explicarlo en una sesión que tuvimos en Kaleidos:

needs02

La idea clave que puse ayer es que las Necesidades se mantienen, mientras que las Soluciones cambian con el tiempo.

Aquí salió la pregunta “¿No hay un gran desperdicio de tiempo y esfuerzo en estos experimentos constantes?”

Mi respuesta es conseguir el equilibrio entre “Rentabilidad vs Atraer Talento” , “Aburrimiento vs Investigación”, “Estrategia empresarial vs Motivaciones personales”

Más diferencias, foto de Alexis Monville

needs01

Espero que os resulte tan interesante este tema como lo es para mi.

[1] Tarjeta trello de la CAS2015 para la charla de Necesidades vs Soluciones
[2] Tarjeta trello de la CAS2015 para la charla de Discusiones y Decisiones

Etiquetado ,

El UX nos va a cambiar más de lo que pensamos

UX role like analyst

UX role is like a aka analyst

Escribí estos miedos rápidos cuando llegaron los UX a Kaleidos, me quedó aquí en borrador y todavía están vigente.

Va a venir gente con mucha experiencia a liderar los proyectos.

Vienen a ser analistas. Porque el Analista de toda la vida a ha muerto. Y lo que antes me cachondeaba, ahora me preocupa. No quiero perder como informático el liderato de los proyectos para siempre, ni que se me oxiden mis capacidades analíticas.

¿Qué pintamos los Informáticos, como expertos en información, en la nueva manera de hacer los proyectos?

¿Qué diferencias hay entre un UX y un informático?

¿Apesta mi Curriculum?

Etiquetado

Q: “Me gustaría controlar el avance del sprint con las tareas cerradas”

Taskboard

Post publicado también en el blog de Kaleidos

Entre los usuarios de Taiga y soporte, suelen surgir debates y preguntas muy interesantes sobre cómo usar la herramienta y si encaja o no con la filosofía y objetivos del producto.

Os traigo hoy uno sobre control del avance del sprint:

“La gráfica actual del sprint (Sprint Burndown Chart en Taiga) no nos vale porque solo aparecen los puntos quemados cuando se cierran todas las tareas de una User Story con lo cual durante la primera semana del sprint da la impresión de que no se ha avanzado nada, aunque se vayan cerrando tareas de las diferentes User stories.

Los requerimientos que tenemos del scrum master es trabajar con la filosofía de tarea como medida de lo que hace el equipo y avance real (incluso trabajan con horas)”

Este Scrum Master, sigue el libro. La guía oficial de Scrum en su sección de Sprint Backlog habla de:

Monitoring Sprint Progress

At any point in time in a Sprint, the total work remaining in the Sprint Backlog can be summed. The Development Team tracks this total work remaining at least for every Daily Scrum to project the likelihood of achieving the Sprint Goal. By tracking the remaining work throughout the Sprint, the Development Team can manage its progress.

Un desarrollo más en profundidad muy conocido es como lo cuenta Henrik Kniberg en su libro “Scrum desde las trincheras” (aquí original) y también habla de contabilizar el trabajo pendiente del sprint.

En los dos casos hablan de preguntar al equipo cuánto trabajo cree que les queda pendiente de cada historia, sea en puntos, sea en horas, sumarlo y ver lo que queda.

Lo que es propio de la implementación que hace este equipo, es contabilizar el avance sumando las horas de las tareas que se han terminado.

El avance de las tareas en una historia no te da información real del avance del sprint, porque si somos fieles a Scrum, en la demo solo se pueden mostrar historias terminadas, no ‘casi’ terminadas.
Una gráfica de tareas pendientes en el sprint que muestra que estamos al 90% de sprint terminado, pero realmente solo tenemos 2 de 8 historias terminadas (25%), puede dar una falsa sensación de tranquilidad. Y evita algo muy importante, que es centrarse en terminar historias.

Además de esto, llevar el control por tareas, y además en horas, hace que haya que estimarlas al inicio del sprint con el correspondiente esfuerzo.
Y el problema de calcular el ‘quemado’ del sprint a partir de una estimación inicial, es que no contempla los cambios y problemas que nos vayamos encontrando. Y si la solución es reestimar las tareas si ‘explotan’, solo hace aumentar la burocracia.

Cuando allá por el 2010 intentamos una aproximación fiel contando las horas pendientes en el sprint, enseguida nos dimos cuenta que era una microgestión que aportaba poca información que no nos diera ya el panel. Los bloqueos que puedas tener en una historia se pueden detectar igual en el daily: “Llevas tres días con esta historia de 2 puntos. Hay algún problema?” , es mucho más efectivo.

En mi opinión, si se quiere tener una gráfica de “Sprint Burndown” con más detalle que la actual de Taiga, haría como recomienda la literatura, preguntando al equipo en el daily “¿Cuántas horas calculas que te quedan de tu historia?”. Es mucho más realista y no depende de tareas terminadas. Y con esa información haría una gráfica para colgar en el tablón o en un doc compartido.

Si se quiere automatizar, en la versión liberada esta semana de Taiga, se puede crear un custom field para ir poniendo esa cantidad de horas pendientes en ese campo y se podrá sacar una gráfica de manera fácil.

Tema muy interesante, sin duda. Volveremos sobre el control detallado de los tiempos, internamente llamado “El dilema del Time-Tracking”, en otras preguntas que nos hacen.

Etiquetado , , ,

Carta abierta para mi cumple

me

by @elhombretecla at #kosdem15

¡Hola!

Soy informático. Trabajo en una empresa de desarrollo muy especial, somos todos muy cracks, pero a la vez especialitos. La montamos juntos.
El esfuerzo personal que requiere es muy alto.

Y soy padre, dos hijos. La mayor tres y el pequeño uno. Ya hace tiempo que dejé de pensar que no aprovecho el tiempo cuando estoy en casa. 🙂

Y el 20 de abril cumplo 40 años… y cuando mis padres y mi mujer me preguntan “¿Qué quieres para tu cumple?”, yo les contesto “Tiempo”. — JA, JA, vale en serio, ¿qué quieres?. — En serio. Quiero que me regales tiempo, no necesito otra cosa.

Me encantaría empezar a ver que después de cada día me queda algo en el colador.

Un abrazo,

Antonio

Etiquetado

PiWeek VII. Done!

piweekvii

PiWeek done!

Goals review

Emacs

  • Change from vim to emacs

Grails

  • Learn async capabilities in grails 2.4.4
  • GPars

Javascript

  • Compare with ajax

Seekagift

  • Upgrade Seekagift to grails 2.4.4
  • Integrate all of this in Seekagift
  • Deploy in public

Writing

  • Write post about CAS 2014
  • Write post about Scrum Day Oviedo
  • Investigate about Time Tracking for Taiga
  • Answer Epic topic conversation

In terms of progress and task done, wasn’t very well. Only achieve two of the goals.

Problems:

  • Retake a 2 years old project was not as good idea as I thought.
  • Upgrade to grails 2.4.4 was easy
  • Upgrade facebook login plugin was a little bit hard to integrate with the actual project.
  • Review all facebook permissions, accounts and api calls. Most of them deprecated.
  • Review all amazon credentials and api calls. Hard problems with the API keys valid to connect with Amazon Affiliates.

Retrospective

Stop doing

  • Lost a lot of time and effort in an application that I’m not sure I’m going to maintain in the future.
  • Retake a very old project that I didn’t pay attention any more.

Less of

  • Focus less in ‘Working Software’ and more in ‘Personal Innovation’.

Continue doing

  • A PiWeek where I have to do my best.
  • Solo projects are not so bad.

More of

  • Learn knowledge that I can apply on next monday.
  • Create conversations during piweek that help to achieve the goals
  • In my Next PiWeek-team project, I will assure that all members share the vision

Start doing

  • Pivot much earlier, leaving useless knowledge.
  • Prepare before piweek the basic software I need.

Conclusions

I’m very proud of effort, very happy to concentrate in the goals and very happy to feel exhausted.

See you next PiWeek in July 2015!

Etiquetado

Go PiWeek, Go! (My goal for PiWeek VII)

piweek vii breakfast

This post will be the first of one post-per-day for PiWeek VII (I hope so)

Mission for this PiWeek

Remember the great feeeling I felt this year in Euskal Encounter, having enough time to develop without any rush.

Goals

Emacs

  • Change from vim to emacs

Grails

  • Learn async capabilities in grails 2.4.4
  • GPars

Javascript

  • Compare with ajax

Seekagift

  • Integrate all of this in Seekagift
  • Deploy in public

Writing

  • Write posts about CAS 2014 and Scrum Day Oviedo
  • Investigate about Time Tracking for Taiga
  • Answer Epic topic conversation

What can I show on Friday?

A very improved version of Seekagift

Go for it!

Etiquetado