La Invasión de los Gerentes de Proyecto

Hace unos días me junté con un viejo amigo, a quien no veía hacía un buen tiempo; llamémoslo Luchín. Mi amigo trabaja hace ya unos 4 años como desarrollador senior en una empresa local proveedora de soluciones de software. Muy acongojado, Luchín me contó: "Ahora sí que se fue todo al diablo. Llegó la invasión de los gerentes de proyecto a la empresa". Mi primera reacción fue de decepción, pues durante 3 años trabajé en esa empresa y me esforcé por forjar una cultura que cultive precisamente lo contrario a lo que esa frase vaticinaba.

Esta situación coincidió con un thread muy activo a inicios de este mes en la lista de la comunidad Agile Perú, el cual fue abierto con una cita extraída de un tweet del mundo real: "Ya no quiero ser ingeniero, quiero ser gerente de proyectos!" El thread creció muy rápidamente hasta llegar a tener más de 60 replies en menos de dos días. Es evidentemente un tema sensible, un tanto polémico y que está "de moda".

¿Pero, de qué estoy hablando exactamente? Vamos al grano. Tomaré como definición general de gerente de proyectos a alguien que:

• Ya no desarrolla software
• Les dice qué hacer a los desarrolladores
• Es pagado considerablemente mejor que a los desarolladores
• Es visto con mejores ojos y tiene más status que los desarrolladores ante todo el personal
• No es explotado ni forzado a trabajar horas insanas
• Tiene el privilegio de repartir tarjetas de presentación y firmar e-mails que dicen "Gerente"

¿Y cuál es problema con todo esto?

Bueno, desde mi humilde punto de vista, veo lo mismo que Tobias Mayer describió muy claramente hace ya 2 años en esta serie de iluminadores artículos:

• Oppression, Revolution and the Future of Scrum — #1
• Oppression, Revolution and the Future of Scrum — #2

Extraigo algunas secciones imperdibles:

The tragedy of many revolutions is that once successful the leaders tend towards the same behavior that caused the need for the revolution in the first place. The oppressed become the oppressors, i.e. they take on essentially the same behaviors because they don’t know how else to behave.

George Orwell characterized this tendency in the novel Animal Farm, an allegory for the Russian Revolution and subsequent events.  By the end of the book, the revolutionary leader, Napoleon (a pig, by some charming coincidence) is walking on two legs, dressing in human clothing and selling his best friends out for horse meat.

There can be no really pervasive system of oppression . . . without the consent of the oppressed.” —Florynce Kennedy

Too often the oppressed don’t want change; they simply want to be on the other side of the oppression.  That is the ugly reality we live in.  We have all seen individuals rise to middle-management and change behavior accordingly, fitting in to the system and emulating their superiors.  Many of us have seen teams fall apart through infighting — indeed a key part of the Scrum Master training course is focused on dealing with such situations. Reward systems in most software corporations are based on individual superiority, and to be superior, others must be considered inferior.

Commenting on the syndrome of in-fighting between oppressed natives in colonized countries, Paulo Friere notes “At a certain point in their existential experience the oppressed feel an irresistible attraction towards the oppressors and their way of life.  Sharing this way of life becomes an overpowering aspiration.  In their alienation, the oppressed want at any cost to resemble the oppressors, to imitate them, to follow them.”

En resumen, esto significaría que muchos desarrolladores al hartarse de la opresión a la que son sometidos por sus respectivos jefes o gerentes de proyecto, no ven otra salida que convertirse en opresores ellos mismos y a perpetuar (probablemente de forma inconsciente) el mismo modelo de opresión antes nuevos desarrolladores.

Esta opresión se expresa comúnmente a través del lenguaje de los opresores, con frases del tipo: "No sé que haces pero lo quiero para mañana".

Lo paradójico de todo esto, al menos en mi caso, fue que hace poco tuve que firmar un mail con el título de Gerente de Proyectos. No precisamente por una preferencía mía, sino del cliente con el que estaba trabajando, quien a su vez deseaba proyectar cierta imagen ante su respectivo cliente.

