La experiencia y el conocimiento suman, pero tu actitud multiplica

Hace poco escuché una frase a un coach que me gustó mucho: la experiencia y el conocimiento suman, pero la actitud multiplica. Fijaros en la fórmula: (E+C)*A. Toda nuestra experiencia que vamos acumulando en cuanto a desarrollo software es vital, así como el conocimiento que vamos adquiriendo a base de la lectura y formación. Sin embargo, todo esto no sirve absolutamente de nada sin una actitud correcta y profesional. Una actitud de esfuerzo y búsqueda de la excelencia. Aún si tenemos poco conocimiento y poca experiencia, nuestra actitud nos llevará a buscar la manera de desarrollar todos esos skills que nos faltan.

actitud

Pero, ¿Qué ocurre si llevamos muchísimos años trabajando sin plantearnos si hay maneras mejores de hacerlo o simplemente sin ser autocríticos con nuestra forma de proceder? Este relato, está orientado a llevarte a la reflexión. Hoy en día, en España, “Scrum está de moda” y muchos adoptan la metodología pensando que es una cuestión principal consistente en leer un libro básico como por ejemplo Scrum y XP desde las trincheras (el cual no dejo de recomendar como iniciación) y seguir el procedimiento sin plantearse realmente de forma crítica si realmente tiene sentido lo que están haciendo, convirtiendo su día a día en rituales y referencias a una documentación que siento decirlo y a muchos les dolerá, pero resume tanto las cosas que puede llevar a la confusión en algunos casos si esta lectura no se complementa con otras (y os dejo aquí algunas sugerencias).

Naturalidad-infancia-Suavinex

A continuación os dejo un relato que escribí hace años. Este relato aunque está lleno de humor negro, no deja de presentar una realidad, al menos en España, que es la falta de profesionalidad. Empresas deciden adoptar una metodología (sea cual fuere, en el caso del relato Scrum, pero como veremos…podría ser cualquier otra) y eligen a personas para liderar el cambio organizacional que no están preparadas. Quizá han acumulado años de experiencia, pero su actitud no es precisamente la adecuada. Normalmente esto se produce por el contexto y falta de motivación. Usaba el nombre de Patrick B. tratando de buscar una relación entre este tipo de persona y la película American psycho. Os dejo con el relato.

american

A Patrick B. le tocó ser Scrum Master: momento y lugar inadecuados él decía sonriendo. En su empresa las cosas iban mal y los proyectos no terminaban del todo bien. Se dieron cuenta de que el 49% de los proyectos terminaban con un sobrecoste, el 27% no terminaban y se cancelaban y el resto estaba al borde de o acabar mal o cancelarse. Aunque había un pequeño número terminaban con éxito, cosa que nunca llegaron a entender. Algunos decían que era por la involucración de cliente en esos proyectos, otros decían que era suerte. A Patrick B. simplemente, no le importaban demasiado estos números.

Chuck Norris - Scrum master

Pero como iba diciendo, Patrick B. era Team Leader. Sumar, quitar y poner horas ya no tenía ningún misterio para él. Con su Gantt en la mano se sentía bastante seguro y “sus chicos”, como él los llamaba, estaban “a tope”. Si eso de la Zona de confort existiera, creo que la de Patrick B. era de látex con doble capa, con un televisor y con un par de pufs para apoyar sus cansadas piernas. Su vida era maravillosa, siempre cumplían los hitos, de una manera u otra. Tenía trucos que nadie conocía, como mandar la entrega en un CD rayado a cliente para tener cinco días más de desarrollo. Infalible.

scrum norris - gantt

Su empresa, una gran multinacional que poseía grandes, pesados y seguros procesos para todo. Tenía en el plan de desarrollo software un modelo en V descrito. La primera vez que escuchó de él, se imaginó que era algo novedoso, pero al parecer llevaba aplicado bastante tiempo. Lo leyó una vez y casi obligado. El caso es que fuera lo que fuera, parece ser que no funcionaba del todo y no tenían claro por qué. Patrick B. sabía que alguien había escrito el documento y lo había subido a control de configuración un tiempo atrás. ¿Qué más había que hacer para que funcionara?

ni idea de lo que hablas

