Casilla Inteligente en la Renta

En España estamos en estado de alarma por el COVID-19, con cifras de infectados y fallecidos que crecen cada día, pero también de recuperados y de vacunados.

Ante esta crisis, todos tenemos el deber de contribuir de una u otra manera. Estamos viendo todos los días que los que más se están dejando la piel son nuestros sanitarios y cuerpos de seguridad, sin ellos estaríamos perdidos y entre todos tenemos que hacer que cuenten con la mayor cantidad de recursos posibles. Uno de los principales es el apoyo económico: nuestra sanidad pública necesita tener más recursos, en todo el país.

Ojalá hubiera una web donde con un par de clicks pudieramos donar algunos euros a la sanidad pública, todos los haríamos, pero como no la hay, he pensando una alternativa igual de fácil e incluso más efectiva que permitirá tener más recursos el Estado para sanidad pública sin quitárselo a los que más lo necesitan.

Estos serían los dos simples pasos, las razones y cuestiones de todo esto las explico más abajo:

  1. Deja sin marcar la casilla de la Iglesia en la declaración del IRPF 2020 (la que se hace en 2021)
  2. Dona 5€ a Cáritas directamente en este enlace

¿Por qué hablamos de Cáritas y no de otras asociaciones?

La inmensa mayoría de contribuyentes que marca la casilla de la Iglesia en la declaración de la renta lo hace pensando en la función social de ésta a través de Cáritas.

¿Por qué dejar sin marcar la casilla de la Iglesia si ellos son los que financian Cáritas?

Según la memoria de la propia Conferencia Episcopal Española, sólo un 2,5% de los 254M€ (millones de euros) que recibió la Iglesia por el IRPF fueron para Cáritas, esto equivale a tan sólo 6 millones de euros, el resto va a parar a sueldos de sacerdotes y obispos y mantener la elefántica estructura eclesiástica. Fuente el Plural
Haciendo un simple cálculo, si esos 6M€ los dividimos por el número de contribuyentes que han marcado esa casilla (unos 7 millones) obtenemos 85 céntimos de euro nada más.
Es decir, donando directamente 5€ estamos aportando 6 veces más a Cáritas que la propia Iglesia.

¿En qué beneficia no marcar la casilla de la Iglesia a la Sanidad? Son mis impuestos y yo decido.

Esa es una verdad a medias, es cierto que es dinero de tus impuestos pero no es dinero que te pertenezca, me explico: marcar o no marcar la casilla de la Iglesia (igual que la de fines sociales) ni hace que pagues más ni que te devuelvan menos. Eso es así porque lo que se da a la Iglesia sale de la bolsa común de los presupuestos de todos, no de tu bolsillo.
Por tanto, si se da menos a la Iglesia, habrá más dinero en nuestros prespuestos que se destinarán a Sanidad a través de las CCAA que es su principal partida junto a educación.

¿Cómo sé que mis impuestos van a ir principalmente a sanidad pública?

Una de las lecciones que nos está dando esta crisis es que los únicos que nos van a salvar de verdad son nuestros profesionales sanitarios públicos, son los héroes de esta guerra y por eso les aplaudimos todos los días.

Una parte muy importante del IRPF va a parar a las CCAA cuyas partidas principales son Sanidad y Educación, por tanto a mayor cantidad que venga del IRPF más va a estas partidas.

Los gobiernos central y autonómicos ya han reiterado en todas sus comparecencias e incluso en el Congreso, que la prioridad número uno es el fortalecimiento de la sanidad pública, para que esto no nos pase otra vez.

¿Por qué no se le quita dinero a partidos políticos, sindicatos, patronal, asociaciones, etc… en lugar de la Iglesia?

Es cierto que para dotar de más fondos a la sanidad, habrá que quitar de otros sitios, pero por desgracia no hay una casilla en la renta para destinar impuestos a partidos, asociaciones, sindicatos y patronal, pero sí la hay para la Iglesia, está en nuestra mano.

¿Por qué no dejamos la casilla de la Iglesia y también donamos a Cáritas?

Es una posibilidad, no obstante, se está demostrando en esta brutal crisis que hay colectivos que han estado muy por debajo de lo que se esperaba de ellos. Uno de los más decepcionantes está siendo la respuesta de la Iglesia Católica Española, recibiendo al año 257 M€, no han aportado apenas nada, a pesar de su vocación de servicio. Quien si lo está haciendo es Cáritas, por eso hay que seguir financiándoles.

Pero yo quiero aportar a la Iglesia, estoy en mi derecho

Por supuesto, faltaría más, siempre podrá dar un donativo en su parroquia o sede eclesiástica directamente, estará contribuyendo a su sostenimiento y a la vez dejando libre un pedacito de sus impuestos para apoyar la sanidad. Todos ganamos.