Y ustedes, ¿qué quieren ser cuando "crezcan"?

Propuestas presidenciales SMART

La primera idea para escribir sobre este tema la tuve durante la campaña para las elecciones municipales de hace unos meses. Pero se puede trasladar tal cual a la presente campaña presidencial.

Existe una sencilla manera de describir los objetivos a los que puede aspirar una persona o una empresa. En inglés, esta técnica recibe el acrónimo SMART (que se puede traducir como astuto, listo o incluso "vivo"). Así, la idea es establecer objetivos SMART (o SMART Goals) en nuestras vidas.

Es una técnica bastante conocida y de hecho ya la había encontrado en libros como Behind Closed Doors y Pragmatic Thinking & Learning. Incluso, es bastante útil cuando se emplea en el contexto de una retrospectiva. Leyendo los posts que mi buen amigo Abner realizó hace poco, fue que me volví a encontrar con este concepto.

La idea es que cuando definamos objetivos, cada uno de ellos debería poseer las siguientes cualidades:

• S - Ser eSpecífico 
• M - Ser Medible
• A - Ser Alcanzable
• R - Ser Relevante
• T - Estar limitado por el Tiempo

Por ejemplo, decir que mi objetivo es "aprender a bailar" no es SMART. Decir, en cambio, que mi objetivo es "poder bailar salsa, cumbia y merengue en las fiestas sin repetir los mismos pasos en cada baile y sintiéndome cómodo y contento al hacerlo en un tiempo límite de 3 meses" sí es SMART.

Es más, gente como Joanna Rothman recomienda que, cuando planifiquemos, nos fijemos objetivos SMART pequeños y progresivos, de modo que podamos medir el avance más fácilmente. Siguiendo con el ejemplo anterior, quizás sería mejor establecer como primer objetivo "aprender 3 pasos básicos de salsa en máximo 2 semanas". Una vez conseguido este objetivo, podríamos fijar el siguiente.

¿A qué viene todo esto? Bueno, a que cuando escucho a algún candidato político hablar sobre sus propuestas, busco evaluarlas según el criterio SMART. Y para ser franco, durante la última campaña municipal, no encontré mucho de SMART en el discurso de ninguno de los candidatos.

Veremos si esta vez, al menos uno me sorprende cuando tome la palabra en alguna entrevista, mitin o debate.

Ágiles 2010: 3ras Jornadas Latinoamericanas sobre Metodologías Ágiles

Ágiles 2010 es una excelente oportunidad para encontrase con
profesionales de IT de la región, interesados en compartir sus
experiencias, debatir y capacitarse en temas relacionados con el
desarrollo de software a través del uso de metodologías ágiles.

Esta tercera edición, con sede en la ciudad de Lima, Perú, contará
con la presencia de especialistas locales e internacionales, quienes
compartirán su conocimiento durante los cuatro días que durará el
evento.

El programa incluye distintos tipos de actividades: presentaciones,
sesiones interactivas, talleres y espacios abiertos de debate.

Entre los invitados internacionales se encuentran los keynote
speakers Lee Devin y Joshua Kerievsky, que también estarán brindando
cursos durante el evento.

¡Inscríbete y se parte de Ágiles 2010!

La retrospectiva de Scrooge

Supongo que todos están familiarizados con la novela A Christmas Carol de Charles Dickens (o alguna de sus adaptaciones), en la cual un viejo gruñon, Ebenezer Scrooge, es visitado durante la Nochebuena por tres fantasmas quienes le hacen reflexionar, reencontrase con su niño interior e imbuirse de espíritu navideño. Hace poco Jim Carrey protagonizó una versión en 3D para la pantalla grande.

Bueno, en las últimas fiestas me topé con una de las tantas versiones en televisión, esta vez representada por Patrick Stewart. Sí, el mismísimo Profesor Xavier de X-Men y Capitán Jean-Luc Picard de Stark Trek. Y sí, sé que ya hace tiempo que pasó la Navidad.