Comenzó la moda en la que las grandes multinacionales con sus pesados, completos y e inexpugnables modelos en V y en cascada querían pasar a eso de las metodologías ágiles. Querían cambiar su filosofía, adaptarse al cambio. En algunas empresas, se contrata a un agile coach o especialista en metodologías de desarrollo. Patrick B. tenía un amigo que se dedicaba a eso y decía que es una gran trampa.  Muchas empresas normalmente no quieren cambiar su forma de trabajar y lo que quieren es que las nuevas formas de trabajar se adapten a ellos dando resultados positivos a corto plazo. Decía que contrataban a un agile coach y pensaban que sin ningún tipo de apoyo por parte de la dirección y mediante extraños rituales conseguirían llevar a cabo esos cambios tan deseados.

dilbert_ideas

Otras empresas contratan a un consultor externo. Pero Patrick B. decía que solían ser gente muy teórica que querían hacer cambios radicales. “Si quisiéramos hacer cambios radicales llamaríamos a Longueras”,  decía Patrick. “Estos devoradores de libros, están media hora y te cobran un ojo de la cara”. Alguien le contestó una vez que no le cobraba los 10 minutos de tiempo por resolver el problema, si no todo el tiempo que había invertido en aprender cómo resolver su problema en 10 minutos.

longueras

El caso es que a Patrick B., le cayó el tema agile y le tocó empaparse de todo esto de los “agiles”. Como Patrick B. era un tipo con recursos, lo primero que hizo fue teclear www.google.com  y buscar “agile V Model” y Eureka! Encontró una página que se titulaba “¿por qué Agile es mejor que V-Model?“. Le pareció curioso que estuviera la séptima y que hubiera antes páginas extrañas que hablaban de manuscritos, comunidades y trincheras. Patrick B. pensó que es lo mismo que cuando buscas cracks que te sale porno por todos sitios.

agile vmodel perturbado

Patrick B. vio un poco los dibujos y sintió que ya sabía de qué iba. Tras un análisis de 30 segundos llegó a la conclusión de que estaba muy bien desde el punto de vista teórico, pero en proyectos de verdad, de los que acaban con sobre-coste o se cancelan, esto no era aplicable… y menos en el suyo. Nunca le llegó a gustar eso del burndown chart: “eso de que la línea vaya hacia abajo y no hacia arriba, le resultaba extrañamente inquietantemente”.

sherlock2

Se  creó un backlog con las cosas que había que hacer, “historias de usuario” las llaman los agilistas. Debían tener una prioridad y un criterio de aceptación. Esto del scrum, es un marco de trabajo así que el bueno de Patrick B. decidió hacer su propia implementación adaptándolo a las necesidades de su proyecto. Decidió que iba a ser product owner y scrum master ya que estos roles se adaptaban más a lo que él conocía de antes. Dicen que son roles que no son compatibles por tener objetivos distintos, pero Patrick B. suponía que esta advertencia era como la fecha de caducidad de los yogures, es decir, opcional.

1241915072NEURAS

Empezaron con las reuniones diarias. Al principio las hacían de pié, pero a partir de los 45 minutos ya les dolía la espalda y decidieron hacerlas sentados. Cada uno contaba lo que había hecho el día anterior y lo que iba a hacer ese día. Dejaron de usar la pizarra porque tener que actualizarla era agotador y la verdad es que nadie la utilizaba. Al poco tiempo tampoco le encontraron mucho sentido a la reunión diaria, salvo para tomar el café de la mañana. Conocieron a mucha gente durante estas dailies ya que la gente se paraba para ver que hacían y algunos acabaron quedándose por hábito. Patrick B. conoció a su mujer en una daily.

batman

Las historias de usuario se mantenían tanto tiempo en la pizarra en progreso que tuvieron que designar responsables de historia de usuario para “ver si eso se movía un poco”. Patrick B. decidió ahondar un poco, mirando el las retrospectivas de los equipos de desarrollo. No solía echarles un vistazo porque opinaba que la gente al final acaba quejándose y no siendo constructiva. Hizo una lista con los últimos sprints pero no obtuvo respuesta ninguna a su problema. Decididamente pensó que la gente se quejaba por vicio. He aquí algunas de sus incoherentes quejas:

  • Los test unitarios tardan 3 horas en ejecutar.
  • Baja cobertura.
  • Rama de desarrollo inestable.
  • Cambios en mitad del sprint.
  • Demasiadas reuniones.
  • Si no nos hacen caso, que no nos pregunten, por favor.

shutterstock_39087388-A

