Hacer todo al mismo tiempo

En cualquier área de la industria es necesario que quienes trabajan se hagan cargo de múltiples tareas. Un error que con frecuencia se hace es tratar de hacer todo al mismo tiempo.  Parece obvio que es mejor hacer una cosa después de la otra para producir muchos y buenos resultados, pero desgraciadamente la tentación de intentar abarcarlo todo simultáneamente es muy grande.

A lo largo de mi carrera, como programador, jefe de proyectos y gerente en desarrollo de software, he visto en multiples ocasiones personas y organizaciones muy capaces fracasar por tratar de hacer mucho simultáneamente. Personalmente me ha ocurrido y debo confesar que debo esforzarme a veces por evitar caer en la tentación.

Aquí algunas razones por las cuales es tentador tratar de paralelizar:

• Crea la impresión de "estar haciendo algo", de no haber dejado de lado el tema. 
• Hacer varias cosas en paralelo puede servir para utilizar mejor la capacidad disponible, pues existen tiempos de espera en toda actividad. Sirve para "aprovechar mejor el tiempo".
• Aprovechar el hecho de que una organización tiene múltiples miembros para tratar multiples temas en paralelo

Esos puntos pueden ser ciertos y puede que paralelizar tenga en algunos casos un efecto positivo.  Lo cierto es que también tiene riesgos:

• Cada una de las actividades que se realiza en paralelo, avanza más lento que si se llevaran a cabo una después de la otra (en secuencia). 
• Debido a que actividades que se realizan en paralelo tardan más en finalizar, se tiene permanentemente la sensación de avanzar lento y entregar resultados de mala calidad.  Esto es muy, muy, muy frustrante!
• Mantener distintas actividades andando simultáneamente requiere más concentración pues hay que estar pendiente de cada una de las actividades que se realiza. Puede parecer trivial, pero no lo es. En la práctica nos cuesta hacer dos cosas a la vez sin equivocarnos o dejar de prestar atención a una de las actividades.
• Paralelizar implica aumentar el esfuerzo requerido para coordinar los distintos procesos. No hay que menospreciar este esfuerzo!

Una buena organización se preocupa de ordenar las tareas en una única lista e intenta resolver las tareas una después de la otra, concentrando toda su capacidad y energía en hacerlo rápido y bien. No siempre es posible hacerlo, pero es una meta que hay que seguir.

Lo difícil es ponerse de acuerdo en la lista de tareas y definir el orden (no prioridad!) de ellas. Lograr acordar dicha lista común es una difícil actividad, pero lograr hacerla es un hito tremendamente importante para toda organización. He visto organizaciones florecer después de hacer este "pequeño" cambio.

To Scrum or not to Scrum

En el mundo del desarrollo de software ha ocurrido una pequeña revolución en los últimos años. La gente se ha dado cuenta que la calidad del software no depende principalmente de pesados procesos y herramientas, sino de la gente que lo hace, de cómo se comunica, de lo que sabe y qué es lo que la motiva. El pensamiento ha llevado a cambiar las bases del desarrollo de software por principios y conceptos que otorgan "agilidad".

Ese descubrimiento (nada nuevo, dirán algunos) ha creado una nueva industria de gente que ayuda a equipos de desarrolladores de softwre a modificar la forma en que trabajan para ser más ágiles. Han aparecido expertos, coaches, miles de libros, programas, conferencias y cursos.

Uno de esos "productos" que ha nacido se llama "Scrum", es un sistema, un marco (framework) para desarrollar software. Consiste en una serie de métodos, consejos, definiciones que permiten a un equipo trabajar de manera ágil.

Me parece bien, muy bien. Es bueno que existan esta clase de sistemas, claramente definidos.

Pero al mismo tiempo es un peligro. El peligro está que que esos sistemas se usen ciegamente, como quien sigue un proceso, sin pensar, sin siquera cuestionarse que algo podría hacerse de mejor manera.

Yo prefiero seguir principios que seguir una definición tan detallada como Scrum. Eso me deja pensar si lo que hago sigue los principios, y si no lo hace, pues debo corregir la dirección. Prefiero eso que pensar si estoy haciendo Scrum como dice en el libro, sin pensar que las ideas del libro puedan alejarme de una mejor manera de trabajar.

Scrum es mejor que Waterfall, Scrum es mejor que ningún proceso definido. Pero en mi experiencie, tener como meta ser cada día mejor y seguir los principios de la agilidad entrega más libertad y mejores resultados.

Acerca de la importancia de las retrospectivas

En mi experiencia, nunca debe faltar tiempo para retrospectivas.  Nunca, nunca, nunca!

He visto proyectos, he trabajado en proyectos y los he gestionado y conozco el costo que tiene no tomarse suficiente tiempo, frecuentemente,  para reflexionar acerca de la forma en que se trabaja y de las maneras que existen para mejorar, para superar problemas, para acercarse un paso más a la excelencia.

He visto a geniales arquitectos de software, analistas, programadores, testers fracasar usando métodos ágiles, siguiendo con fervor las ideas de Ken Schwaber, pero olvidando tomarse tiempo para hacer retrospectivas.

Si tu proyecto está tarde, si crees que no tienes tiempo que perder para lograr producir el software en que trabajas, entonces para por unos minutos, o por algunas horas y habla con tu equipo acerca de aquello que les impide ser más rápidos y mejores.  Da igual si usas Scrum, FDD, V-ModelXT o lo que sea, el tiempo invertido se recuperará más rápido de lo que puedes imaginar!

Gerentes y Agilidad

Hoy toda la industria del software habla de agilidad y Scrum. Quienes desarrollan software trabajan cada vez más en equipos multifuncionales, que buscan organizarse solos.  La pregunta que crece y crece es el rol de los gerentes, jefes de departamentos y áreas en una organización que desarrolla software de forma ágil.

Si los equipos se organizan solos, cuál es el rol del jefe? Si los equipos determinan por su propia cuenta, a través de retrospección, lo que deben modificar para ser más productivos, qué es lo que hace el jefe de un departamento de desarrollo de software?

Incluso el tema de la capacitación es algo que ocurre dentro del equipo.  Si se determina que alguien necesita capacitarse para rendir más, pues el equipo (con ayuda quizás de un scrummaster) lo organiza.  No era esa un área exclusiva del jefe o del área de recursos humanos?

El movimiento de agilidad y lean han cambiado mucho la industria del software y de seguro tendrá un impacto en el resto de las organizaciones.  El jefe ha pasado de ser una máquina de decisiones a ser un ayudante, que ayuda a resolver los problemas y un coach.  Si el foco de los métodos ágiles está en los equipos, el del jefe de desarrollo (o R&D) está en crear el entorno para que los equipos puedan desenvolverse y en cada individuo.  Qué hacer para que cada empleado obtenga retroalimentación (feedback)? Qué hacer para que aplique y desarrolle sus talentos? En qué dirección debe desarrollarse para que sus habilidades y sus resultados crezcan?

El mundo del desarrollo de software ha cambiado mucho, a favor de programadores, testers y analistas. Ahora por fin es permitido y requerido usar el cerebro completo. Para quienes lideran el mundo también es muy distinto, mucho mejor.