El punto es que al observar la narración de la película en cuestión empecé a encontrar asombrosas similitudes entre lo que ocurría con nuestro héroe (¿o anti-héroe?) y lo que usualmente sucede durante las retrospectivas de los proyectos de software. Veamos a qué me refiero, y para esto nos basaremos en el framework flexible de restrospectivas de Esther Derby y Diana Larsen.

El primer fantasma en visitar a Scrooge es el de las navidades pasadas, quien le recuerda a Scrooge sucesos de su pasado, especialmente de su infancia, adolescencia y juventud. Esto coincide con la etapa de Recolección de Datos (Gather Data), pues lo que se busca es que Scrooge contemple, a modo de observador externo, los hechos relevantes que tengan influencia sobre su comportamiento en la actualidad.

El segundo fantasma es el de las navidades presentes. Este le muestra cómo festejan aquéllos del círculo de personas cercanas a Scrooge. Tanto pobres como ricos personifican el espíritu navideño y celebran con lo poco o mucho que poseen. A partir de aquí se comienzan a formar reflexiones profundas dentro del protagonista (Generate Insights), al combinar elementos pasados y presentes,de maneras no obvias para alguien que se había acostumbrado a vivir de cierta manera y sin pensar mucho al respecto.

Finalmente, el tercer fantasma, el de las navidades futuras, le muestra a Scrooge el triste y lamentable porvenir que le espera, acaso decida seguir por el mismo rumbo carente de compasión y benevolencia con el prójimo. Es aquí que termina la etapa de reflexión y Scrooge comienza a tomar decisiones sobre cómo debe comportarse y qué elementos de su personalidad debe cambiar para mejorar (Decide What to Do).

Si tienen la oportunidad de ver esta película, prueben mirándola a través de estos nuevos ojos y se darán cuenta por qué se afirma comúnmente que las retrospectivas (entre otras prácticas ágiles) no son más que sentido común aplicado al contexto de los equipos de trabajo y el desarrollo de nuevos productos de software.

Discos, transparencia y cuellos de botella

Hace unas semanas fui a comprar unos CD’s a Plaza San Miguel (sí, soy uno de esos especímenes raros que todavía compra discos originales). Hacía tiempo que no iba por allá, así que estaba un poco desorientado, pues varias tiendas se habían mudado de sitio. Dando unas cuantas vueltas por el lugar, encontré Sonodiscos, una tienda que a simple vista se nota que no es parte de una cadena, sino que, más bien, aparenta tener tradición y ser parte de un negocio familiar.

El punto es que, cuando empecé a revisar los discos que tenían a la vista, me vi bastante desorientado. La razón es simple: ninguno de los discos tenía el precio adherido al empaque! Lo que exhibían era un código algo críptico y para nada indicativo.

El producto de esto es que, para un humilde melómano como el que escribe, se me hacía imposible evaluar el costo-beneficio de las posibles compras que deseaba realizar, pues cada vez que necesitaba saber un precio debía consultar con alguno de los empleados del lugar.

La situación llegó a un punto tal, que me comencé a sentir bastante incómodo por la falta de información, o más bien por la falta de rapidez en conseguirla y por el cuello de botella que se generaba con el personal de la tienda al intentar conseguirla.

Ahora, ¿cuál es mi punto con esta historia? Pues básicamente dos: el primero es que, muchas veces en los proyectos de software, pecamos de falta de transparencia. Usualmente, la razón de esto es el miedo. Miedo porque, si somos transparentes, el resto de personas nos juzgará o, peor aún, nos castigará por nuestros errores. Me atrevo a soltar la hipótesis de que, en el caso de Sonodiscos, el dueño podría tener miedo de la competencia y de que ésta acuda a su tienda a espiar los precios.

El segundo punto es que, al ocultar información, creamos cuellos de botella artificiales, innecesarios y que entorpecen la colaboración y la consecución de objetivos. En mi caso, tenía poco tiempo para visitar la tienda y mi objetivo era comprar la mayor cantidad de discos de artistas que no conociera mucho en el menor tiempo posible y bajo un presupuesto predefinido.