Para favorecer la comunicación, Patrick B. decidió implantar reuniones diarias donde participaran algunos miembros del proyecto de distintos equipos. Eran unos 20 diariamente y trataban temas tan variopintos como el problema que había habido con tal módulo de desarrollo, problemas en testing, en especificaciones o los problemas de Pepe el chico de mantenimiento, que todos los días pasaba por allí hasta que al ver tanta gente reunida decidió tomarse el café de por la mañana con ellos.

tapon-reuters--644x362

Como Patrick B. siempre decía, “esto de las metodologías ágiles es sólo aplicable a entornos de laboratorio. En el mundo real, no funcionan.” No tenían ningún resultado positivo, el número de historias de usuario resueltas no bajaban. La motivación de los equipos estaba por los suelos y la calidad del código estaba deteriorándose cada día más. Patrick B. no paraba de repetir que no funcionaba en entornos reales porque se trataba de metodologías de plastilina.

El jefe de departamento contrató a un consultor Agile muy famoso que les dijo que tenían que partir las historias para reducir el cycle time, los sprints deberían ser del mismo tamaño para poder medir la velocidad del equipo y tenían que volver a hacer retrospectivas, dailies y planificaciones en los sprints. Patrick B. no entendía cómo podía todo eso arreglar su problema. No veía en que podía ayudarles nada de lo que ese famoso agile coach les decía. En las páginas web que había leído sobre agile no ponía absolutamente nada de “cycle time”, o de que los sprints tenían que tener el mismo tamaño. Patrick B. finalmente llegó a la conclusión de que este consultor al que él había admirado durante tanto tiempo se había vuelto tan teórico que ya no tenía los pies en la tierra: en alguna ocasión hasta le había visto intentar levitar.

Coach

En definitiva, Patrick B. se dio cuenta de que nada de esto funcionaba así que decidió volver a la metodología que tenía antes. Un maravilloso modelo en V, que aunque nunca les había dado buenos resultados, estaban acostumbrados a utilizar. Su modelo en V era algo particular y por eso Patrick B. había hecho algunos ajustes:

  • No hacían un análisis previo porque era una pérdida de tiempo ya que los requisitos cambian.
  • Preferían empezar el desarrollo antes de tener los requisitos. Ya que daban prioridad al software corriendo frente a documentación exhaustiva.
  • No creían en los test unitarios. O sólo en aquellas partes importantes…y si hubiera tiempo.
  • En cuanto a la verificación si tenían tiempo lo harían. Pero lo más seguro es que reservaran un mes de la planificación antes de la calificación con cliente para resolver bugs.

american ps

Así, Patrick B. volvió a la oscuridad de la que procedía sin haber aprendido absolutamente nada y con la extraña convicción de que ninguna metodología ágil podía aplicarse a proyectos de verdad y concretamente… al suyo propio.

autocritica

Como vemos en el relato, el problema no es la metodología, simplemente la actitud de las personas. Al final decide volver a lo mismo que tenían antes, pero deciden ajustarlo a su propia comodidad, rompiendo con todos los principios de V-Model, de forma que tampoco están haciendo un modelo en cascada, simplemente están haciendo otro tipo de rituales. Este relato aunque es inventado, las cosas que se cuentan son cosas que en algún momento, en algún equipo y en alguna empresa han ocurrido tal cual. Os invito a reflexionar, si realmente somos parte del ritual, o parte de la solución. La autocrítica, es el primer paso de la excelencia.

https://www.scrum.org/ScrumBut

PDFicono EXTENDIDO

Libros que me recomendaron y llevo en mi mochila

A lo largo del camino de cambio y renovación que me ha llevado a romper muchos de los paradigmas en cuanto a desarrollo software se refiere, he ido recopilando una serie de libros que algunos he leído ya y otros los tengo en mi backlog personal. Son libros que siempre tienen una historia por detrás y que han sido recomendados y comentados de forma repetitiva con aquellos que he considerado mis mentores. Estos libros salieron de escenas cotidianas en trabajo, durante la comida, el café de por la mañana. Momentos de charla en los que sale el nombre de un libro o un nuevo concepto que consecuentemente nos lleva a buscar el libro que le dio origen.

escalera-libros-educacion

A Pablo se le podría describir como una persona disciplinada y altamente apasionada con la ingeniería software, le he puesto el avatar de Dark Vader Mr. Potato, primero porque desde que le conozco siempre ha tenido un Dark Vader potato encima de su escritorio y segundo porque le pega: te pega, y lo sabes.