5 lecciones aprendidas en el Mind the Product Con que todo Product Manager debe saber

Corría el año 2014, cuando estaba trabajando en bq junto a José Carlos Díaz y entre café y café hablábamos de Marty Cagan y sus charlas para crear productos que la gente ame o Jeff Patton y sus técnicas de User Story Mapping para organizar el jaleo de una planificación temporal y de historias de usuario en un producto. Cuando salió el nombre de Mind the Product, una comunidad exclusivamente dedicada al Product Management; sus posts y reflexiones de alta calidad y dando en la diana sobre lo que realmente me interesaba me hicieron pronto desear ir a alguno de sus dos eventos anuales que organizan en San Francisco y Londres. Este año por suerte y gracias a Guillermo y DEISER he podido asistir al de éste último, no podía estar más ilusionado.

Lo primero que me sorprendió al llegar al Barbican Theater de Londres es la magnitud del evento que era. Estoy acostumbrado a grandes citas del mundo de la tecnología como los Summit de Atlassian o AtlasCamps, eventos multitudinarios (más de 2000 personas) y con unos cuantos millones de dólares detrás. Pero claro, una cosa son los grandes eventos organizados por una multinacional que cotiza en bolsa y otra el de una comunidad. Por eso cuando vi el despliegue en medios, sponsors, voluntarios, etc lo primero que me pregunté es: ¿de veras esto es una comunidad? Quizás sí pero de las caras, o al menos por el precio de los tickets podríamos afirmarlo.

La jornada se desarrolló con un único track de charlas en el teatro principal donde fueron pasando speakers más o menos conocidos pero todos con un mensaje muy claro e inspirador para hacernos pensar de manera diferente y hacer mejores nuestros productos, aquí van algunas de las lecciones que a mi se me han quedado:

Embrace the awkwardness, no pasa nada por ser un impostor porque hace falta un impostor (Martin Eriksson)

El cofundador de la comunidad Martin Eriksson empezaba el evento soltando la bomba y mentando al elefante en la habitación. ¡Todos somos impostores! pero no pasa nada, porque es bueno y hay que aceptarlo.

Se refería al famoso síndrome del impostor, el cual hace sentir a una persona que está por debajo del nivel de otras que están a su alrededor porque éstas están mucho más especializadas en su trabajo y el tuyo es hacer de pegamento, guiarlas o llevar la estrategia. Si bien este sentimiento es totalmente subjetivo porque el resto de gente sí que te ve valioso, tú mismo te ves como un impostor.

En el mundo tecnológico es cada vez más común pues hay roles como el de Scrum Master o Product Manager que tienen una componente social muy fuerte y parte de tu trabajo es sacar lo mejor de cada miembro del equipo. Yo he de confesar que a lo largo de los años en puestos como estos a veces me he sentido un impostor, sé que está solo en mi cabeza pero el hecho de escucharlo en otros PM’s y asumir que es algo normal me ha ayudado mucho a aceptarlo.

A product is made of decisions, not pixels and code (Kim Goodwin)

El código fuente de un producto software es parte esencial, por supuesto, se podría decir imprescindible (aunque hay productos sin una línea de código, dedicaré otro post a esto).

Pero lo que nos contaba Kim Goodwin es que lo vital es tomar decisiones, casi cada día, decisiones que tienen que estar basadas en datos, sin éstos no somos nadie y sin las métricas y números nuestro producto estará ciego.

Uno de los aspectos más importantes de las métricas es que siempre deben estar acompañadas de un objetivo, medir por medir no vale para nada.

HEART (Roan Lavery)

Roan nos habló del framework HEART, diseñado por Google. En cual consiste en diferentes áreas de métricas para evaluar la experiencia de usuario y como va tu producto. Consiste en cinco grupos de métricas:

  • Happiness
  • Engagement
  • Adoption
  • Retention
  • Task Success

Cada una de ellas tendrá diferentes indicadores que dependerá del producto, plataforma, etc.. En la imagen Roan nos enseñó las que el usa, sin duda es algo que implementaré en breve.

Do the right things in the right order for the right reasons (Joe Leech)

La charla de Joe fue una de las más fascinantes, se adentró en un mundo tan necesario como normalmente desconocido en product management: la psicología.

Nos enseñó la diferencia entre comportamientos estáticos y tautológicos en procedimientos y secuencias por que son éstos los que las personas entienden e interiorizan mejor. Secuencia, secuencia, secuencia y además siempre la misma y si vas a introducir cambios, por nimios que parezcan, es mejor hacerlos muy poco a poco para no perturbar el mapa mental de la interfaz que tiene el usuario. «Si lo haces de golpe, lo rechazará, por muy bueno que sea el cambio.»