Lamentablemente, no conseguí mi objetivo a cabalidad. Lo siento Sonodiscos, pero la próxima vez iré directamente a Phantom. Aunque los precios a veces son ligeramente más caros, me ofrecen una mejor relación costo-beneficio para alcanzar mis objetivos.

Entrevista con Diana Larsen

El evento Agiles 2009 que se llevó a cabo en Florianópolis, Brasil llegó a su fin la semana pasada. Fue una vivencia gratísima compartir conocimiento y experiencias con tanta gente interesada en la Agilidad, principalmente de Brasil y Argentina, así como también conocer a personas como Diana Larsen, autora del libro “Agile Retrospectives: Making good teams great!” y presidente del directorio de la Agile Alliance.

En esta entrevista, Diana nos habla sobre qué son las retrospectivas, de dónde vienen y cómo se estructuran.

Además toca algunos temas sociológicos, relacionados a las retrospectivas pero un poco más amplios y, finalmente, discute un poco sobre el futuro de la Agile Alliance y de Agile en general.

Powered by Podbean.com

Pueden bajarse la entrevista aquí.

En los negocios, ¿el tiempo es lo más importante?

No veo mucha televisión. Es más, ni siquiera tengo cable (!!??). Pero sucede que hace poco estuve mal de salud y tuve que pasar unos días en casa frente a la caja boba. Es así que descubrí este comercial de Interbank que me dejó un tanto intranquilo:

La dinámica de la publicidad gira entorno a la siguiente idea-fuerza: "En los negocios el tiempo es lo más importante." Si bien es obvio que el comercial está realizado en tono de burla o comedia, deja traslucir la que varios empresarios o ejecutivos piensan que es la mejor manera de gestionar a su personal, área o empresa.

Es decir, concentrarse en mantener a los empleados ocupados el 100% del tiempo, asumiendo que los objetivos planteados por los niveles superiores de la jerarquía son los correctos (sin una adecuada validación) y tratando de alcanzarlos lo más rápido posible, evitando crear espacios para el diálogo, la contrapropuesta y la generación de intercambios de opiniones que aporten valor. O visto de otro modo, desaprovechar la capacidad que cada persona tiene para crear, generar soluciones e ideas; en resumen, para innovar.

Veo varios problemas con esta forma de gestión. En primer lugar opino que lo más importante en los negocios no es el tiempo (a secas), sino generar valor en los clientes. Es decir ofrecerles productos o servicios de calidad que satisfagan sus necesidades. En segundo lugar está la suboptimización. El hecho de tener al personal ocupado todo el tiempo pierde de vista el objetivo real de lo que estamos haciendo y cómo podemos mejorarlo, alienta la separación entre las áreas funcionales de la empresa, la formación de colas de información (con las correspondientes demoras) y una presión excesiva sobre las tareas a realizar, lo que promueve una cultura de "tomar atajos" y acarrea una pérdida de calidad en las actividades que hacemos.

Una vez claro lo anterior, recién podemos empezar a discutir el factor tiempo. Obviamente, si nuestra competencia ofrece un producto o servicio con mejor calidad que la nuestra en la mitad del tiempo, estamos en problemas. Pero esto debe enfocarse como un problema sistémico, a modo de atacar las causas raíz que permitan generar soluciones y que eliminen los desperdicios dentro de nuestros procesos, teniendo en claro todo el flujo de valor, desde que una necesidad es detectada hasta que ésta es satisfecha.

CSP, ¿y ahora qué?

Hace unos días recibí la buena noticia de que había obtenido la certificación CSP (Certified Scrum Practitioner) de parte de la Scrum Alliance. Mi primera reacción fue de alegría y satisfacción, obviamente. No considero que sea una certificación fácil de obtener pues, a diferencia de muchas otras, lo que se evalúa es un cuestionario de unas 20 preguntas acerca de la experiencia que uno tiene aplicando (o al menos intentando aplicar) Scrum en un contexto específico. A diferencia de la certificación CSM, que sólo requiere llevar el curso (aunque próximamente será exigible un examen on-line de alternativa múltiple) y que tiene aproximadamente 56,000 personas certificadas en todo el mundo, la CSP sólo tiene alrededor de 600.

