"¡Paralelizá!". Como desarrolladores de software, ¿qué nos pasa cuando un cliente nos pide que paralelicemos nuestro trabajo? Si sos como yo, es probable que no guste la idea de que te digan como tenés que trabajar. De hecho, se supone que formás parte de un equipo ágil autodirigido que sabe muy bien como organizarse para lograr los objetivos del proyecto. ¿Por qué nos dicen esto? ¿Será un tema de confianza? ¿Creerán que inflamos las estimaciones para trabajar sin presiones? ¿Hay un esfuerzo que no le estamos mostrando?

Dejame darte dos consejos (y algunas técnicas) que pueden traerte claridad y, de yapa, mejorar mucho más tu relación con el cliente.

Terminás la jornada laboral y cansado soltás los auriculares sobre la mesa, feliz por terminar el día pero molesto por la cantidad de cosas que tenes para hacer. De alguna manera, no te sentiste productivo. ¿Te suenan frases como "uf, son un montón de cosas", "ya no puedo con todo", "me siento desmotivado con todo esto", "me exigen banda de cosas, y para ayer", "me cansa, pero no puedo decir que no", "esto no se termina más" o incluso "¡que ganas de renunciar!"?

Si te sentís identificado con alguna de estas frases, es mi deseo que este post te dé ideas para experimentar y generar un cambio.

Hoy en día en el ámbito de la informática, muchas empresas están comenzando una transición de su cultura de trabajo hacia una cultura ágil. 

Si bien conocemos metodologías ágiles como Scrum o Kanban ¿que significa que un equipo sea ágil? ¿Mi equipo es ágil solo si aplica scrum? ¿Que características debe tener un equipo ágil?

Vamos entonces a ver que significa ser un equipo ágil.

Quizá estés familiarizado con el concepto de Pair Programming, o tal vez sea una práctica que normalmente no hacés o no conocés bien. Capaz pensás que lo estás haciendo perfectamente. O quizá creas que no. Podría ser que creas que tu organización rechaza la idea de hacer pair programming por pensar que es perjudicial para el negocio.

Si tenés algunas dudas sobre el Pair Programming o hay cosas que no te cierren de la práctica (¡más ahora en cuarentena!) te invito a que reflexionemos juntos.

En un equipo que trabaja con metodologías ágiles (como Scrum) llevar diferentes métricas durante el ciclo de vida de un proyecto es sumamente importante. Por ejemplo, ¿para qué traqueamos la velocidad del sprint, la cantidad de issues en testing, la performance de un módulo o la satisfacción del cliente? ¡Para tomar decisiones!

El Niko-Niko (del japonés "sonriente") es una herramienta que nos sirve para medir uno de los factores más importantes del proyecto: el equipo.

En un entorno en el que buscamos superarnos, una de las acciones que realizamos con más frecuencia es dar y recibir feedback. A veces lo damos inconscientemente como cuando decimos “Que bueno que sos con X cosa” o “Eso que tenes puesto te queda horrible”, y es normal que de esta forma nuestras opiniones queden como comentarios pasajeros y la persona a quien se lo estemos diciendo no lo perciba como una oportunidad de identificar una fortaleza o debilidad con el fin de mejorar, aprender y crecer.

Entonces ¿qué se supone que deberíamos decir? ¿qué deberíamos resaltar? ¿cómo lo estructuramos?

A la hora de trabajar bajo el marco de SCRUM, es probable que tarde o temprano nos veamos involucrados en participar de diferentes reuniones o actividades: la Planificación del Sprint, el SCRUM Diario, la Retrospectiva y la Demostración del Sprint. En este artículo haremos foco en esta última.