Experiments don’t fail, hypothesis are proven wrong (Rick Higham, Skyscanner)

¿Cómo podemos estar seguros de la dirección a tomar si no hacemos experimentos y evaluamos si funciona? Todos tocamos el agua de la ducha a ver si está lo suficientemente caliente antes de meternos, ¿verdad?

La formulación y validación de hipótesis es la piedra angular de todo producto, ya que no tenemos ni idea de cómo se comportará el mercado ni el rumbo de nuestros competidores, ni la psicología de nuestros usuarios. No debemos tener ningún miedo a formular una hipótesis, y probar que es incorrecta por que no es un fallo nuestro o del producto, es asegurarnos del comportamiento de todos los factores que he nombrado antes.

Rick decía que una hipótesis debe ser “testeable” y poder ser demostrada falsa.

Como herramienta nos dejó http://experimentationhub.com un toolbox con muchísimos recursos, consejos y guías para experimentar bien se con tests A/B, plantillas de formulación de hipótesis y análisis de resultados.

Estas son las lecciones más importantes que me marcaron en la MTP Con de Londres pero hubo muchísimos más consejos y acciones que me llevo de vuelta y seguro usaré.

Mi experiencia en la CAS 2015 y el ego

Para los que me conocéis sabréis que el tema de llevar equipos de desarrollo de software es lo mío, para nada me considero un erudito en la materia, más bien al contrario, tengo mucho que aprender y cada día aprendo cosas nuevas pero creo que es algo que se me da bastante bien, disfruto con ello y tengo algún éxito que contar, también fracasos y momentos duros que al fín y al cabo es cuando uno más aprende.

El pasado verano mi compañero Miguel Ángel García me pasaba un link en el que decía que la CAS abría su call for papers para la edición de este año y me animaba a presentar algo. Al principio no le di mucha importancia pero trás decir las palabras mágicas “a que no hay hue***” no pude resistirme a mandar una idea.

No tuve que pensar mucho, en el 2015 viví en mis propias carnes algo que más tarde llamé EDD (Ego Driven Development). No es el objetivo de este post el desarrollar el tema pues para eso habrá otro más detallado, tan solo quisiera transmitir el porqué elegí esa idea. Principalmente es porque en el último año y medio en diferentes equipos he podido vivir como el ego que todos tenemos, bien tratado y dirigido puede llevar a hacer de un equipo normalito o incluso flojo a ser uno de los mejores y el caso contrario, un ego descontrolado, una diva en el equipo mezclada con alguna puñalada por la espalda y una pizca de maquiavelismo puede hacer no solo que un equipo fracase si no que un producto se vaya al traste.

Estoy seguro que todos tenemos en mente casos como estos y no solo en el ámbito del desarrollo de software pues somos humanos y todos tenemos nuestro pequeño orgullo y ego por tanto en cualquier grupo u organización podremos encontrarlos. Debido a que estas situaciones me han tocado personalmente me decidí a hablar sobre ellas.

Trás unos meses de espera mi charla fue seleccionada como “Lightning”, se trataba de un formato corto de unos 15 minutos, no eran los 45 que me hubiera gustado pero me valía para contar mi idea. Como se dice en mi tierra manchega “me puse más contento que unas castañuelas”.

Como siempre me pasa no rematé la presentación hasta la noche anterior, en ese momento justo al terminar vi que mi Keynote no guardaba la copia en iCloud, no le di importancia pues me iba a llevar mi propio Mac, ¿qué podría pasar? Lo llevaba en el sitio más seguro.

image_large

Y por fín comenzó la CAS, abriéndola un magnífico Eugenio Moliní que con sus experiencias vitales y de superación personal nos dejó a todos boquiabiertos, si hubiera tenido un sombrero en ese momento me lo hubiera quitado. Seguí asistiendo a algunas charlas a lo largo de la mañana, la mía era a las 16h.
Entre tanto fui a almorzar con mi mujer que trabaja cerca y mientras iba ocurrió la fatalidad, la correa de la banbdolera donde llevaba el Mac se rompe y cae al suelo, en ese momento no me percaté de la magnitud de la tragedia hasta que a las 15h me metí a otra charla y al abrir el Mac resulta que no enciende, el golpe ha debido de estropear algo. En ese momento podéis imaginar los sudores fríos que me entraron, recordad que mi presentación estabas ahí y solo ahí, ni en la nube ni ningún otro sitio, de nuevo Murphy actuó y de la manera más malévola que podría. En ese momento no entré en pánico, pedí a alguien de la organización de la CAS un portátil para deprisa y corriendo rehacer la presentación teniendo en cuenta tan solo los recuerdos de la que había hecho la noche anterior. Desde aquí agradecerles que me prestaran ese portátil pues me salvaron y al final creo que la presentación me quedó mejor incluso que la original, lo que son las cosas. Consejo: haced siempre siempre copia de seguridad de vuestras presentaciones, en la nube, en un pen drive, en una caja de seguridad de un banco suizo, en pdf, word, wordperfect, todos los formatos que se os ocurran.