Una vez pasada la emoción, me empecé a preguntar qué es lo que vino antes y también qué viene después. Un paso lógico sería buscar obtener la CSC o CST, que no son nada fáciles (ni baratas, valgan verdades). Sin embargo, más que eso, en este momento me gustaría reflexionar un poco sobre la real utilidad de las certificaciones.

Hubo un tiempo en que buscaba obtener certificaciones de manera un tanto obsesiva, por varias razones: siendo valoradas en el mercado, usualmente llevan a un mejor sueldo y posición, demuestran el conocimiento que puedes tener en una determinada materia y por supuesto, ¡lo hacen sentir muy bien a uno cuando las recibe! No niego que me sirvieron de mucho, profesionalmente hablando. Pero la verdad es que de, de todo el conocimiento que adquirí estudiando para esos exámenes, una buena parte simplemente ha desaparecido de mi memoria, o para decirlo más elegantemente, no fue correctamente indexado y, por lo tanto, es inubicable.

La realidad es que para que el conocimiento sea realmente útil es indispensable acompañarlo de la experiencia. Es ésta la que permite validar lo aprendido, combinarlo en nuevas formas e incluso descartar aquellas cosas que no son tan válidas en la práctica. Ahora, todo esto suena muy obvio, ¿no? Sin embargo, muchas empresas no lo ven de esa manera. Se concentran únicamente en el certificado y no toman en cuenta la experiencia, confiando en que por poseer el cartoncito (o PDF) la persona será capaz de asumir los retos propios del trabajo. Esto sería similar a que se contrate a un gerente recién egresado de un MBA, ¡pero con ninguna experiencia gerencial!

Ahora, no estoy en contra de las certificaciones. Simplemente pienso que no es un indicador 100% fiable (quizás ni 50%) de lo que una persona puede hacer en el campo laboral y por lo tanto, considero que no debería jamás ser un requisito indispensable o exigible para un puesto relacionado al desarrollo de software. Las veces que he entrevistado gente (que han sido varias) he tenido mucho cuidado en este punto, llegando incluso a rechazar postulantes con muy bonitos certificados pero sin la experiencia necesaria o sin una personalidad que viera que encajaba adecuadamente con nuestra cultura empresarial.

Conferencia Internacional sobre Testing y Calidad del Software

Me llegó hace poco una invitación a esta conferencia, a llevarse a cabo en Bilbao, España a fines del mes de octubre. El programa se ve muy interesante. Desde mi punto de vista, una de las presentaciones que más destaca es la de Mary Poppendieck, una de las más importantes impulsoras del enfoque Lean en el mundo del software (Lean Software Development). 

Tuve la gran suerte de conocer a Mary durante el curso que dictó en Buenos Aires el año pasado, el cual fue una gratísima experiencia para mí. El conocimiento y la experiencia que destila con cada afirmación u opinión que vierte es realmente impresionante y digno de destacar.

Lamentablemte no podré asistir a esta conferencia, pero si alguno de ustedes trabaja con software embebido y está por allá durante esas fechas, creo que es un evento al que no puede dejar de asistir.

Primer Curso Certified ScrumMaster en español en Lima

Durante los días 31 de agosto y 1 de setiembre de 2009 se dictará por primera vez en Lima el Curso de Certificación de Scrum (CSM) en idioma español, oficialmente reconocido por la Scrum Alliance.

Esta es una excelente oportunidad de llevar este curso, pagando la tercera parte de lo que cuesta en Estados Unidos o Europa. Será dictado por Alan Cyment, el único Certified Scrum Trainer nativo hispanoparlante en el mundo.

Toda la información sobre el curso, así como el formulario de inscripción, la pueden encontrar en la página de la empresa organizadora, Open Edge Technologies, de la cual formo parte.

Espero verlos allí!