julio_iglesias_y_lo_sabes

José no suele tener ningún Mr. Potato encima el escritorio, pero por su personalidad y su formación como coach, así como por su sabiduría y su grandes dotes como mentor, creo que el que más le encaja de los personajes es Yoda. Y curiosamente existe un Yoda Mr. Potato que viene ni que al pelo para poderlo utilizarlo como avatar.

potato-heads-4

Hay que decir que he aprendido mucho de ambos (y sigo aprendiendo), así que he creído que merecía la pena incluirlos en un post. Yo también he sido en alguna ocasión mentor, y la verdad es que siempre ha sido un orgullo ver los resultados de esos granitos que vamos dejando a lo largo del camino. Así que me ha parecido buena idea, entre broma y frikada starwars hacer una recomendación de libros y a la vez hacer mención a algunos recuerdos con ellos.

mochila

¿Qué libros llevo en mi mochila? Pues suelen ser libros que rompen con las creencias clásicas de desarrollo software. Libros que te argumentan cuál ha sido el problema del software, de la motivación o gestión de equipos en los últimos años. Libros que te abren los ojos y te hacen darte cuenta que la realidad que vivimos en muchos proyectos: tomamos decisiones incorrectas porque no entendemos cuales pueden ser las consecuencias de nuestras decisiones o de nuestra falta de las mismas.

choice.png

Flow: principles of the product development.

Donald D. Reinersten.

potato vaderPablo, no paraba de repetir una y otra vez que si lleváramos un contador en la cabeza en el que salieran euros “clink clink clink” (sonido de los euros cayendo sobre tu cabeza) tomaríamos decisiones distintas de las que tomamos habitualmente. Estamos anestesiados, decía, se nos ha olvidado pensar y estamos aquí para ganar dinero con los proyectos, algo que nos olvidamos. Un cambio de paradigma es a lo que se refería él con sus palabras, tomamos decisiones pero ¿en base a qué?, si hacemos un muestreo y le preguntamos a muchos desarrolladores de productos cuanto coste les supone un retraso en una entrega, obtendrás seguramente respuestas dispares. Y es que tan sólo el 20% sabrían calcular cuánto dinero pierde su empresa en un día de retraso. Si trabajamos para que nuestros productos se vendan, ¿por qué tomamos decisiones que nunca un economista tomaría?, porque nuestras decisiones están basadas en creencias erróneas.

el-tiempo-es-dinero640

Drive (Todo lo que no nos contaron sobre la motivación)

Daniel Pink

yodaJosé comenzaba el segundo bloque del curso de Scrum Master diciendo ¿Qué es para vosotros la motivación? Se produjo un silencio. Durante esta época estaba obteniendo la certificación de Life Coach y sabía cuán importante era jugar con el silencio con la audiencia. ¿Si os pagaran más… os sentiríais más motivados? Todos se miraron con cara estupefacta dando por hecho que la respuesta era obvia, pero José volvió a preguntar ¿cuántos reduciríais vuestro sueldo por tener más tiempo libre o mayor flexibilidad horaria? Después de cinco minutos de reflexión comenzó con la presentación. Daniel Pink, en su libro “Drive”, nos explica… Y es de siempre se ha creído que podías motivar a una persona con más dinero, y la realidad demuestra que la motivación no funciona de esa manera y mucho menos en entornos creativos. La gente que trabaja en desarrollo software le apasiona su trabajo, se divierten con él, buscan un propósito y adquirir maestría en lo que hacen. Quieren evolucionar, resolver ellos solos los problemas con autonomía. El dinero simplemente no desmotiva, pero no motiva por sí mismo.

Cyanide-and-Happiness-motivacion

Kanban.

David J. Anderson

potato vaderPablo te coge y te pone delante de una pizarra con postits. Dais un paso hacia atrás y empieza a hablarte de Flow. Fíjate como las historias de usuario avanzan, ¿Qué te dice la pizarra? ¿Qué información te proporciona? Ahora mismo tenemos demasiada variabilidad, demasiadas historias en curso, ¿en cuántas puedes focalizar tu atención? El Working In Process (WIP) es la clave, fíjate en este proyecto y en este instante tenemos acumuladas demasiadas historias en testing. Hay un cuello de botella en testing y todavía nadie se ha percatado, estamos anestesiados.

anestesiados.jpg