Llegó mi turno, la sala llena y aunque al principio estuve algo nervioso pero me vine arriba enseguida, fueron solo 15 minutos de charla, lo sé, pero los viví como si hubieran sido muchos más. Tampoco es que haya sido mi primera charla, he tenido muchas pero quizás porque el momento en lo personal era cuando más necesitaba un empujón, el caso es que salí de allí con el ánimo por las nubes, super orgulloso, a la gente le había encantado y al parecer el tema del ego en los equipos de desarrollo de software es un mal endémico, espero que haya servido un poco de ayuda mis palabras aunque sea para que sepáis que no estáis solos.

Por lo demás de la CAS me llevé la agradable sensación de encontrarme con un antiguo compañero de trabajo, Jorge Moratilla, un profesional como la copa de un pino y mejor persona que llevábamos tiempo sin vernos y pudimos ponernos al día. Gracias Jorge.

Os dejo el link a la presentación por si queréis echarle un vistazo y publicaré el video cuando lo suba la organización de la CAS.

Slideshare

Evangelizando Scrum

Uno de los retos más complicados a los que se suelen enfrentar todos los que forman parte de algún equipo que abrace las metodologías ágiles es contar en qué consiste su forma de trabajar a los a los civiles (aquellas personas ajenas al mundo tecnológico/del software y que no tienen porque entender nuestra jerga y tecnicismos). Esta labor es aún más complicada cuando tu jefe o algún superior al que reportas es un civil. Normalmente esta ardua y peligrosa tarea recae sobre los Scrum Masters, pues entre otras, su función evangelizar en las bondades y también defectos de las metodologías ágiles, en concreto Scrum aunque también hay cabida para otras como Kanban.

Voy a profundizar un poco en algunas aseveraciones que he hecho pues si bien algún profesional del mundo Agile sabe de lo que hablo, lo más probable es que el resto no.

Quisiera empezar por la necesidad casi imperiosa que tienen todos los Scrum Masters de evangelizar a todo bicho viviente con el que se cruza. La razón de este comportamiento no es porque de repente se les hayan abierto las puertas del cielo y se hayan convertido en profetas si no porque si bien Scrum puertas adentro se perciben todos sus beneficios, se viven las liturgia y se impregna el sentimiento de equipo; de puertas hacia fuera estas sensaciones son difícilmente perceptibles por lo que es casi obligatorio el ir por ahí contando las maravillas y detalles de la metodología con la que trabajas.

Aunque no te lo creas pero tu jefe o responsable no tiene porqué saber de Scrum y lo mismo ni le importa. Está bien, no pasa nada, estas situaciones se dan muy a menudo, cuando reportas a un mando no técnico, bien de negocio, o miembros del board de la compañía. Este escenario no tiene porque causarnos respeto o miedo, aquí os comparto algunos consejos sobre como abordar esta situación:

  • Desde el día uno tu responsable tiene que ser consciente del trabajo que vas a realizar y como vas a hacerlo.
  • Hazle un breve resumen de lo que consiste la metodología, no se trata de hacerle un curso si no que sepa los aspectos básicos de los procesos que vas a seguir.
  • Avísale de que habrá situaciones que no entienda pero que cuando eso ocurra ahí estarás tú para explicárselas.
  • Invítale a las liturgias, sobre todo al principio, si participa algún daily meeting, planning o retrospectiva seguro que le es mucho más encillo entender todos los conceptos. Desde luego no es lo mismo que te lo cuenten a vivirlo tu mismo.
  • Se transparente, cuando haya problemas (y en mundo del software siempre los hay) trata de contar todo como realmente es, no maquillar la realidad por muy dura que sea. Siempre será preferible esto a que se te pueda acusar de ocultar los problemas, ya que aunque los del equipo saben que no es así pero desde fuera es difícil de entender que, por ejemplo, se les diga que no a una petición que hacen en medio de un sprint.

Estas son solo algunas de las situaciones en las que un Scrum Master o cualquier miembro del equipo tiene que poner un especial esfuerzo en evangelizar al personal. ¿Y tú? ¿has tenido que lidiar con una situación similar?, compártela con el resto en los comentarios.

Mi equipo es mejor que el tuyo

