Hace unos días estaba leyendo la primera de una serie de entrevistas realizadas a varios desarrolladores de software sobre PHP, el lenguaje de programación. Me llamó la atención que el entrevistado mencionara su propósito de utilizar los principios SCRUM para el desarrollo de sus productos. Era la primera vez que oía de dicho enfoque por lo que la curiosidad me llevó a investigar un poco más.
Me enteré que existe una organización llamada Scrum Alliance (http://www.scrumalliance.org) que ofrece cursos y certificaciones sobre estos principios que, en una primer lectura, son muy prometedores pues de acuerdo a la página de la alianza:
"Scrum is a simple yet incredibly powerful set of principles and practices that help teams deliver products in short cycles, enabling fast feedback, continual improvement, and rapid adaptation to change."
También me enteré que el proceso scrum tiene ya cerca de veinte años y su creador, Jeff Sutherland, había sido influenciado por un artículo publicado en 1986 en el Harvard Business Review por Hirotaka Takeuchi e Ikujiro Nonaka llamado "The new new product development game". En tiempos del hipertexto, donde una cosa lleva a otra, me encontré pronto leyendo el artículo de marras.
En él, se compara el desempeño de los equipos de generación de nuevos productos con los equipos de Rugby, en particular con la formación scrum. La propuesta de los autores es que el modo clásico de desarrollo de productos al que llaman de 'carrera de relevos' implica tiempos de desarrollo largos. Ese modelo, basado en etapas bien definidas conducidas por equipos de expertos donde una fase empieza hasta que la anterior ha concluido, pueden no resultar flexibles ni veloces en tiempos donde dichas características son necesarias para operar en entornos altamente competitivos.
En su lugar, resaltan la integración de equipos multidisciplinarios, con cierta autonomía y capaces de auto organizarse, conscientes de la importancia de su tarea. Estos equipos trabajan a partir de un requerimiento expresado de forma muy general pero que representa un reto. A continuación el equipo se organiza y empieza el desarrollo avanzando como un todo, trabajando en varias fases al mismo tiempo, sin tener que esperar a terminar una para iniciar la siguiente, corrigiendo donde haya que corregir y adaptando donde haya que adaptar.
De acuerdo a los autores hay ciertos efectos benéficos para una organización que opere de esta forma, resaltan lo que llaman 'multilearning' que consiste en la adquisición de conocimientos multidisciplinarios que dan a los integrantes del equipo una perspectiva más amplia del entorno y una mejor comprensión de las actividades en las que no están especializados. Este aprendizaje tiene dos ejes: los diferentes niveles de una organización (individual, grupal y corporativo) y las diferentes funciones que los miembros del equipo desempeñan. Los ingenieros aprenden algo de mercadotecnia y diseño y los expertos del mercado aprenden sobre producción. Otro de los beneficios de la conformación de este tipo de equipos es la transferencia de lo aprendido, lo que mejora el desarrollo de toda la organización y favorece la acumulación del conocimiento y su difusión de los individuos a los equipos.
Por supuesto, los autores señalan las situaciones en donde el enfoque no es aplicable, por ejemplo en proyectos que, por su tamaño, no sean susceptibles de ser atacados por equipos pequeños.
En fin, que resultó una lectura interesante donde, por ejemplo, se menciona que en 3M se incentivaba a que los ingenieros dedicaran 15% de su tiempo de trabajo "to pursuing their 'dream'" varios años antes de que se convirtiera en lugar común decir que en Google los desarrolladores dedican parte de su tiempo a proyectos no oficiales.
No hay comentarios:
Publicar un comentario