Agile Estimating and Planning

Mike Cohn

yodaJosé se había percatado de que el product owner había pedido que le calcularan la complejidad en cada historia de usuario a parte de la estimación en días ideales. “Juanma, ¿has pensado en utilizar tallas de camisetas para clasificar las historias de usuario?, es un concepto más fácil de entender.” José quería ayudar a Juanma a darse cuenta de que el tamaño de las historias debía reducirse para reducir a su vez el cicle time, era su objetivo, pero le había picado tanto la curiosidad de la utilización de Juanma de la complejidad y a su vez de que entendía él por complejidad. Por eso decidió aparcar por un momento el tema del cicle time. A lo largo de los años se había dado cuenta que la gente no entendía este concepto de “complejidad” para clasificar el tipo de historia. Para unos la complejidad es lo difícil que sea, para otros la incertidumbre que tengan… no parece una buena medida aunque sea recomendada por algunos Scrum Masters. Sin embargo, es más fácil el concepto de talla de camiseta, al menos para clasificar las historias de usuario.

TallasCamisetasMultilenguajeNEW

Management 3.0.

Jurgen Appelo

potato vaderyodaJosé y Pablo se juntan y empiezan a hablar de equipos auto organizados. ¿Pero como logramos que un equipo sin experiencia logre sus objetivos sin llegar a decirles que hacer? Boundaries dice Pablo, debes limitar su área de actuación, establecer límites como vallas electrificadas. Diles que pueden o no hacer y vete abriendo esas boundaries según el equipo vaya madurando. No les digas que hacer, deja que se equivoquen. Pero sólo una vez, dice José.

scrum-meets-management-30-how-to-apply-the-latest-management-ideas-to-strengthen-scrum-4-638.jpg

Guía de Arquitectura N-Capas orientada a Dominio con .NET – Domain Driven Design

Cesar de la Torre, Unai Zorrilla, Miguel Ángel Ramos, Javier Calvarro

potato vader “No quiero meterme en la arquitectura, quiero que vosotros como equipo decidáis cual es la mejor”. Primer día oficial de proyecto, estábamos siete personas en una sala y un ordenador. Se trataba de MOB programming y Pablo era el Agile Master. La única restricción que os pongo es que las capas estén bien definidas y separadas por interfaces. Test unitarios es un deber. ¿Habéis leído el libro negro? Lo necesitaréis para crear las tuberías. Tres meses de desarrollo, pair programming, teníamos una arquitectura que se adaptaba a los cambios propuestos por el cliente.

225px-Necronomicon_prop

 Inteligencia emocional

Daniel Goleman

yoda¿Por qué crees que tienes un problema de comunicación? – Dijo José mirándote fijamente y esperando ver cuál era tu reacción. Creo que era mi primera sesión o segunda sesión de coaching tratando de mejorar esta faceta. Quería ver si realmente ese problema de comunicación era un problema real o realmente era una creencia mía que debía romper trataba de generarme una disonancia cognitiva. La verdad es que todos estamos llenos de paradigmas, ideas preconcebidas que nacen de nuestra experiencia, que pueden ser ciertas o no, pero que si realmente creemos que tenemos ese problema, sea cierto o no, tenemos un problema

.coaching_session

Flow

Mihály Csíkszentmihályi

potato vaderPablo estaba concentrado en su mesa, si alguien se acercaba miraba de reojo y continuaba trabajando como si nadie existiera. Estaba en pomodoro. Durante los 25 minutos de pomodoro había decidido no ser interrumpido y lograr tener durante su jornada laboral el mayor número de momentos de flow que pudiera, momentos de máxima productividad.

pomodoro

Otros libros recomendados son Las cinco disfunciones del equipo y Agile Retrospectives. Salieron tantos que no acabaría nunca de escribir, y este post tiene que acabar en algún momento. No obstante, eso no quiere decir que no siga metiendo más libros dentro mi mochila. Espero que disfrutéis esta selección.

 PDFicono EXTENDIDO

REFERENCIAS:

[1] Flow: principles of the product development – Donald D. Reinersten
[2] Drive – Daniel Pink
[3] Kanban – David J. Anderson
[4] Agile Estimating and Planning – Mike Cohn
[5] Management 3.0 – Jurgen Appelo
[6] Guía de Arquitectura N-Capas orentada a dominio con .NET
[7] Flow – Mihály Csíkszentmihályi