Las personas tendemos a compararnos con nuestros semejantes en todo momento. Desde que somos niños nos encanta fijarnos en lo que tiene nuestro hermano/a y lo deseamos con todas nuestras fuerzas, no importa lo que tengamos nosotros. En la cultura occidental en la que vivimos todo se ha convertido en una competición, el tener que llegar más arriba que el compañero, el ser mejor y si no se puede al menos el parecerlo. Estos son comportamientos inherentes a la persona (en algunos más que en otros obviamente) y que aunque no lo sabemos nos influyen en nuestro día a día.

Este post no tiene la intención de hablar de la psicología humana, ni de lo “envidiosos” que somos o dejamos de ser. A lo que quiero apuntar es a como en empresas o departamentos de software donde hay más de un equipo trabajando con metodologías ágiles se tiende a comparar unos con otros, bien sea por el comportamiento natural de medirse entre compañeros como cuando los responsables necesitan métricas para tomar algún tipo de decisión.

No comparemos peras con manzanas

El primer punto que aunque parece obvio en la práctica se comete muy a menudo el error de comparar equipos que lo único que tienen que ver entre ellos son que están compuesto por personas de carne y hueso, nada más.

Si tienes equipos distintos, en proyectos distintos, con responsables distintos, disciplinas distintas y roadmaps distintos. ¿Por qué comparar uno con otro? No tiene ningún sentido. En este caso lo que recomiendo es que si necesitamos tomar alguna decisión sobre movimientos o ajustes se haga sobre las personas en concreto basándonos meramente en criterios personales y no de equipos.

La velocidad no es un KPI

La velocidad de un equipo ágil es una métrica que nos indica el número de puntos que ha conseguido un equipo en un sprint. Este valor es muy irregular sobre todo cuando un equipo está en una fase inmadura, acaba de cambiar o comienza un proyecto nuevo. A lo largo de los sprints se va estabilizando.

La principal utilidad de esta medida es servir como herramienta al propio equipo a la hora de estimar a lo que puede llegar en un sprint. Si durante los últimos cinco sprints se han conseguido 40 puntos, al estimar para el siguiente cuando se han metido ya unos 38-40 el equipo sabe que su límite está cerca y no debe arriesgarse a coger más historias porque corre el riesgo de no poder terminarlas.

La velocidad ayuda a conseguir el objetivo último de usar metodologías ágiles: ser predecible.

¿Por qué la velocidad no es en absoluto un KPI para comparar equipos?

  • La medida de estimación de cada equipo es distinta, lo que para uno supone cinco puntos para otro son ocho.
  • La velocidad es una herramienta de apoyo a la estimación interna.
  • Es muy sensible a factores externos como pueden ser sprints más cortos, absentismo de sus miembros, situaciones inesperadas, etc.

Cada equipo tiene su propia historia

Incluso siendo equipos distintos que trabajan bajo el paraguas del mismo proyecto tienen historias y casuística distintas. Cada uno de ellos ha pasado por problemas y situaciones que en muchas ocasiones no se parecerán los unos a los otros, las decisiones tomadas ante estas situaciones por sus respectivos Scrum Masters o Product Owners (si fuera distinto) de seguro que han marcado el resultado de lo que se intenta comparar.

Sería muy irresponsable juzgar a un equipo o compararlo con otro sin tener en cuenta por todo lo que ha pasado.

Mi equipo ha llegado a su objetivo y el tuyo no

Volvemos otra vez a las peras y las manzanas, he visto en muchas ocasiones hacer comparaciones entre equipos bajo el pretexto de “El equipo X ha llegado a su objetivo y el equipo Y aún no”.

Si eran objetivos distintos, con roadmaps distintos, productos distintos e integrantes distintos. ¿Por qué compararlos?

Lo que SÍ se podría usar para hacer alguna comparación

Está claro en algunos momentos es necesario tener una visión global de todos los equipos sobre lo que se tiene una responsabilidad y cuando hay que tomar decisiones hacerlo en base a criterios objetivos, homogéneos, veraces y verificables.

Tener en cuenta el camino recorrido y los obstáculos que se han encontrado es importante a la hora de hacer una valoración, no sería justo juzgar a un corredor por hacer los 100 metros en veinte segundos teniendo que saltar vallas que otro que lo ha hecho en diez con el camino llano.

Actitud ante los problemas, todos los equipos y proyectos tienen situaciones difíciles a las que deben enfrentarse, ya que cada uno será distinta no podemos compararlos por la situación en sí ni si han tenido éxito o no resolviéndolas ya que puede haber factores externos que interfieran pero sí se puede analizar la actitud que ha tenido el equipo a la hora de enfrentarse a los problemas y los procesos que han seguido para la toma de decisiones.

Recolecta toda la información posible antes de tomar alguna decisión, seguramente cada miembro del equipo tiene una visión particular que te aporta información complementaria y tener sobre la mesa todos los puntos de vista te va a ayudar a la hora de decidir.

Seguro que os habéis visto reflejados en alguna de estas situaciones o habéis caído en la tentación de utilizar algunos de los elementos arriba descritos para mirar al equipo de al lado por el rabillo del ojo, yo también lo he hecho y por eso la experiencia me ha enseñado que hay que cambiar el filtro con el que nos miramos.

¿Es un pájaro?, ¿es un avión?, ¡es un Scrum Master!

En este post quiero comentar las peculiaridades, aventuras y desventuras, virtudes y defectos de un rol al que le tengo especial cariño, no sólo por haber tenido la suerte de trabajar en él si no porque realmente pienso que una figura así es necesaria en todas las profesiones. A estas alturas ya sabréis a quien me refiero, así es, ¡hablo del Scrum Master!

Si has continuado leyendo hasta aquí seguramente estés en uno de los siguientes grupos: 1: eres un gran conocedor de este rol; 2: no tienes ni idea de lo que es un Scrum Master y te pica la curiosidad 3: no tienes nada mejor que hacer y estás matando unos minutos. A los de los grupos 2 y 3, lo siento pero este no es un post para contar la qué es un Scrum Master, hay multitud de libros que van a contar la teoría mucho mejor que yo, personalmente recomiendo Succeeding with Agile de Mike Cohn (http://www.succeedingwithagile.com/); este es un post para hablar de la parte del trabajo de SM que no cuentan en los libros, y eventualmente los sentimientos que lo rodean, en este caso subjetivamente hablando desde mi experiencia.

  • El primer rasgo que quiero destacar es un Scrum Master es el hecho de que NO ES UN JEFE, es un líder, pero un líder con una peculiaridad, es un líder que sirve al equipo, se dice que el trabajo del SM ha terminado cuando el equipo puede operar perfectamente sin él. Esta figura es una parte esencial en los equipos porque hace que el resto del equipo pueda trabajar, resuelve problemas, les quita distracciones, engrasa la máquina y está a su disposición. Como bien dice mi gran amigo Ismael Arroyo (fantástico SM por cierto) cuando le preguntan en qué consiste su trabajo: “Simplemente quito palos de las ruedas, y no pocos”.
  • Es alguien social y comunicativo, ¡como no!, esta es una cualidad clave para el SM, gran parte de su tiempo se lo pasa tratando de convencer a los demás de las bondades de las metodologías ágiles y no solo al equipo (que se convence prácticamente solo) si no lo que tiene por encima, ¡esos son los verdaderos huesos a roer!. Los beneficios de esta cultura suelen ser poco tangibles si no es está dispuestos a ello y sus bondades tardan un tiempo en llegar, por eso es esencia hacer una gran pedagogía. Creedme cuando os digo que he visto grandes SM hacer de equipos verdaderas máquinas del “agilismo" y sacar productos estupendos y fallar en este aspecto.
  • Facilitador, todos los que andéis en este mundillo del software sabéis que siempre ha sido, es y será un caos, el software es probablemente una de las ingenierías más complejas debido a la infinita casuística, si a esto le sumas que las personas a veces sacamos a relucir nuestro orgullo torero por encima de todo pues hace falta una figura facilitadora que ayude a alcanzar acuerdos. Por el bien del SM estos momentos mejor que sean pocos por de tanto facilitar al final uno se resiente.
  • Energy & Empowerment, a veces pienso que los SM desayunan un tazón de Pharmaton todas las mañana porque no os imagináis la cantidad de energía y positivismo que desprenden, es la única manera de contagiarlo a los demás.
  • Mejora continua, cuando era pequeño quería ser médico, hasta que alguien que me quería quitar la idea de la cabeza me dijo que éstos se pasan la vida estudiando porque siempre salen nuevos medicamentos y técnicas, me asusté y me tiré por la informática, que iluso… Pues eso, un SM debe de tener un gran background técnico, programe o no, debe de estar al día de las últimas tecnologías y procesos para así, poder anticiparse a los problemas, que os aseguro llegarán.
  • Grano y paja, una de las tareas más complicadas a las que se va a enfrentar un SM es a saber distinguir cuando hay un problema, si de verdad lo hay, y ser transparente y reportarlo. Recordemos que el SM no es un representante de los trabajadores, tampoco es un jefe al uso, por tanto su mejor herramienta es la transparencia, mostrar las situaciones tal y como son para poder buscar la mejor solución.
  • El valor de la entrega, debe transmitir cuan importante es que cada sprint se entregue algo, por pequeño y minúsculo que sea, da igual, pero siempre debe de haber un incremento de funcionalidad, siempre se debe mostrar algo nuevo y este principio se lo debe trasladar a todos los miembros del equipo.

Si después de leer estas cualidades sigues queriendo ser un superhéroe llamado Scrum Master, ¡enhorabuena! este va a ser un trabajo para ti, si tienes tus dudas o no te crees un carajo todo esto del “agilismo”, no te culpo, es normal, por eso es necesaria tanta pedagogía que comento antes.

Como esto no es un artículo técnico ni una entrada de Wikipedia sobre lo que es un SM voy a mojarme y contar algunas de mis experiencias que he tenido en este rol que he desempeñado durante años. Os puedo decir sinceramente que para mi ha sido muy gratificante trabajar como SM, es un trabajo bonito y apasionante, sobre todo en el ámbito humano pues tienes mucho trato con los equipos.

Como decía Diego Rojas (@drobur), profesor de uno de los cursos de Scrum a los que asistí “El trabajo del SM es tomarse cafés con la gente” y vaya si tenía razón, tuve que empezar a tomarlos descafeinados si no quería sufrir ataques de nervios; ¿por qué los cafés? es el momento en el que entablas más relación con los compañeros, tienes que ser su consejero, ganarte su confianza, tienes que saber cuando tienen un mal día, uno bueno, las cosas que les preocupan, las que les gustan, las que les molestan…

Por otro lado no os voy a engañar, el trabajo de Scrum Master es agotador, sobre todo cuando tienes que lidiar con equipos o parte de la organización que no creen en los principios ágiles, ni quieren creer por mucha pedagogía o psicología que despliegues, eso es todo un reto, creedme; es difícil, sí, pero no imposible.
En resumen, os animo a que si os sentís atraídos por esta figura lo intentéis, que probéis porque realmente os enganchará y aunque hay momentos no tan buenos (como en todos los trabajos), merece la pena estar ahí.

Mientras tanto me tenéis a vuestra disposición tanto en los comentarios de este post como en mi contacto al que os invito a que me escribáis si tenéis alguna duda o consulta sobre este superhéroe llamado Scrum Master.

¿Eres un Developer +?

Desarrollador, programador, developer, picacódigo… existen muchos nombres para esta hermosa profesión, o más bien es un modo de vida, al igual que cuando un cura por el motivo X deja de serlo, para la iglesia siempre lo será. Pues con los desarrolladores es igual, si has empezado siendo programador y con que te guste un poquito aunque cambies de puesto y vayas cambiando el Eclipse por el Excel, siempre dentro de ti serás un programador.

Cuando yo estaba estudiando Ingeniería Informática uno de mis primeros objetivos que me puse para la salida al mundo laboral era el ser un buen Programador .NET y bueno tuve suerte de caer en un par de empresas que me permitieron desarrollarme como tal, mientras tanto por mi cuenta y en los ratos libres hacía y hago mis pinitos como desarrollador iOS y Web, la aparición de tanto Framework Javascript me ha hecho replantearme mi fidelidad a .NET y estoy tirándole los trastos a Angular.JS.

En la trayectoria laboral que tengo he tenido la oportunidad de trabajar con muchísima gente, gente buena, mala, regular, orgullosa, humilde… cada uno de ellos con un nivel de experiencia distinto en una larga variedad de tecnologías. Y mientras tanto todo este tiempo siempre ha habido algo en toda esta gente que me ha hecho el que me apeteciera estar más cerca o lejos de ellos y es que sean como yo llamo “Developers +”, voy a explicar en una lista lo que para mi un programador debe tener para tener el distintivo “plus”:

  • Las tecnologías van y vienen, ahora está de moda Javascript cuando hace cinco años era la oveja negra de la programación web. Pero un Developer + se ha formado en sólidos conceptos de programación funcional, algorítmica, bases de datos, etc… Da igual lo que le pongas delante, se va a aprender la sintaxis a las pocas semanas va a ser capaz de rendir bien. Para mi, alguien que se ha machacado los libros del lenguaje de moda y lo controla de maravilla no me vale, porque si mañana cambia algo (y seguro que lo hará) con esa persona ya no podría contar. La industria del software necesita ingenieros que piensen más allá de lo que mola en el momento.
  • El trabajo en equipo, esto es un aspecto VITAL hoy en día, no existe el producto software (con un mínimo de entidad) que lo pueda llevar una persona sola sin colaborar con otros programadores. De nada me vale que tengas 2001 certificaciones y seas el mega crack de la maquetación si no eres capaz de trabajar con tus compañeros y si tienen un nivel más bajo que tú, el poder transmitírselo. Siendo un lobo solitario podrás ganar alguna batalla, pero no la guerra.
  • Valores, compañeros programadores, con valores no me refiero a lo que contiene la variable index, me refiero a palabras como humildad, fortaleza, disciplina, autocrítica, compañerismo… Estas son cosas que no las enseñan en Stackoverflow, o las tienes o no las tienes. Prefiero contratar a un programador que sea un 7 en lugar de un 9 pero sabiendo que el compromiso de esa persona con el proyecto y sus compañeros son altos, la técnica la cogerá con poco que se ponga, si eres un “canalla” no habrá tutorial que te lo quite.

Es posible que algunos no estéis de acuerdo con alguna de estas cualidades del “Developer +”, al fin y al cabo esto son opiniones y mis formas de ver el sector, hasta ahora siempre que me buscado gente que cuadre con estas cualidades me ha ido bastante bien. Espero que os valga la reflexión.

Termina mi etapa en bq

Hace poco más de año y medio cuando yo todavía estaba viviendo en Turquía y peleándome con los entresijos del mundo de los ebooks con Skan4Labs, por suerte, casualidad o providencia vi un anuncio que decía que la empresa tecnológica española bq iba a abrir un centro de desarrollo en Ciudad Real y buscaban gente, a alguien que pudiera liderar un grupo de ingenieros informáticos para un proyecto nuevo y fascinante que se traían entre manos. Acepté.

Durante este año y medio he tenido por delante uno de los mayores retos que he tenido nunca, liderar y “educar” en metodologías ágiles a un grupo heterogéneo de ingenieros que nunca habían trabajado de esa manera, llevar a buen puerto un proyecto en el ámbito del Ocio Digital ambicioso, lleno de incógnitas pero apasionante; ser el portavoz y responsable de la empresa en la oficina de Ciudad Real, hacer crecer al equipo hasta llegar a triplicarlo cuidando de la cultura de desarrollo que tan importante es y hacer de escudo cuando hacía falta.

He tenido la tremenda suerte de poder trabajar en una empresa de producto, que ve y desarrolla sus ideas con la vista puesta en la calidad como bandera. También he tenido la fortuna de contar con un equipo humano y técnico que todo lo que diga aquí se queda corto, juntos hemos sabido darlo todo en los momentos que “pintaban bastos” y hacer cosas increíbles.

Dificultades ha habido muchas, como en todos los proyectos y empresas como el tener equipos distribuidos en varias localizaciones, contratiempos y situaciones ajenas a uno mismo. Ante todos estos momentos es de agradecer a los que siempre han estado arrimando el hombro y a los que no lo han arrimando tanto también les agradezco porque al final todo te hace más fuerte.

Ahora es el tiempo de mirar a nuevos proyectos, nuevas metas e ilusiones con un gran bagaje y muchísimas ganas de hacer lo que mejor se me da, llevargrandes personas para hacer grandes productos. Espero veros pronto en algún “Daily Meeting”.

La mujer del César

El mundo de la tecnología está lleno de peculiaridades, es un mundo frenético, las tendencias cambian día a día, hay siempre mucha presión en el aire y cuando hay que reaccionar y dar un volantazo no siempre le gustará a todo el mundo, hay que estar bien posicionado. ¿A dónde quiero ir? pues bien, quiero ir precisamente al concepto intrínseco de competitividad que solemos tener los ingenieros informáticos.

En nuestra profesión, al contrario de otras ingenierías clásicas no todo es blanco o negro, bien o mal, hay un millón de matices que pueden hacer que algo que creíamos excelente e irrefutable otro lo consiga y eso no quiere decir de ninguna manera que lo nuestro este mal o lo de otro mejor o peor, es simplemente diferente, y como tal hay que aceptarlo.

Tras el paso por muchos proyectos, jefes y equipos puedo decir que he tenido buenas y malas experiencias (como todos en vuestros trabajos) pero hay siempre un denominador común: “Uno no es lo que es sino lo que otros dicen que es”, lo comunmente llamado Marca Personal y ese concepto es un arma de doble filo, y ambos lados cortan como bisturíes.

Existen muchas técnicas todas perfectamente documentadas de forjarse una buena marca personal, de dar buena impresión, una de ellas es hacer bien tu trabajo, hacerlo mejor que nadie e incluso ponerte alguna medalla con un logro inesperado; también es necesario destacar los logros de tus compañeros más cercanos o los de tu equipo pues también serán vistos como propios. Todo esto es importante, sí, pero no tanto como lo más vital de todo: Si esos logros y buen trabajo no generan una fama, estás muerto, ya puedes ser el descubridor de un algoritmo mejor que el de Google que si los otros no hablan de ti, no eres nada, al contrario, si no generas buena fama se entenderá por defecto que estás haciendo mal tu trabajo.

Estaréis pensando que esto es hacer apología del trepismo o lamenalguismo, nada más lejos de la realidad, aquí no se trata de hacer parecer lo que no es, si no algo más legítimo y difícil porque si es bueno en este mundo competitivo van a intentar echartelo para atrás: hacer parecer lo que es porque como siempre se ha dicho “La mujer del César no solo tiene que serlo sino parecerlo”.